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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 21 May 2013, Tim Deegan wrote:
> 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.

While I agree with you, as a matter of fact the vast majority of Xen
installations today do not use driver domains. That didn't stop them
from enjoying Xen so far. Moreover the frontend/backend interface
remains narrow and difficult to exploit, it's not a fully emulated
interface (AHCI / virtio). The backend is still protected from the
frontend. Having the backend running non-privileged is a great bonus
and certainly required on a product that allows the user to install
third party driver domains. However if the driver domains are "trusted"
then I think they can also be trusted with a full memory map. After all
it has been the case for all XenServer, OVM and SLES releases so far
AFAIK.

An hypothetic future Xen release could offer both increased security
(driver domains) or increased IO performances (backends with a full
physical memory map) and give the user a choice between the two. I am
pretty sure that a non-negligible amount of people would make the
conscious choice to go for the performance option.
Why should we be the ones to force security down their throats?
After all it's all about what the users want from the project.

Obviously in an ideal world we would be able to offer both at the same
time, and maybe George's proposal is exactly what is going to achieve
that. But I was describing the case that requires us to make a choice.

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