Messages in this thread | | | Date | Mon, 7 Nov 2022 05:31:03 -0800 | Subject | Re: [PATCH 2/2] x86/tdx: Do not allow #VE due to EPT violation on the private memory | From | Dave Hansen <> |
| |
On 11/6/22 21:10, Guorui Yu wrote: >> Without ATTR_SEPT_VE_DISABLE, a #VE can occur on basically any >> instruction. We call those kinds of exceptions "paranoid entry" points. >> They need special handling like the NMI or #MC handlers. >> >> I'd be happy to look at a patch that does the MMIO path check *and* >> turns the #VE handler into a robust entry point. >> >> Bonus points if you can do ~5 lines of C like the approach in this >> thread. > > Yes, there is a fix to satify your requirement and get the bouns points 😄 > > Please refer to > https://github.com/intel/tdx/commit/f045b0d52a5f7d8bf66cd4410307d05a90523f10 > > case EXIT_REASON_EPT_VIOLATION: > + if (!(ve->gpa & tdx_shared_mask())) { > + panic("#VE due to access to unaccepted memory. " > + "GPA: %#llx\n", ve->gpa); > + } > + > /* original from Kirill and Kuppuswamy */ > > It's already there, but it just didn't get into the main branch.
Could you explain how that prevents the #VE from occurring in the "syscall gap" or in a place where the kernel is running with the user GSBASE value?
It doesn't as far as I can tell. You need the SEPT_VE_DISABLE check for that.
| |