lkml.org 
[lkml]   [2022]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-10-31 23:10    [W:0.075 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site