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

Re: [PATCH 2/4] x86/P2M: relax guarding of MMIO entries

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 31 Aug 2021 17:38:49 +0200
  • 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-SenderADCheck; bh=pn1CBAarCnQzDCn4EGTb+dJnk2FgPr7ghDshwpy5KHw=; b=lt3+raH9SXgWcdPXBZ40QS2uS86UBqQKz/4kIjrSMzAmQBTxfuFFdW2VVPle/FLW6Hk69y2LknbKY4CxG4g9qWSCbrNtcgJ9dC2iWjQ3Huev6EMP1p10SsKD88fPPG8v0O9nDviIlPFJWllWwJVbaVQCxTspbW0JQNe2JI8/GayF1mFYx3GYUw1UDPo5wUKfZ/tkezSgYrt/9nSwBWxRHHPT92iPJJjMBtBerKfYaa5YW91pWrIUBM4/lzbPvQBRBOErrt8npKYBIUzxvroiy8ovfcmuPWYSv1An0bf1MuE8AqQaZS4IMsSle99z3Mu7PqsWt9Ht95JpTQRLmyOwfg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hBt+w+z8/Cx57HPnOhe75Btjo4YEM1WbVNSdQvcQUuMUn7kZF8HYu8ZUBWPmBicK7YdA+wqsrzbWbwMCTOBtzNyruT+evpoda1sBlBuYfU3sli4wL05taH8bNF/Vx8OkcbFcaTQU+/DndUx+lBKoask3awBHm2py0xK+hcWGksvGSH3+38dNm9MJEfjgx4U0mSJ6sNdUzI90eGlXb8CpjKeaNAKG0Z9396CFPXnQKco13tBFyoict9Vu69c2SWjmcvymwrqT5RtVhVKXOBdE2iLnoyFsvusQi0ts6XjIxqHs+Lok4/SRfrgyC1DrWFwg8CkgH+vVGCIH8CgXXh6tFQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 31 Aug 2021 15:39:03 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 31.08.2021 17:25, Andrew Cooper wrote:
> On 31/08/2021 14:26, Jan Beulich wrote:
>> On 31.08.2021 15:16, Andrew Cooper wrote:
>>> On 30/08/2021 14:02, Jan Beulich wrote:
>>>> Further permit "access" to differ in the "executable" attribute. While
>>>> ideally only ROM regions would get mapped with X set, getting there is
>>>> quite a bit of work. Therefore, as a temporary measure, permit X to
>>>> vary. For Dom0 the more permissive of the types will be used, while for
>>>> DomU it'll be the more restrictive one.
>>> Split behaviour between dom0 and domU based on types alone cannot
>>> possibly be correct.
>> True, but what do you do.
>>> DomU's need to execute ROMs too, and this looks like will malfunction if
>>> a ROM ends up in the region that HVMLoader relocated RAM from.
>>> As this is a temporary bodge emergency bugfix, don't try to be clever -
>>> just take the latest access.
>> And how do we know that that's what is going to work?
> Because it's the pre-existing behaviour.

Valid point. But for the DomU case there simply has not been any
pre-existing behavior. Hence my desire to be restrictive initially

>>  We should
>> strictly accumulate for Dom0. And what we do for DomU is moot for
>> the moment, until PCI passthrough becomes a thing for PVH. Hence
>> I've opted to be restrictive there - I'd rather see things break
>> (and getting adjusted) when this future work actually gets carried
>> out, than leave things permissive for no-one to notice that it's
>> too permissive, leading to an XSA.
> Restricting execute permissions is something unique to virt.  It doesn't
> exist in a non-virtualised system, as I and D side reads are
> indistinguishable outside of the core.
> Furthermore, it is inexpressible on some systems/configurations.
> Introspection is the only technology which should be restricting execute
> permissions in the p2m, and only when it takes responsibility for
> dealing with the fallout.

IOW are you saying that the calls to set_identity_p2m_entry()
(pre-dating XSA-378) were wrong to use p2m_access_rw? Because that's
what's getting the way here.

Plus, as a side note, then we don't even have e.g. IOMMUF_executable.




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