linux-kernel - Re: [PATCH] iommu/amd: Add support for hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250826175813.GH2130239@nvidia.com>
Date: Tue, 26 Aug 2025 14:58:13 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: "Suthikulpanit, Suravee" <suravee.suthikulpanit@....com>
Cc: linux-kernel@...r.kernel.org, joro@...tes.org, kevin.tian@...el.com,
	vasant.hegde@....com, iommu@...ts.linux.dev, santosh.shukla@....com,
	sairaj.arunkodilkar@....com, jon.grimm@....com,
	prashanthpra@...gle.com, wvw@...gle.com, wnliu@...gle.com,
	gptran@...gle.com, kpsingh@...gle.com
Subject: Re: [PATCH] iommu/amd: Add support for hw_info for iommu capability
 query

On Tue, Aug 26, 2025 at 12:36:23PM -0500, Suthikulpanit, Suravee wrote:
> > I think you should probably just pass the raw HW value through and
> > require the VMM to figure out what bits it needs based on feature
> > flags elsewhere.
> 
> The problem is some of the features are virtualized by hardware, which needs
> enabling from the Linux AMD IOMMU driver. We cannot just provide all flags
> since VMM would not know if the kernel has the support enabled.

The VMM is not supposed to forward these flags as-is! It is sort of
some kind of maximum what the underlying HW can support.

If you forward as-is then the VMM will forward broken flags it doesn't
support when the kernel gets updated, that isn't OK.

Each and every feature the VMM wants to show in the EFR has to figured
out on its own if it can be supported based on other kernel features.

The utility of the get_info return is for HW features that don't
require any special kernel enablement.

This is all the same as ARM which is working this way, I don't think
there is a reason to deviate here, it just gets confusing and opens up
paths for bugs.

Pass the real values from HW, write a comment similar to ARM that says
these are raw HW values and the VMM must generate its own EFR not copy
blindly from here.

Jason