From: "Mihai Donțu" <mdontu@bitdefender.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
"Jim Mattson" <jmattson@google.com>,
"kvm list" <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Alex Williamson" <alex.williamson@redhat.com>
Subject: Re: [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support.
Date: Wed, 18 Oct 2017 17:13:18 +0300 [thread overview]
Message-ID: <1508335998.3230.118.camel@bitdefender.com> (raw)
In-Reply-To: <96efaece-306c-cde3-06d6-553505612136@redhat.com>
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.
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?
Thanks,
> > 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
next prev parent reply other threads:[~2017-10-18 14:13 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 23:11 [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support Zhang Yi
2017-10-13 16:57 ` Jim Mattson
2017-10-13 21:13 ` Paolo Bonzini
2017-10-16 0:08 ` Yi Zhang
2017-10-18 9:35 ` Paolo Bonzini
2017-10-18 14:07 ` Yi Zhang
2017-10-19 11:57 ` Paolo Bonzini
2017-10-20 8:51 ` Yi Zhang
2017-10-18 14:13 ` Mihai Donțu [this message]
2017-10-20 8:47 ` Yi Zhang
2017-10-20 17:06 ` Mihai Donțu
2017-10-24 7:52 ` Yi Zhang
2017-10-16 0:01 ` Yi Zhang
2017-10-13 23:12 ` [PATCH RFC 01/10] KVM: VMX: Added EPT Subpage Protection Documentation Zhang Yi
2017-10-13 23:12 ` [PATCH RFC 02/10] x86/cpufeature: Add intel Sub-Page Protection to CPU features Zhang Yi
2017-10-13 23:13 ` [PATCH RFC 03/10] KVM: VMX: Added VMX SPP feature flags and VM-Execution Controls Zhang Yi
2017-10-13 23:13 ` [PATCH RFC 04/10] KVM: VMX: Introduce the SPPTP and SPP page table Zhang Yi
2017-10-13 23:14 ` [PATCH RFC 05/10] KVM: VMX: Introduce SPP-Induced vm exit and it's handle Zhang Yi
2017-10-13 23:14 ` [PATCH RFC 06/10] KVM: VMX: Added handle of SPP write protection fault Zhang Yi
2017-10-13 23:14 ` [PATCH RFC 07/10] KVM: VMX: Introduce ioctls to set/get Sub-Page Write Protection Zhang Yi
2017-10-13 23:14 ` [PATCH RFC 08/10] KVM: VMX: Update the EPT leaf entry indicated with the SPP enable bit Zhang Yi
2017-10-13 23:14 ` [PATCH RFC 09/10] KVM: VMX: Added setup spp page structure Zhang Yi
2017-10-13 23:16 ` [PATCH RFC 10/10] KVM: VMX: implement setup SPP page structure in spp miss Zhang Yi
2017-10-18 7:09 ` [PATCH RFC 00/10] Intel EPT-Based Sub-page Write Protection Support Christoph Hellwig
2017-10-18 14:02 ` Yi Zhang
2017-11-04 0:12 ` Yi Zhang
2017-11-04 16:54 ` Paolo Bonzini
2017-11-10 15:39 ` Paolo Bonzini
2017-11-13 10:37 ` Yi Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1508335998.3230.118.camel@bitdefender.com \
--to=mdontu@bitdefender.com \
--cc=alex.williamson@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.