From: Robin Murphy <robin.murphy@arm.com> To: Ross Philipson <ross.philipson@oracle.com>, linux-kernel@vger.kernel.org, x86@kernel.org, iommu@lists.linux-foundation.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org Cc: dpsmith@apertussolutions.com, luto@amacapital.net, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tglx@linutronix.de, trenchboot-devel@googlegroups.com Subject: Re: [PATCH v2 12/12] iommu: Do not allow IOMMU passthrough with Secure Launch Date: Fri, 18 Jun 2021 19:32:27 +0100 [thread overview] Message-ID: <53edcf0e-c094-876c-ac3d-7c9752e9ea99@arm.com> (raw) In-Reply-To: <1624032777-7013-13-git-send-email-ross.philipson@oracle.com> On 2021-06-18 17:12, Ross Philipson wrote: > The IOMMU should always be set to default translated type after > the PMRs are disabled to protect the MLE from DMA. > > Signed-off-by: Ross Philipson <ross.philipson@oracle.com> > --- > drivers/iommu/intel/iommu.c | 5 +++++ > drivers/iommu/iommu.c | 6 +++++- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index be35284..4f0256d 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -41,6 +41,7 @@ > #include <linux/dma-direct.h> > #include <linux/crash_dump.h> > #include <linux/numa.h> > +#include <linux/slaunch.h> > #include <asm/irq_remapping.h> > #include <asm/cacheflush.h> > #include <asm/iommu.h> > @@ -2877,6 +2878,10 @@ static bool device_is_rmrr_locked(struct device *dev) > */ > static int device_def_domain_type(struct device *dev) > { > + /* Do not allow identity domain when Secure Launch is configured */ > + if (slaunch_get_flags() & SL_FLAG_ACTIVE) > + return IOMMU_DOMAIN_DMA; Is this specific to Intel? It seems like it could easily be done commonly like the check for untrusted external devices. > + > if (dev_is_pci(dev)) { > struct pci_dev *pdev = to_pci_dev(dev); > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index 808ab70d..d49b7dd 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -23,6 +23,7 @@ > #include <linux/property.h> > #include <linux/fsl/mc.h> > #include <linux/module.h> > +#include <linux/slaunch.h> > #include <trace/events/iommu.h> > > static struct kset *iommu_group_kset; > @@ -2761,7 +2762,10 @@ void iommu_set_default_passthrough(bool cmd_line) > { > if (cmd_line) > iommu_cmd_line |= IOMMU_CMD_LINE_DMA_API; > - iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY; > + > + /* Do not allow identity domain when Secure Launch is configured */ > + if (!(slaunch_get_flags() & SL_FLAG_ACTIVE)) > + iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY; Quietly ignoring the setting and possibly leaving iommu_def_domain_type uninitialised (note that 0 is not actually a usable type) doesn't seem great. AFAICS this probably warrants similar treatment to the mem_encrypt_active() case - there doesn't seem a great deal of value in trying to save users from themselves if they care about measured boot yet explicitly pass options which may compromise measured boot. If you really want to go down that route there's at least the sysfs interface you'd need to nobble as well, not to mention the various ways of completely disabling IOMMUs... It might be reasonable to make IOMMU_DEFAULT_PASSTHROUGH depend on !SECURE_LAUNCH for clarity though. Robin. > } > > void iommu_set_default_translated(bool cmd_line) >
next prev parent reply other threads:[~2021-06-18 18:32 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-18 16:12 [PATCH v2 00/12] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson 2021-06-18 16:12 ` [PATCH v2 01/12] x86/boot: Place kernel_info at a fixed offset Ross Philipson 2021-06-18 16:12 ` [PATCH v2 02/12] x86: Secure Launch Kconfig Ross Philipson 2021-06-18 16:12 ` [PATCH v2 03/12] x86: Secure Launch main header file Ross Philipson 2021-06-18 16:12 ` [PATCH v2 04/12] x86: Add early SHA support for Secure Launch early measurements Ross Philipson 2021-06-18 16:12 ` [PATCH v2 05/12] x86: Secure Launch kernel early boot stub Ross Philipson 2021-06-18 16:12 ` [PATCH v2 06/12] x86: Secure Launch kernel late " Ross Philipson 2021-06-18 16:12 ` [PATCH v2 07/12] x86: Secure Launch SMP bringup support Ross Philipson 2021-06-18 16:12 ` [PATCH v2 08/12] kexec: Secure Launch kexec SEXIT support Ross Philipson 2021-06-18 16:12 ` [PATCH v2 09/12] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson 2021-06-18 16:12 ` [PATCH v2 10/12] x86: Secure Launch late initcall platform module Ross Philipson 2021-06-18 16:12 ` [PATCH v2 11/12] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson 2021-06-18 16:12 ` [PATCH v2 12/12] iommu: Do not allow IOMMU passthrough with " Ross Philipson 2021-06-18 18:32 ` Robin Murphy [this message] 2021-06-21 17:51 ` Ross Philipson 2021-06-21 21:15 ` Andy Lutomirski 2021-06-30 9:50 ` Ross Philipson 2021-08-04 3:05 ` Daniel P. Smith 2021-06-22 11:06 ` Robin Murphy 2021-06-30 9:47 ` Ross Philipson
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=53edcf0e-c094-876c-ac3d-7c9752e9ea99@arm.com \ --to=robin.murphy@arm.com \ --cc=bp@alien8.de \ --cc=dpsmith@apertussolutions.com \ --cc=hpa@zytor.com \ --cc=iommu@lists.linux-foundation.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mingo@redhat.com \ --cc=ross.philipson@oracle.com \ --cc=tglx@linutronix.de \ --cc=trenchboot-devel@googlegroups.com \ --cc=x86@kernel.org \ --subject='Re: [PATCH v2 12/12] iommu: Do not allow IOMMU passthrough with Secure Launch' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).