Messages in this thread | | | Date | Tue, 1 Nov 2022 01:10:11 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCH 1/2] x86/tdx: Extract GET_INFO call from get_cc_mask() |
| |
On Mon, Oct 31, 2022 at 12:44:15PM -0700, Dave Hansen wrote: > On 10/31/22 12:27, Andi Kleen wrote: > >> Moving panic() after earlyprintk working is not good idea as it exposes > >> kernel more: by the time we already have full #VE handler. > > > > It should be fine to move since there is no user land at this point (the > > attack requires user land) > > Maybe I'm misunderstanding the exposure. A normal MMIO #VE goes > something like this: > > 1. %rax points to some MMIO > 2. Kernel executes: mov (%rax),%rbx, trying to read MMIO > 3. #VE handler is triggered > 4. Handler emulates the 'mov' with instruction decoding > 5. Handler asks the VMM what the value of %rax should be > 6. Handler puts VMM value in %rax > 7. Return from #VE > > I think the attack scenario subverts a normal MMIO to the following > (changes from the normal flow are marked with *): > > *1. %rax points to some private kernel memory, VMM removes > Secure-EPT entry for that memory. > 2. Kernel executes: mov (%rax),%rbx as part of normal kernel > execution, not an MMIO read. > 3. #VE handler is triggered, assuming a MMIO read > 4. Handler emulates the 'mov' with instruction decoding > 5. Handler asks the VMM what the value of %rax should be > *6. Handler puts (malicious) VMM value in %rax > 7. Return from #VE > *8. Now the guest kernel is running with an attacker-controlled > %rax > > This effectively gives the attacker the ability to override the contents > of a memory read. > > Am I misunderstanding the attack scenario? I don't see guest userspace > needing to be involved at all.
Looks correct to me.
I think Andi refers to attack against syscall gap that also addressed by the patch.
-- Kiryl Shutsemau / Kirill A. Shutemov
| |