
Debian 9 not including support for UEFI Secure Boot - aruggirello
http://www.phoronix.com/scan.php?page=news_item&px=Debian-9-Secure-Boot-Maybe-Not
======
vbernat
Direct link to the announce: [https://lists.debian.org/debian-devel-
announce/2017/04/msg00...](https://lists.debian.org/debian-devel-
announce/2017/04/msg00013.html). 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](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](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).

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

~~~
infodroid
> 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.

~~~
loeg
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.

~~~
infodroid
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.

~~~
loeg
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.

~~~
infodroid
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.

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

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

~~~
indolering
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.

~~~
poizan42
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.

~~~
my123
PatchGuard can be disarmed on 8.1 ;-)

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

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

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

~~~
kakarot
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.

~~~
zokier
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!

~~~
bubblethink
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.

~~~
zokier
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.

~~~
bubblethink
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.

~~~
zokier
> 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.

~~~
bubblethink
> 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.

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

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

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

~~~
btgeekboy
Out of curiosity, why have you disabled it?

~~~
int_19h
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?"

~~~
floatboth
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.

~~~
int_19h
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.

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

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

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

~~~
JonathonW
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.

~~~
devrandomguy
Found the story: [https://arstechnica.com/security/2016/08/microsoft-secure-
bo...](https://arstechnica.com/security/2016/08/microsoft-secure-boot-
firmware-snafu-leaks-golden-key/)

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.

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

