Debian 9 not including support for UEFI Secure Boot | Hacker News Reader

Debian 9 not including support for UEFI Secure Boot

phoronix.com

130 pointsaruggirello93 comments

Direct link to the announce: https://lists.debian.org/debian-devel-announce/2017/04/msg00.... The Phoronix article doesn't bring anything.

The reasons of forfeiting secure boot support can be found in the following bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036 (look at the list of blocked bugs). The main blocker seems to be this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821051 (and the root cause seems to be the lack of time from the FTP masters).

A decent amount of Phoronix' content is basically blogspam. Can a moderator update the URL as vbernat has suggested?

On the other hand: this post is probably on HN because someone read phoronix. So, why not give it credit for bringing such things to the attention of a wider audience? I'm a Debian user for a long time, but i don't subscribe to debian-devel. How else would i know of this?

IOW one's blogspam is another's curation.

> A decent amount of Phoronix' content is basically blogspam.

This has not been true for a long time. Phoronix may have started as an amateur site with dubious content but it has now become a serious resource.

These days, it does a good job of (1) highlighting important developments around Linux and (2) providing context and fact-checking for new developments beyond what is provided in primary sources.

If you still hold a grudge against Phoronix for its reporting style from ten years ago, please reconsider.

I didn't even know Phoronix 10 years ago, and not even 5 years ago, and I understand the critique voiced over it.

They often basically just repeat source information and add unwanted opinion, like an overengineered RSS feed merged with a blog. Also, often the link to the source is not given, or not the the link one would expect it to be, which then factually turns to some other Phoronix article.

I'm saying this while still looking at Phoronix regularly. I see the potential for a great news site in it, especially considering the benchmarking they do.

> often basically just repeat source information and add unwanted opinion

I don't think this is fair or accurate criticism. There aren't any Phoronix stories that just republish the whole of the source verbatim. And even when quoting the source material, the site adds a great deal of value by identifying the critical excerpt. And the real value isn't usually in the quote itself, but in highlighting the story as a notable development in the first place. Also, I doubt you will find anything resembling the opinionated style of The Register on there. Perhaps what you criticize as being "unwanted opinion" is just some background information or a summary of the source that did not reflect your opinion?

Yes, it was too strongly worded. I should have said "sometimes" instead of "often".

For example the first paragraph in [1] really doesn't go down well with me. It seems so negative, which I call unwanted opinion. Also the linking policy is not good. If I stumble an interesting development in Phoronix, I want next to take a look at the source myself.

I agree that Phoronix creates value, that's why I read it.

I don't even know The Register, but the comparison can't make a difference because I have an ideal in mind.

[1] http://www.phoronix.com/scan.php?page=news_item&px=KDE-Babe-...

The linking policy is something I can overlook, because the linked Phoronix article is often a good summary of the original source, and it would actually be hard to find that linked Phoronix article unless the link was given to it, and the linked Phoronix article likely contains the link to the original source anyway.

As for unwanted opinions, you did not say what you found so negative in the first paragraph of the KDE Babe article, since it seems rather impartial to me.

I can only conclude that you felt the article wasn't enthusiastic enough for your taste. But if the real issue is this absence of positive bias then it would be inaccurate to call it a problem of "unwanted opinion". More importantly, such "cheerleader" style of writing, like you might find on community websites, is not good journalism and it is not clear why it is even desirable.

There are reasons why we maintain standards of objectivity in journalism. It gives people the freedom to make their own minds up about an issue and thereby to make decisions based on the best available information. This is not possible if all you read is that everything is great all the time.

Besides, having a widespread "cheerleader" culture is in the end harmful for any community, because it prevents discussing and fixing the things that are broken, which insiders are no longer able or willing to see.

I don't want enthusiasm either, I just don't want opinion. Given the facts, I can form my own, thank you. Journalists' job should be to provide all relevant facts and present it in a neutral way. The further any news goes from this, the lesser the quality in my eyes.

The rhetoric style and choice of facts given in the first paragraph don't seem impartial, they convey a negative view about the project. The comparison to the other media players was unnecessary, especially in this way. But despite our agreement or disagreement on this, it is not the first article that made me dislike some of the writing on Phoronix. And it seems I'm not the only one. In fact, in the past I stopped reading it because of it.

Yes, the linking on Phoronix can be worked around. The fact that it is the way it is, does not make it look good, though, at least to me.

