On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <[email protected]> wrote:
> > The EFI stub carries out a bunch of actions that have meaningful
> > security impact, and that's material that should be measured. Having the
> > secure launch kernel execute the stub without awareness of what it does
> > means it would need to measure the code without measuring the state,
> > while the goal of DRTM solutions is to measure state rather than the
> > code.
>
> But how is that any different from the early kernel code?
From a conceptual perspective we've thought of the EFI stub as being
logically part of the bootloader rather than the early kernel, and the
bootloader is a point where the line is drawn. My guy feeling is that
jumping into the secure kernel environment before EBS has been called is
likely to end badly.
On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <[email protected]> wrote:
>
> On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote:
> > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <[email protected]> wrote:
> > > The EFI stub carries out a bunch of actions that have meaningful
> > > security impact, and that's material that should be measured. Having the
> > > secure launch kernel execute the stub without awareness of what it does
> > > means it would need to measure the code without measuring the state,
> > > while the goal of DRTM solutions is to measure state rather than the
> > > code.
> >
> > But how is that any different from the early kernel code?
>
> From a conceptual perspective we've thought of the EFI stub as being
> logically part of the bootloader rather than the early kernel, and the
> bootloader is a point where the line is drawn. My guy feeling is that
> jumping into the secure kernel environment before EBS has been called is
> likely to end badly.
If you jump back into the system firmware, sure.
But the point I was trying to make is that you can replace that with
your own minimal implementation of EFI that just exposes a memory map
and some protocols and nothing else, and then the secure launch kernel
would be entirely in charge of the execution environment.
In fact, I have been experimenting with running the EFI stub
unprivileged on arm64, which would give the secure launch kernel very
tight control over what goes on between the stub entry and
ExitBootServices(). I would be happy to entertain patches that remove
any issues that complicate running the stub unprivileged for x86 or
other architectures.
On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <[email protected]> wrote:
> > From a conceptual perspective we've thought of the EFI stub as being
> > logically part of the bootloader rather than the early kernel, and the
> > bootloader is a point where the line is drawn. My guy feeling is that
> > jumping into the secure kernel environment before EBS has been called is
> > likely to end badly.
>
> If you jump back into the system firmware, sure.
>
> But the point I was trying to make is that you can replace that with
> your own minimal implementation of EFI that just exposes a memory map
> and some protocols and nothing else, and then the secure launch kernel
> would be entirely in charge of the execution environment.
We can't just replace system firmware with an imitation of the same -
for instance, configuring the cold boot prevention memory overwrite
requires us to pass a variable through to the real firmware, and that's
something that we do in the stub.