6 ms·

Do people realize what they are doing here? I'm happy not touching my Windows kernel, stuff generally just works. Stuff never just works on Linux. And now the l

Do people realize what they are doing here? I'm happy not touching my Windows kernel, stuff generally just works. Stuff never just works on Linux. And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. Because it makes it impossible to do things that on Linux are still a monthly requirement. Not to mention the impact this stuff has on kernel and driver development. Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it. Right now, this should be strictly the domain of Google and Amazon that can actually have a trusted chain from bootloader to userland. Not enabled on any vanilla Ubuntu because hey, we detected UEFI!

segfaultbuserr 7y ago
> And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. There is no conspiracy here. The option you are looking for is in your BIOS/UEFI, not in the OS. You should have known better and read the fucking manual. Your machine comes with Secure Boot enabled by default, by the policy of Secure Boot, there are two possible outcomes. 1. If the OS doesn't support Secure Boot, you cannot boot the OS until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). 2. If the OS supports Secure Boot and signed by a big firm, you can boot it by default, but by the policy, it cannot execute any unsigned driver until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). By supporting Secure Boot, Ubuntu has made OS installation works out-of-the-box, otherwise you cannot even install the system (if so, I bet you'll complain how Ubuntu is gone for you, and how free and open source has terrible user experience - due to its absurd priority on the notation of freedom, does not even boot, and blablabla). TL;DR: Your rants are unwarranted. You can always disable Secure Boot, try disabling it first. If the UEFI on your PC doesn't allow you to disable Secure Boot, you can write a warranted angry post then, the conspiracy would be real (there used to be some evil embedded/tablet PCs that did this), otherwise it's not - you are free to disable Secure Boot, adding your signing key, optionally, even deleting Microsoft's signing key to fully control Secure Boot under your own discretion in the vast majority of PCs. > Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. This is plain falsehood. Again, read the manual from Microsoft: If Secure Boot is enabled, you cannot boot into a development mode - the BCD setting is disabled. Windows does not allow you to modify your system as you wish. You cannot run, develop, or debug an unsigned kernel-mode driver unless you disable Secure Boot [0]. Disclaimer: I run Linux/BSD exclusively, I don't do any development on Windows, don't take my words for it, instead, check my citations to Microsoft's documentation. It's for Windows 8 32-bit that happened to be the first hit in my search, but I believe the policies are the same in Windows 10. Finally, locking down a system is not only used for DRM. Maybe you don't want it on a PC, but it's often desirable in production systems. For example, on my server, I completely disabled kernel modules, hotpatching, /dev/mem, etc., so that no code can even be loaded into the kernel (other people do the opposite, it's a tradeoff between uptime and security). There may still be some exploits that make it possible - PaX/grsecurity has better countermeasures and blocks additional attack vectors - but it's not available to the general public anymore. [0] https://docs.microsoft.com/en-us/windows/win32/w8cookbook/secured-boot-signing-requirements-for-kernel-mode-drivers https://docs.microsoft.com/en-us/windows/win32/w8cookbook/se...
cyphar 7y ago
If you're using a modern machine, then you probably are using Secure Boot. For better or worse, Secure Boot requires Microsoft[+] to sign your binaries and they have certain requirements which you cannot break or they will revoke the signature. One of these requirements is that you cannot have a signed binary load unsigned code into ring-0. So (ignoring whether these features are useful or good) in order to be able to run Linux on modern hardware these types of features are necessary. And I'm sure you'd be just as annoyed if you couldn't run Ubuntu on a machine that was less than 6-8 years old. > I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it. It's a shame you didn't manage to find it, because it's pretty trivial to create your own signing keys and enroll them in the MOK. You can then use those to sign your kernels. You just need the sbsign package. If you want to just turn it all off, it's even more trivial -- go into your BIOS and disable Secure Boot. I would hope someone who wishes to do some kernel development would be able to overcome this fairly minor hurdle. [+] Technically it's whoever owns the keys that the manufacturer has approved to run software on the machine. On basically all modern machines that list is just "Microsoft" but you can enroll your own keys or remove Microsoft's keys if you want.
- tomatocracy 7y ago
  > One of these requirements is that you cannot have a signed binary load unsigned code into ring-0. I think the requirement is slightly looser - MS won't sign binaries which in turn allow arbitrary unsigned binaries to be loaded/run at ring-0 without any user interaction/confirmation. The shim and PreLoader loaders used by most Linux distributions allow you to boot arbitrary ring-0 code by requiring user interaction first, and both have been signed by Microsoft. The distribution-specific versions of shim/PreLoader also usually allow booting any code signed by the distribution's own key without needing to enroll that in the MOK. The process you need to go through, as you describe, is to use shim/PreLoader to first enroll the hashes/keys you want into the MOK variable, then after that's been done once it will all happen without interaction.
