[PATCH RFC V11 0/5] Basic guest memory introspection support

[PATCH RFC V11 0/5] Basic guest memory introspection support

[Razvan Cojocaru]

I apologize, I've sent this as a duplicate V10.
Here it is, resent (correctly) as V11. Sorry.

As stated originally, we had to modify Xen in order to be able to detect
rootkits in HVM guests, in a way that allows an application that runs in
dom0 (or a similarly privileged domain) to control what the guest is
allowed to do once a threat is detected. This has been done over the
mem_event mechanism.

To this end, we needed to:

1. Be able to execute the current instruction without allowing it to
write to memory. This is done based on new mem_event response
fields sent from the controlling application.

2. Have the guest as responsive as possible amid all the processing. So
we had to cache some information with each mem_event sent.

3. Not allow the hypervisor to disable sending information about
interesting MSR events.

4. Add an additional mem_event type, namely a VMCALL event - in order to
do its work, our application occasionally triggers VMCALLs in the guest
(not included in the current series, but included in the initial RFC
series).

5. Add an additional libxc function that allows triggering page faults
in the guest.

Changes since V9:
 - The "xen, libxc: Request page fault injection via libxc" has
   been reworked to extend HVMOP_inject_trap instead of a new
   libxc hypercall.

Patches:

xen: Handle resumed instruction based on previous mem_event reply
xen, libxc: Request page fault injection via libxc
xen, libxc: Force-enable relevant MSR events
xen: Optimize introspection access to guest state
xen: Emulate with no writes


Thanks,
Razvan Cojocaru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH RFC V11 0/5] Basic guest memory introspection support

[Konrad Rzeszutek Wilk]

On Tue, Sep 02, 2014 at 06:37:09PM +0300, Razvan Cojocaru wrote:
> I apologize, I've sent this as a duplicate V10.
> Here it is, resent (correctly) as V11. Sorry.

You also have the RFC part on the patchset. Is that intentional?
Some maintainers (looks at himself) ignore (well, put it in the
'todo pile' to be exact) patches like that until they are
more mature (non-RFC) and then they will review them.

I think the RFC part of the patches has been rubbed up as
the design is pretty baked?

> 
> As stated originally, we had to modify Xen in order to be able to detect
> rootkits in HVM guests, in a way that allows an application that runs in
> dom0 (or a similarly privileged domain) to control what the guest is
> allowed to do once a threat is detected. This has been done over the
> mem_event mechanism.
> 
> To this end, we needed to:
> 
> 1. Be able to execute the current instruction without allowing it to
> write to memory. This is done based on new mem_event response
> fields sent from the controlling application.
> 
> 2. Have the guest as responsive as possible amid all the processing. So
> we had to cache some information with each mem_event sent.
> 
> 3. Not allow the hypervisor to disable sending information about
> interesting MSR events.
> 
> 4. Add an additional mem_event type, namely a VMCALL event - in order to
> do its work, our application occasionally triggers VMCALLs in the guest
> (not included in the current series, but included in the initial RFC
> series).
> 
> 5. Add an additional libxc function that allows triggering page faults
> in the guest.
> 
> Changes since V9:
>  - The "xen, libxc: Request page fault injection via libxc" has
>    been reworked to extend HVMOP_inject_trap instead of a new
>    libxc hypercall.
> 
> Patches:
> 
> xen: Handle resumed instruction based on previous mem_event reply
> xen, libxc: Request page fault injection via libxc
> xen, libxc: Force-enable relevant MSR events
> xen: Optimize introspection access to guest state
> xen: Emulate with no writes
> 
> 
> Thanks,
> Razvan Cojocaru
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PATCH RFC V11 0/5] Basic guest memory introspection support

[Razvan Cojocaru]

On 09/02/14 21:53, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 02, 2014 at 06:37:09PM +0300, Razvan Cojocaru wrote:
>> I apologize, I've sent this as a duplicate V10.
>> Here it is, resent (correctly) as V11. Sorry.
> 
> You also have the RFC part on the patchset. Is that intentional?
> Some maintainers (looks at himself) ignore (well, put it in the
> 'todo pile' to be exact) patches like that until they are
> more mature (non-RFC) and then they will review them.
> 
> I think the RFC part of the patches has been rubbed up as
> the design is pretty baked?

Thanks for the comment, I was actually going to ask about that. I
thought I'd keep the "RFC" in the title until I get Acks for all the
patches, and then switch the prefix to "PATCH", but I'm not sure what
the etiquette is in these cases.

Also, in this particular case I've reworked the 4/5 patch (the page
fault injection patch), so I thought it might be proper to keep the
"RFC" part for the whole series.

I'll switch to "PATCH" for the next series.


Thanks,
Razvan Cojocaru

Re: [PATCH RFC V11 0/5] Basic guest memory introspection support

[Konrad Rzeszutek Wilk]

On Tue, Sep 02, 2014 at 10:13:15PM +0300, Razvan Cojocaru wrote:
> On 09/02/14 21:53, Konrad Rzeszutek Wilk wrote:
> > On Tue, Sep 02, 2014 at 06:37:09PM +0300, Razvan Cojocaru wrote:
> >> I apologize, I've sent this as a duplicate V10.
> >> Here it is, resent (correctly) as V11. Sorry.
> > 
> > You also have the RFC part on the patchset. Is that intentional?
> > Some maintainers (looks at himself) ignore (well, put it in the
> > 'todo pile' to be exact) patches like that until they are
> > more mature (non-RFC) and then they will review them.
> > 
> > I think the RFC part of the patches has been rubbed up as
> > the design is pretty baked?
> 
> Thanks for the comment, I was actually going to ask about that. I
> thought I'd keep the "RFC" in the title until I get Acks for all the
> patches, and then switch the prefix to "PATCH", but I'm not sure what
> the etiquette is in these cases.

It varies with maintainers. But with the amount of emails we get I think
most folks try to use the 'Del' button (or Ctrl-D) as much as possible.

> 
> Also, in this particular case I've reworked the 4/5 patch (the page
> fault injection patch), so I thought it might be proper to keep the
> "RFC" part for the whole series.
> 
> I'll switch to "PATCH" for the next series.

Thank you.

Also pls double-check that you have all the toolstack maintainers on
the 'To' so they can review the patches (I think those ones need
eyeballs as some of the hypervisor ones have been Acked by Jan).

Perhaps even mention in the cover letter what has been reviewed/changed
/needs attention to make it easier for maintainers to go right
ahead to the meat?

See http://lists.xen.org/archives/html/xen-devel/2013-06/msg00357.html
for an example.

> 
> 
> Thanks,
> Razvan Cojocaru
>