linux-kernel - Re: [RFC PATCH v1 10/38] iommufd/vdevice: Add TSM map ioctl

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: <yq5aikj38p8a.fsf@kernel.org>
Date: Mon, 04 Aug 2025 13:58:53 +0530
From: Aneesh Kumar K.V <aneesh.kumar@...nel.org>
To: Alexey Kardashevskiy <aik@....com>, Jason Gunthorpe <jgg@...pe.ca>
Cc: linux-coco@...ts.linux.dev, kvmarm@...ts.linux.dev,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	lukas@...ner.de, Samuel Ortiz <sameo@...osinc.com>,
	Xu Yilun <yilun.xu@...ux.intel.com>,
	Suzuki K Poulose <Suzuki.Poulose@....com>,
	Steven Price <steven.price@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>
Subject: Re: [RFC PATCH v1 10/38] iommufd/vdevice: Add TSM map ioctl

Alexey Kardashevskiy <aik@....com> writes:

> On 28/7/25 19:47, Jason Gunthorpe wrote:
>> On Mon, Jul 28, 2025 at 07:21:47PM +0530, Aneesh Kumar K.V (Arm) wrote:
>>> With passthrough devices, we need to make sure private memory is
>>> allocated and assigned to the secure guest before we can issue the DMA.
>>> For ARM RMM, we only need to map and the secure SMMU management is
>>> internal to RMM. For shared IPA, vfio/iommufd DMA MAP/UNMAP interface
>>> does the equivalent
>> 
>> I'm not really sure what this is about? It is about getting KVM to pin
>> all the memory and commit it to the RMM so it can be used for DMA?
>> 
>> But it looks really strange to have an iommufd ioctl that just calls a
>> KVM function. Feeling this should be a KVM function, or a guestmfd
>> behavior??
>
>
> I ended up exporting the guestmemfd's kvm_gmem_get_folio() for gfn->pfn and its fd a bit differently in iommufd - "no extra referencing":
> https://github.com/AMDESE/linux-kvm/commit/f1ebd358327f026f413f8d3d64d46decfd6ab7f6
>
> It is a new iommufd->kvm dependency though.
>

Was the motivation for that design choice the fact that in case of AMD
VFIO/IOMMUFD manages both private memory allocation and updates to the
IOMMU page tables?

On the ARM side, the requirement is to ensure that pages are present in
the stage-2 page table, which is managed by the firmware (RMM). Because
of this, we need an interface that VFIO/IOMMUFD can use to trigger
stage-2 mappings within KVM.

Alternatively, we could introduce a dedicated KVM ioctl for this
purpose, avoiding the need to rely on IOMMUFD.

For reference, TDX uses a similar ioctl—`KVM_TDX_INIT_MEM_REGION`—to
initialize guest memory. However, that interface isn’t well-suited for
dynamic updates to stage-2 mappings during shared-to-private or
private-to-shared transitions.


>
>> I was kind of thinking it would be nice to have a guestmemfd mode that
>> was "pinned", meaning the memory is allocated and remains almost
>> always mapped into the TSM's page tables automatically. VFIO using
>> guests would set things this way.
>
> Yeah while doing the above, I was wondering if I want to pass the fd type when DMA-mapping from an fd or "detect" it as I do in the above commit or have some iommufd_fdmap_ops in this fd saying "(no) pinning needed" (or make this a flag of IOMMU_IOAS_MAP_FILE).
>
> The "detection" is (mapping_inaccessible(mapping) && mapping_unevictable(mapping)), works for now.
>
> btw in the AMD case, here it does not matter as much if it is private or shared, I map everything and let RMP and the VM deal with the permissions. Thanks,
>
>

-aneesh