It's still true. Look at this very post, for an example.

Phoronix is just Larabel banging out short blogspam around 3rd party sources and very dubious benchmarks. It's all sloppy and rushed.

If you want to follow important developments around Linux, I would highly recommend LWN.net over Phoronix. The writing is professional, for lack of a better word.

You're just repeating yourself without addressing the points I made. The value in a news site is in summarizing new developments, putting them in context, explaining their impact, performing fact checking.

Phoronix does all of this fairly well. Perhaps the style of writing or length of articles is not to your liking, and that's unfortunate, but that doesn't make the site blogspam.

This article doesn't prove anything at all. The Debian announcement was quite short, and there isn't much more that can be said about it, since most users have Secure Boot disabled anyway.

A significant point of difference with LWN.net is that Phoronix doesn't require a subscription in order to read the content, which makes it appropriate for sharing.

I don't agree with you on several points, but I don't think it would be a good use of either of our time to get into a silly point-by-point rebuttal. I don't think I'd convince you Phoronix is a bad blog dressed up as a news source for ad revenue. Instead, I'll just address the last wrong point:

> A significant point of difference with LWN.net is that Phoronix doesn't require a subscription in order to read the content, which makes it appropriate for sharing.

LWN doesn't require a subscription to read the vast majority of its content. Period.

The only thing you need a subscription for (which can be as low as $3.50/mo for students or anyone else who feels they are low income) is reading the current weekly edition.

In return, there are no ads and you get some high quality journalism. It's difficult for me to explain how much better the writing is than Larabel's.

LWN is a fine resource for original articles about Linux technology, and I am happy to recommend it on that basis.

But as a news provider, it is seriously lacking compared to the alternatives, which have at least half a dozen stories per day and cover a broad range of new developments. If you care to look, it should be obvious just how much LWN misses out.

> LWN doesn't require a subscription to read the vast majority of its content. Period.

This is misleading, though. Perhaps it is true if we count each post on LWN as a piece of content. But a lot of posts on LWN are just noise and not really what most people would consider to be content.

For example, there are daily "Security updates for today" posts consisting of just links, as well as frequent one-sentence announcements about new kernel prepatch releases and stable updates. One wonders whether they are automatically generated.

Such posts provide little value to a general reader compared to a dedicated mailing list digest. They don't even attempt to summarize what changed, or describe the context or impact of the changes.

If you exclude such items then a significant amount of LWN content will require a subscription, maybe more than half, especially stories that go beyond one sentence/paragraph in length.

All that content is made available to non-subscribers in the following week.

> Phoronix is just Larabel banging out short blogspam around 3rd party sources and very dubious benchmarks.

It's clear that you have an axe to grind with Phoronix and you are very vocal with your strong personal opinion, but your comments also don't strike me as reasonable.

For instance, Phoronix does distribute its phoronix test suite, and anyone (including you) is free to test and validate their claims. Yet, from all benchmark sites on earth, somehow you single out Phoronix as a site whose benchmarks somehow are "dubious".

Phoronix is also the first site that systematically tested hardware on linux and released benchmarks covering interesting linux-related issues, such as the performance gap in graphics cards resulting from the use of proprietary and FLOSS drivers.

Do you actually have any basis to substantiate your personal assertions, or are you just dedicated to slander Phoronix with baseless assertions?

First, just to get this out the way:

> are you just dedicated to slander Phoronix with baseless assertions?

If you think anything I've said is slander, you don't have the first clue what slander is.

> Yet, from all benchmark sites on earth, somehow you single out Phoronix as a site whose benchmarks somehow are "dubious".

There may be other bad benchmarking sites I'm not aware of, but they aren't the ones in the article? Not sure why you think this is "singling out."

Here's some excerpts from a discussion of the topic on reddit[0]. I tend to agree with their characterizations of Phoronix' flaws:

> Apart from sensationalist headlines where he (Michael Larabee) tries his hardest to manufacture controversy I also think the benchmarks are the worst aspect of Phoronix as they are typically so poor in their implementations as to be worthless and generally only serves to spread misinformation. > > The compiler benchmarks are a joke, only recently has he even started to display the actual compiler options used and not even for all tests, secondly he doesn't even understand how compiler options doesn't correlate and make totally pointless tests of -O2 versus -O2, -O1 vs -O1 etcetera > > ... > The we have the operating system / distro comparisons where he doesn't make a lick of effort to have them use similar settings, for example doing game benchmarks where one system also runs desktop 3d compositing and the other doesn't means that the end results are inconclusive enough to be worthless

