Three PC Brands Where SecureBoot On Linux Is Botched

[phoronix]

Phoronix: Three PC Brands Where SecureBoot On Linux Is Botched

Matthew Garrett has written a new article summarizing the state of UEFI/SecureBoot on Linux. Overall, the situation isn't good if you're using hardware from one of three major vendors...

http://www.phoronix.com/vr.php?view=MTI4OTc

[kwahoo]

Apropos Lenovo: Y and Z-series notebook need an ugly ACPI hack to enable Nvidia Optimus.

[RussianNeuroMancer]

Except Toshiba case, two other issues is just UEFI bugs (like many BIOS bugs we seen before) that not related to Secure Boot.

[Rexilion]

Sorry, couldn't resist. Make sure you read the title of the comment first.

[M1kkko]

Last time I heard, using secureboot was optional and one could disable it from BIOS settings. Is this still the case, and does it apply for these vendors?

[Sidicas]

Except Toshiba case, two other issues is just UEFI bugs (like many BIOS bugs we seen before) that not related to Secure Boot.

Yes, but if the BIOS bugs don't break Windows then they get binned as "low-priority".

I remember it took HP 4 months to fix their Envy series when it was released due to having huge empty holes or downright incorrect data in their ACPI tables which caused tons of problems on both linux and Windows... Much more so for linux for some reason or another, possibly because HP had tried to fix up some of the problems with their own custom driver patches for Windows to work-around a broken ACPI... Keep in mind, the Envy lineup is HP's consumer flagship product.. What did HP say? They said if you want to run linux you need to buy a "business-class laptop" such as the Pro-books or Elitebooks as linux isn't supported on their "home"/"consumer" models. These laptops can cost almost $1000 more for the exact same specs.

Granted, I've heard that HP actually provides fantastic US-based hardware support (including BIOS problems) for the Probooks and Elitebooks under linux.


I'm running a Dell Inspiron 15R Special Edition now and it runs Linux rock solid.. A couple of multimedia buttons don't work ("dell_wmi: unknown key)".. The key presses don't make it past X and don't appear to generate ACPI events either (nothing from acpi_listen)

The touchpad LED also didn't work by default, but that was just a matter of tweaking a script and getting it to run without prompting for a root password.. Now all documented in the wiki for my laptop.

Everything else on the laptop works flawlessly out of the box.

[grotgrot]

Last time I heard, using secureboot was optional ...

There seems to be a belief that secureboot has no value to Linux users (I'm not saying you share that). However it does have value and I wish I could use it everywhere. You could then be reassured that only operating systems and their kernels that you allow to run are in fact what is running. There has to be an unbroken chain of trust starting at the BIOS through the bootloaders, kernels and modules to establish that.

As a concrete example, I use dmcrypt on my laptop. I have to make /boot a separate unencrypted partition so that the kernel and initrd can be loaded into memory and executed by the BIOS. The initrd then asks for the encryption keys and is able to mount the root filesystem etc. You could trivially change the kernel on that partition and there is no way I would even know. The replacement could capture the encryption keys without me realising.

If you manage a whole bunch of servers in data centre, it would again be nice to know that only kernels you authorise can run on the systems.

[Rexilion]

There seems to be a belief that secureboot has no value to Linux users (I'm not saying you share that). However it does have value and I wish I could use it everywhere. You could then be reassured that only operating systems and their kernels that you allow to run are in fact what is running. There has to be an unbroken chain of trust starting at the BIOS through the bootloaders, kernels and modules to establish that.

As a concrete example, I use dmcrypt on my laptop. I have to make /boot a separate unencrypted partition so that the kernel and initrd can be loaded into memory and executed by the BIOS. The initrd then asks for the encryption keys and is able to mount the root filesystem etc. You could trivially change the kernel on that partition and there is no way I would even know. The replacement could capture the encryption keys without me realising.

If you manage a whole bunch of servers in data centre, it would again be nice to know that only kernels you authorise can run on the systems.

Yes, I imagine this going all the way through signed java browser plugins... and they are safe! am I right? ...

[TheLexMachine]

Last time I heard, using secureboot was optional and one could disable it from BIOS settings. Is this still the case, and does it apply for these vendors?

Yes, it is. That will likely change in the next few years though.

[Ex-Cyber]

Yes, it is. That will likely change in the next few years though.

I think the most likely scenario is that the option to disable it remains present, but Windows 9 or 10 will refuse to "activate" unless it's enabled. Not so much for Microsoft's sake (they'd rather have you using an illegal Windows system than a legal Linux system), but rather to enforce restrictions on Windows Store apps.