All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Philipson <ross.philipson@oracle.com>
To: Robin Murphy <robin.murphy@arm.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,
	kanth.ghatraju@oracle.com, tglx@linutronix.de,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v4 04/14] Documentation/x86: Secure Launch kernel documentation
Date: Fri, 3 Dec 2021 12:48:43 -0500	[thread overview]
Message-ID: <b2fd060d-0ac8-b00e-cebb-46015dfea14c@oracle.com> (raw)
In-Reply-To: <7ee55288-209f-8f19-ef69-27e2a5448473@arm.com>

On 12/3/21 11:03, Robin Murphy wrote:
> On 2021-12-03 15:47, Ross Philipson wrote:
>> On 12/2/21 12:26, Robin Murphy wrote:
>>> On 2021-08-27 14:28, Ross Philipson wrote:
>>> [...]
>>>> +IOMMU Configuration
>>>> +-------------------
>>>> +
>>>> +When doing a Secure Launch, the IOMMU should always be enabled and
>>>> the drivers
>>>> +loaded. However, IOMMU passthrough mode should never be used. This
>>>> leaves the
>>>> +MLE completely exposed to DMA after the PMR's [2]_ are disabled.
>>>> First, IOMMU
>>>> +passthrough should be disabled by default in the build configuration::
>>>> +
>>>> +  "Device Drivers" -->
>>>> +      "IOMMU Hardware Support" -->
>>>> +          "IOMMU passthrough by default [ ]"
>>>> +
>>>> +This unset the Kconfig value CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
>>>
>>> Note that the config structure has now changed, and if set, passthrough
>>> is deselected by choosing a different default domain type.
>>
>> Thanks for the heads up. We will have to modify this for how things
>> exist today.
>>
>>>
>>>> +In addition, passthrough must be disabled on the kernel command line
>>>> when doing
>>>> +a Secure Launch as follows::
>>>> +
>>>> +  iommu=nopt iommu.passthrough=0
>>>
>>> This part is a bit silly - those options are literally aliases for the
>>> exact same thing, and furthermore if the config is already set as
>>> required then the sole effect either of them will have is to cause "(set
>>> by kernel command line)" to be printed. There is no value in explicitly
>>> overriding the default value with the default value - if anyone can
>>> append an additional "iommu.passthrough=1" (or "iommu=pt") to the end of
>>> the command line they'll still win.
>>
>> I feel like when we worked on this, it was still important to set those
>> values. This could have been in an older kernel version. We will go back
>> and verify what you are saying here and adjust the documentation
>> accordingly.
>>
>> As to anyone just adding values to the command line, that is why the
>> command line is part of the DRTM measurements.
> 
> Yeah, I had a vague memory that that was the case - basically if you can
> trust the command line as much as the config then it's definitely
> redundant to pass an option for this (see iommu_subsys_init() - it's now
> all plumbed through iommu_def_domain_type), and if you can't then
> passing them is futile anyway.

Thanks you for your feedback.

Ross

> 
> Cheers,
> Robin.


WARNING: multiple messages have this Message-ID (diff)
From: Ross Philipson <ross.philipson@oracle.com>
To: Robin Murphy <robin.murphy@arm.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, kanth.ghatraju@oracle.com, hpa@zytor.com,
	bp@alien8.de, tglx@linutronix.de,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v4 04/14] Documentation/x86: Secure Launch kernel documentation
Date: Fri, 3 Dec 2021 12:48:43 -0500	[thread overview]
Message-ID: <b2fd060d-0ac8-b00e-cebb-46015dfea14c@oracle.com> (raw)
In-Reply-To: <7ee55288-209f-8f19-ef69-27e2a5448473@arm.com>

