Re: [PATCH 13/25] argo: implement the register op

From: Tamas K Lengyel <tamas@tklengyel.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: "Julien Grall" <julien.grall@arm.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wei.liu2@citrix.com>,
	"James McKenzie" <voreekf@madingley.org>,
	ross.philipson@gmail.com, "Jason Andryuk" <jandryuk@gmail.com>,
	"Daniel Smith" <dpsmith@apertussolutions.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <royger@freebsd.org>,
	"Tim Deegan" <tim@xen.org>,
	"Christopher Clark" <christopher.w.clark@gmail.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Rich Persaud" <persaur@gmail.com>,
	"Paul Durrant" <paul.durrant@citrix.com>,
	"Jan Beulich" <JBeulich@suse.com>,
	"eric chanudet" <eric.chanudet@gmail.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 13/25] argo: implement the register op
Date: Wed, 9 Jan 2019 09:50:12 -0700	[thread overview]
Message-ID: <CABfawhnA1-7DjCQTY_7Ddy32nB4wDQZV35oSm567kt+tmnDkCQ@mail.gmail.com> (raw)
In-Reply-To: <d71b17a9-0ff9-5c48-db96-33bef501d3e0@bitdefender.com>

On Wed, Jan 9, 2019 at 9:48 AM Razvan Cojocaru
<rcojocaru@bitdefender.com> wrote:
>
> On 1/9/19 6:34 PM, Roger Pau Monné wrote:
> >>>>> Maybe this is use-case is different, but how does introspection handle
> >>>>> accesses to the shared info page or the runstate info for example?
> >>>>>
> >>>>> I would consider argo to be the same in this regard.
> >>>>
> >>>> Not exactly: The shared info page is special in any event. For
> >>>> runstate info (and alike - there's also struct vcpu_time_info)
> >>>> I'd question correctness of the current handling. If that's
> >>>> wrong already, I'd prefer if the issue wasn't spread.
> >>>
> >>> There are also grants, which when used together with another guest on
> >>> the same host could allow to bypass introspection AFAICT? (unless
> >>> there's some policy applied that limit grant sharing to trusted
> >>> domains)
> >>>
> >>> TBH I'm not sure how to handle hypoervisor accesses with
> >>> introspection.  My knowledge of introspection is fairly limited, but
> >>> it pauses the guest and sends a notification to an in guest agent. I'm
> >>> not sure this is applicable to hypervisor writes, since it's not
> >>> possible to pause hypervisor execution and wait for a response from a
> >>> guest agent.
> >>>
> >>
> >> Introspection applications only care about memory accesses performed
> >> by the guest. Hypervisor accesses to monitored pages are not included
> >> when monitoring - it is actually a feature when using the emulator in
> >> Xen to continue guest execution because the hypervisor ignores EPT
> >> memory permissions that trip the guest for introspection. So having
> >> the hypervisor access memory or a grant-shared page being accessed in
> >> another domain are not a problem for introspection.
> >
> > Can't then two guests running on the same host be able to completely
> > bypass introspection? I guess you prevent this by limiting to which
> > guests pages can be shared?
>
> Would these two guests be HVM guests? Introspection only works for HVM
> guests. I'm not sure I follow your scenario though. How would these
> guests collaborate to escape introspection via grants?

If there are two domains acting maliciously in concert to bypass
monitoring of memory writes they could achieve that with grants, yes.
Say a write-monitored page is grant-shared to another domain, which
then does the write on behalf of the first. I wouldn't say that's
"completely bypassing introspection" though, there are many types of
events that can be monitored, write-accesses are only one. I'm not
aware of any mechanism that can be used to limit which pages can be
shared but you can use XSM to restrict which domains can share pages
to begin with. That's normally enough.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel