On Wed, 2021-02-03 at 15:37 -0800, Dave Hansen wrote: > On 2/3/21 3:32 PM, Sean Christopherson wrote: > > > > > Yeah, special casing KVM is almost always the wrong thing to do. > > > > > Anything that KVM can do, other subsystems will do as well. > > > > Agreed. Thwarting ioremap itself seems like the right way to go. > > > This sounds irrelevant to KVM SGX, thus I won't include it to KVM SGX series. > > I would say it's relevant, but a pre-existing bug. Same net effect on what's > > needed for this series.. > > > > I say it's a pre-existing bug, because I'm pretty sure KVM can be coerced into > > accessing the EPC by handing KVM a memslot that's backed by an enclave that was > > created by host userspace (via /dev/sgx_enclave). > > Dang, you beat me to it. I was composing another email that said the > exact same thing. > > I guess we need to take a closer look at the KVM fallout from this. > It's a few spots where it KVM knew it might be consuming garbage. It > just get extra weird stinky garbage now. I don't quite understand how KVM will need to access EPC memslot. It is *guest*, but not KVM, who can read EPC from non-enclave. And if I understand correctly, there will be no place for KVM to use kernel address of EPC to access it. To KVM, there's no difference, whether EPC backend is from /dev/sgx_enclave, or /dev/sgx_vepc. And we really cannot prevent guest from doing anything. So how memremap() of EPC section is related to KVM SGX? For instance, the implementation of this series needs to be modified due to this?
