UEFI Secure Boot Booted From Debian 9 'Stretch' (theregister.co.uk)

← Back to Stories (view on slashdot.org)

UEFI Secure Boot Booted From Debian 9 'Stretch' (theregister.co.uk)

Posted by msmash on Monday May 1, 2017 @05:20AM from the going-forward dept.

Debian's release team has decided to postpone its implementation of Secure Boot. From a report: In a release update from last week, release team member Jonathan Wiltshire wrote that "At a recent team meeting, we decided that support for Secure Boot in the forthcoming Debian 9 'stretch' would no longer be a blocker to release. The likely, although not certain outcome is that stretch will not have Secure Boot support." "We appreciate that this will be a disappointment to many users and developers," he continued, "However, we need to balance that with the limited time available for the volunteer teams working on this feature, and the risk of bugs being introduced through rushed development." The decision not to offer Secure Boot support at release leaves Debian behind Red Hat and Suse, making it the only one of Linux's three main branches not to support the heir-to-BIOS and the many security enhancements it offers.

25 of 168 comments (clear)

Min score:

Reason:

Sort:

RedHat by Aighearach · 2017-05-01 05:24 · Score: 4, Interesting

This is an example of why 20 years later, I'm still running RedHat/Fedora/Centos family distros.
I want all my FLOSS software to work. And I want business integration to work too. I don't want to have to choose them because they're not actually in conflict.
1. Re:RedHat by Anonymous Coward · 2017-05-01 05:43 · Score: 5, Insightful
  
  UEFI is a successor to BIOS in the same way that systemd is a successor to init. They both "solved" many problems that didn't exist to anybody but their creators and financial supporters. Nobody wanted them, yet somehow they were forced down our throats. Neither came from the bottom-up in grassroots-fashion; both came from the top-down in military-fashion. And yet here we are today, and they've both won.
2. Re: RedHat by TWX · 2017-05-01 06:01 · Score: 3, Interesting
  
  Back in the late nineties I convinced my best friend to drop NetBSD and join us on Linux. At the time Linux seemed to be where all of the development was being done to make new hardware work where it didn't do so well in BSD. Now I'm wondering if it's time to reconsider the BSDs.
  
  --
  Do not look into laser with remaining eye.
