4 ms·

Naive question: Is Core Boot in any way a potential remedy for the sad, sorry situation we're in here? I wonder when there will become a market for manufacture

Naive question: Is Core Boot in any way a potential remedy for the sad, sorry situation we're in here? I wonder when there will become a market for manufacturers to start releasing devices with hardware DIP switches or jumpers that need to be bridged for flashing purposes.

pgeorgi 12y ago
coreboot has a very different architecture, and we try to avoid having it parse external data (except for hardware registers). It also has next to no presence during the runtime of the OS (no API for the OS to call into, and to exploit) - which is part of the "no external data" approach. It's also much smaller: A minimum UEFI for QEmu that can barely boot into Linux loaded from SATA is 120kloc, coreboot (plus payload) for the same purpose are about 20kloc. These differences should stop some of the exploit approaches right from the start. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. (Disclosure: I'm a coreboot developer and no fan of UEFI)
- userbinator 12y ago
  Motherboards were produced with flash write-enable jumpers around the end of the last century, but my guess is that the cost savings of omitting the part and not requiring users to physically move the switch whenever reflashing BIOS, combined with what seems to be now perpetually buggy BIOSes needing constant updates, made them disappear. I think it's still a good idea, however. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. How much data is this? I thought it'd be stored in the CMOS NVRAM, which could be a better design.
  - pgeorgi 12y ago
    CMOS NVRAM addresses 256 bytes (minus 16 for the clock). Unfortunately that's not enough. Maybe things could be stored smarter, given that the data should have some structure, but the raw format is ~2000 bytes, IIRC.
- MichaelGG 12y ago
  Wow, that sounds rather horrid! But it seems everyone is switching to UEFI, and MS was happily showing of ~2s boots due to it. Is the complexity because of bad engineering, or politics growing scope, cluelessness, maliciousness, just to keep competition (who?) out via barrier to entry, or what?
  - pgeorgi 12y ago
    In my opinion, it's * part bad engineering (I find their concept of loadable modules and a central dispatch mechanism that can override pretty much everything absolutely misplaced in the context of firmware), * part politics (the rumour mills claims one of the reasons UEFI was done in the first place instead of going for Open Firmware, which was an established standard back then, was to protect Intel's BIOS partners from having to compete in an existing ecosystem that was quite alive and dominated by others. also NIH), * part growing scope (Secure Boot locks down said dispatch mechanism through signatures when its inherent insecurity became an issue), * part cluelessness (Intel is good with silicon and processes, but generally not so good when it comes to software, and they shaped EFI and through that UEFI). I don't think there's malice involved, and the competitive angle is covered in politics. That it's pushed the way it is has lots of complex reasons. One is certainly pride (even if they wanted to, Intel can't simply back down after promoting that stuff for 15 years without losing face). It also doesn't help that the only realistic existing alternative for an OS-facing API remains BIOS (because OpenFirmware never really existed on x86 outside laptop.org), which has its own set of issues (even if they are all patchable with enough effort).
- nextos 12y ago
  I was about to ask about coreboot as well, but I am pretty ignorant about this part of the hardware stack. I came to know about coreboot thanks to Chromebooks. If one is security conscious, what laptops with good coreboot support do you recommend? A Chromebook Pixel? New Thinkpads seem not to be supported.
  - pgeorgi 12y ago
    The thinkpad support is mostly done by the free software part of the coreboot community, and they don't touch devices that come with a Management Engine (see http://me.bios.io/ http://me.bios.io/). If "security conscious" includes not having any unexplained binaries around, the Asus C201 Chromebook may actually be the best bet (maybe there will be devices with the same chipset but more laptop-like properties eg regarding storage), but it's less powerful than a contemporary Intel based device.
    - nextos 12y ago
      Thanks. Probably misunderstanding something, but I thought some Thinkpads that do have Coreboot support are equipped with Management Engine? http://www.coreboot.org/Intel_Management_Engine http://www.coreboot.org/Intel_Management_Engine
      - pgeorgi 12y ago
        Some chipsets before Sandy Bridge had that processor, but were able to operate normally without its firmware, with a disabled ME. Since Sandy Bridge it's mandatory.

