[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 21 Mar 2022 09:48:04 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NiG1GcGYfMsd7mWxX9j1ZoaOXKnuTxprSE38Z1XhgRk=; b=fMn3xhlRh9j40FwrBBGC982W0kUrPeZ4fDMyeTAiC3rX3Bople8e88nMUipUOK0OCYJhGnlx9XFpyB12OCH6fDopqXwSBqMDUjx88q9QZEmzdBaH2hdw1b3w2byJ/VgH4Yfwy82/6Y7uB+flXg+7R63zblaLkzTZQo+BW3CpBT+LZEZydV6AmPK1TvBCWjjr/WfGuirArUGc7y5NBJvWIRDmdh3mVe4tDBFkvB8yISwj5oJJx710lwN9pN0hBMU3yl2+Hu0yKLFozHMfhdJjE4fWrwqv1V1PpYvcgdX520Ekvso0l3dzdzilmJ5wUnhdJ8rW3Eit2htmrV8wzUivJA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MZT47uXf5gdX6VJnn6J7jsCqMBSVZghQvyyYmjnbxQwEIPD4IVHEFqRhIpcIyU3u0AAdv/XCUCaEBY5p6QSan167Qc8iXSgVeUBAf0JrJfwpXYgxfBCkyKMSMNt7DuAoikZQHi9XxWM3cI7o8GwYvblay90EKIai4/YBzo9gMH7pSX1FKaDzQrz5EC+tTev7JFw3s4s9sQETwgwGQq+zCDNIyKOot7+veXg5jlOeUqNbgN3rzBc4PixoSQ7j8Vp4H3ZMifFIp2rubzZlXWaToBZnEH1QAkLlhuRpuxiuIfY/H3pkS+s1HDZ2OMIxk3M6RaHR52YKNuQjzWZjAvRgiw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Penny Zheng <Penny.Zheng@xxxxxxx>, nd@xxxxxxx, Penny Zheng <penzhe01@xxxxxxxxxxxxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 21 Mar 2022 08:48:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.