3. Re:RedHat by networkBoy · 2017-05-01 06:03 · Score: 4, Informative
  
  I have to disagree, at least on the BIOS front.
  BIOS is a mess, hard to code for, pragmatically impossible to patch (how many users will actually do the updates).
  BIOS is a 16 bit system... it _needed_ to go away.
  UEFI may not be perfect, and it may not be the best delivery, but BIOS simply can't support what systems provide these days. > 512 byte disk sectors, SSDs, massive ram, BIOS is crap at all of them. Sure you can shoehorn some support in, but it's still crap. Most systems have been on EFI much longer than most people realize (mid 90's for big systems, 2000 for consumer), and uEFI since 05.
  
  --
  whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
4. Re:RedHat by whoever57 · 2017-05-01 06:28 · Score: 3, Informative
  
  Ah, so you just want to sacrifice package quality and QA, while adopting dependency hell,
  
  Begone, Troll!
  RedHat/CentOS haven't suffered from dependency hell for years. The adoption of YUM solved the issues.
  
  --
  The real "Libtards" are the Libertarians!
5. Re: RedHat by fred6666 · 2017-05-01 06:49 · Score: 3, Informative
  
  PC hardware support is still years ahead on Linux, especially for stuff such as WiFi adapters and GPU.
6. Re:RedHat by Megol · 2017-05-01 07:39 · Score: 2
  
  BIOS: 16 bit old design originally for booting from floppy drives, 32 bit support (partially) hacked in for some functions. System starts as a real-mode (8086 compatible) and have to be switched to 32/64 bit mode. Settings have been added ad hoc style over many years but still remains vendor specific. Extensions are hard to add. There aren't many standard interfaces for hardware and those that exist are mostly limited to hardware functionality from (at best) the 90's. Only 80x25 textmode is "guaranteed" (not really) to exist. Graphics modes are limited to VGA modes (assuming the graphics adapter supports them) or one can use an extension which often is of a bad quality (nobody uses it). It is a mess. Booting is done by reading a sector (normally 512 bytes) into memory and jumping to that memory block in real mode, that code is mostly enough to load the second stage bootloader. The BIOS doesn't know of filesystems so that is the responsibility of the boot block and/or the bootloader. Boot errors are handled by yet another mess of hacks. Power management is retrofitted over the legacy system as are other extensions. Emulation of legacy (PS/2) keyboard is a hack partially in hardware and partially in software, supports only the USB boot protocol and is a mess.
  UEFI: 32/64 bit design. Extensible. Standardized interface for settings. Abstracted graphics, network, storage etc. Supports FAT32, reads a 32/64 bit executable into memory from the boot media and jumps to that code with a rich API. After the boot loader is finished (it can load other files, initialize graphics modes etc.) it calls a function that essentially turns of the UEFI system allowing the system to continue booting under its own control. Faster. All implementations I know of supports emulating the legacy BIOS if needed.
  UEFI is bloated and I don't like the design. But saying that nobody wanted it is ludicrous. Everyone wanted something better than the legacy BIOS mess. If you want a grassroots approach then start coding an alternative but don't forget that you also have to have the support from X large companies (that have specific needs ans wants) and Y smaller ones (that just want something that works). You'd also need to support interfaces and standards that UEFI already does. Good luck.
7. Re: RedHat by sl3xd · 2017-05-01 09:42 · Score: 4, Insightful
  
  Systemd alone has caused me more headaches than anything MS or SCO ever did. In fact it was software from that camp which made me evaluate OpenBSD.
  There are a lot of good ideas in Systemd; overall, I don't disagree with a lot of the overall design goals.
  The implementation, on the other hand, is lacking. My own experience is that systemd has finally reached an "early beta" level of stability. (My desktop system boots correctly about half the time with Systemd. The other half of the time Systemd doesn't start up D-Bus... I can't even shut the system down cleanly, because <drum roll> you need d-bus to shut down with Systemd! Yay!)
  It's a shame systemd was pushed into production for most distributions years ago.
  
  --
  -- Sometimes you have to turn the lights off in order to see.
8. Re: RedHat by Aighearach · 2017-05-01 12:57 · Score: 2, Interesting
  
  I love systemd and PulseAudio.
  Gnome 3 I don't use, I use xfce and the world is wonderful and the desktop never changes. I don't actually use a "desktop," but I do like a traditional window manager and task bar.
  Gtk+ 3 is irrelevant to me. Even when I'm writing Gtk-based GUI apps I can just use the parts of the API that were in Gtk 2 if I want. There is nothing wrong with Gtk+ 3 though, the way there is with Gnome 3 and the needless shifting of paradigms. Gtk mostly behaves the way it always has, from the application perspective or the user perspective.
  Wayland isn't something I'm ever likely to use. I guess I'm weird but I like having a networked window system. X isn't going away from serious platforms, even as other options are added.
  If you can't manage a system because of systemd, if you actually have serious business-y high maintenance system needs and you can't learn how to have it be easier under systemd, then maybe it is actually just you? If OpenBSD does everything you need, this is probably more of a grooming issue than a technical issue.
9. Re:RedHat by Aighearach · 2017-05-01 13:42 · Score: 2
  
  Nope. I won't care at all.
  People will publish on the internet news about which manufacturers are unfriendly to software freedom, and it will be easy to select hardware that meets my needs.
  The trend is the other direction. These days I can even program a Texas Instruments microcontroller using emacs and gcc and a cli flash tool. Hardware isn't getting locked down, it is getting thrown wide open!
What about Non-Secure Boot UEFI Boot? by Zombie+Ryushu · 2017-05-01 05:38 · Score: 4, Interesting

Several of my boards support UEFI boot, or CSM Boot but the Secure Boot Portion can be turned off (or is absent in the case of one of my boards. I have one of the few early boards that has UEFI but not Secure Boot.). You can do a UEFI Boot without SecureBoot Verification like Macs do,
1. Re:What about Non-Secure Boot UEFI Boot? by tepples · 2017-05-01 07:20 · Score: 4, Insightful
  
  If there is a "Windows 10 compatible" sticker for example, you won't be able to run Debian on it.
  If there is a "Windows 8 compatible" sticker, you may or may not be able to, depending on what that OEM decided to do, so will need a bit of research.
  Source?
  Microsoft required x86 and x86-64 PCs with the "Windows 8 compatible" sticker to ship with Secure Boot on but let the owner turn it off in the UEFI configuration form. Microsoft eased this requirement for x86 and x86-64 PCs with the "Windows 10 compatible" sticker: they must ship with Secure Boot on but configurability is up to the preference of the manufacturer. In either case, even if Secure Boot can be turned off, that doesn't mean that things like backlight brightness, audio, WLAN, Bluetooth, and suspend will work correctly.
2. Re:What about Non-Secure Boot UEFI Boot? by jabuzz · 2017-05-01 21:17 · Score: 2
  
  So one presumes that "Windows 10" compatible certification that my Surface Book has is er imaginary then? I say because you can turn off secure boot if you want. You get a big red unlocked padlock thing on the boot screen, but it *DOES* work.
  I ended up turning it back on when I realized that Ubuntu supports secure boot, so there was no need to actually turn it off. Which reminds me I need to fix the grub font's because right now they are tiny.
"Heir-to-BIOS?" by hackel · 2017-05-01 05:40 · Score: 3, Informative

Lot of FUD being spread in this article. Debian certainly supports UEFI, the *true* "heir-to-BIOS." Secure Boot was a terrible technology from the start. It's disappointing that they weren't able to finish work on it in time, but this certainly isn't the huge issue this article is making it out to be. The majority of Debian installations are going to be in virtualised environments in the first place. Desktop users are probably going to be on testing or another Debian derivative. It kind of makes me angry that Ubuntu didn't contribute this code to Debian straight away, but what can you do.
1. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 05:50 · Score: 4, Interesting
  
  Why is secure boot a 'terrible technology'? We use it quite successfully here. What are the problems with it?
2. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 06:10 · Score: 4, Interesting
  
  1) Why? Because you said so? Exactly what is insecure about it?
  2) Exactly the opposite in our case. We sign our own images. The only code that will run is stuff signed by the appropriate key. That means users, hackers, and especially rogue admins don't get to install their own backdoors. Our stuff remains OURS, not THEIRS. As it should be.
3. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 06:17 · Score: 4, Interesting
  
  We use it to protect important machines (servers, automation controllers, etc) from tampering by external or internal parties. Of course, it is not secure boot by itself that does that, it is in combination with SELinux and IMA. Secure boot, however, is a key component (does no good to have your kernel verify signatures before running things if the kernel itself is not trusted).
4. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 06:26 · Score: 2
  
  The Microsoft signing thing is only a convenience, it is certainly not required. We sign all our own stuff, MS is not involved at all.
5. Re: "Heir-to-BIOS?" by bws111 · 2017-05-01 06:32 · Score: 3, Insightful
  
  Nobody said they WERE a big problem, just that they COULD be a big problem. If you can't acknowledge that, clearly you don't know much about security. Which I guess is rather obvious since you ask that dumb question about the keys (hint: no single person has the key, and the people who DO have a portion of the key are quite a bit higher than 'admin', and the whole key never exists anywhere but tamper-resistant hardware).
6. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 06:49 · Score: 2
  
  What system do you run where an admin can't replace a kernel? Or do you just stick your head in the sand and pretend there is no such thing as an inside job? Or that there is no way (social engineering) to get an admin to do something stupid, intentionally or not?
7. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 07:06 · Score: 3, Insightful
  
  How? I notice a common thread of the anti-secure boot people is that they just make statements with nothing to back them up.
8. Re:"Heir-to-BIOS?" by bws111 · 2017-05-01 07:32 · Score: 2
  
  Manufacturers don't have to 'deign' anything. There are loads of manufacturers who are only too happy to sell you servers, etc for something other than Windows. That is not going to change. In addition many manufacturers will build you a workstation to your requirements, you just have to make it worth their while to do it. Your statement is pure FUD.
"Secure boot" only ever had one mission by whoever57 · 2017-05-01 06:33 · Score: 4, Insightful

The mission of "Secure Boot" is not to secure any computers, but to secure Microsoft's revenue stream.
Yes, you may be able to disable it on your desktop, but will this situation continue? Remember those Surface RT tablets?

--
The real "Libtards" are the Libertarians!
Beggars can't be choosers by tepples · 2017-05-01 07:16 · Score: 2

How horrible that consumers are given the choice as to which OEM to buy from, and can presumably determine if a new machine meets their needs or not in this regard
Provided they have the budget for a new machine in the first place.
Checking before buying doesn't work in several situations. One is switching from Windows to Linux or from Windows to a Windows/Linux dual boot without wanting to have to buy all new hardware. Another is minors and charities, which tend to depend on donations of random hardware by those who haven't done research. A third is when after doing the research, you conclude that no manufacturers offer Linux-friendly laptop or convertible laptop/tablet PCs in a particular size range factor with a warranty in your country.
Re:I take issue with the definition by sl3xd · 2017-05-01 09:05 · Score: 2

It's vendor lock-in when secure boot is forced upon the hardware's owner.
It's important to recognize that the owner is not necessarily the person posessing the hardware.
Consider, for a second, the point of view of an IT department: There's a perfectly reason to prevent users of hardware from reinstalling an OS on top of hardware owned by the university/company/organization.

--
-- Sometimes you have to turn the lights off in order to see.