10 ms·
Coreboot Blocked from Recent Thinkpads by Intel Boot Guard
- voltagex_ 12y agoOriginal mailing list thread: http://www.coreboot.org/pipermail/coreboot/2015-February/thread.html#79207 http://www.coreboot.org/pipermail/coreboot/2015-February/thr... Scary times indeed.
- aortega 12y agohttp://www.coreboot.org/pipermail/coreboot/2015-February/079208.html http://www.coreboot.org/pipermail/coreboot/2015-February/079... >This means the OEM are fusing SHA256 public key hashes into the southbridge. SHA256 public keys, scary indeed.
- Buge 12y agoSHA256 public key hashes
- aortega 12y agoMaybe they meant "HMAC" or "Fingerprint".
- Dylan16807 12y agoYou don't need an HMAC to verify a key or other blob of data, and isn't fingerprint a less technical term for hash?
- geofft 12y ago"Hash" is a perfectly valid term, although "fingerprint" would also be correct. "HMAC" is something else entirely.
- pgeorgi 12y agoIntel likes to use SHA256(pubkey) for their verification schemes. I guess that reduces the amount of storage while sufficiently secure. Details are in http://apress.com/9781430265719 http://apress.com/9781430265719
- yuhong 12y agoWhen this came up on Phoronix, I suggested a jumper to disable it.
- micro-ram 12y agoSecond this. Put a switch under the memory door. Problem solved.
- contingencies 12y agoWhile we're at it, we need something similarly physical for IPMI BMCs.
- walterbell 12y agoLenovo Broadwell devices are attempting to dig themselves out of the hole caused by Haswell trackpads. Probably not a good time to cripple them. How would Lenovo react if Broadwell devices began receiving many service calls under warranty? Presumably the lock could be changed by a motherboard replacement. Related article, http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modifying-your-pcs-firmware.html http://www.pcworld.com/article/2883903/how-intel-and-pc-make..., ".. New thinkpad's can't be used anymore for coreboot. Especially the U and Y Intel CPU Series. They come with Intel Boot Guard and you are won't be able to boot anything which is unsigned and not approved by OEM. This means the OEM are fusing SHA256 public key hashes into the southbridge. ... to their credit, Intel does allow PC manufacturers to configure the hardware in a different way. The real way to get that open hardware seems to be to build it from scratch and make the right decisions along the way, as Purism is trying to do. If you want this sort of open hardware, be prepared to vote with your wallet." Purism: https://www.crowdsupply.com/purism/librem-laptop https://www.crowdsupply.com/purism/librem-laptop
- yuhong 12y agoAt least this did not get as much backlash as Superfish did.
- walterbell 12y agoBroadwell Thinkpads were announced a month ago, I wonder how many have shipped already? Superfish affected many Lenovo devices.
- 12y ago
- ppereira 12y agoI have no problem with a cryptographically verified boot process, so long as I control the key or verification step. Unfortunately, Intel stripped this freedom from CPU owners by allowing OEMs to lock down the boot process in a manner that cannot be bypassed. Soon Coreboot will be all but dead for machines with Intel processors -- other than Chromebooks which ship with Coreboot. Owners will have to accept the bios that vendors give us. The UEFI legacy boot option also seems to be on its way out, so I expect there will be fewer OS choices in our future too.
- yuhong 12y agoI don't think the option to disable Secure Boot is going anywhere at this point though.
- walterbell 12y agoEdit: Measured boot (DRTM, e.g. implemented by Qubes) has some benefits over "Secure Boot" (SRTM), both for firmware modification and key management. http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modifying-your-pcs-firmware.html http://www.pcworld.com/article/2883903/how-intel-and-pc-make..., "There’s also a second option: “Measured Boot” mode, where the hardware securely stores information about the boot process in a trusted platform module (TPM) or Intel Platform Trust Technology (PTT). The operating system could then examine this information, and—if there was a problem—present an error to the user. More on DRTM & SRTM: http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html http://theinvisiblethings.blogspot.com/2011/09/anti-evil-mai...
- geofft 12y ago"Secure Boot" and "SRTM" are different things. Secure Boot is a facility of UEFI, the firmware, to restrict which bootloaders and OSes can load, and prevent them from loading if a signature check fails. It makes sure that the firmware knows and trusts the OS. "SRTM" is a facility of the TPM to inspect what firmware and bootloaders have already loaded and executed, and refuse to unlock an encryption key, attest to the network, etc. if the hashes don't match. It requires a TPM (Secure Boot does not), and crucially it cannot prevent anything from running. It can just refuse to do cryptographic operations depending on what has run. It makes sure that the OS knows and trusts the firmware. They both have the effect of blocking boot sector malware (although from opposite directions), but the way that they work, the requirements for setting them up, the flexibility you get, and the other threats they defend against are rather different. And complementary, it's often a good plan to use them together to tie a nice knot. ("Boot Guard," the topic of this article, is something else entirely, where the hardware checks the signature on the firwmare. The firmware in turn can Secure Boot if it wants.)
- userbinator 12y agoFirst it was "secure boot", now it's "boot guard"? It seems that the PC, which was once a very open platform (IBM published schematics and the source code of the BIOS up to the PC/AT), is gradually becoming another locked-down walled-garden ecosystem. The worst part is that the masses are going to think these anti-user measures are helping them, "because security". They'll see only the "prevents hackers" part being advertised and agree wholeheartedly, or even if they realise that it means they won't be able to choose the firmware they run, they'll shrug it off as "I'm basically never going to do that, so why should it matter to me?" The majority have spoken for security over freedom, and lead us down this path, where eventually almost no one will own the computers they use, or be allowed to do anything with them (including write software) except as permitted by the organisations that control them. This is really, really scary. It's quite reminiscent of the dystopia in Stallman's "The Right to Read": https://www.gnu.org/philosophy/right-to-read.html https://www.gnu.org/philosophy/right-to-read.html It won't be easy to turn the situation around, but if anything I believe it will have to start with education - to reverse the brainwashing that companies and governments have propagated, and show people the power they can have when they control their computing devices. It is particularly hard when the majority are barely computer-literate, and there is vested interest in keeping them that way. I don't think the situation has gotten to the point where it's necessary to stockpile older and freer computers, but that could be an option in the future. However, I'm certainly not going to be replacing my Thinkpad X60 with anything else for as long as possible. I think this famous quote really needs to be made more aware of among those preparing to fight against the war on general-purpose computing: "Those who give up freedom for security deserve neither."
- lqdc13 12y agoI don't think education is the answer. There is no great conspiracy to keep people computer-illiterate. Most people follow the path of least resistance. We just have to make sure that path involves open technologies. This can be done either through other technologies or through laws.
- geofft 12y agoSecure Boot doesn't build a walled garden if implemented the way it generally is on x86: anyone physically present at boot time can add and remove keys or just disable it (unless someone's set a firmware password). The way it's typically implemented on ARM is a walled garden, but that's not inherent to the technology, nor is it required for the security benefits. Boot Guard, evidently, doesn't require building a walled garden, either, according to this article. You can use it to securely attest to the signature on the firmware, and seal your hard drive's encryption key to that attestation. That way an unauthorized modification to the firmware won't result in your private data being stolen, but the computer remains usable with an intentional modification to the firmware, whether it's Coreboot or a manual binary patch or whatever. Freedom and security shouldn't be a tradeoff. Security includes making sure authorized use of the system is permitted. Freedom involves making sure that my computer isn't acting against my interests. We need to stop portraying this as a tradeoff, and we should make it clear that we'll accept (and maybe even demand) security when it is done in the service of computing freedom. (x86) Secure Boot was a big step forward here for both freedom and security: it lets me make sure that only an OS I choose runs on my machine, and that no nonfree OS, not even the one that came with the computer, will boot up unless I want it to. It also (obviously) played well into the security demands of the wider market. We should be demanding more things like Secure Boot, alongside fewer things like Boot Guard.
- gygygy 12y agoLadies and gentleman lenovo.
- deleted 12y ago[deleted]
- progman 12y agoThat's why I always emphasize that TPM (UEFI/SecureBoot/Boot Guard etc.) are not the right way for open source systems (Linux etc.). The Linux community should stop to fiddle with locked-down boot systems. They actually should boycott locked-down systems and only support hardware vendors who officially support Linux. Many of them are presented at LinuxGizmos. I believe that such hardware vendors are much more open to the demands of the Opensource Community than vendors who produce locked-down systems. http://linuxgizmos.com http://linuxgizmos.com
- geofft 12y ago> TPM (UEFI/SecureBoot/Boot Guard etc.) These are four different technologies. Some of them help your freedom. Some of them hurt it. Some of them have nothing to do with your freedom at all. It doesn't really do anyone any favors to lump them all in the same category; it certainly doesn't make hardware vendors inclined to think you're making cogent arguments.
- NeutronBoy 12y agoUEFI has nothing to do with secure boot (apart from the fact they're compatible). I run Linux on my Thinkpad, with UEFI-only enabled, secure boot disabled, and UEFI will boot my kernel directly using EFISTUB - no more screwing around with bootloaders. It's awesome! There's even ways to use SecureBoot with various distros [1]. Sure it's a pain, but it can be done. Having and using teh tech is a different issue from vendors hindering what you can do with your hardware. [1] http://www.rodsbooks.com/efi-bootloaders/secureboot.html http://www.rodsbooks.com/efi-bootloaders/secureboot.html
- xkiwi 12y agoI recently purchase a Dell Inspiron Laptop which gave me a nightmare to install Windows 7 on it. The "secure Boot" isn't to secure the boot against rootkit, but secure from "unauthorized" or "unsupported" install your favorite operate system. In this case, I cannot install windows 7 on my brand new laptop. I still remember the SIM card lock from carriers years ago, so if i am the vigilant, I am going to ask users to pay upfront to unlock "Secure Lock" so that they can install another operate system.