Message-ID: <1508519207.29329.67.camel@bitdefender.com>
Date:   Fri, 20 Oct 2017 20:06:47 +0300
From:   Mihai Donțu <mdontu@...defender.com>
To:     Yi Zhang <yi.z.zhang@...ux.intel.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        kvm list <kvm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection
 Support.

On Fri, 2017-10-20 at 16:47 +0800, Yi Zhang wrote:
> On 2017-10-18 at 17:13:18 +0300, Mihai Donțu wrote:
> > On Wed, 2017-10-18 at 11:35 +0200, Paolo Bonzini wrote:
> > > On 16/10/2017 02:08, Yi Zhang wrote:
> > > > > And the introspection facility by Mihai uses a completely
> > > > > different API for the introspector, based on sockets rather than ioctls.
> > > > > So I'm not sure this is the right API at all.
> > > > 
> > > > Currently,  We only block the write access, As far as I know an example,
> > > > we now using it in a security daemon:
> > > 
> > > Understood.  However, I think QEMU is the wrong place to set this up.
> > > 
> > > If the kernel wants to protect _itself_, it should use a hypercall.  If
> > > an introspector appliance wants to protect the guest kernel, it should
> > > use the socket that connects it to the hypervisor.
> > 
> > We have been looking at using SPP for VMI for quite some time. If a
> > guest kernel will be able to control it (can it do so with EPT?) then
> > it would be useful a simple switch that disables this ability, as an
> > introspector wouldn't want the guest is trying to protect to interfere
> > with it.
> 
> Could you mind to provide more information and history about your
> investigation?

We are using VMI to secure certain parts of a guest kernel in memory
(like prevent a certain data structure from being overriten). However,
it sometimes happens for that part to be placed in the same page with
other data, of no interest to us, that gets written frequently. This
makes using the EPT problematic (a 4k page is just too big and
generates too many violations). However, SPP (with its 128 bytes
granularity) is ideal here.

> > Also, if Intel doesn't have a specific use case for it that requires
> > separate access to SPP control, then maybe we can fold it into the VMI 
> > API we are working on?
> 
> That's totally Excellent as we really don't have a specific user case at
> this time.

OK. We will spend some time thinking at a proper way of exposing SPP
with the VMI API.

For example, we now work on implementing something similar to this:

  kvm_set_page_access( struct kvm *kvm, gfn_t gfn, u8 access );

The simplest approach would be to add something like:

  kvm_set_sub_page_access( struct kvm *kvm, gfn_t gfn, u32 mask );

where every bit from 'mask' indicates the write-allowed state of every
128-byte subpage.

> BTW, I have already submit the SPP implementation draft in Xen side.
> when you got some time, you can take a look at if that match your
> requirement.

I believe my colleague Răzvan Cojocaru has already commented on that
patch set. :-)

> > > > Consider It has a server which launching in the host user-space, and a
> > > > client launching in the guest kernel. Yes, they are communicate with
> > > > sockets. The guest kernel wanna protect a special area to prevent all
> > > > the process including the kernel itself modify this area. the client
> > > > could send the guest physical address via the security socket to server
> > > > side, and server would update these protection into KVM. Thus, all the
> > > > write access in a guest specific area will be blocked.
> > > > 
> > > > Now the implementation only on the second half(maybe third ^_^) of this
> > > > example: 'How kvm set the write-protect into a specific GFN?'
> > > > 
> > > > Maybe a user space tools which use ioctl let kvm mmu update the
> > > > write-protection is a better choice.

-- 
Mihai Donțu

Powered by blists - more mailing lists