> copy-paste articles, especially wine announcements or information from mailing lists, where author just copy-pastes what message said, without apparently having any understanding of his own on the topic. nothing really annoys me more than that - lazy journalism for the advertising dime. posts without links to original source, or with barely any links. but tons of links leading back to phoronix are sure to be always there. benchmarks where results visible on the graphs are summed up by some inconclusive filler banter that doesn't really say anything relatable to data represented on them (and sometimes is quite the opposite) . > > phoronix is basically total opposite of LWN. nearly zero effort/research goes into each article, beer promotion all the time and extreme amounts of self-referencing links. it's pretty much clickbait all the time, where a single quip from a mailing list can get into a full blown article.

[0]: https://www.reddit.com/r/linux/comments/1ittd8/why_all_of_th...

Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants.

Newer Windows kernels generally blacklists drivers with know vulns, but you can just use an older version, and practically speaking old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working.

You could also unenroll all vendor supplied signing keys and load it up with one that you keep in a HSM.

Yes, you are technically correct that any opportunistic encryption scheme can be bypassed but it adds cost to the attack and (more importantly) it is a step towards a more secure system.

I feel like that is missing the point. You need social engineering (and probably not an easy case) to get people to change the keys. Using a pre-made image that allows you to bypass secure boot by way of a windows driver with a known vuln is practically free as soon as anyone packages it. I don't know whether that is currently being done, but I suspect it since I have seen people discussing bypassing PatchGuard in Windows 10 where they used a known exploit in a driver from a company that starts with n and ends with vidia.

PatchGuard can be disarmed on 8.1 ;-)

I remember hearing that there is some problem unenrolling vendor keys, especially MS ones, because they are also used to sign some of the firmware blobs. I'm not sure if that concern really became realized at any point, do you have any information regarding that?

Blobs inside the FW image are not subjected to signature checks.

I think it is bit more complicated than that. I checked some presentations [1] about UEFI/SB, and they do seem to imply that there is potentially some blobs (namely option roms, uefi applications and dxe drivers) that need to pass signature check. I don't know how much such modularity is really used in real life, especially in the boot path, but I think the "best practice" recommendation is to keep dxe core small and have stuff as loadable drivers.

[1] eg http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-B...

Everything that is in the ROM proper isn't checked actually, in TianoCore at least.

I think I set this up in about 5 minutes on my devuan laptop (basically just Debian 8.3 for the purposes of this discussion). I told it to delete all its keys, then whitelisted the debian efi blob (no Microsoft signature needed), and all was well.

I did not test the configuration with an old copy of windows, but I'm pretty sure installing secure-boot enabled Linux distros now fails as expected.

Is this not standard functionality for secureboot laptops?

FWIW Secure Boot has its own blacklist, called the Revoked Signatures or Forbidden Signatures database or dbx, though I don't know if and how it is actually used.

> old windows kernels can't be blacklisted because then people's install media that they might have paid for would stop working.

I understand the theory, but are you sure that is true in practice? There also could be a workaround (such as disabling Secure Boot for the install).

