Re: [RFC PATCH v1 34/38] coco: guest: arm64: Validate mmio range found in the interface report

Arto Merilainen
2025-09-10T05:47:51Z

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