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.) Jan
