Messages in this thread | | | Date | Mon, 11 Oct 2021 15:06:11 +0000 | From | Sean Christopherson <> | Subject | Re: [PATCH v8 06/11] x86/traps: Add #VE support for TDX guest |
| |
On Sat, Oct 09, 2021, Lai Jiangshan wrote: > On Tue, Oct 5, 2021 at 10:54 AM Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > > > > > The entry paths do not access TD-shared memory, MMIO regions or use > > those specific MSRs, instructions, CPUID leaves that might generate #VE. > > In addition, all interrupts including NMIs are blocked by the hardware > > starting with #VE delivery until TDGETVEINFO is called. This eliminates > > the chance of a #VE during the syscall gap or paranoid entry paths and > > simplifies #VE handling.
Minor clarification: it eliminates the chance of a #VE during the syscall gap _if the VMM is benign_. If the VMM is malicious, it can unmap and remap the syscall page to induce an EPT Violation #VE due to the page not being accepted.
> Hello > > If the reason is applied to #VE, I think it can be applied to SVM-ES's > #VC too. (I wish the entry code for #VC to be simplified since I'm > moving some the asm entry code to C code) > > And I'm sorry I haven't read all the emails. > Has the question asked by Andy Lutomirski been answered in any emails? > > https://lore.kernel.org/lkml/CALCETrU9XypKbj-TrXLB3CPW6=MZ__5ifLz0ckbB=c=Myegn9Q@mail.gmail.com/
This question?
Can the hypervisor cause an already-accepted secure-EPT page to transition to the unaccepted state?
Yep. I wrote the above before following the link, I should have guessed which question it was :-)
IIRC, the proposed middle ground was to add a TDCALL and/or TDPARAMS setting that would allow the guest to opt-out of EPT Violation #VE due to page not accepted, and instead terminate the VM on such a condition. The caveat is that that would require the kernel to never take an "page not accepted #VE" when doing lazy page acceptance, but that was deemed doable.
That also raises the question of whether Andy's NAK applies to SEV-SNP without support for "Enhanced SYSCALL Behavior"[*], otherwise SEV-SNP has the same "#VC in syscall gap" attack.
[*] https://www.amd.com/system/files/TechDocs/57115.pdf
| |