Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
depriv)"):
> On 08.08.16 at 15:46, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > So would it therefore be OK to introduce the enhanced security promise
> > - the lack of `class 2' bugs - for HVMCTL from the beginning ?
> 
> I think so, since ...
> 
> > This would involve a small amount of extra thought for each invididual
> > hypercall, just to check that the assumptions we are relying on (as
> > you put them above) are not violated.
> 
> ... this looks to be a manageable amount of code auditing (albeit
> I'd like to see whether someone else can perhaps come up with
> some potential, more realistic kind of bug that could fall into class
> 2 before volunteering to make an attempt at doing such an audit).

Right.

Let me try to think of some examples.  Thinking `aloud':

The real problem comes if a DMOP talks about the calling domain's
resources or namespaces, implicitly or explicitly.

An example of an explicit reference to the calling domain's resources
is the references to memory space in the calling domain (vaddrs).  We
have already had an extensive discussion of that...

Another example would be a DMOP that takes (or returns) an event
channel number in the calling domain.  This would be a problem because
there would be nothing to stop qemu from messing about with evtchns
which dom0 is using for other purposes (or conversely, there would be
no way for the dom0 evtchn driver to know about the returned evtchn
number and allow qemu to receive it).

Another might be a DMOP that implicitly grants the target domain some
of the calling domain's scheduling priority.  (I realise this is quite
implausible from a scheduling API POV, but it gives an idea.)

Another example is that of course VCPU pool management and VCPU-PCPU
pinning must not be available via DMOP.

(I write `qemu' here for brevity and clarity, but really I mean any
DMOP caller which is supposed to be privileged for the target domain
but not generally privileged.)

Does that help at all ?

Thanks,
Ian.

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