From: Ross Philipson <ross.philipson@oracle.com>
To: Andy Lutomirski <luto@kernel.org>,
Andi Kleen <ak@linux.intel.com>, Joerg Roedel <jroedel@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Wang <jasowang@redhat.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
iommu <iommu@lists.linux-foundation.org>,
linux-integrity <linux-integrity@vger.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"Daniel P. Smith" <dpsmith@apertussolutions.com>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 12/12] iommu: Do not allow IOMMU passthrough with Secure Launch
Date: Wed, 30 Jun 2021 05:50:20 -0400 [thread overview]
Message-ID: <61f383bc-d582-418f-8d6b-4838bd0d912c@oracle.com> (raw)
In-Reply-To: <CALCETrUdEvLFKuvU7z_ut6cEfAgJogNp3oBXL-EdDLU=W+VeKA@mail.gmail.com>
On 6/21/21 5:15 PM, Andy Lutomirski wrote:
> On Mon, Jun 21, 2021 at 10:51 AM Ross Philipson
> <ross.philipson@oracle.com> wrote:
>>
>> On 6/18/21 2:32 PM, Robin Murphy wrote:
>>> 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.
>>
>> It is currently Intel only but that will change. I will look into what
>> you suggest.
>>
>>>
>>>> +
>>>> 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
>>
>> Ok so I guess it would be better to set it to IOMMU_DOMAIN_DMA event
>> though passthrough was requested. Or perhaps something more is needed here?
>>
>>> 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...
>>
>> Doing a secure launch with the kernel is not a general purpose user use
>> case. A lot of work is done to secure the environment. Allowing
>> passthrough mode would leave the secure launch kernel exposed to DMA. I
>> think what we are trying to do here is what we intend though there may
>> be a better way or perhaps it is incomplete as you suggest.
>>
>
> I don't really like all these special cases. Generically, what you're
> trying to do is (AFAICT) to get the kernel to run in a mode in which
> it does its best not to trust attached devices. Nothing about this is
> specific to Secure Launch. There are plenty of scenarios in which
> this the case:
>
> - Virtual devices in a VM host outside the TCB, e.g. VDUSE, Xen
> device domains (did I get the name right), whatever tricks QEMU has,
> etc.
> - SRTM / DRTM technologies (including but not limited to Secure
> Launch -- plain old Secure Boot can work like this too).
> - Secure guest technologies, including but not limited to TDX and SEV.
> - Any computer with a USB-C port or other external DMA-capable port.
> - Regular computers in which the admin wants to enable this mode for
> whatever reason.
>
> Can you folks all please agree on a coordinated way for a Linux kernel
> to configure itself appropriately? Or to be configured via initramfs,
> boot option, or some other trusted source of configuration supplied at
> boot time? We don't need a whole bunch of if (TDX), if (SEV), if
> (secure launch), if (I have a USB-C port with PCIe exposed), if
> (running on Xen), and similar checks all over the place.
>
I replied to Robin Murphy in another thread. As far as the IOMMU is
concerned, I think we need to rethink our approach. As to the other
technologies you mention here, we have not considered special casing
anything at this point.
Thanks
Ross
next prev parent reply other threads:[~2021-06-30 9:50 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
2021-06-21 17:51 ` Ross Philipson
2021-06-21 21:15 ` Andy Lutomirski
2021-06-30 9:50 ` Ross Philipson [this message]
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=61f383bc-d582-418f-8d6b-4838bd0d912c@oracle.com \
--to=ross.philipson@oracle.com \
--cc=ak@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dpsmith@apertussolutions.com \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jasowang@redhat.com \
--cc=jroedel@suse.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=trenchboot-devel@googlegroups.com \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).