On Wed, 24 May 2023 08:59:43 +0000 "Tian, Kevin" kevin.tian@intel.com wrote:
From: Liu, Yi L yi.l.liu@intel.com Sent: Thursday, May 11, 2023 10:51 PM
The first Intel platform supporting nested translation is Sapphire Rapids which, unfortunately, has a hardware errata [2] requiring special treatment. This errata happens when a stage-1 page table page (either level) is located in a stage-2 read-only region. In that case the IOMMU hardware may ignore the stage-2 RO permission and still set the A/D bit in stage-1 page table entries during page table walking.
A flag IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17 is introduced to report this errata to userspace. With that restriction the user should either disable nested translation to favor RO stage-2 mappings or ensure no RO stage-2 mapping to enable nested translation.
Intel-iommu driver is armed with necessary checks to prevent such mix in patch10 of this series.
Qemu currently does add RO mappings though. The vfio agent in Qemu simply maps all valid regions in the GPA address space which certainly includes RO regions e.g. vbios.
In reality we don't know a usage relying on DMA reads from the BIOS region. Hence finding a way to allow user opt-out RO mappings in Qemu might be an acceptable tradeoff. But how to achieve it cleanly needs more discussion in Qemu community. For now we just hacked Qemu to test.
Hi, Alex,
Want to touch base on your thoughts about this errata before we actually go to discuss how to handle it in Qemu.
Overall it affects all Sapphire Rapids platforms. Fully disabling nested translation in the kernel just for this rare vulnerability sounds an overkill.
So we decide to enforce the exclusive check (RO in stage-2 vs. nesting) in the kernel and expose the restriction to userspace so the VMM can choose which one to enable based on its own requirement.
At least this looks a reasonable tradeoff to some proprietary VMMs which never adds RO mappings in stage-2 today.
But we do want to get Qemu support nested translation on those platform as the widely-used reference VMM!
Do you see any major oversight before pursuing such change in Qemu e.g. having a way for the user to opt-out adding RO mappings in stage-2? 😊
I don't feel like I have enough info to know what common scenarios are going to make use of 2-stage and nested configurations and how likely a user is to need such an opt-out. If it's likely that a user is going to encounter this configuration, an opt-out is at best a workaround. It's a significant support issue if a user needs to generate a failure in QEMU, notice and decipher any log messages that failure may have generated, and take action to introduce specific changes in their VM configuration to support a usage restriction.
For QEMU I might lean more towards an effort to better filter the mappings we create to avoid these read-only ranges that likely don't require DMA mappings anyway.
How much does this affect arbitrary userspace vfio drivers? For example are there scenarios where running in a VM with a vIOMMU introduces nested support that's unknown to the user which now prevents this usage? An example might be running an L2 guest with a version of QEMU that does create read-only mappings. If necessary, how would lack of read-only mapping support be conveyed to those nested use cases? Thanks,
Alex