Re: [RFC PATCH v3 00/27] KVM SGX virtualization support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2021-02-03 at 16:28 -0800, Sean Christopherson wrote:
> On Thu, Feb 04, 2021, Kai Huang wrote:
> > 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?
> 
> See kvm_vcpu_map() -> __kvm_map_gfn(), which blindly uses memremap() when the
> resulting pfn isn't a "valid" pfn.  KVM doesn't need access to an EPC memslot,
> we're talking the case where a malicious userspace/guest hands KVM a GPA that
> resolves to the EPC.  E.g. nested VM-Enter with the L1->L2 MSR bitmap pointing
> at EPC.  L0 KVM will intercept VM-Enter and then read L1's bitmap to merge it's
> desires with L0 KVM's requirements.  That read will hit the EPC, and thankfully
> for KVM, return garbage.

Right. I missed __kvm_map_gfn(). 

I am not quite sure returning all ones can be treated as garbage, since one can means
true for a boolean, or one bit in bitmap as you said. But since this only happens
when guest/userspace is malicious, so causing misbehavior to the guest is fine? Do we
see any security risk here?

And I also agree that denying memremap() for EPC is desirable. But I am not sure
whether this should be addressed before KVM SGX series, or KVM SGX series should take
care of it.





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux