4 ms·

My knee-jerk reaction to this project is that it would be overall inferior to simply allowing coreboot to measure and boot the user's desired Linux distribution

by bri3d 8y ago

My knee-jerk reaction to this project is that it would be overall inferior to simply allowing coreboot to measure and boot the user's desired Linux distribution directly, and vastly inferior to a small first-stage bootloader written in a safer language than C. I still think that's mostly true - at the end of the day, you're introducing a second Linux distribution to maintain and audit into your bootchain. However, the 33c3 presentation about Heads at least presents a few decent arguments for using Linux : https://trmm.net/Heads_33c3#Philosophy_of_Heads https://trmm.net/Heads_33c3#Philosophy_of_Heads . Fundamentally I'm not sure I agree with the concept that Linux could be more robust, secure, audited, or hardened than an open-source miniaturized early stage bootloader audited by a good security research firm. I think the dated "more eyes makes more more secure software" concept has been fairly debunked at this stage and the path towards security will revolve around smaller trusted components written in a memory-safe language (i.e. not C).

bubblethink 8y ago
The other downside I see is that it rules out booting other operating systems (at least right now). Other than linux itself (and maybe freebsd?) you can't kexec from a running linux kernel to another OS.
- jacobush 8y ago
  But why couldn't you?
- nickik 8y ago
  You actually can.
  - bubblethink 8y ago
    How does one boot windows from a running linux kernel ?
    - Iolaum 8y ago
      I don't know the details but I recall that using linux as a bootloader was a potential threat the ChromeOS people wanted to block with some patches to the Linux kernel that tied it somehow to secure boot that the kernel maintainers (Linus himself commented on the issue as it was controversial) rejected at the form the patches had at the time. Here's a post, with some technical details, from one of the developers that were involved in the issue: https://mjg59.dreamwidth.org/50577.html https://mjg59.dreamwidth.org/50577.html
      - pjc50 8y ago
        I think there are two things being conflated here: - the "shim" bootloader: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloader_signed_with_Microsoft_key https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloa... - it's important that this can't be used to boot a Windows that thinks it's secure but isn't. - the "lockdown" patches you refer to. The goal of those is to maintain the attestation that the running kernel code is the code that was loaded through a signature chain. If you can modify the kernel at runtime, obviously the attestation has to be invalid. I don't think it's impossible to boot Windows from Linux, but doing so should result in Windows detecting that it's in insecure/unsigned mode.
- e12e 8y ago
  Not sure if this is current, but apparently you can kexec to grub4dos, an on to windows (i assume this won't work for W10 with secure boot enabled, though): http://reboot.pro/topic/7223-how-to-boot-directly-into-windows-from-kexecgrub4dos/ http://reboot.pro/topic/7223-how-to-boot-directly-into-windo...
derefr 8y ago
> a small first-stage bootloader written in a safer language than C Given that most of what a bootloader does is calling arch-specific opcodes to initialize the memory model et al (and C is used mostly because it can embed the assembler to make those calls, but also lets you break away from it now and then to do some complex math more readably [i.e. on named variables instead of using explicit registers]), what do you gain by using a language other than C? > written in a memory-safe language What does this even mean in bootloader land, when you're starting off in real mode without the GPT enabled, and writing to raw memory addresses rather than to any allocation known as "the heap" or "the stack" or "the data segment"?
- bri3d 8y ago
  Certainly escaping the hell that x86 puts you in early in the boot process requires a bit of assembler, yes. I think we're mostly talking past one another semantically if you believe that "most of what a bootloader does is calling arch-specific opcodes." Most projects I'm familiar with called "bootloader" (including coreboot, GRUB/LILO, etc.) are by and large, both by lines of code and complexity, focused on loading binary files from disk using a filesystem driver, parsing them (!!!), and then passing off execution - all tasks which are better handled by a language or framework where it's not so easy to make a parsing mistake which compromises an entire system. This is true especially once trust chain verification and cryptography are also thrown into the mix. Now that you've gotten me thinking about it as well, static verification of the real mode portion of a bootloader should be entirely possible. Although I'm not sure of a good toolset for doing so off the top of my head, there's nothing theoretically stopping someone from implementing a safe(ish) system which is capable of assembling software which could operate in real mode. Anyway, since it seems unclear: my main thesis is "introducing Linux to the trust verification part of your boot process seems rather ridiculous because it is a gigantic surface area implemented in a way that makes it exceptionally challenging to audit."
- gcb0 8y ago
  every compiled code is assembly. C was considered very high level, at some point in history. > What does this even mean in bootloader land that your disk encryption password input can't override the program data that will later on write to some bios memory address, for example. who knows? If I knew they wouldn't be undiscovered bugs, but CVEs :)
