Message-ID: <c3291a06-1154-4c89-a77b-73e2a3ef61ee@nvidia.com>
Date: Wed, 10 Sep 2025 08:47:43 +0300
From: Arto Merilainen <amerilainen@...dia.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@...nel.org>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, aik@....com,
 lukas@...ner.de, Samuel Ortiz <sameo@...osinc.com>,
 Xu Yilun <yilun.xu@...ux.intel.com>, Jason Gunthorpe <jgg@...pe.ca>,
 Suzuki K Poulose <Suzuki.Poulose@....com>,
 Steven Price <steven.price@....com>,
 Catalin Marinas <catalin.marinas@....com>, Marc Zyngier <maz@...nel.org>,
 Will Deacon <will@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
 kvmarm@...ts.linux.dev, linux-coco@...ts.linux.dev
Subject: Re: [RFC PATCH v1 34/38] coco: guest: arm64: Validate mmio range
 found in the interface report

On 31.7.2025 14.39, Arto Merilainen wrote:
> On 28.7.2025 16.52, Aneesh Kumar K.V (Arm) wrote:
> 
>> +    for (int i = 0; i < interface_report->mmio_range_count; i++, 
>> mmio_range++) {
>> +
>> +        /*FIXME!! units in 4K size*/
>> +        range_id = FIELD_GET(TSM_INTF_REPORT_MMIO_RANGE_ID, 
>> mmio_range->range_attributes);
>> +
>> +        /* no secure interrupts */
>> +        if (msix_tbl_bar != -1 && range_id == msix_tbl_bar) {
>> +            pr_info("Skipping misx table\n");
>> +            continue;
>> +        }
>> +
>> +        if (msix_pba_bar != -1 && range_id == msix_pba_bar) {
>> +            pr_info("Skipping misx pba\n");
>> +            continue;
>> +        }
>> +
> 
> 
> MSI-X and PBA can be placed to a BAR that has other registers as well. 
> While the PCIe specification recommends BAR-level isolation for MSI-X 
> structures, it is not mandated. It is enough to have sufficient 
> isolation within the BAR. Therefore, skipping the MSI-X and PBA BARs 
> altogether may leave registers unintentionally mapped via unprotected 
> IPA when they should have been mapped via protected IPA.
> 
> Instead of skipping the whole BAR, would it make sense to determine
> where the MSI-X related regions reside, and skip validation only from 
> these regions?

I re-reviewed my suggestion, and what I proposed here seems wrong. 
However, I think there is a different more generic problem related to 
the MSI-X table, PBA and non-TEE ranges.

If a BAR is sparse (e.g., it has TEE pages and the MSI-X table, PBA or 
non-TEE areas), the TDISP interface report may contain multiple ranges 
with the same range_id (/BAR id). In case a BAR contains some registers 
in low addresses, the MSI-X table and other registers after the MSI-X 
table, the interface report is expected to have two ranges for the same 
BAR with different "first 4k page" and "size" fields.

This creates a tricky problem given that RSI_VDEV_VALIDATE_MAPPING 
requires both the ipa_base and pa_base which should correspond to the 
same location. In above scenario, the PA of the first range would 
correspond to the BAR base whereas the second range would correspond to 
a location residing after the MSI-X table.

Assuming that the report contains obfuscated (but linear) physical 
addresses, it would be possible to create heuristics for this case. 
However, the fundamental problem is that none of the "first 4k page" 
fields in the ranges is guaranteed to correspond to the base of any BAR: 
Consider a case where the MSI-X table is in the beginning of a BAR and 
it is followed by a single TEE range. If the MSI-X is not locked, the 
"first 4k page" field will not correspond to the beginning of the BAR. 
If the realm naiviely reads the ipa_base using pci_resouce_n() and 
corresponding pa_base from the interface report, the addresses won't 
match and the validation will fail.

It seems that interpreting the interface report cannot be done without 
knowledge of the device's register layout. Therefore, I don't think the 
ranges can be validated/remapped automatically without involving the 
device driver, but there should be APIs for reading the interface 
report, and for requesting making specific ranges protected.

- R2

Powered by blists - more mailing lists