Re: [PATCH v1 02/13] xen/arm: introduce a special domain DOMID_SHARED

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 21/03/2022 20:03, Stefano Stabellini wrote:
> On Mon, 21 Mar 2022, Jan Beulich wrote:
> > On 18.03.2022 22:50, Stefano Stabellini wrote:
> > > On Fri, 18 Mar 2022, Jan Beulich wrote:
> > > > On 11.03.2022 07:11, Penny Zheng wrote:
> > > > > In case to own statically shared pages when owner domain is not
> > > > > explicitly defined, this commits propose a special domain DOMID_SHARED,
> > > > > and we assign it 0x7FF5, as one of the system domains.
> > > > >
> > > > > Statically shared memory reuses the same way of initialization with static
> > > > > memory, hence this commits proposes a new Kconfig CONFIG_STATIC_SHM to wrap
> > > > > related codes, and this option depends on static memory(CONFIG_STATIC_MEMORY).
> > > > >
> > > > > We intends to do shared domain creation after setup_virt_paging so shared
> > > > > domain could successfully do p2m initialization.
> > > > There's nothing said here, in the earlier patch, or in the cover letter
> > > > about the security aspects of this. There is a reason we haven't been
> > > > allowing arbitrary, un-supervised sharing of memory between domains. It
> > > > wants clarifying why e.g. grants aren't an option to achieve what you
> > > > need, and how you mean to establish which domains are / aren't permitted
> > > > to access any individual page owned by this domain.
> > >
> > > I'll let Penny write a full reply but I'll chime in to try to help with
> > > the explanation.
> > >
> > > This is not arbitrary un-supervised sharing of memory between domains,
> > > which indeed is concerning.
> > >
> > > This is statically-configured, supervised by the system configurator,
> > > sharing of memory between domains.
> > >
> > > And in fact safety (which is just a different aspect of security) is one
> > > of the primary goals for this work.
> > >
> > > In safety-critical environments, it is not considered safe to
> > > dynamically change important configurations at runtime. Everything
> > > should be statically defined and statically verified.
> > >
> > > In this case, if the system configuration knows a priori that there are
> > > only 2 VM and they need to communication over shared memory, it is safer
> > > to pre-configure the shared memory at build time rather than let the VMs
> > > attempt to share memory at runtime. It is faster too.
> > >
> > > The only way to trigger this static shared memory configuration should
> > > be via device tree, which is at the same level as the XSM rules
> > > themselves.
> > >
> > > Hopefully I made things clearer and not murkier :-)
> > It adds some helpful background, yes, but at the same time it doesn't
> > address the security concern at all: How are access permissions
> > managed when the owning domain is a special one? I haven't spotted
> > any recording of the domains which are actually permitted to map /
> > access the pages in questions. (But of course I also only looked at
> > non-Arm-specific code. I'd expect such code not to live in arch-
> > specific files.)
> All this static memory sharing is statically done at __init time only.
> It should not be possible to trigger any further memory sharing at
> runtime (if there is, that would be a bug). 
Looking at the code, get_pg_owner() will be able to handle DOMID_SHARED. 
So anyone that is permitted to access DOMID_SHARED will be able to map 
any memory region at runtime.
> There are no new interfaces for the guest to map this memory because it
> is already "pre-mapped".
It can via XENMAPSPACE_gmfn_foreign (assuming proper permission).

Cheers,

--
Julien Grall