[Rust-VMM] [Stratos-dev] Xen Rust VirtIO demos work breakdown for Project Stratos

[Oleksandr Tyshchenko]

On Tue, Sep 28, 2021 at 9:26 AM Stefano Stabellini <sstabellini at kernel.org>
wrote:

Hi Stefano, all

[Sorry for the possible format issues]


On Mon, 27 Sep 2021, Christopher Clark wrote:
> > On Mon, Sep 27, 2021 at 3:06 AM Alex Bennée via Stratos-dev <
> stratos-dev at op-lists.linaro.org> wrote:
> >
> >       Marek Marczykowski-Górecki <marmarek at invisiblethingslab.com>
> writes:
> >
> >       > [[PGP Signed Part:Undecided]]
> >       > On Fri, Sep 24, 2021 at 05:02:46PM +0100, Alex Bennée wrote:
> >       >> Hi,
> >       >
> >       > Hi,
> >       >
> >       >> 2.1 Stable ABI for foreignmemory mapping to non-dom0 ([STR-57])
> >       >> ───────────────────────────────────────────────────────────────
> >       >>
> >       >>   Currently the foreign memory mapping support only works for
> dom0 due
> >       >>   to reference counting issues. If we are to support backends
> running in
> >       >>   their own domains this will need to get fixed.
> >       >>
> >       >>   Estimate: 8w
> >       >>
> >       >>
> >       >> [STR-57] <https://linaro.atlassian.net/browse/STR-57>
> >       >
> >       > I'm pretty sure it was discussed before, but I can't find
> relevant
> >       > (part of) thread right now: does your model assumes the backend
> (running
> >       > outside of dom0) will gain ability to map (or access in other
> way)
> >       > _arbitrary_ memory page of a frontend domain? Or worse: any
> domain?
> >
> >       The aim is for some DomU's to host backends for other DomU's
> instead of
> >       all backends being in Dom0. Those backend DomU's would have to be
> >       considered trusted because as you say the default memory model of
> VirtIO
> >       is to have full access to the frontend domains memory map.
> >
> >
> > I share Marek's concern. I believe that there are Xen-based systems that
> will want to run guests using VirtIO devices without extending
> > this level of trust to the backend domains.
>
> From a safety perspective, it would be challenging to deploy a system
> with privileged backends. From a safety perspective, it would be a lot
> easier if the backend were unprivileged.
>
> This is one of those times where safety and security requirements are
> actually aligned.


Well, the foreign memory mapping has one advantage in the context of Virtio
use-case
which is that Virtio infrastructure in Guest doesn't require any
modifications to run on top Xen.
The only issue with foreign memory here is that Guest memory actually
mapped without its agreement
which doesn't perfectly fit into the security model. (although there is one
more issue with XSA-300,
but I think it will go away sooner or later, at least there are some
attempts to eliminate it).
While the ability to map any part of Guest memory is not an issue for the
backend running in Dom0
(which we usually trust), this will certainly violate Xen security model if
we want to run it in other
domain, so I completely agree with the existing concern.

It was discussed before [1], but I couldn't find any decisions regarding
that. As I understand,
the one of the possible ideas is to have some entity in Xen (PV
IOMMU/virtio-iommu/whatever)
that works in protection mode, so it denies all foreign mapping requests
from the backend running in DomU
by default and only allows requests with mapping which were *implicitly*
granted by the Guest before.
For example, Xen could be informed which MMIOs hold the queue PFN and
notify registers
(as it traps the accesses to these registers anyway) and could
theoretically parse the frontend request
and retrieve descriptors to make a decision which GFNs are actually
*allowed*.

I can't say for sure (sorry not familiar enough with the topic), but
implementing the virtio-iommu device
in Xen we could probably avoid Guest modifications at all. Of course, for
this to work
the Virtio infrastructure in Guest should use DMA API as mentioned in [1].

Would the “restricted foreign mapping” solution retain the Xen security
model and be accepted
by the Xen community? I wonder, has someone already looked in this
direction, are there any
pitfalls here or is this even feasible?

[1]
https://lore.kernel.org/xen-devel/464e91ec-2b53-2338-43c7-a018087fc7f6@arm.com/



-- 
Regards,

Oleksandr Tyshchenko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendev.org/pipermail/rust-vmm/attachments/20210928/b2eb5bfb/attachment.htm>