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

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 31 Aug 2021 16:25:35 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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; bh=CnQbHdPGCNJy4/jJuVsKzbrpwgrQe9EcFfe6kRh7Q/o=; b=lNIkLVScZGBp/GPKVGxQ3qb6V04XvB4jq33sXrbdt8B7Mfo6e6z4z0H+hZ3MPOuyDO6dd1rP55cT5M5Ic1aAfdv7pNjxMPNobC6Ec5jL8zmwQKYWc8wPHeH2uQ/pdRI7Cdu0j0m/XX6nmt42TORDjmLU+uujaDQfkmpfAbcadnfkBBgeDryGprU6rINzZM0GfSTr8izgGTndIoSleU26IqnWYEshi8VkABs1sv/KdqlskXGldE7Nd013qkp7KblrUN4BYqtyiXxNqTHqtuqDoz8uF+fu8lyCC5eGE+yFY8k2u7B9owGmQYLOJnzIIIZLGBSquYFBEbtxTm2HOMD+uQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FIBgfedRZfyqgChTS4bpVODtuyV4nuvOFoH+MmFOo6vHRyCEVPbDqqSx7Gwtnbq4op8YeS22vhM3ORecdt0zR/b8kv1OL3oKZggOaQWcIj1NPc5Cw9MaPXw1S3osd8T7SW6a/euPhgJenWNstlKKFkAJZOXYPB9WF4D4/Acz7bK5IUb51SU+Axht6XXi/fhssfcJMrntetUJ8uskNGagmTQK3t+bqt5qbuxNIAaWn+KvLlaI4V8XnMsLabqJZ+YXfcTmhPzdIunCPTzie4qG6y+UF0MmZLG4Bn6ErEvAHeHTr7FZG1B5iY9SnCkPo+6GFhDcXZRV5Po2Vfg2cRIoZw==
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.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:26:02 +0000
  • Ironport-hdrordr: A9a23:jMSjNKpuEEsCU3JlWDT91IcaV5oveYIsimQD101hICG9E/b1qy nKpp8mPHDP5wr5NEtPpTnjAsm9qALnlKKdiLN5Vd3OYOCMghrKEGgN1/qH/xTQXwH46+5Bxe NBXsFFebrN5IFB/KTHCd+DYrMd/OU=
  • Ironport-sdr: EpYIAtrJwCnoDuZXE0//T+szq3jFwZJ+XCMYvLs8bM75VBrzbvHrk2bKA4TAr3zZab8J0e2+wK wikQaMJUaKHm7V9oSoEKoHu68S+DITZGTs7kAPbLCj7fOgRTf1PfTnpMCzugoPRRiv+hgqm0Si lJP0K+s0pwkN/lEWyOmsd5Ra9Crn7W5d+piIJNl3VxPxBOMamKeZPJehJzi+QZpiH9ypJmc+kR 1wB7NXcgVla+I6pDwi2qhNiz7TnKWEScoHrlrOKSDDi82xc4vLmwp++/mJ4Ev0K9SPEMywRK17 iji9N/Sri7zGqJOXySi9GWph
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

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




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