From: Jason Gunthorpe <jgg@ziepe.ca>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
joro@8bytes.org, thomas.lendacky@amd.com, vasant.hegde@amd.com,
michael.roth@amd.com, jon.grimm@amd.com, rientjes@google.com
Subject: Re: [PATCH 1/9] iommu/amd: Introduce helper functions for managing IOMMU memory
Date: Wed, 1 May 2024 13:17:41 -0300 [thread overview]
Message-ID: <20240501161741.GG1723318@ziepe.ca> (raw)
In-Reply-To: <20240430152430.4245-2-suravee.suthikulpanit@amd.com>
On Tue, Apr 30, 2024 at 03:24:22PM +0000, Suravee Suthikulpanit wrote:
> Depending on the modes of operation, certain AMD IOMMU data structures are
> allocated with constraints. For example:
>
> * Some buffers must be 4K-aligned when running in SNP-enabled host
>
> * To support AMD IOMMU emulation in an SEV guest, some data structures
> cannot be encrypted so that the VMM can access the memory successfully.
Uh, this seems like a really bad idea. The VM's integrity strongly
depends on the correct function of the HW. If the IOMMU datastructures
are not protected then the whole thing is not secure.
For instance allowing hostile VMs to manipulate the DTE, or interfere
with the command queue, destroys any possibility to have secure DMA.
Is this some precursor to implementing a secure iommu where the data
structures will remain encrypted? What is even the point of putting a
non-secure viommu into a SEV guest anyhow?
Jason
next prev parent reply other threads:[~2024-05-01 16:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 15:24 [PATCH 0/9] iommu/amd: Add AMD IOMMU emulation support for SEV-SNP guest kernel Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 1/9] iommu/amd: Introduce helper functions for managing IOMMU memory Suravee Suthikulpanit
2024-05-01 16:17 ` Jason Gunthorpe [this message]
2024-05-13 18:59 ` Suthikulpanit, Suravee
2024-05-13 23:13 ` Jason Gunthorpe
2024-04-30 15:24 ` [PATCH 2/9] iommu/amd: Convert Device Table pointer to use struct amd_iommu_mem Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 3/9] iommu/amd: Convert Command Buffer " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 4/9] iommu/amd: Convert Completion-Wait Semaphore " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 5/9] iommu/amd: Convert Event Log " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 6/9] iommu/amd: Convert PPR Log pointer to use the " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 7/9] iommu/amd: Remove iommu_alloc_4k_pages() helper function Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 8/9] iommu/amd: Decrypt interrupt remapping table for AMD IOMMU emulation in SEV guest Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 9/9] iommu/amd: Set default domain to IDENTITY_DOMAIN when running " Suravee Suthikulpanit
2024-05-01 14:17 ` Jason Gunthorpe
2024-05-13 12:17 ` Suthikulpanit, Suravee
2024-05-13 23:10 ` Jason Gunthorpe
2024-05-13 20:05 ` [PATCH 0/9] iommu/amd: Add AMD IOMMU emulation support for SEV-SNP guest kernel Michael Kelley
2024-05-14 19:02 ` Suthikulpanit, Suravee
2024-05-14 21:34 ` Michael Kelley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240501161741.GG1723318@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=iommu@lists.linux.dev \
--cc=jon.grimm@amd.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=rientjes@google.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=thomas.lendacky@amd.com \
--cc=vasant.hegde@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox