From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: Ard Biesheuvel <ardb@kernel.org>,
Ross Philipson <ross.philipson@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
linux-crypto@vger.kernel.org, kexec@lists.infradead.org,
linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com,
mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
luto@amacapital.net, nivedita@alum.mit.edu,
herbert@gondor.apana.org.au, davem@davemloft.net,
kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v8 14/15] x86: Secure Launch late initcall platform module
Date: Thu, 22 Feb 2024 08:57:24 -0500 [thread overview]
Message-ID: <c5bd3ee4-4bf1-4e9a-8e5d-12ee8e195d3d@apertussolutions.com> (raw)
In-Reply-To: <CAMj1kXHXt6z94JCM2C5rLz-n9nGA46bb1eMbqcP5e7K9+NzPSg@mail.gmail.com>
On 2/15/24 03:40, Ard Biesheuvel wrote:
> On Wed, 14 Feb 2024 at 23:32, Ross Philipson <ross.philipson@oracle.com> wrote:
>>
>> From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
>>
>> The Secure Launch platform module is a late init module. During the
>> init call, the TPM event log is read and measurements taken in the
>> early boot stub code are located. These measurements are extended
>> into the TPM PCRs using the mainline TPM kernel driver.
>>
>> The platform module also registers the securityfs nodes to allow
>> access to TXT register fields on Intel along with the fetching of
>> and writing events to the late launch TPM log.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>> Signed-off-by: garnetgrimm <grimmg@ainfosec.com>
>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
>
> There is an awful amount of code that executes between the point where
> the measurements are taken and the point where they are loaded into
> the PCRs. All of this code could subvert the boot flow and hide this
> fact, by replacing the actual taken measurement values with the known
> 'blessed' ones that will unseal the keys and/or phone home to do a
> successful remote attestation.
To set context, in general the motivation to employ an RTM, Static or
Dynamic, integrity solution is to enable external platform validation,
aka attestation. These trust chains are constructed from the principle
of measure and execute that rely on the presence of a RoT for Storage
(RTS) and a RoT for Reporting (RTR). Under the TCG architecture adopted
by x86 vendors and now recently by Arm, those roles are fulfilled by the
TPM. With this context, lets layout the assumptive trusts being made here,
1. The CPU GETSEC instruction functions correctly
2. The IOMMU, and by extension the PMRs, functions correctly
2. The ACM authentication process functions correctly
3. The ACM functions correctly
4. The TPM interactions function correctly
5. The TPM functions correctly
With this basis, let's explore your assertion here. The assertion breaks
down into two scenarios. The first is that the at-rest kernel binary is
corrupt, unintentionally (bug) or maliciously, either of which does not
matter for the situation. For the sake of simplicity, corruption of the
Linux kernel during loading or before the DRTM Event is considered an
equivalent to corruption of the kernel at-rest. The second is that the
kernel binary was corrupted in memory at some point after the DRTM event
occurs.
For both scenarios, the ACM will correctly configure the IOMMU PMRs to
ensure the kernel can no longer be tampered with in memory. After which,
the ACM will then accurately measure the kernel (bzImage) and safely
store the measurement in the TPM.
In the first scenario, the TPM will accurately report the kernel
measurement in the attestation. The attestation authority will be able
to detect if an invalid kernel was started and can take whatever
remediation actions it may employ.
In the second scenario, any attempt to corrupt the binary after the ACM
has configured the IOMMU PMR will fail.
> At the very least, this should be documented somewhere. And if at all
> possible, it should also be documented why this is ok, and to what
> extent it limits the provided guarantees compared to a true D-RTM boot
> where the early boot code measures straight into the TPMs before
> proceeding.
I can add a rendition of the above into the existing section of the
documentation patch that already discusses separation of the measurement
from the TPM recording code. As to the limits it incurs on the DRTM
integrity, as explained above, I submit there are none.
v/r,
dps
next prev parent reply other threads:[~2024-02-22 13:58 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 22:18 [PATCH v8 00/15] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2024-02-14 22:18 ` [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset Ross Philipson
2024-02-15 7:56 ` Ard Biesheuvel
2024-02-15 10:56 ` Daniel Kiper
2024-03-21 13:45 ` Daniel P. Smith
2024-03-22 14:18 ` H. Peter Anvin
2024-03-23 1:33 ` Daniel P. Smith
2024-02-14 22:18 ` [PATCH v8 02/15] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2024-02-14 22:18 ` [PATCH v8 03/15] x86: Secure Launch Kconfig Ross Philipson
2024-02-15 7:59 ` Ard Biesheuvel
2024-02-15 22:20 ` ross.philipson
2024-02-14 22:18 ` [PATCH v8 04/15] x86: Secure Launch Resource Table header file Ross Philipson
2024-02-15 8:08 ` Ard Biesheuvel
2024-02-22 2:03 ` Andrew Cooper
2024-02-22 2:10 ` ross.philipson
2024-02-22 17:49 ` ross.philipson
2024-03-29 22:38 ` Kim Phillips
2024-03-29 22:38 ` Kim Phillips
2024-03-29 22:38 ` Kim Phillips
2024-04-01 18:25 ` ross.philipson
2024-02-14 22:18 ` [PATCH v8 05/15] x86: Secure Launch main " Ross Philipson
2024-02-14 22:18 ` [PATCH v8 06/15] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2024-02-15 8:17 ` Ard Biesheuvel
2024-02-22 3:04 ` Andrew Cooper
2024-02-22 9:34 ` Ard Biesheuvel
2024-02-22 12:30 ` Andrew Cooper
2024-02-23 9:27 ` Ard Biesheuvel
2024-02-23 16:42 ` Andrew Cooper
2024-02-23 17:54 ` Eric Biggers
2024-02-23 18:20 ` Andrew Cooper
2024-02-23 18:30 ` Eric Biggers
2024-04-03 16:32 ` Andy Lutomirski
2024-04-03 23:56 ` Eric Biggers
2024-04-04 4:55 ` ross.philipson
2024-04-04 14:55 ` Jarkko Sakkinen
2024-02-14 22:18 ` [PATCH v8 07/15] x86: Secure Launch kernel early boot stub Ross Philipson
2024-02-15 8:29 ` Ard Biesheuvel
2024-02-15 22:26 ` ross.philipson
2024-02-14 22:18 ` [PATCH v8 08/15] x86: Secure Launch kernel late " Ross Philipson
2024-02-14 22:18 ` [PATCH v8 09/15] x86: Secure Launch SMP bringup support Ross Philipson
2024-02-14 22:18 ` [PATCH v8 10/15] kexec: Secure Launch kexec SEXIT support Ross Philipson
2024-02-14 22:18 ` [PATCH v8 11/15] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2024-02-14 22:18 ` [PATCH v8 12/15] tpm: Add ability to set the preferred locality the TPM chip uses Ross Philipson
2024-02-14 22:18 ` [PATCH v8 13/15] tpm: Add sysfs interface to allow setting and querying the preferred locality Ross Philipson
2024-02-14 22:18 ` [PATCH v8 14/15] x86: Secure Launch late initcall platform module Ross Philipson
2024-02-15 8:40 ` Ard Biesheuvel
2024-02-22 13:57 ` Daniel P. Smith [this message]
2024-02-23 9:36 ` Ard Biesheuvel
2024-03-21 14:11 ` Daniel P. Smith
2024-02-16 1:53 ` kernel test robot
2024-02-17 7:53 ` kernel test robot
2024-02-14 22:18 ` [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch Ross Philipson
2024-02-15 9:01 ` Ard Biesheuvel
2024-02-21 20:17 ` ross.philipson
2024-02-21 20:37 ` H. Peter Anvin
2024-02-21 23:24 ` Ard Biesheuvel
2024-02-17 7:31 ` kernel test robot
2024-02-17 20:06 ` kernel test robot
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=c5bd3ee4-4bf1-4e9a-8e5d-12ee8e195d3d@apertussolutions.com \
--to=dpsmith@apertussolutions.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kanth.ghatraju@oracle.com \
--cc=kexec@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=nivedita@alum.mit.edu \
--cc=peterhuewe@gmx.de \
--cc=ross.philipson@oracle.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 read-only IMAP folder(s) and NNTP newsgroup(s).