Microsoft uses STLs, which are flashed into UEFI variables. (had other glaring issues though, Secure Boot policies weren't checked with DBX or the STLs... which made it a real issue)

There was the secure golden key boot exploit last year[0]. In the conclusion they also points out that Microsoft can't revoke the affected bootmgr versions:

> Either way, it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc.

[0]: https://rol.im/securegoldenkeyboot/

Oh well, Secure Boot security is a can of worms. It can be workarounded with enough effort...

> Secure Boot is utterly broken (for general purpose pcs at least) anyways. I can just take an old windows kernel and boot with a configuration that loads a driver with a known vulnerability (a certain gpu manufacturer might be a good place to look) and a script that use it to run kernel mode code that does whatever it wants.

If you are referring to the Golden Key exploit (a misnomer because it doesn't involve keys, FWIW), it doesn't impact desktops and laptops, possibly because you can simply disable Secure Boot on them, but does affect certain mobile devices on which Secure Boot was supposed to be impossible to disable. It also requires physical access.

For those of you who glossed over the title, It's secure boot that is now unsupported, not UEFI. UEFI is still supported.

An important detail which doesn't change what you are saying: Secure Boot is from the UEFI specification, but I think SB is optional.

I wonder if it'll actually finally have useful a SELinux implementation and policies like they promised they'd have before releasing Jessie (8), or remotely up to date clustering software such as pacemaker, corosync, ha resource agents and DRBD which is pretty much unusable in any modern in 7, or 8. Jessie (8) was such a flop of a release so many people and business's I know that were loyal to Debian moved to CentOS 7 + EPEL/Elrepo with great success and given how hostile the Debian community (mainly packing community) has become over recent years and how helpful and inclusive Fedora and RHEL's community and bug tracking ecosystem has become I can't see many of us moving back.

Seconded. Migrated from Debian to Fedora after Jessie. And to CentOS on my servers. Stretch isn't as bad now, but... I don't think I'm switching from RHEL for a long time. So much just works out of the box, including SELinux, and all of the documentation seems to be security-focused.

idk. I have been recently setting up some new RHEL/CentOS systems both at home and work. While the base system and documentation both feel really good, the experience still has been somewhat frustrating to the point that I'm moving to Ubuntu LTS at home. The biggest pain point is the amount of stuff that is missing from the main repos, like:

* Python3

* Nginx

* ZFS (this I can understand)

* LXC

RHSCL is supposed to alleviate the pain, but using them also loses one of the big reasons of using RHEL in the first place because RHSCL releases are only supported couple of years. For example for Python3 the RHSCL version is 3.5 and supported until May 2019; even Python.org supports 3.5 series longer than that!

You would be better off with Ubuntu LTS or Fedora at home. For client usage, RHEL will always feel old within a couple of years of its release. That's just how fast things move on the client side. You may find something like OpenSUSE Leap a better fit since it is a hybrid between LTS and rolling releases.

But it's not that it is old, that I planned for and can live with. The stuff I mentioned was already included in e.g. Ubuntu 12.04 which was released two years before RHEL7 and in Debian 7 which was released a year before RHEL7.

All the stuff that you mentioned is already there in some capacity. python3 is at 3.4 in the main channel. SCL would likely have newer versions. SCL is mostly for development. I wouldn't expect crazy long support for the SCL stuff. That's by definition though. Use the main channel for long support. nginx is in epel. zfs is in the zfsonlinux repos. LXC used to be in main channels, but they deprecated it in favour of docker. You can still get it from epel. RHEL + EPEL should cover most of the useful stuff. There are also some multimedia and nvidia driver packages packaged by negativo17 if you really need them.

> python3 is at 3.4 in the main channel

Sadly, nope. Only in EPEL.

> LXC used to be in main channels, but they deprecated it in favour of docker

Docker is hardly a drop-in replacement for LXC. In Debian I can just have both and make my own decisions.

> zfs is in the zfsonlinux repos

Which reminds me of another missing piece; DKMS

Overall your comment feels to confirm my view; RHEL/CentOS installations tend to end up being a frankestein patchwork of different repos with varying degree of support.

Please don't take me as a RH/CentOS hater, I do still plan to run CentOS VMs for the software they do support. But I've now learned that I can't easily use it as a default go-to system to run whatever springs to mind.

> RHEL/CentOS installations tend to end up being a frankestein patchwork of different repos with varying degree of support.

Yes, that is kind of true if you need to push the boundaries of RHEL into client/workstation use. However, I've found EPEL to be quite stable and mature. I would say that the quality of packaging is on par with Ubuntu's universe and other auxiliary repositories. Ubuntu makes it less obvious that their non-core packages are not actually supported. EPEL fits sort of in a similar category.

Isn't that what EPEL is for?

SELinux is currently packaged in Stretch and doesn't have any release critical bug reported. Same for pacemaker and corosync. Dunno if it's actually good enough, but Debian is a community distribution and if nobody cares enough, nothing will be done. If businesses rely on this aspect, they should find some time to help.

> given how hostile the Debian community (mainly packing community) has become over recent years

Could you clarify? What changed wrt packaging?

I don't know what the above comment refers to, but the drama around the live cd subsystem left a bad taste in my mouth, and the decision to only support systemd got me to switch away.

There were claims that Canonical subverted the Debian voting process by having too many committers, and then forced through votes that let then treat upstream debian as a dumping ground for unreviewed Ubuntu breakage. (And also force out existing subsystems, etc).

I am not sure how true the allegations are, but I am hoping that Shuttleworth helps improve the situation now that he has re-taken the helm at Canonical. The changes I've heard of seem positive from an outsider's perspective. Concretely, they had that HN thread, and got rid of unity (I am happy as an end user, but am sad for the developer team).

So when will Debian 9 be released anyway? I can't seem to find any planning on the Debian website...

The usual date for Debian releases is "when it's ready."

A pity - however I always disabled UEFI boot for my partitions... At least the good news is that the release is very near now.

Out of curiosity, why have you disabled it?

I can't speak for OP but for me, I disable it because UEFI is an over-engineered mess that solves no problems for me.

I love EFI! No more bootloaders!!!! Just rename your bzimage bzimage.efi, put it on a FAT fs, and select it with the firmware!

Yes, and if for some reason then you clear the CMOS (BIOS configuration error, discharged battery, or whatever) you can no longer boot your PC because the boot information regarding the parameters to pass to the kernel is lost...

That's why EFI variables should never be used. Just put whatever you want to boot into BOOTX64.EFI!

Ah the lovely naming hacks of UEFI. :-P I remember the troubles it took to boot Ubuntu on a Lenovo laptop because the EFI was 32 bit, while the system supported 64 bit.

Yeah, old devices with 32-bit EFI…

I have a Mac mini 2006 (upgraded to 2007). I compiled GRUB 2 for 32-bit EFI and it boots 64-bit FreeBSD from ZFS just fine :)

Then just select it again? It's maybe 4 key presses unless you have a lot of .efi files laying around...

EFI variables are not stored in the "CMOS", note (misnomer that that is). They are stored in flash RAM.

* https://superuser.com/a/708332/38062

You realize that in most cases "disabling UEFI" is really enabling a poorly-tested emulation of BIOS running on top of UEFI?

Not OP, but I also disable it on my home boxes that run Linux, mainly because 1) I know how the BIOS boot process works very well (and I kinda like knowing how things work, especially on critical paths that can get broken sometimes), and 2) I know how to set up Linux with BIOS boot because I did it so many times before.

