Re: Trusted kernel patchset

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> I really think "trusted" is the right term here. It's about as
> accurate as possible for what this flag means. In the same way that

verified perhaps - however its bikeshedding territory and I don't care
that much 8)

> > I'm kind of torn on this - yes, there are deployment scenarios where
> > hibernation can be used to circumvent the restrictions, but there are
> > also scenarios where that can be avoided (eg, the bootloader verifies
> > some state with respect to the hibernation image).
> 
> We have no system yet to validate hibernation images, so it's correct
> to disable hibernation images that lack validation (which is all of
> them).

Agreed.

> > Good point. In general there's also the risk that GPIOs may be used for
> > features like TPM physical presence detection, so exposing those to
> > userspace does seem like a bad idea.
> 
> Possibly the SPI driver too.

SPI and I2C from userspace are both good candidates. The devices are not
DMA but often it does include power management ICs. On many phones it
would however break assorted evilware binary userspace drivers not that I
care.

> I still say that a trusted kernel includes its boot parameters. This
> is true in the Chrome OS case, as parameters are part of the verified
> kernel boot block, but it could be a concern for someone who has built
> a grub-based CDROM or something and didn't lock the grub menu down. I
> think, though, that those things need to be part of documentation, not
> code, as this point.

I think we need to clearly document the assumption. Who owns validating
boot parameters, is there an assumption that boot parameters are safe, do
we need a whitelist to make it user friendly (eg turning off rhgb quiet
and adding debug init=/bin/sh every time systemd s**ts itself).

Alan