linux-kernel - Re: [PATCH 1/4] iommu/amd: Introduce Protection-domain flag VFIO

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 for Android: free password hash cracker in your pocket

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

Message-ID: <90762dee-1559-58ac-220d-a13635d5032e@amd.com>
Date:   Thu, 19 Jan 2023 02:54:43 -0600
From:   "Kalra, Ashish" <ashish.kalra@....com>
To:     Jason Gunthorpe <jgg@...pe.ca>,
        Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Cc:     linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
        joro@...tes.org, robin.murphy@....com, thomas.lendacky@....com,
        vasant.hegde@....com, jon.grimm@....com
Subject: Re: [PATCH 1/4] iommu/amd: Introduce Protection-domain flag VFIO

Hello Jason,

On 1/13/2023 9:33 AM, Jason Gunthorpe wrote:
> On Tue, Jan 10, 2023 at 08:31:34AM -0600, Suravee Suthikulpanit wrote:
>> Currently, to detect if a domain is enabled with VFIO support, the driver
>> checks if the domain has devices attached and check if the domain type is
>> IOMMU_DOMAIN_UNMANAGED.
> 
> NAK
> 
> If you need weird HW specific stuff like this then please implement it
> properly in iommufd, not try and randomly guess what things need from
> the domain type.
> 
> All this confidential computing stuff needs a comprehensive solution,
> not some piecemeal mess. How can you even use a CC guest with VFIO in
> the upstream kernel? Hmm?
> 

Currently all guest devices are untrusted - whether they are emulated, 
virtio or passthrough. In the current use case of VFIO 
device-passthrough to an SNP guest, the pass-through device will perform 
DMA to un-encrypted or shared guest memory, in the same way as virtio or 
emulated devices.

This fix is prompted by an issue reported by Nvidia, they are trying to 
do PCIe device passthrough to SNP guest. The memory allocated for DMA is 
through dma_alloc_coherent() in the SNP guest and during DMA I/O an 
RMP_PAGE_FAULT is observed on the host.

These dma_alloc_coherent() calls map into page state change hypercalls 
into the host to change guest page state from encrypted to shared in the 
RMP table.

Following is a link to issue discussed above:
https://github.com/AMDESE/AMDSEV/issues/109

Now, to set individual 4K entries to different shared/private mappings 
in NPT or host page tables for large page entries, the RMP and NPT/host 
page table large page entries are split to 4K pte’s.

The same split is required in iommu page table entries to remain in sync 
with the corresponding RMP table entry. If the iommu entry is covering a 
range with a large page entry and the individual 4K mappings in that 
range have now changed, the RMP checks during IOMMU page table walk will 
cause a RMP page fault to be signaled.

The fix is to force 4K page size for IOMMU page tables for SNP guests.

This patch-set adds support to detect if a domain belongs to an 
SNP-enabled guest. This way it can set default page size of a domain to 
4K only for SNP-enabled guest and allow non-SNP guest to use larger page 
size.

Hopefully, this explains the usage case for this patch-set.

Thanks,
Ashish