Re: [PATCH v2 10/11] iommu/tegra241-cmdqv: Warn on a VCMDQ base above the 48-bit hardware limit
Will Deacon <[email protected]> Sun, 26 Jul 2026 13:57:38 +0100
| Newsgroups | org.kernel.vger.linux-tegra,dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <amYEQt7Y5MC48kRD@willie-the-truck> |
On Tue, Jul 14, 2026 at 01:55:07PM -0700, Nicolin Chen wrote: > tegra241_vcmdq_alloc_smmu_cmdq() allocates the VCMDQ buffer via the common > arm_smmu_init_one_queue(), which uses smmu->dev and its coherent DMA mask > of DMA_BIT_MASK(smmu->oas). The architectural Q_BASE_ADDR_MASK is 52 bits, > but the Tegra241 VCMDQ_BASE holds only 48 (VCMDQ_ADDR), so the masked write > "q_base = base_dma & VCMDQ_ADDR" silently drops bits 48 and up. > > A real Tegra241 never reports a 52-bit OAS alongside the 48-bit VCMDQ, so > this cannot happen on correct hardware, but a buggy or hostile hypervisor > could still advertise such an OAS to a guest. The user-VCMDQ path already > rejects a base_addr_pa with bits set outside VCMDQ_ADDR; add the same guard > to the kernel-allocated path, failing the queue init rather than silently > truncating the base. Use dev_warn_once() rather than WARN_ON(): the OAS is > hypervisor-controlled, and a WARN_ON() would let it panic a guest that is > booted with panic_on_warn. So here you talk about "a buggy or hostile hypervisor". Is that really part of the threat model? Presumably such a thing could cause havoc in a million other ways? > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: Nicolin Chen <[email protected]> > --- > drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c > index f93e59b7bd2db..d27ee215032f7 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c > +++ b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c > @@ -674,6 +674,19 @@ static int tegra241_vcmdq_alloc_smmu_cmdq(struct tegra241_vcmdq *vcmdq) > if (ret) > return ret; > > + /* > + * The q->base_dma is bounded by DMA_BIT_MASK of SMMU's IDR5.OAS. On a > + * real hardware, VCMDQ_ADDR mask and IDR5.OAS are always aligned. But > + * a buggy VM might set a mismatched IDR5.OAS for SMMU. Spit a warning > + * instead of a silent truncation. > + */ But then here you talk about "a buggy VM might set a mismatched IDR5.OAS". How can a VM write to that? /confused Will