Re: Linux DRTM on UEFI platforms

[Daniel P. Smith]

On 7/7/22 23:36, Brendan Trotter wrote:
> Hi,
> 
> On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
> <dpsmith@apertussolutions.com> wrote:
>> On 7/5/22 20:03, Brendan Trotter wrote:
>> Greetings!
>>
>> Not sure why I got dropped from distro, but no worries.
>>
>>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
>>> <dpsmith@apertussolutions.com> 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
  2) potentially the ability to load files from disk if it is not
     acceptable for the bootloader to load the DCE (ACM/SLB)
  3) miscellaneous system evaluations, memory table, machine check, etc.

The only thing that is gained from such an approach is to make dynamic
launch for Linux be self-contained in the kernel. 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 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
  2) establishes an API that decouples pre- and post-launch
  3) reduces the complexity required to enable adoption by an OS
  4) zero reduction in the security properties of the architecture

> 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. 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.

[1] https://www.platformsecuritysummit.com/2018/speaker/smith/
[2]
https://events19.linuxfoundation.org/events/linux-security-summit-north-america-2019/program/schedule/
[3] https://lpc.events/event/7/contributions/739/
[4] https://lkml.org/lkml/2022/2/18/699