On Tue, Feb 02, 2021, Dave Hansen wrote: > On 2/2/21 2:33 PM, Sean Christopherson wrote: > >> Do we need to restrict normal KVM host kernel access to EPC (i.e. via > >> __kvm_map_gfn() and friends)? As best I can tell the exact behavior of > >> this kind of access is undefined. The concern would be if any HW ever > >> treated it as an error, the guest could subject the host kernel to it. > >> Is it worth a check in those? > > I don't think so. The SDM does state that the exact behavior is uArch specific, > > but it also explicitly states that the access will be altered, which IMO doesn't > > leave any wiggle room for a future CPU to fault instead of using some form of > > abort semantics. > > > > Attempts to execute, read, or write to linear addresses mapped to EPC pages > > when not inside an enclave will result in the processor altering the access to > > preserve the confidentiality and integrity of the enclave. The exact behavior > > may be different between implementations. > > I seem to remember much stronger language in the SDM about this. I've > always thought of SGX as a big unrecoverable machine-check party waiting > to happen. > > I'll ask around internally at Intel and see what folks say. Basically, > should we be afraid of a big bad EPC access? If bad accesses to the EPC can cause machine checks, then EPC should never be mapped into userspace, i.e. the SGX driver should never have been merged. The SGX architecture is predicated on using isolation to protect enclaves from software, not by poisoning memory, a la TDX. E.g. SGX on ICX's MKTME wouldn't be a thing if that weren't the case. A physical attack on DRAM can trigger #MC on systems that use the MEE as opposed to MKTME, but that obviously doesn't require a guest to coerce KVM into accessing the EPC.