So I guess it boils down to "it's not broken for me, why change it?"

Why would you do this? I doubt support for legacy mode will exist for much longer, either on motherboards or in distributions.

I would be surprised if distros got rid of it anytime soon. There's still a vast amount of relatively old non-UEFI hardware that people still use, and it's not going to suddenly change, because that hardware is plainly "good enough" for all practical purposes - so it's only going to be replaced if and when it fails. Even Windows hasn't so much as announced a switch to UEFI boot only, and Linux generally supports old hardware for much longer. So I wouldn't be surprised if it's still there in a decade - maybe not in all distros, but at least in some mainstream ones, especially more "hackerish" like Arch and Gentoo.

As for motherboards, I doubt they'd get rid of it that soon, either. If only because having it there means that OEMs can ship devices with FreeDOS preinstalled to dodge the licensing fees. As I understand, legacy mode is basically just an emulation layer on top of UEFI, and it's fairly cheap (and already there).

This is different for mobile and tablet devices like Surface, which aren't really advertised as general-purpose PCs in the first place. Since they're only expected to run whatever's preinstalled on them, so long as it only needs UEFI, they will likely ship with UEFI only. But I'm not running Linux on such things.

Because it's old. Because it's painfully slow. Because messing with a FAT partition feels much better than messing with MBR or whatever weird "boot partition" thing that happens in a "legacy-BIOS-plus-GPT" situation.

Who said anything about GPT? I use MBR partitioning as well. Again, it's simple, and it works for my purposes, why change it?

And I don't consider a few seconds to be "painfully slow" for something that is done maybe once a week, if that (suspend is there for a reason...).

As far as "messing with MBR", why is that somehow problematic? MBR was specifically designed for this exact purpose - hosting a partition table and a boot loader. And there are tools to do precisely what needs to be done to it, and these tools have been there for a very long time - so I'm confident that they work right. On top of that, MBR structure is simple enough that I can manually inspect or edit it with dd directly on the block device in question.

For the people who like knowing how things work:

* http://jdebp.eu./FGA/efi-boot-process.html

* http://jdebp.eu./FGA/arc-boot-process.html

* http://jdebp.eu./FGA/pcat-boot-process.html

