|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 00/20] Add SMMUv3 Stage 1 Support for XEN guests
On 8/7/25 19:58, Julien Grall wrote: Hi Milan,On Thu, 7 Aug 2025 at 17:55, Milan Djokic <milan_djokic@xxxxxxxx <mailto:milan_djokic@xxxxxxxx>> wrote: Hello Julien,We have prepared a design document and it will be part of the updated patch series (added in docs/design). I'll also extend cover letter with details on implementation structure to make review easier. Following is the design document content which will be provided in updated patch series: Design Proposal: Add SMMUv3 Stage-1 Support for XEN Guests ========================================================== Author: Milan Djokic <milan_djokic@xxxxxxxx> Date: 2025-08-07 Status: Draft Introduction ------------ The SMMUv3 supports two stages of translation. Each stage of translation can be independently enabled. An incoming address is logically translated from VA to IPA in stage 1, then the IPA is input to stage 2 which translates the IPA to the output PA. Stage 1 translation support is required to provide isolation between different devices within the OS. Xen already supports Stage 2 translation but there is no support for Stage 1 translation. This design proposal outlines the introduction of Stage-1 SMMUv3 support in Xen for ARM guests. Motivation ---------- ARM systems utilizing SMMUv3 require Stage-1 address translation to ensure correct and secure DMA behavior inside guests. This feature enables: - Stage-1 translation in guest domain - Safe device passthrough under secure memory translation Design Overview --------------- These changes provide emulated SMMUv3 support: - SMMUv3 Stage-1 Translation: stage-1 and nested translation support in SMMUv3 driver - vIOMMU Abstraction: virtual IOMMU framework for guest Stage-1 handling - Register/Command Emulation: SMMUv3 register emulation and command queue handling - Device Tree Extensions: adds iommus and virtual SMMUv3 nodes to device trees for dom0 and dom0less scenarios - Runtime Configuration: introduces a 'viommu' boot parameter for dynamic enablement Security Considerations ------------------------ viommu security benefits: - Stage-1 translation ensures guest devices cannot perform unauthorized DMA - Emulated SMMUv3 for domains removes dependency on host hardware while maintaining isolation Observations and Potential Risks -------------------------------- 1. Observation: Support for Stage-1 translation introduces new data structures (s1_cfg and s2_cfg) and logic to write both Stage-1 and Stage-2 entries in the Stream Table Entry (STE), including an abort field for partial config states. Risk: A partially applied Stage-1 configuration might leave guest DMA mappings in an inconsistent state, enabling unauthorized access or cross-domain interference. Mitigation (Handled by design): Both s1_cfg and s2_cfg are written atomically. The abort field ensures Stage-1 config is only used when fully applied. Incomplete configs are ignored by the hypervisor. 2. Observation: Guests can now issue Stage-1 cache invalidations. Risk: Failure to propagate invalidations could leave stale mappings, enabling data leakage or misrouting. Mitigation (Handled by design): Guest invalidations are forwarded to the hardware to ensure IOMMU coherency. 3. Observation: The feature introduces large functional changes including the vIOMMU framework, vsmmuv3 devices, command queues, event queues, domain handling, and Device Tree modifications. Risk: Increased attack surface with risk of race conditions, malformed commands, or misconfiguration via the device tree. Mitigation: - Improved sanity checks and error handling - Feature is marked as Tech Preview and self-contained to reduce risk to unrelated code 4. Observation: The implementation supports nested and standard translation modes, using guest command queues (e.g. CMD_CFGI_STE) and events. Risk: Malicious commands could bypass validation and corrupt SMMUv3 state or destabilize dom0. Mitigation (Handled by design): Command queues are validated, and only permitted configuration changes are accepted. Handled in vsmmuv3 and cmdqueue logic. 5. Observation: Device Tree changes inject iommus and vsmmuv3 nodes via libxl. Risk: Malicious or incorrect DT fragments could result in wrong device assignments or hardware access. Mitigation: Only vetted and sanitized DT fragments are allowed. libxl limits what guests can inject. 6. Observation: The feature is enabled per-guest via viommu setting. Risk: Guests without viommu may behave differently, potentially causing confusion, privilege drift, or accidental exposure. Mitigation: Ensure downgrade paths are safe. Perform isolation audits in multi-guest environments to ensure correct behavior. Performance Impact ------------------ Hardware-managed translations are expected to have minimal overhead. Emulated vIOMMU may introduce some latency during initialization or event processing. Testing ------- - QEMU-based testing for Stage-1 and nested translation - Hardware testing on Renesas SMMUv3-enabled ARM systems - Unit tests for translation accuracy (not yet implemented) Migration and Compatibility --------------------------- This feature is optional and disabled by default (viommu="") to ensure backward compatibility. References ---------- - Original implementation by Rahul Singh:https://patchwork.kernel.org/project/xen-devel/cover/cover.1669888522.git.rahul.singh@xxxxxxx/ - ARM SMMUv3 architecture documentation - Existing vIOMMU code in Xen BR, Milan
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |