Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Debian Operating Systems Software Linux

UEFI Secure Boot Booted From Debian 9 'Stretch' ( 168

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.
This discussion has been archived. No new comments can be posted.

UEFI Secure Boot Booted From Debian 9 'Stretch'

Comments Filter:
  • RedHat (Score:5, Interesting)

    by Aighearach ( 97333 ) on Monday May 01, 2017 @01:24PM (#54334663) Homepage

    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.

    • Re:RedHat (Score:5, Insightful)

      by Anonymous Coward on Monday May 01, 2017 @01:43PM (#54334831)

      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.

      • Re:RedHat (Score:5, Informative)

        by networkBoy ( 774728 ) on Monday May 01, 2017 @02:03PM (#54335059) Journal

        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.

        • What do you have against shoehorns, anyways? It is really hard to find a good shoehorn these days. When I was a lad I could buy a nice brass one at a yard sale for a dollar. Now they want over $20, and they only have plastic.

          People don't remember the old days, "I bought a new hard drive, but my BIOS is old so I had to format it as two drives. Now I can't find anything and I'm always out of space even though I still have space. :(" Sorry grandpa, you have to buy a new computer every year because digital shoe

          • by epyT-R ( 613989 )

            You will care when most oems start shipping their systems with secureboot forced on.

            • 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!

      • by Megol ( 3135005 )

        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" (no

      • UEFI is a successor to BIOS in the same way that systemd is a successor to init.

        And both caused users who didn't have a clue to spew the garbage like you just did.
        They really are very much alike.

    • by hackel ( 10452 )

      Ah, so you just want to sacrifice package quality and QA, while adopting dependency hell, all for "business integration?" That makes sense.

      • Re:RedHat (Score:4, Informative)

        by whoever57 ( 658626 ) on Monday May 01, 2017 @02:28PM (#54335377) Journal

        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.

        • by hackel ( 10452 )

          Too little, too late. OP said he had been suffering under it for 20 years. I still have nightmares about from when I had the unfortunate task of administering a Redhat system. While rpm/deb as a format may not be significant anymore, there's no arguing that the Debian Policy Manual itself is an extremely high standard that produces some excellent, high-quality packages.

    • by nyet ( 19118 )

      I see absolutely no benefit to UEFI. What does it have to do at all with "business integration"?

  • by Zombie Ryushu ( 803103 ) on Monday May 01, 2017 @01:38PM (#54334797)

    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,

    • Re: (Score:1, Informative)

      by Anonymous Coward

      UEFI works fine. It will only be SecureBoot that runs on top of it that could cause problems.

      If you'll be running Debian on a server or virtual machine, this will not be a problem.
      If you run Debian on "Windows 7" era or older desktops, it will also run fine.

      Where you need to be careful is with newer desktop systems mainly designed to run Windows.

      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 b

      • by Anonymous Coward

        Where SecureBoot can not be disabled, your only options are to use boot loaders signed by Microsoft, or to upload your own private keys into SecureBoot and sign your own boot loaders.
        If that doesn't sound like an option for you, you'll want to avoid those OEM vendors.

        Note that you can still have working Debian desktops with the latest gen hardware, but you'll need to either build a system from parts, or find an OEM vendor that specifically caters to Linux.

        Can't we just start murdering MS/Intel/etc board members and corporate officers until they stop the BS?

      • by tepples ( 727027 ) <> on Monday May 01, 2017 @03:20PM (#54335929) Homepage Journal

        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.


        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.

      • by jabuzz ( 182671 )

        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.

      • by ncc74656 ( 45571 ) *

        Microsoft declared that to get the Windows 10 compatible certification, the system must have SecureBoot and there must not be a way to disable it.

        How is it, then, that I got Gentoo up and running on my notebook, and had SystemRescueCD booting from flashsticks before that? It shipped with Win10, but there's an option to disable secure boot that works as it should.

        (If it makes any difference, the machine's a Dell Latitude 7370. The main holdup on putting Gentoo on it wasn't secure boot, but the puny 120GB

    • by whoever57 ( 658626 ) on Monday May 01, 2017 @02:33PM (#54335435) Journal

      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?

  • by Anonymous Coward

    I wish we would stop using the word Security when we really mean Vendor Lock-in.

    • by TWX ( 665546 )

      From that vendor's point of view, that is security. Financial security.

    • by sl3xd ( 111641 )

      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.

      • Why, exactly, should the user of a company laptop who travels for business *not* be allowed to boot Linux from his own USB drive when he's in his hotel room at night? Almost all companies encrypt their drives with Bitlocker, so it's not like there's a real risk of company data being compromised by malware... without the key, it's *impossible* for malware running under an externally-booted OS to read the decrypted data or write subtle changes to the company's boot drive (at worst, it might render it unbootab

  • "Heir-to-BIOS?" (Score:4, Informative)

    by hackel ( 10452 ) on Monday May 01, 2017 @01:40PM (#54334811) Journal

    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.

    • Re:"Heir-to-BIOS?" (Score:5, Interesting)

      by bws111 ( 1216812 ) on Monday May 01, 2017 @01:50PM (#54334907)

      Why is secure boot a 'terrible technology'? We use it quite successfully here. What are the problems with it?

      • Re: (Score:2, Insightful)

        by gweihir ( 88907 )

        1. It is not "secure" at all
        2. It is DRM, i.e. makes it less "your" hardware

        • Re:"Heir-to-BIOS?" (Score:5, Interesting)

          by bws111 ( 1216812 ) on Monday May 01, 2017 @02:10PM (#54335153)

          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.

          • Re: (Score:2, Informative)

            by tepples ( 727027 )

            We sign our own images. The only code that will run is stuff signed by the appropriate key.

            Provided that the manufacturer has deigned to let you trust your own key as opposed to Microsoft's key. As of Windows 10, Microsoft is allowing PC makers and motherboard makers to prevent the user from turning off or otherwise reconfiguring Secure Boot. And if you had intended to work around this by building your own computer, good luck finding parts from which to build a compact laptop.

            • by bws111 ( 1216812 )

              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.

              • good luck finding parts from which to build a compact laptop.

                In addition many manufacturers will build you a workstation to your requirements, you just have to make it worth their while to do it.

                Looks at list of laptops sold by System76 []
                How would an individual go about "mak[ing] it worth their while" for System76, ZaReason, ThinkPenguin, and other Linux laptop makers to make a laptop smaller than 13 inches?

                Looks at pricing of base configuration of said System76 laptops
                What goes into a Linux laptop to make it cost as much as two or three entry-level Windows laptops?

            • Yeah so? They could already do something like that by including some hardware that prevents the computer from working and not providing drivers. There's nothing new here in terms of what is being taken away from consumers.

              The only difference is that now there's a standard interface to do so, one which a manufacturer of general hardware would likely not get caught dead doing, especially given the recent trends for many of them to offer you choice of software platform.

          • by gweihir ( 88907 )

            A fascinating level of naivety and non-knowledge you have there. Sounds very much to me like you made a really stupid decision and now cannot admit it.

            • It's amazing how much is said without saying anything. I assume that while insulting the GP you yourself have run out of knowledge and thus refuse to answer his question. I expected nothing more.

              • by gweihir ( 88907 )

                You wish. But I do not give out free security consulting when it is a) real work and b) the targets are not capable of understanding it anyways.

                • by mvdwege ( 243851 )

                  I find the ranting of homeless psychotics also hard to understand. That still doesn't make them right.

                  • by gweihir ( 88907 )

                    And your point is? Do you have a problem with anybody but you actually having skills and insights?

      • by nyet ( 19118 )

        Why do you use it? To what end?

        • Re:"Heir-to-BIOS?" (Score:5, Interesting)

          by bws111 ( 1216812 ) on Monday May 01, 2017 @02:17PM (#54335235)

          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).

          • by nyet ( 19118 )

            If your machine can be exploited to the point where the kernel can be replaced, preventing the kernel from being replaced is not going to help you.

            • by bws111 ( 1216812 )

              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?

      • by Anonymous Coward

        It's a solution in search of a problem--trying to turn PCs into locked down chains of trust when every PC OS (even OpenBSD) has security vulnerabilities. Let alone the whole rootkit issue. But, sure, let's sign a vulnerable Linux kernel and then for near ever have it as a usable replacement for a "secure" up to date kernel because it's signed. That's "Secure Boot".

        Seriously, while Secure Boot isn't useless, there's a lot of other things that are a lot more useful and without the hassle of trying to obtai

        • by bws111 ( 1216812 )

          The whole 'rootkit issue' is WHY you use secure boot and associated technologies (like IMA). And if you actually know what you are doing, you will be using remote attestation to ensure that you are not, in fact, using a known vulnerable by signed kernel.

  • by Anonymous Coward

    Can't believe adults rant so much, so often about systemd. Get over it, for goodness sake...

    • by TWX ( 665546 )

      You're saying that we shouldn't be disappointed that something that worked fine was replaced with something that is broken?

      Why don't you go back to Windows? Seems that OS is more in-tune with your attitude.

  • Since "secure" boot is anything but and basically just DRM on steroids, it does not matter much in real life. The only thing to do about it is to make sure to buy hardware were it can be turned off.

    As to "heir of BIOS", well maybe. At this time it is still usually a step back. For example, I have an utterly stupid Acer UEFI implementation that cannot boot from memory stick in either mode. It can boot from USB CDROM (go figure), so for a new installation I have to keep an USB CDROM burner and some rewriteab

    • by bws111 ( 1216812 )

      It is amazing how often you can repeat the same nonsense without ever offering a single shred of evidence.

      • by gweihir ( 88907 )

        As I happen to be an expert, if you want evidence you will have to pay for my time. But go head, be as stupid as you like to be.

        • by mvdwege ( 243851 )

          As I happen to be an expert,

          Actual expertise is inversely correlated with the vehemence with which it is announced. You haven't actually shown any indication that you have enough expertise to tell Grandpa where the on/off button is, so I'll take your statements with some salt.

  • by Anonymous Coward

    Secure Boot has no lawful purpose, at all. It is designed only to prevent you using your device how you want.

In 1869 the waffle iron was invented for people who had wrinkled waffles.