On 2/2/21 3:56 PM, Sean Christopherson wrote: >> 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 SDM doesn't define the behavior well enough. I'll try to get that fixed. But, there is some documentation of the abort page semantics: > https://download.01.org/intel-sgx/sgx-linux/2.10/docs/Intel_SGX_Developer_Reference_Linux_2.10_Open_Source.pdf Basically, writes get dropped and reads get all 1's on all the implementations in the wild. I actually would have much rather gotten a fault, but oh well. It sounds like we need to at least modify KVM to make sure not to map and access EPC addresses. We might even want to add some VM_WARN_ON()s in the code that creates kernel mappings to catch these mappings if they happen anywhere else. EPC mappings seem like (silent) trouble waiting to happen.