transpute 8y ago
You may be interested in TrenchBoot, https://github.com/TrenchBoot/documentation/blob/master/documentation/Architecture.md https://github.com/TrenchBoot/documentation/blob/master/docu...

by bri3d 8y ago

bubblethink 8y ago

The other downside I see is that it rules out booting other operating systems (at least right now). Other than linux itself (and maybe freebsd?) you can't kexec from a running linux kernel to another OS.

jacobush 8y ago
But why couldn't you?
nickik 8y ago
You actually can.
- bubblethink 8y ago
  How does one boot windows from a running linux kernel ?
  - Iolaum 8y ago
    I don't know the details but I recall that using linux as a bootloader was a potential threat the ChromeOS people wanted to block with some patches to the Linux kernel that tied it somehow to secure boot that the kernel maintainers (Linus himself commented on the issue as it was controversial) rejected at the form the patches had at the time. Here's a post, with some technical details, from one of the developers that were involved in the issue: https://mjg59.dreamwidth.org/50577.html https://mjg59.dreamwidth.org/50577.html
    - pjc50 8y ago
      I think there are two things being conflated here: - the "shim" bootloader: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloader_signed_with_Microsoft_key https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloa... - it's important that this can't be used to boot a Windows that thinks it's secure but isn't. - the "lockdown" patches you refer to. The goal of those is to maintain the attestation that the running kernel code is the code that was loaded through a signature chain. If you can modify the kernel at runtime, obviously the attestation has to be invalid. I don't think it's impossible to boot Windows from Linux, but doing so should result in Windows detecting that it's in insecure/unsigned mode.
e12e 8y ago
Not sure if this is current, but apparently you can kexec to grub4dos, an on to windows (i assume this won't work for W10 with secure boot enabled, though): http://reboot.pro/topic/7223-how-to-boot-directly-into-windows-from-kexecgrub4dos/ http://reboot.pro/topic/7223-how-to-boot-directly-into-windo...

derefr 8y ago

> a small first-stage bootloader written in a safer language than C Given that most of what a bootloader does is calling arch-specific opcodes to initialize the memory model et al (and C is used mostly because it can embed the assembler to make those calls, but also lets you break away from it now and then to do some complex math more readably [i.e. on named variables instead of using explicit registers]), what do you gain by using a language other than C? > written in a memory-safe language What does this even mean in bootloader land, when you're starting off in real mode without the GPT enabled, and writing to raw memory addresses rather than to any allocation known as "the heap" or "the stack" or "the data segment"?

bri3d 8y ago
Certainly escaping the hell that x86 puts you in early in the boot process requires a bit of assembler, yes. I think we're mostly talking past one another semantically if you believe that "most of what a bootloader does is calling arch-specific opcodes." Most projects I'm familiar with called "bootloader" (including coreboot, GRUB/LILO, etc.) are by and large, both by lines of code and complexity, focused on loading binary files from disk using a filesystem driver, parsing them (!!!), and then passing off execution - all tasks which are better handled by a language or framework where it's not so easy to make a parsing mistake which compromises an entire system. This is true especially once trust chain verification and cryptography are also thrown into the mix. Now that you've gotten me thinking about it as well, static verification of the real mode portion of a bootloader should be entirely possible. Although I'm not sure of a good toolset for doing so off the top of my head, there's nothing theoretically stopping someone from implementing a safe(ish) system which is capable of assembling software which could operate in real mode. Anyway, since it seems unclear: my main thesis is "introducing Linux to the trust verification part of your boot process seems rather ridiculous because it is a gigantic surface area implemented in a way that makes it exceptionally challenging to audit."
gcb0 8y ago
every compiled code is assembly. C was considered very high level, at some point in history. > What does this even mean in bootloader land that your disk encryption password input can't override the program data that will later on write to some bios memory address, for example. who knows? If I knew they wouldn't be undiscovered bugs, but CVEs :)

transpute 8y ago

You may be interested in TrenchBoot, https://github.com/TrenchBoot/documentation/blob/master/documentation/Architecture.md https://github.com/TrenchBoot/documentation/blob/master/docu...