Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd: Show boot type in overview card #20235

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jelly
Copy link
Member

@jelly jelly commented Mar 28, 2024

When on x86_64 or ARM64 find out if we are booting from EFI or legacy boot and if we have secure boot enabled.

Secure boot is supported in ARM64 either natively in professional hardware or via U-Boot which provides an EFI implementation with secure boot.

image

When on x86_64 or ARM64 find out if we are booting from EFI or legacy
boot and if we have secure boot enabled.

Secure boot is supported in ARM64 either natively in professional
hardware or via U-Boot which provides an EFI implementation with secure
boot.

Co-Authored-By: leomoty <leomoty@gmail.com>
@jelly jelly added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Mar 28, 2024
@martinpitt
Copy link
Member

TBH this feels a little too "prominent/expensive". This isn't something that would/should ever change on a system, no? Could this perhaps be moved to the hwinfo page or so?

@jelly
Copy link
Member Author

jelly commented Apr 8, 2024

TBH this feels a little too "prominent/expensive". This isn't something that would/should ever change on a system, no? Could this perhaps be moved to the hwinfo page or so?

There was an argument against it in #19371

@garrett
Copy link
Member

garrett commented Apr 18, 2024

It's a detail, sure. It's also a security setting to help prevent bootloader and unsigned kernel attacks. And you probably want to know if secure boot is available, but not enabled.

Imagine an admin with multiple machines. They want to make sure secure boot is turned on when possible. Diving into sub-pages is not ideal for this.

Ideally, it's something that wouldn't change on a system. However, if it is different on a system, that could indicate a problem. For an example, on my desktop: I had a UEFI update that turned off secure boot on my desktop and I only noticed when I was looking through GNOME Settings and was confused as to why it was off. Had GNOME not shown that in the settings, I wouldn't have ever known and wouldn't have fixed it and would have assumed my computer was still booting with secure boot on (which is how I set it up).

On a server with multiple people having admin access, someone could've accidentally turned it off or not set it from the beginning (in addition to my example above where a firmware update turned it off). Someone could've also intentionally turned off secure boot for whatever other reasons, such as using a custom kernel or unsigned custom distribution. And someone could've also turned it off for nefarious purposes too.

Taking all of this into consideration, should it be on the overview card? Maybe. Should it be shown in the health card as a warning in some circumstances? Also maybe. Is only having it in the details sub-page a good idea? I'm not sure. I do agree that this is rather prominent for something that shouldn't (and usually wouldn't) change, but I can understand why someone would want to know this information at a high level, especially when they have more than one system.

@jelly
Copy link
Member Author

jelly commented Apr 29, 2024

Alternatively we use bootctl to obtain secure boot info systemd/systemd#31856

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-test For doc/workflow changes, or experiments which don't need a full CI run,
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants