[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.
~Andrew
|
