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

Re: [PATCH] arm/acpi: don't expose the ACPI IORT SMMUv3 entry to dom0



On 29/04/2022 19:18, Rahul Singh wrote:
Hi Julien,

Hi Rahul,

On 27 Apr 2022, at 7:26 pm, Julien Grall <julien@xxxxxxx> wrote:

Hi Rahul,

On 27/04/2022 17:12, Rahul Singh wrote:
Xen should control the SMMUv3 devices therefore, don't expose the
SMMUv3 devices to dom0. Deny iomem access to SMMUv3 address space for
dom0 and also make ACPI IORT SMMUv3 node type to 0xff.

Looking at the IORT spec (ARM DEN 0049E), 255 (0xff) is marked as reserved. So I don't 
think we can "allocate" 0xff to mean invalid without updating the spec. Did you 
engage with whoever own the spec?

Yes I agree with you 0xff is reserved for future use. I didn’t find any other 
value to make node invalid.
Linux kernel is mostly using the node->type to process the SMMUv3 or other IORT 
node so I thought this is the only possible solution to hide SMMUv3 for dom0
If you have any other suggestion to hide the SMMUv3 node I am okay to use that.
The other solution is to remove completely the SMMUv3 node from the IORT. This would require more work as you would need to fully rewrite the IORT.

Hence why I suggested to speak with the spec owner (it seems to be Arm) to reserve 0xff as "Invalid/Ignore".

+ smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
+ mfn = paddr_to_pfn(smmu->base_address);
+ rc = iomem_deny_access(d, mfn, mfn + PFN_UP(SZ_128K));
+ if ( rc )
+ printk("iomem_deny_access failed for SMMUv3\n");
+ node->type = 0xff;

'node' points to the Xen copy of the ACPI table. We should really not touch 
this copy. Instead, we should modify the version that will be used by dom0.

As of now IORT is untouched by Xen and mapped to dom0. I will create the IORT 
table for dom0 and modify the node SMMUv3 that will be used by dom0.

Furthermore, if we go down the road to update node->type, we should 0 the node 
to avoid leaking the information to dom0.

I am not sure if we can zero the node, let me check and come back to you.

By writing node->type, you already invalidate the content because the software cannot know how to interpret it. At which point, zeroing it should make no difference for software parsing the table afterwards. This may be a problem for software parsing before hand and keeping a pointer to the entry. But then, this is yet another reason to no updated the host IORT and create a copy for dom0.

Cheers,

--
Julien Grall



 


Rackspace

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