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

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

  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 1 Sep 2021 16:05:56 +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=paypqYQBXso7iTGQUkcCymonj0cg77qB8rkP+sbL1jE=; b=XJaJWGwmZ0Fra57Se5qp+oxp+ioxrkkfUGwGcLj/SKE2Y1hjDRGEMiiOHPcOsv67Eyxrfr08r3vNvF6ly+eLWruQsnNlkHX/DmnzQNADLKbdMwVrCOB1A0hTwDXpd1qrHsOF/wEBspivdoZleEfl2vsIesTrBM/bV483lNbZ+cRa956YJC6v1VIrHIcKVrb4E3HK469E6tBgdQvTTLuZcr/bSwqTdwjSDn+IElonWjYHf9HVnZDxVuwqAv2WTYLoGAbgdyzN/6ryj70iBhOIz+LCL4Gb/XLHO0ASpWAWI1MQRDFK/jvVJON71ORBYUQHvelFMlSS60YsgXDeFkXH6Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DjUHqOWzRUNL9QlCkm1cLKLVBY7B/lLKPtbKv98snqghPwianmnh9oZmPTzAT/4cCWzz/nYacZBUTkl8t9x3onMCII5hLJWwf1Mrvh8BsosvImXZ6wies1l4tDV3DrTj9ZDv3UqzHPe0YJOUWlqwltfhxmwCjRFyM71ao8pHaUrjNAKX2/k1DUIEWnbiOOgjMbaRawkgIHNvBJVPHURmv5EBN66ziU0zM6oO1wEpPBdZ/yd2Dt9U+zM96Qlxill5E8iISlPtwI6ghGBK+MIMurbhHzfjqGQV6ZklQ23SwOO4n34tEaIl8eTfN7Fi7JTYtPipui9f++7qNWPl/ccjJQ==
  • 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: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 01 Sep 2021 14:06:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01.09.2021 15:48, Roger Pau Monné wrote:
> On Wed, Sep 01, 2021 at 11:53:03AM +0200, Jan Beulich wrote:
>> The issue isn't just with execution, though, and as a result I may
>> need to change the logic here to also include at least W. As of
>> one of the XSA-378 changes we may now pass just p2m_access_r to
>> iommu_identity_mapping(), if the ACPI tables on an AMD system were
>> saying so. (We may also pass p2m_access_w, but I sincerely hope no
>> firmware would specify write but no read access.)
>> Similarly in "IOMMU/x86: restrict IO-APIC mappings for PV Dom0" I
>> now pass p2m_access_r to set_identity_p2m_entry().
> Not really I think, as PVH dom0 is the only user of the
> set_identity_p2m_entry call in arch_iommu_hwdom_init, and we should
> never identity map the IO-APIC range in that case because a set of
> emulated IO-APIC replacements are provided and those require ranges to
> be unmapped so that accesses can be trapped.

Correct, this would be only a latent issue for now. The code passes
that value, but that path is not going to be taken (until, perhaps,
a future change).

>> I suppose an underlying issue is the mixed purpose of using
>> p2m_access_*, which possibly has been against the intentions in the
>> first place. We cannot, for example, express r/o access to an MMIO
>> page without using p2m_access_r (or p2m_access_rx), as there's no
>> suitable p2m type to express this via type alone. We may need to
>> split p2m_mmio_direct into multiple types (up to 7), I guess, if
>> we wanted to remove this (ab)use of p2m_access_*.
> My main complaint is mostly with the fact that some MMIO ranges are
> mapped without execute permissions when mapped by
> set_identity_p2m_entry vs map_mmio_regions that will map them with the
> default permissions and that has execution set.

Right - as said in a reply to Andrew, we may need to drop some
p2m_access_t parameters in favor of using default permissions. But
at least for AMD's IOMMU-unity-mapped ranges we will need to have
a way to express at least r/o.




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