Re: Linux DRTM on UEFI platforms
From: Daniel P. Smith
Date: Tue Aug 09 2022 - 06:55:27 EST
On 7/23/22 01:15, Brendan Trotter wrote:
Hi,
Greetings,
On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith
<dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
On 7/7/22 23:36, Brendan Trotter wrote:
On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
<dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
On 7/5/22 20:03, Brendan Trotter wrote:
On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
<dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59,
To help provide clarity, consider the following flows for comparison,
Normal/existing efi-stub:
EFI -> efi-stub -> head_64.S
Proposed secure launch:
EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S
For more clarity; the entire point is to ensure that the kernel only
has to trust itself and the CPU/TPM hardware (and does not have to
trust a potentially malicious boot loader)..Any attempt to avoid a
one-off solution for Linux is an attempt to weaken security.
Please elaborate so I might understand how this entrypoint allows for
the kernel to only trust itself and the CPU/TPM.
Is this a serious request?
Yes, it was serious because I found the statements to be terse and open
to interpretation. Specifically, when I read it, it almost seemed that
the position is that dynamic launch is not needed, and that the kernel
could just establish its own RoT.
Kernel is started (via. firmware using the kernel's efi-stub, or via.
"kexec()", or..); and regardless of how the kernel was started the
kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or
Intel's TXT, followed by measuring the remainder of itself and
anything passed from firmware like APCI tables) without relying on a
call-back provided by "untrusted by kernel" third-parties that don't
exist in most cases. The dynamic root of trust that kernel creates
depends on the kernel, CPU, TPM, etc (and excludes untrusted and
unnecessary third parties)..
This clarifies the previous statements and I would say, yes, this is one
approach. Considering the challenges we have/are facing in getting a
minimal post-launch handling (sl-stub) into the setup kernel, I would be
hard-pressed to believe adding all the pre-launch handling would be
found to be acceptable. If the intent is to have it completely
self-contained, this would require,
1) the introduction of a TPM driver into the setup kernel, a hole I
would rather not go down again
..which is no more work than the introduction of a TPM driver into one
boot loader (probably less so, as Linux already has TPM drivers that
are used later), and significantly less work than introducing a TPM
driver into many boot loaders.
Already been there and no it is not as straight forward as one may
think. A minimal driver was attempted but rejected by the TPM
maintainers with the requirement to reuse the existing driver code. So
we would gladly welcome someone to come rewrite the TPM drive.
Specifically to de-tangle the core TPM interface code away from all of
its kernel proper dependencies so that it can be used by both the setup
kernel and the kernel proper.
Note that to do this well (with some protection against malicious
devices) you'd disable all PCI devices, then set up IOMMU as "allow
the least possible", then establish a dynamic root of trust, then
enable and allow individual devices only if/when their driver is
started by kernel and not sooner. Without doing it like this there's
less guarantee that the code/data being measured is the same as the
code/data being executed/used (as a malicious device can modify
anything before it's measured, restore the original extremely briefly
while measurement is done, then modify anything after it's measured
and before it's used). Also note that I mean "some protection" and not
100% protection (it's unsolvable unless firmware uses an "allow the
least necessary by default" strategy) but "some protection" is better
than none.
In other words; it isn't necessarily just TPM driver alone that would
need to be started "earlier" (ideally it's also IOMMU and PCI
enumeration too). However, "earlier" is "earlier than the
establishment of dynamic root of trust"; which can be achieved by
moving the establishment of dynamic root of trust to a later stage
(rather than bringing things like TPM driver to an earlier stage)..
With all due respect, the statement above demonstrates a clear lack of
understanding how the hardware dynamic launch works. I have written a
summary[1], with links to details, of how the process works. It is
highly recommended this is read, as well as the referenced sections in
Intel's SDM and AMD's APM.
2) potentially the ability to load files from disk if it is not
acceptable for the bootloader to load the DCE (ACM/SLB)
..which is both unnecessary and ill-advised.
See [1]
3) miscellaneous system evaluations, memory table, machine check, etc.
..which is the same regardless of where it's done.
The only thing that is gained from such an approach is to make dynamic
launch for Linux be self-contained in the kernel.
Making it self-contained in the kernel means:
a) it actually works, for the most important use case (where UEFI
firmware boots Linux's efi-stub directly)
b) it actually works, for other use cases (booted via. "kexec()",
booted from LILO, booted from ELILO, ...).
c) It continues to work; even when you change/update/install/remove a
boot manager (which would otherwise change the measurement and break
anything that depended on the measurement).
d) it's more portable (e.g. easier to port to ARM/Uboot, etc)
e) It's more likely to actually be used by end-users (can just install
a kernel like normal without extra pages of instructions on how to
install and configure unnecessary bootware)
f) It'll be peer reviewed by more people
The hook approach does all of this.
It does not reduce the
TCB because the whole design of the dynamic launch is to provide a
controlled process that establishes a new trust chain/TCB that is
started from an untrusted state. Specifically, dynamic launch starts
with the CPU being provided all the material for the process by
untrusted code that is currently in control at the time the launch is
initiated.
The whole design of dynamic launch is to establish a new trust chain
that doesn't depend on an untrusted boot loader (or anything that came
before it - firmware, etc). If the "dynamic root of trust" is
established by boot loader then it partially suffers the same problems
as a static root of trust.
See [1]
The only potential benefit that the callback solution provides is that
it, in theory, it could reduce duplication of work for other operating
systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same
callback instead of doing it themselves); but previous discussions
(talk of formalising the contract between the boot stub and the Linux
kernel) suggest that you aren't interested in any other OS.
With all due respect, but this is where I would have to disagree. There
is substantial benefit,
1) a single code base that needs to be reviewed vs multiple OS
specific versions
If you wanted to minimize code duplication you'd implement it as an
open source library (with a non-restrictive licence like MIT) so that
the code can be used by all the different boot loaders instead of
duplicated by each different boot loader, in addition to being used by
all the different operating systems/kernels.
I completely agree and my intent is to get there eventually.
2) establishes an API that decouples pre- and post-launch
..by providing a call-back that kernel uses post-launch to call an API
from pre-launch, that couples pre- and post-launch more than has ever
been done before?
That is not what is being proposed.
3) reduces the complexity required to enable adoption by an OS
There's only one OS that uses the Linux Boot Protocol. Any other OS
(FreeBSD, Fuschia, Haiku, ...) has to radically change everything
about how it boots before it can think about adopting your Linux
specific solution. Is there even a proposal to add support to GRUB
developers' own multi-boot specification (to "enable easy adoption" by
Solaris and its forks)?
Building it directly into the Linux kernel would make adoption by
other operating systems easier, as they wouldn't need to change their
boot code and most of them are used to porting code from Linux anway.
Nothing in this proposal binds it to the Linux Boot Protocol.
4) zero reduction in the security properties of the architecture
It's a huge reduction in the security properties. It allows a "just
lie and measure nothing" boot loader to be (pre)installed,, tricking
the kernel into thinking there's security when there is none.
See [1].
This leaves me wondering what your true motivation is. Are you trying
to benefit GRUB/Trenchboot (at the expense of security, end-user
convenience, distro installer hassle, etc); or trying to manufacture
scope for future man-in-the middle attacks (by promoting a solution
that requires something between firmware and kernel)?
As a loyal member of the tinfoil hat brigade, I will always advocate for
accept nothing and question everything. All I can ask is to evaluate the
technical merit of the presentations [1][2][3] and the patch series [4].
If there is anything concerning with the theory or the implementation,
then it should be raised so that it may be addressed. A means to do so
is the "what if" game, as it is great to formulate a hypothesis. In this
case, the "what if" postulated is the assumption that the approach is to
allow a future MitM attack.
How quickly could a disgruntled system administrator (or someone
selling computers with a Linux distro pre-installed, or anyone trying
to circumvent a company's digital rights management scheme that
happens to rely on DRTM for remote attestation, or...) break your
security in a way that survives kernel updates?
My estimate is that it'd take about 5 minutes to download the boot
loader's open source code then 10 minutes to modify it.
The only real safeguard against this is UEFI's Secure Boot, which
doesn't work on old computers or most "non-8086" computers, doesn't
work if an attacker can install their own secure boot keys, and
doesn't work in most virtual machines.
See [1].
Then the challenge is to examine the
process, their underlying mechanism, and the security properties of
those mechanisms to see if a MitM can be discerned. I will gladly engage
with anyone that presents an analysis demonstrating an assumption I
made/missed that opens the possibility for subversion of the launch
integrity attempting to be built.
Surely it'd be easier for kernel to ignore the bootloader's
"untrustworthy dynamic root of trust" (and establish its own
"trustworthy dynamic root of trust") than it would be for kernel to
detect a MiTM boot loader.
See [1].
- Brendan
[1] https://trenchboot.org/documentation/Late_Launch_Overview/