Re: [Xen-devel] [Hackathon minutes] PV network improvements

[Tim Deegan <tim@xxxxxxx>]

At 19:31 +0100 on 20 May (1369078279), Wei Liu wrote:
> On Mon, May 20, 2013 at 03:08:05PM +0100, Stefano Stabellini wrote:
> > J) Map the whole physical memory of the machine in dom0
> > If mapping/unmapping or copying slows us down, could we just keep the
> > whole physical memory of the machine mapped in dom0 (with corresponding
> > IOMMU entries)?
> > At that point the frontend could just pass mfn numbers to the backend,
> > and the backend would already have them mapped.
> > >From a security perspective it doesn't change anything when running
> > the backend in dom0, because dom0 is already capable of mapping random
> > pages of any guests. QEMU instances do that all the time.
> > But it would take away one of the benefits of deploying driver domains:
> > we wouldn't be able to run the backends at a lower privilege level.
> > However it might still be worth considering as an option? The backend is
> > still trusted and protected from the frontend, but the frontend wouldn't
> > be protected from the backend.
> > 
> 
> I think Dom0 mapping all machine memory is a good starting point.

I _strongly_ disagree.  The opportunity for disaggregation and reduction
of privilege in backends is probably Xen's biggest techical advantage
and we should not be taking any backward steps there.

> As for the driver domain, can we not have a driver domain mapped all
> of its target's machine memory? What's the security implication here?

If, say, a network driver domain is compromised it's the difference
between intercepting network traffic and total control of the OS.
It's probably worth reading some of the Xen papers about this stuff,
if you haven't already:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.6391
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.229.3708

Tim.

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