- CameronNemo 7y ago
  >it's pretty trivial to create your own signing keys and enroll them in the MOK Aleksa, I know you are probably aware, but if keys can be added by a user then the mechanism is not really achieving verified boot. The keys need to be burned into a read only portion of memory if we hope to protect against evil maid style attacks. Unfortunately this conflicts with the "user freedom" side of the hardware. Wish there was a good solution for device owners and only device owners to own their keys.
skummetmaelk 7y ago
> Stuff never just works on Linux This is the worst argument ever because it carries the false pretense that stuff "just works" on Windows and MacOS which is blatantly false. Just yesterday I had to use regedit on Windows to stop its auto update from overwriting my manually installed video drivers. The only way to stop windows from doing that is to stop it from updating _all_ drivers. How dumb is that? Which normal user can figure out that this is why their video performance suddenly goes into the gutter?
- jbverschoor 7y ago
  A normal user shouldn't have to install a driver manually
  - shrimp_emoji 7y ago
    I can't remember when I needed to install a driver on Linux (e.g., GPU drivers come in with system updates). I can remember when I needed to install a driver on Windows (any GeForce XpErIeNcErS???).
  - Hendrikto 7y ago
    Read his comment… Windows auto update fucked things up. This problem would be even worse for users who never installed a driver manually, as they have no idea at all why things suddenly run worse.
    - jbverschoor 7y ago
      If he didn't have to install drivers, because they're available / checked, then it wouldn't have messed things up. On macOS, I have 0 need to install drivers. On windows, I'm not sure because I haven't used it in such a while, but afaic remember, windowsupdate has updated drivers suppiled by vendors. And that actually works. His comment is similar to: I compiled a kernel modulue, and loaded it. When I do my regular uprade / dist-upgrade, and now I'm stuck with a vanilla drivers. The only way I can fix this is to alter the Makefiles, and compile from scratch. Oh look.. 1 google gives the exact situation actually: https://askubuntu.com/questions/492217/nvidia-driver-reset-after-each-kernel-update https://askubuntu.com/questions/492217/nvidia-driver-reset-a...

segfaultbuserr 7y ago

