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

Re: XSA-378 fixes breaking PVH Dom0 (was: [xen-4.15-testing test] 164495: regressions - FAIL)

  • To: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 27 Aug 2021 16:46:33 +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=Z7J1H3J0X+/LLquYbfXYODBT3Oje80wJi5hvPtEZe/w=; b=lRbvzZUVoKvlC0vniwOwwQeiCorFyq2O69JCHYp2eFFgn0ngeNnGgfNHmVNcKw7Jj0kwXZWuVxDqiPIzvX5MOs/BbdhBlMTMnvY5eFNqiJoq6QvZofYqncQs/ijl7Ks0RsIHZH8NQ2E3mq2Hq2Eoi93cYPlzllkANDlRBUI4i9JeQUh4cbLiLeNboWibI7Wk4rN4n84lqdb+0P9PAQcCnEqUFMKs6IRCsAlvBIo2FsUqhbZFwIVKWR6h5tiuXF7WhIXlcsHceCqCXEvMYY/6EVduOwc8EUWQRd+huhjYIc8pjCvIwXO5EoYDRMEuMdqx0u1RdCCMmYl5gJ3SADr0Uw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R2cVKdp6o5355qHo/mh5TtHn25dzyo4Tf9FnC8yTzCt2KCtqbpTxS8SZD8/xTL/Ntx2P7ChxuX9w8pjMtHKA81Jq2soJPq8WkoHPLpz5ngFb7VvX4kVjmZVsWwYjqEnHo22Q9xHMRPV8Xic37IV4J08KdYX0TYxX2c+VgoeIvaSBe1mGvrxX2nl/rYfk0w40sTpK7T1gYdNfigVEwRlLF56jnoNIaND40B3haGKs7zgr1ogov1CHkoj5Yj9CiM3g2GhdgVRxcLL9yCx2gDFZatAnw5ml5xFREBwd527g/yg8V50SBL3bYokSSYNOvTosfjskLpW6Opio4HtCAaJywg==
  • Authentication-results: xenproject.org; dkim=none (message not signed) header.d=none;xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: osstest service owner <osstest-admin@xxxxxxxxxxxxxx>
  • Delivery-date: Fri, 27 Aug 2021 14:46:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.08.2021 15:29, Jan Beulich wrote:
> On 27.08.2021 08:52, osstest service owner wrote:
>> flight 164495 xen-4.15-testing real [real]
>> flight 164509 xen-4.15-testing real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/164495/
>> http://logs.test-lab.xenproject.org/osstest/logs/164509/
>> Regressions :-(
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-amd64-dom0pvh-xl-amd  8 xen-boot              fail REGR. vs. 
>> 163759
>>  test-amd64-amd64-dom0pvh-xl-intel  8 xen-boot            fail REGR. vs. 
>> 163759
> This is fallout from XSA-378. During Dom0 setup we first call
> iommu_hwdom_init(), which maps reserved regions (p2m_access_rw).
> Later map_mmio_regions() gets used to identity-map the low first
> Mb. This, using set_mmio_p2m_entry(), establishes default-access
> mappings (p2m_access_rwx).
> Hence even if relaxing the logic in set_typed_p2m_entry() to
>     if ( p2m_is_special(ot) )
>     {
>         gfn_unlock(p2m, gfn, order);
>         if ( mfn_eq(mfn, omfn) && gfn_p2mt == ot && access == a )
>             return 0;
>         domain_crash(d);
>         return -EPERM;
>     }
> we're still in trouble (because the two access types don't match)
> when there is any reserved region below 1Mb.
> One approach would be to avoid blindly mapping the low first Mb,
> and to instead honor mappings which are already there. Or the
> opposite - avoid mapping anything from arch_iommu_hwdom_init()
> which is below 1Mb. (Other mappings down the call tree from
> pvh_setup_acpi() imo would then also need adjusting, to avoid
> redundant mapping attempts of space below 1Mb. At least RSDP is
> known to possibly live there on various systems.)
> Another approach could be to stop passing ->default_access from
> set_mmio_p2m_entry() to set_typed_p2m_entry(). (And I think the
> same should go for set_foreign_p2m_entry()). At the very least
> right now it makes no sense at all to make RWX mappings there,
> except when mapping PCI device ROMs. But of course reducing
> permissions always comes with a (however large or small) risk of
> regressions.
> While I think the latter aspect wants improving in any event,
> right now I'm leaning towards the "opposite" variant of the
> former. I'll draft a patch along these lines at least to see if
> it helps, or if there is yet more fallout.

There is more fallout - with the initial issue addressed as
described I'm now hitting another similar domain_crash() in
guest_physmap_add_entry(). There's no question there whether to
check that old and new mappings match - they are different. Here
PVH Dom0 setup really does what the final XSA-378 patch is
intended to disallow: It produces MMIO mappings to then replace
some (or really most) by RAM ones. This means I'll have to
further adjust how pvh_populate_p2m() works. This will have to
wait until after the weekend, sorry.




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