<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 9:26 AM Stefano Stabellini <<a href="mailto:sstabellini@kernel.org">sstabellini@kernel.org</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><br></div><div class="gmail_attr">Hi Stefano, all</div><div class="gmail_attr"><br></div><div class="gmail_attr">[Sorry for the possible format issues]</div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 27 Sep 2021, Christopher Clark wrote:<br>
> On Mon, Sep 27, 2021 at 3:06 AM Alex Bennée via Stratos-dev <<a href="mailto:stratos-dev@op-lists.linaro.org" target="_blank">stratos-dev@op-lists.linaro.org</a>> wrote:<br>
> <br>
> Marek Marczykowski-Górecki <<a href="mailto:marmarek@invisiblethingslab.com" target="_blank">marmarek@invisiblethingslab.com</a>> writes:<br>
> <br>
> > [[PGP Signed Part:Undecided]]<br>
> > On Fri, Sep 24, 2021 at 05:02:46PM +0100, Alex Bennée wrote:<br>
> >> Hi,<br>
> ><br>
> > Hi,<br>
> ><br>
> >> 2.1 Stable ABI for foreignmemory mapping to non-dom0 ([STR-57])<br>
> >> ───────────────────────────────────────────────────────────────<br>
> >><br>
> >> Currently the foreign memory mapping support only works for dom0 due<br>
> >> to reference counting issues. If we are to support backends running in<br>
> >> their own domains this will need to get fixed.<br>
> >><br>
> >> Estimate: 8w<br>
> >><br>
> >><br>
> >> [STR-57] <<a href="https://linaro.atlassian.net/browse/STR-57" rel="noreferrer" target="_blank">https://linaro.atlassian.net/browse/STR-57</a>><br>
> ><br>
> > I'm pretty sure it was discussed before, but I can't find relevant<br>
> > (part of) thread right now: does your model assumes the backend (running<br>
> > outside of dom0) will gain ability to map (or access in other way)<br>
> > _arbitrary_ memory page of a frontend domain? Or worse: any domain?<br>
> <br>
> The aim is for some DomU's to host backends for other DomU's instead of<br>
> all backends being in Dom0. Those backend DomU's would have to be<br>
> considered trusted because as you say the default memory model of VirtIO<br>
> is to have full access to the frontend domains memory map.<br>
> <br>
> <br>
> I share Marek's concern. I believe that there are Xen-based systems that will want to run guests using VirtIO devices without extending<br>
> this level of trust to the backend domains.<br>
<br>
>From a safety perspective, it would be challenging to deploy a system<br>
with privileged backends. From a safety perspective, it would be a lot<br>
easier if the backend were unprivileged.<br>
<br>
This is one of those times where safety and security requirements are<br>
actually aligned.</blockquote><div><br></div><div>Well, the foreign memory mapping has one advantage in the context of Virtio use-case<br>which is that Virtio infrastructure in Guest doesn't require any modifications to run on top Xen. <br>The only issue with foreign memory here is that Guest memory actually mapped without its agreement<br>which doesn't perfectly fit into the security model. (although there is one more issue with XSA-300,<br>but I think it will go away sooner or later, at least there are some attempts to eliminate it).<br>While the ability to map any part of Guest memory is not an issue for the backend running in Dom0<br>(which we usually trust), this will certainly violate Xen security model if we want to run it in other<br>domain, so I completely agree with the existing concern.<br><br>It was discussed before [1], but I couldn't find any decisions regarding that. As I understand,<br>the one of the possible ideas is to have some entity in Xen (PV IOMMU/virtio-iommu/whatever)<br>that works in protection mode, so it denies all foreign mapping requests from the backend running in DomU<br>by default and only allows requests with mapping which were *implicitly* granted by the Guest before.<br>For example, Xen could be informed which MMIOs hold the queue PFN and notify registers<br>(as it traps the accesses to these registers anyway) and could theoretically parse the frontend request<br>and retrieve descriptors to make a decision which GFNs are actually *allowed*.<br><br>I can't say for sure (sorry not familiar enough with the topic), but implementing the virtio-iommu device<br>in Xen we could probably avoid Guest modifications at all. Of course, for this to work<br>the Virtio infrastructure in Guest should use DMA API as mentioned in [1].</div><div><br>Would the “restricted foreign mapping” solution retain the Xen security model and be accepted<br>by the Xen community? I wonder, has someone already looked in this direction, are there any<br>pitfalls here or is this even feasible?<br><br>[1] <a href="https://lore.kernel.org/xen-devel/464e91ec-2b53-2338-43c7-a018087fc7f6@arm.com/">https://lore.kernel.org/xen-devel/464e91ec-2b53-2338-43c7-a018087fc7f6@arm.com/</a><br></div></div><div class="gmail_quote"><br><div> </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="background-color:rgb(255,255,255)"><font size="2"><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">Regards,</span></font></span></div><div dir="ltr"><br></div><div dir="ltr"><div><span style="background-color:rgb(255,255,255)"><font size="2">Oleksandr Tyshchenko</font></span></div></div></div></div></div></div></div></div>