On Mi, 10.05.23 12:00, Neal Gompa (ngomp...@gmail.com) wrote:

> This proposal isn't better. Neither Windows nor macOS put critical
> operating system code in the ESP, and we shouldn't either.

This is nonsense. I am not sure what definition of "critical" you
have, but the ESP is the entrypoint to the OS, of course it contains
"critical" stuff in there, if you delete what windows places there you
cannot boot anymore.

> As soon as you throw UKIs in the mix, you've completely broken that
> because now the absolutely most valuable code for your system is in a
> "hostile" environment. At least we can make /boot authenticated and

"most valueable code"? what is that even supposed to mean?

> tamper resistant as a Btrfs subvolume.

What is a tamper resistent btrfs subvolume? I have not heard of such a
thing. And don't say "fsverity" now. Because that's really not
it. "fsverity" is not some secret sauce that you attach to an fs and
then it cannot be tempered with. It has a much more limited usecase
and requires userspace to first validate the file's metadata and it's
hash manually before using it.

Seriously, fsverity is not an answer for this. And you know what, the
person behind fsverity will tell you the same. (also here at lfsmmbpf,
and I can connect you if you want)

Moreover, you need to validate a complex file system before you access
it, it's too late if you do it the other way round. Hence, unless you
established trust in your btrfs fs *before* you go into and and look
for kernel you are not doing security, you are just doing nonsense.

> I would rather have a multi-stage boot process, where the first stage
> does just enough to unlock and load the OS volume to load the real
> boot environment.

And I'd like a pony!

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to