Hacker News Reader

Comment by geofft | Hacker News Reader

If they're signing Ubuntu's ARM shim loader the same way they're signing Ubuntu's x86-64 shim loader, you can use it to boot an arbitrary kernel in non-EFI mode. I am using this on my personal laptop to to boot Debian stable with Debian's kernel - grab shimx64.efi + grubx64.efi from Ubuntu, put them in the ESP, and write a little grub.cfg that sets $root and $prefix to the Debian partition and runs `normal`. Since you're exiting UEFI boot services before running unsigned code, Microsoft (apparently?) does not care.

Also, if they're signing any Linux distro's shim loader, shim allows a physically present user to enroll their own key or disable secure boot. See method 3 at https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS .

(I don't actually know if they are signing any Linux shim for ARM - https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#UEFI.2FSecur... implies no. Which means you can't use any version of Linux on it, unless they change their policy.)

View on HN

Microsoft won't sign third-party ARM drivers or bootloaders.

It makes absolutely no sense to do that. You get no added security at the cost of having to use non-free software.

To be honest secure boot has very little to do with actual security anyway.

In theory, if you enable signature checking in Grub, sign your kernel, add that key to Grub, sign Grub, import that key into the UEFI, delete all the stock (Microsoft) keys and use full disk encryption (use the luks module in grub and place an unlocking key in the initrd) .. then in theory, it should be very difficult for someone to reformat and fency your stolen laptop.

I've got the full disk encryption working with luks/grub (you do have to unlock the device twice, one for grub to read its stage2 and one in the initrd for the kernel), I just haven't gotten around to trying to re-enable secure boot.

I get that. But as you can surely see, this is not a common use case at all. Less than 1% (number pulled out of the ass) of regular consumers get their laptop stolen. Then among those, very little percentage of people actually care (enough to pay somebody to to secure the laptop properly) about the data stored in the machine. Mandating secure boot and making legit consumers to go through all that just to run their own os is simply bullshit. It's just a method to lock down the machine.

Your ass-pull laptop theft rate of 1% is still roughly four times the use rate of Linux in the Steam Hardware Survey. Installing your own OS is not a common use case at all, either.

Steam is a bit of an ass-pull itself, not at all being an accurate representation of an average computer user. Real figures tend to be around 2-3%, for example: https://www.netmarketshare.com/operating-system-market-share...

That doesn't really change the point much, does it? Installing your own non-Windows OS on a machine is a very small part of the market. Providing security for the people who will never install a new OS on their machine (not even a new version of Windows) is serving a much larger part of the market.

Providing security for the much larger part of the market does not mean, that it is necessary to lock out the minority.

Otherwise, why have the antitrust laws at all? The dominant market players provide useful services, why should we care about the minor players? (Not only in operating systems, but in general).

> then in theory, it should be very difficult for someone to reformat and fency your stolen laptop.

The solution is to attach a SPI programmer (eg a RasPi) and flush the UEFI variable store. UEFI will reset to factory defaults, incl Secure Boot.

The complicated part of that is opening the device.

The average fencer will not know how to do this and will most likely toss the laptop or strip it for parts.

Why use GRUB if you're on UEFI? Just boot the kernel directly, no need for "boot loaders" or any of that silliness.

Your firmware probably does not know how to do full-disk encryption.

It is very much a security tool, it has some bad defaults but otherwise the theory is sound and safe.

I don't see why it's not actual security.

It sounds like it makes sense if you look at it from the perspective of Microsoft wanting to hold onto the keys in case they ever want to lock the door.

And fair's fair, Microsoft was the one that pushed UEFI so hard.

AFAIK that's just another way to switch to Custom Mode.

Which? The first one (the one I'm running on my laptop) doesn't involve custom mode at all - I'm using an MS-signed bootloader to exit boot services and do some stuff, with no changes to SecureBoot or PK or any other variables. I have an actual Secure Boot-enabled platform with only Microsoft keys enrolled.

The rest involve changing EFI variables, yes, but my impression is that "Custom Mode" refers to a UI in the BIOS which permits you to change the variables, and those variables are always writable by code running in boot services. The requirements say, "On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: 'Custom' and 'Standard'." Nothing I'm suggesting involves going to firmware setup.

Reply on news.ycombinator.com