Why UEFI secure boot is difficult for Linux

I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit.
Secure boot requires that all code that can touch hardware be trusted
Right now, if you can run unstrusted code before the OS then you can subvert the OS. Secure boot gives you a mechanism for making sure you only run trusted code, which protects against that. So your UEFI drivers have to be signed, your bootloader has to be signed, and your bootloader must only load a signed kernel. If you've only booted trusted code then you know that your OS is safe. But, unlike trusted boot, secure boot provides no way for you to know that only trusted code was executed. That has to be ensured by OS policy.
-
- Login or register to post comments
Printer-friendly version
- 1232 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Events: Video Conferences, Code.gov, and LibreOffice
| GitLab Web IDE
|
Record Terminal Activity For Ubuntu 16.04 LTS Server
At times system administrators and developers need to use many, complex and lengthy commands in order to perform a critical task. Most of the users will copy those commands and output generated by those respective commands in a text file for review or future reference. Of course, “history” feature of the shell will help you in getting the list of commands used in the past but it won’t help in getting the output generated for those commands.
| Linux Kernel Maintainer Statistics
As part of preparing my last two talks at LCA on the kernel community, “Burning Down the Castle” and “Maintainers Don’t Scale”, I have looked into how the Kernel’s maintainer structure can be measured. One very interesting approach is looking at the pull request flows, for example done in the LWN article “How 4.4’s patches got to the mainline”. Note that in the linux kernel process, pull requests are only used to submit development from entire subsystems, not individual contributions. What I’m trying to work out here isn’t so much the overall patch flow, but focusing on how maintainers work, and how that’s different in different subsystems.
|
Recent comments
3 hours 4 min ago
3 hours 5 min ago
3 hours 6 min ago
6 hours 13 min ago
6 hours 24 min ago
13 hours 17 min ago
1 day 15 hours ago
1 day 16 hours ago
1 day 22 hours ago
2 days 23 hours ago