UEFI, or Secure Boot?

I boot UEFI, but have SB disabled, so this will have zero impact on my systems.

UEFI cannot be disabled. The "disable" UI is a big fat fucking lie by morons who think everyone else is a moron, therefore they concoct big fat fucking lies like this one.

What they've done with the "disable" option is enable a compatibility support module for UEFI to present a faux-BIOS to the operating system. The point of a CSM was to provide backward compatibility to legacy operating system that have no idea how to talk to UEFI, but can interface with BIOS.

So all you're doing is using UEFI and also a fake BIOS layer. But they call this "disabling" UEFI. Hence it's a big fat fucking lie. The things liars tell people who they think are stupid. So, you know, you should be a little pissed at people who think you're a moron that you need to be lied to.

Ohhhhh but we were just trying to make things easier to understand, we were just trying to be nice!

Well, guess what? Go fuck yourself. Stop being nice. Try being honest.

We ban accounts that continue to violate the guidelines like this. Please stop.

https://news.ycombinator.com/newsguidelines.html

I don't see a single item in the guidelines that applies to what I wrote. My derogatory comments were clearly directed at the manufacturers of firmware who lie to users about how the firmware functions. Those lies are far worse and more damaging to users than my appropriate and diplomatic ad hominem attack. I haven't written anything I would not say to any product or marketing manager or CEO of any of the firmware manufacturers, to their face, should the opportunity present itself.

Anyone know what other distros support UEFI? I hope Debian supports it in a later release I wouldn't mind going back to my second distro ever (first one was Slackware, not an option for me these days).

AFAIK both Fedora and Ubuntu support it.

I can vouch that Fedora does, decently well. My only issue is that if you're using Nvidia-vended graphics drivers, you'll need to sign the kernel modules after every kernel update & subsequent akmod build. And since you don't have RedHat's key, you need to generate your own key, upload it into your BIOS/EFI control panel, and run sign-file against each of the .ko that akmod generates. If you don't do this before rebooting, the drivers will fail to load and GDM will crash.

This is a rough overview of the process, though it's slightly outdated: http://www.pellegrino.link/2015/11/29/signing-nvidia-proprie... (I believe there's 4 modules to sign now.)

Fedora is using their own patches. Upstream are basically doing the ignorant asshole "ostrich maneuver" and refusing to settle the Secure Boot issue by upstreaming a solution. So every distro has their own way of doing it and it's not sustainable is basically how I view Debian's decision.

https://lists.fedoraproject.org/archives/list/kernel@lists.f...

Debian still supports UEFI, just not Secure Boot (which is not very secure these days if you're using a Microsoft-signed key).

Can you elaborate on why it's not secure? Too many people have MS signed keys that just work out of the box ?

Microsoft's secure boot key is compromised* on ARM, and it's not feasible to revoke and replace it.

AFAIK, Secure Boot is still secure on x86_64, at least if you trust Microsoft to not be doing something (either deliberately or unintentionally) malicious.

* The key isn't actually exposed, but a signed binary that will run unsigned code has been-- which allows secure boot to be bypassed without turning it off on affected systems.

Found the story: https://arstechnica.com/security/2016/08/microsoft-secure-bo...

It's things like this that make me want to try using an FPGA dev kit as my next motherboard. Not because the FPGA is relevant to this, but because it demands a lot of the high speed components (CPU cores, RAM controller) that a desktop computer would have.

Mind you, having an FPGA running the show would be the ultimate in extensibility.

Debian will still support UEFI, just not SB. I use Arch and UEFI. With a kernel supporting EFISTUB, a UEFI system can boot the kernel directly, without the use of a bootloader - it's awesome!

Does that mean you can skip the efi partition?

No. The kernel is its own bootloader and that must be on the EFI partition.

The UEFI spec pretty much says it must be there. What's your big problem with that, anyway? :)

Waste of space, and extra complexity. This is a thread about over engineering, right?

I'll agree lots of bits of the UEFI-spec represent solid over-engineering, but the EFI partition is IMO not one of those bits.

It standardizes how to deploy a bootloader in a multi-boot friendly way without any cheating, tricks or risk of "competing" OSes stepping on each other's toes.

It significantly reduces complexity in all cases except for the simplest of them all, and even in those cases it represents a reliable standardization so it's possible for people (like you and me!) to inspect what actually gets booted, how and why.

Try that with ad-hoc MBR-written voodoo-tracks outside the FS and partitions. Now try it again as a OS-vendor who doesn't want to risk bad PR by accidentally overwriting existing bootloaders.

I honestly think this part of the UEFI spec is among those which makes most sense and is least problematic.

Ok. But as a single OS user I'd prefer the space used be in the writeable area of the firmware rather than taking up my disk.

> But as a single OS user I'd prefer the space used be in the writeable area of the firmware rather than taking up my disk.

OK. That's your preference. But now consider this use-case:

You are installing a new OS, your first OS, on a blank PC, on a new disk. All is grand. No toes to step on. How does that OS deploy its bootloader?

You vote it should chose a simplistic way which is optimized for the single-OS use-case. It's primary objective: To save space, around 500MB of space, because you think that's something which matters.

But let's say you were actually planning for a dual-boot scenario. Now you're in the process of installing your second OS. How should that OS deploy its bootloader?

To determine that it is indeed a single-OS use-case (and this that it should use the single-OS simplistic approach, which differs from the multi-OS approach), it needs to find out if another OS and another bootloader is deployed. How should it know that? How should it be certain it doesn't overwrite something which doesn't belong to it?

And since we are now moving from a single-OS solution to a multi-OS solution... Should we migrate the existing simplistically deployed bootloader to a multi-OS config and wipe the existing single-OS configuration?

To put it bluntly: Should Windows move Linux's bootloader? Can you imagine the outrage? Any and every honest bug in such code would be deemed malicious by internet hotheads and be talked about for decades to come in threads filled with "M$".

And this is all getting very complex, very fast, isn't it? It wasn't so simple after all, was it?

With the EFI-partition there is a simple solution and simple answers for all those questions, at any point. Inspecting the state of bootloaders is simple. Deploying OSes is simple. Avoiding collisions is the default because different OSes namespace their bootloaders inside the EFI partition. Windows doesn't even need to know or care if Linux is installed!

Everything just works. At a cost. The cost of allocating a few MBs in the age when Terabytes rules.

And honestly, I find that a pretty good trade-off.

There's no reason these days something like an efi partition couldn't be put in flash next to the firmware, cheap. SSDs on the other hand are still expensive, after many years I was just able to afford a 512GB.

In the 90s I used the ibm? (I think) boot manager with 4 or 5 OSs, it took a one or two megabytes and worked quite well. That is more choices than are practical, honestly. And with VMs and containers less necessary than ever. (I do like GPT.) Doesn't have to be that small today, but shows what is possible. Xosl too.

Thirdly developing a completely new proprietary OS (uefi) when embedded Linux exists is about as cynical and wasteful as they come.

> There's no reason these days something like an efi partition couldn't be put in flash next to the firmware, cheap. SSDs on the other hand are still expensive, after many years I was just able to afford a 512GB.

Unless you want to switch your HDD to another computer and have it boot properly?

That doesn't happen very often, and when it does you could copy the bootloader as well. Probably each OS should have a copy of it, for recovery purposes.

So now your computer needs to figure out if it should boot the bootloader either from firmware OR from disk. How should it know that? What would be a 100% reliable way to determine this?

And if there is a conflict (because now there can be conflicts. Oh boy!)... How should it be resolved?

Again, this is a source of even more complexity. All in the name of the "simple" solution you wanted. Just because a few MBs on disk.

Can't you see where this is heading? Do you really think this is worth all that extra bullshit?

While UEFI is clearly over-engineered in many aspects, what you're asking for is under-engineering. And we all know that leads to nasty stuff down the road too.

>So now your computer needs to figure out if it should boot the bootloader either from firmware OR from disk.

That's not what I wrote, pls read again.

openSUSE, Fedora and Ubuntu all work. In fact openSUSE and (I think) Fedora will enrol their own distribution keys (after prompting you) to ensure that Microsoft can't blacklist them in the future.

Not sure why the downvotes, I asked a legitimate question. Oh well.

See https://news.ycombinator.com/item?id=14224297 for the error in your question.

I rather be downvoted and told why than left clueless. I guess my mistake is in seeing UEFI and UEFI Secure Boot as the same problem altogether. I'm pretty sure I'm not alone in this.

When Debian 9 (aka Stretch) goes stable then time to install sid:)

Reply on news.ycombinator.com