pgeorgi 12y ago

coreboot has a very different architecture, and we try to avoid having it parse external data (except for hardware registers). It also has next to no presence during the runtime of the OS (no API for the OS to call into, and to exploit) - which is part of the "no external data" approach. It's also much smaller: A minimum UEFI for QEmu that can barely boot into Linux loaded from SATA is 120kloc, coreboot (plus payload) for the same purpose are about 20kloc. These differences should stop some of the exploit approaches right from the start. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. (Disclosure: I'm a coreboot developer and no fan of UEFI)

userbinator 12y ago
Motherboards were produced with flash write-enable jumpers around the end of the last century, but my guess is that the cost savings of omitting the part and not requiring users to physically move the switch whenever reflashing BIOS, combined with what seems to be now perpetually buggy BIOSes needing constant updates, made them disappear. I think it's still a good idea, however. Regarding the switches/jumpers, hardware is now complex enough to set up that a wakeup after suspend requires more data than what CPUs can store by themselves to revive memory without data loss. That data ends up in flash, so something needs to change in that area before a flash chip could be write protected with a jumper. How much data is this? I thought it'd be stored in the CMOS NVRAM, which could be a better design.
- pgeorgi 12y ago
  CMOS NVRAM addresses 256 bytes (minus 16 for the clock). Unfortunately that's not enough. Maybe things could be stored smarter, given that the data should have some structure, but the raw format is ~2000 bytes, IIRC.
MichaelGG 12y ago
Wow, that sounds rather horrid! But it seems everyone is switching to UEFI, and MS was happily showing of ~2s boots due to it. Is the complexity because of bad engineering, or politics growing scope, cluelessness, maliciousness, just to keep competition (who?) out via barrier to entry, or what?
- pgeorgi 12y ago
  In my opinion, it's * part bad engineering (I find their concept of loadable modules and a central dispatch mechanism that can override pretty much everything absolutely misplaced in the context of firmware), * part politics (the rumour mills claims one of the reasons UEFI was done in the first place instead of going for Open Firmware, which was an established standard back then, was to protect Intel's BIOS partners from having to compete in an existing ecosystem that was quite alive and dominated by others. also NIH), * part growing scope (Secure Boot locks down said dispatch mechanism through signatures when its inherent insecurity became an issue), * part cluelessness (Intel is good with silicon and processes, but generally not so good when it comes to software, and they shaped EFI and through that UEFI). I don't think there's malice involved, and the competitive angle is covered in politics. That it's pushed the way it is has lots of complex reasons. One is certainly pride (even if they wanted to, Intel can't simply back down after promoting that stuff for 15 years without losing face). It also doesn't help that the only realistic existing alternative for an OS-facing API remains BIOS (because OpenFirmware never really existed on x86 outside laptop.org), which has its own set of issues (even if they are all patchable with enough effort).
nextos 12y ago
I was about to ask about coreboot as well, but I am pretty ignorant about this part of the hardware stack. I came to know about coreboot thanks to Chromebooks. If one is security conscious, what laptops with good coreboot support do you recommend? A Chromebook Pixel? New Thinkpads seem not to be supported.
- pgeorgi 12y ago
  The thinkpad support is mostly done by the free software part of the coreboot community, and they don't touch devices that come with a Management Engine (see http://me.bios.io/ http://me.bios.io/). If "security conscious" includes not having any unexplained binaries around, the Asus C201 Chromebook may actually be the best bet (maybe there will be devices with the same chipset but more laptop-like properties eg regarding storage), but it's less powerful than a contemporary Intel based device.
  - nextos 12y ago
    Thanks. Probably misunderstanding something, but I thought some Thinkpads that do have Coreboot support are equipped with Management Engine? http://www.coreboot.org/Intel_Management_Engine http://www.coreboot.org/Intel_Management_Engine
    - pgeorgi 12y ago
      Some chipsets before Sandy Bridge had that processor, but were able to operate normally without its firmware, with a disabled ME. Since Sandy Bridge it's mandatory.