> And now the last time I tried to load a kernel module I had built for my Ubuntu system, it refused because, duh, it wasn't signed by some UEFI key I had never even seen. So now of course, the Ubuntu is fucking gone. There is no conspiracy here. The option you are looking for is in your BIOS/UEFI, not in the OS. You should have known better and read the fucking manual. Your machine comes with Secure Boot enabled by default, by the policy of Secure Boot, there are two possible outcomes. 1. If the OS doesn't support Secure Boot, you cannot boot the OS until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). 2. If the OS supports Secure Boot and signed by a big firm, you can boot it by default, but by the policy, it cannot execute any unsigned driver until Secure Boot is disabled (or you add your own signing key to BIOS/UEFI). By supporting Secure Boot, Ubuntu has made OS installation works out-of-the-box, otherwise you cannot even install the system (if so, I bet you'll complain how Ubuntu is gone for you, and how free and open source has terrible user experience - due to its absurd priority on the notation of freedom, does not even boot, and blablabla). TL;DR: Your rants are unwarranted. You can always disable Secure Boot, try disabling it first. If the UEFI on your PC doesn't allow you to disable Secure Boot, you can write a warranted angry post then, the conspiracy would be real (there used to be some evil embedded/tablet PCs that did this), otherwise it's not - you are free to disable Secure Boot, adding your signing key, optionally, even deleting Microsoft's signing key to fully control Secure Boot under your own discretion in the vast majority of PCs. > Even Windows you can just boot into a development mode and it might scream at you on the desktop, but it will allow you to modify your system as you wish. This is plain falsehood. Again, read the manual from Microsoft: If Secure Boot is enabled, you cannot boot into a development mode - the BCD setting is disabled. Windows does not allow you to modify your system as you wish. You cannot run, develop, or debug an unsigned kernel-mode driver unless you disable Secure Boot [0]. Disclaimer: I run Linux/BSD exclusively, I don't do any development on Windows, don't take my words for it, instead, check my citations to Microsoft's documentation. It's for Windows 8 32-bit that happened to be the first hit in my search, but I believe the policies are the same in Windows 10. Finally, locking down a system is not only used for DRM. Maybe you don't want it on a PC, but it's often desirable in production systems. For example, on my server, I completely disabled kernel modules, hotpatching, /dev/mem, etc., so that no code can even be loaded into the kernel (other people do the opposite, it's a tradeoff between uptime and security). There may still be some exploits that make it possible - PaX/grsecurity has better countermeasures and blocks additional attack vectors - but it's not available to the general public anymore. [0] https://docs.microsoft.com/en-us/windows/win32/w8cookbook/secured-boot-signing-requirements-for-kernel-mode-drivers https://docs.microsoft.com/en-us/windows/win32/w8cookbook/se...

cyphar 7y ago

If you're using a modern machine, then you probably are using Secure Boot. For better or worse, Secure Boot requires Microsoft[+] to sign your binaries and they have certain requirements which you cannot break or they will revoke the signature. One of these requirements is that you cannot have a signed binary load unsigned code into ring-0. So (ignoring whether these features are useful or good) in order to be able to run Linux on modern hardware these types of features are necessary. And I'm sure you'd be just as annoyed if you couldn't run Ubuntu on a machine that was less than 6-8 years old. > I wasted a few hours when that Ubuntu thing happened to figure out where that switch was and didn't find it. It's a shame you didn't manage to find it, because it's pretty trivial to create your own signing keys and enroll them in the MOK. You can then use those to sign your kernels. You just need the sbsign package. If you want to just turn it all off, it's even more trivial -- go into your BIOS and disable Secure Boot. I would hope someone who wishes to do some kernel development would be able to overcome this fairly minor hurdle. [+] Technically it's whoever owns the keys that the manufacturer has approved to run software on the machine. On basically all modern machines that list is just "Microsoft" but you can enroll your own keys or remove Microsoft's keys if you want.

tomatocracy 7y ago
> One of these requirements is that you cannot have a signed binary load unsigned code into ring-0. I think the requirement is slightly looser - MS won't sign binaries which in turn allow arbitrary unsigned binaries to be loaded/run at ring-0 without any user interaction/confirmation. The shim and PreLoader loaders used by most Linux distributions allow you to boot arbitrary ring-0 code by requiring user interaction first, and both have been signed by Microsoft. The distribution-specific versions of shim/PreLoader also usually allow booting any code signed by the distribution's own key without needing to enroll that in the MOK. The process you need to go through, as you describe, is to use shim/PreLoader to first enroll the hashes/keys you want into the MOK variable, then after that's been done once it will all happen without interaction.
CameronNemo 7y ago
>it's pretty trivial to create your own signing keys and enroll them in the MOK Aleksa, I know you are probably aware, but if keys can be added by a user then the mechanism is not really achieving verified boot. The keys need to be burned into a read only portion of memory if we hope to protect against evil maid style attacks. Unfortunately this conflicts with the "user freedom" side of the hardware. Wish there was a good solution for device owners and only device owners to own their keys.

skummetmaelk 7y ago

> Stuff never just works on Linux This is the worst argument ever because it carries the false pretense that stuff "just works" on Windows and MacOS which is blatantly false. Just yesterday I had to use regedit on Windows to stop its auto update from overwriting my manually installed video drivers. The only way to stop windows from doing that is to stop it from updating _all_ drivers. How dumb is that? Which normal user can figure out that this is why their video performance suddenly goes into the gutter?

jbverschoor 7y ago
A normal user shouldn't have to install a driver manually
- shrimp_emoji 7y ago
  I can't remember when I needed to install a driver on Linux (e.g., GPU drivers come in with system updates). I can remember when I needed to install a driver on Windows (any GeForce XpErIeNcErS???).
- Hendrikto 7y ago
  Read his comment… Windows auto update fucked things up. This problem would be even worse for users who never installed a driver manually, as they have no idea at all why things suddenly run worse.
  - jbverschoor 7y ago
    If he didn't have to install drivers, because they're available / checked, then it wouldn't have messed things up. On macOS, I have 0 need to install drivers. On windows, I'm not sure because I haven't used it in such a while, but afaic remember, windowsupdate has updated drivers suppiled by vendors. And that actually works. His comment is similar to: I compiled a kernel modulue, and loaded it. When I do my regular uprade / dist-upgrade, and now I'm stuck with a vanilla drivers. The only way I can fix this is to alter the Makefiles, and compile from scratch. Oh look.. 1 google gives the exact situation actually: https://askubuntu.com/questions/492217/nvidia-driver-reset-after-each-kernel-update https://askubuntu.com/questions/492217/nvidia-driver-reset-a...