On 12/3/21 11:03, Robin Murphy wrote:
> On 2021-12-03 15:47, Ross Philipson wrote:
>> On 12/2/21 12:26, Robin Murphy wrote:
>>> On 2021-08-27 14:28, Ross Philipson wrote:
>>> [...]
>>>> +IOMMU Configuration
>>>> +-------------------
>>>> +
>>>> +When doing a Secure Launch, the IOMMU should always be enabled and
>>>> the drivers
>>>> +loaded. However, IOMMU passthrough mode should never be used. This
>>>> leaves the
>>>> +MLE completely exposed to DMA after the PMR's [2]_ are disabled.
>>>> First, IOMMU
>>>> +passthrough should be disabled by default in the build configuration::
>>>> +
>>>> +  "Device Drivers" -->
>>>> +      "IOMMU Hardware Support" -->
>>>> +          "IOMMU passthrough by default [ ]"
>>>> +
>>>> +This unset the Kconfig value CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
>>>
>>> Note that the config structure has now changed, and if set, passthrough
>>> is deselected by choosing a different default domain type.
>>
>> Thanks for the heads up. We will have to modify this for how things
>> exist today.
>>
>>>
>>>> +In addition, passthrough must be disabled on the kernel command line
>>>> when doing
>>>> +a Secure Launch as follows::
>>>> +
>>>> +  iommu=nopt iommu.passthrough=0
>>>
>>> This part is a bit silly - those options are literally aliases for the
>>> exact same thing, and furthermore if the config is already set as
>>> required then the sole effect either of them will have is to cause "(set
>>> by kernel command line)" to be printed. There is no value in explicitly
>>> overriding the default value with the default value - if anyone can
>>> append an additional "iommu.passthrough=1" (or "iommu=pt") to the end of
>>> the command line they'll still win.
>>
>> I feel like when we worked on this, it was still important to set those
>> values. This could have been in an older kernel version. We will go back
>> and verify what you are saying here and adjust the documentation
>> accordingly.
>>
>> As to anyone just adding values to the command line, that is why the
>> command line is part of the DRTM measurements.
> 
> Yeah, I had a vague memory that that was the case - basically if you can
> trust the command line as much as the config then it's definitely
> redundant to pass an option for this (see iommu_subsys_init() - it's now
> all plumbed through iommu_def_domain_type), and if you can't then
> passing them is futile anyway.

Thanks you for your feedback.

Ross

> 
> Cheers,
> Robin.

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-12-03 17:49 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 13:28 [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2021-08-27 13:28 ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 01/14] x86/boot: Fix memremap of setup_indirect structures Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-09-22 12:01   ` Daniel Kiper
2021-09-22 12:01     ` Daniel Kiper
2021-08-27 13:28 ` [PATCH v4 02/14] x86/boot: Add setup_indirect support in early_memremap_is_setup_data Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-09-22 12:03   ` Daniel Kiper
2021-09-22 12:03     ` Daniel Kiper
2021-08-27 13:28 ` [PATCH v4 03/14] x86/boot: Place kernel_info at a fixed offset Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 04/14] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-12-02 17:26   ` Robin Murphy
2021-12-02 17:26     ` Robin Murphy
2021-12-03 15:47     ` Ross Philipson
2021-12-03 15:47       ` Ross Philipson
2021-12-03 16:03       ` Robin Murphy
2021-12-03 16:03         ` Robin Murphy
2021-12-03 17:48         ` Ross Philipson [this message]
2021-12-03 17:48           ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 05/14] x86: Secure Launch Kconfig Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 06/14] x86: Secure Launch main header file Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 07/14] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 08/14] x86: Secure Launch kernel early boot stub Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 09/14] x86: Secure Launch kernel late " Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 10/14] x86: Secure Launch SMP bringup support Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 11/14] kexec: Secure Launch kexec SEXIT support Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 12/14] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 13/14] x86: Secure Launch late initcall platform module Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:28 ` [PATCH v4 14/14] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
2021-08-27 13:28   ` Ross Philipson
2021-08-27 13:30   ` Jason Gunthorpe
2021-08-27 13:30     ` Jason Gunthorpe
2021-08-30 19:45     ` Daniel P. Smith
2021-08-30 19:45       ` Daniel P. Smith
2021-12-01  1:06 ` [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support Paul Moore
2021-12-01  1:06   ` Paul Moore
2021-12-02 16:09   ` Daniel P. Smith
2021-12-02 16:09     ` Daniel P. Smith
2021-12-06 20:56     ` Paul Moore
2021-12-06 20:56       ` Paul Moore
2022-01-21 21:39       ` Paul Moore
2022-01-21 21:39         ` Paul Moore
2022-02-15 15:50         ` Daniel P. Smith
2022-02-15 15:50           ` Daniel P. Smith

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=b2fd060d-0ac8-b00e-cebb-46015dfea14c@oracle.com \
    --to=ross.philipson@oracle.com \
    --cc=bp@alien8.de \
    --cc=dpsmith@apertussolutions.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kanth.ghatraju@oracle.com \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.