
Torvalds clarifies Linux's Windows 8 Secure Boot position - mtgx
http://www.zdnet.com/torvalds-clarifies-linuxs-windows-8-secure-boot-position-7000011918/
======
speeder
I always thought that the secure boot is a very, very, very bad idea.

In fact the whole UEFI in general I think it is a clusterfuck of mishmashed
random ideas, some good, many bad.

What I intend to do personally, is attempt to don't use secure boot.

And this all might explain the e-mail I got from Lenovo 10 minutes ago...

I asked them for a non-Windows machine. They replied saying that they from now
on only manufacture machines with Windows. At first I was: "wtf? why?" now
this article remembered me that now we have firmware tied to Microsoft, and
this explains then why ThinkPads must come with Windows.

Here in Brazil this is illegal, and Lenovo for example got sued (and lost)
once. I hope a rain of lawsuits make this shit stop.

~~~
rplnt
What exactly is illegal? Selling a machine with OS or not selling it without
one?

And as for the "this explains then why ThinkPads must come with Windows" - no.
It doesn't explain it. Secure boot has to be present on Windows certified
machine, not the other way around. Lenovo can sell whatever they want (but
apparently it's beneficial for them economically to only sell Windows
machines).

Also, certified machine has to have secure boot disable-able. So it's not
about you not being able to use the machine with Linux, it's about not being
able to use Secure Boot with Linux.

~~~
nolok
Responding from a French point of view, so that might not match Brazil (but
does match Germany): you can not tie a material product with an immaterial
one, if you do not also sell the material product as a stand alone.

You cannot sell a car with an insurance if you don't sell the car alone.

You cannot sell a phone with a plan if you don't sell the phone alone (see:
iPhone 1 release in Europe).

You cannot sell a computer with an OS license if you don't sell the computer
alone (you're not buying the disk, but the license to use the software on it).

~~~
demallien
_You cannot sell a computer with an OS license if you don't sell the computer
alone (you're not buying the disk, but the license to use the software on
it)._

Sure you can. I bought a very nice MacBook Air in Paris a couple of months
back - and you most definitely can't buy a MacBook Air without OS X.

~~~
nolok
The fact that something is illegal doesn't mean people are never doing it; it
only means they lose when they go to court.

You cannot drive over the speed limit in France, but "sure you can, I just did
this morning".

There are plenty of court cases, all won by the buyers, where the complaint
was that the computer was sold with a windows license, and couldn't be bought
without.

------
UnoriginalGuy
The thing about secure boot is that it is a GOOD idea done very badly indeed.

What was needed was for a trusted neutral party(or two) to be the owner of the
root key, and for that organisation to hand out child keys (e.g. Microsoft,
Open Source Initiative, Apple, etc) who could in turn generate child keys (all
of which could be revoked). Essentially we need the "internet model" of key
exchanges for this too.

I cannot understand who thought it was a good idea for Microsoft to be the
only authorised party to generate keys. Even from Microsoft's perspective it
is just asking to get anti-trust-ed again.

~~~
rwmj
The real use for secure boot is within a single company/organization where you
want to control exactly what runs on the computers you own. That's an argument
for secure boot to be switched off by default, and for the companies that want
it to manage their own keys.

Although Microsoft will now point at me and say _"but, but we need to prevent
boot sector viruses!"_ it's telling that no other operating system _except_
Windows commonly suffers from this problem.

~~~
jwoah12
> _it's telling that no other operating system except Windows commonly suffers
> from this problem._

This is an honest question, as this area isn't my specialty, but could this be
for the same reason that people used to perpetuate the myth that Macs don't
get viruses? Attackers simply target the platform with the largest market
share.

~~~
rwmj
Linux servers are far more common than Windows servers, and servers usually
have loads of bandwidth making them especially valuable targets for spammers
and fraudsters.

~~~
tbrownaw
Unlike desktops, servers are mostly run by people who have at least some idea
of what they're doing.

~~~
chris_mahan
the key word in your sentence being _some_.

------
kogir
From my read of the article, Linus simply states his preference to actually
support secure boot (and verify signatures), or not support it at all. He
thinks attempts to "Secure Boot" a loader which then allows arbitrary code
execution are a waste of time, and they are. If you don't want boot time
signature verification, you should turn it off, not break the chain of trust.

In fact, done right, perhaps hardware vendors that currently only provide
binary blobs could be coerced into providing source. "Oh, you want to boot on
our distribution? We don't sign blobs, but if you commit source we'll build
and sign the module."

If ever hardware does come out that doesn't allow you to opt out of signature
verification or provide your own keys, just don't buy it.

------
negativity
I'm glad Linus Torvalds is smarter than your average developer. Truly a solid
chap.

If he were lacking these kinds of personality traits, and shrank like a mouse
every time there happened to be an opportunity to compromise the integrity of
his project, Linux would have died long, long ago.

------
bcl
Matthew posted a good response yesterday:
<http://mjg59.dreamwidth.org/23400.html>
<https://news.ycombinator.com/item?id=5295272>

------
trotsky
Having read through the entire thread instead of just the expletives, in my
opinion it's a rare case of Linux and Greg being totally wrongheaded on the
issue.

The problem crops up because redhat submitted a pull request to enhance the
existing in kernel live inclusion of additional trusted x.509 certificates.
Note that this is 100% upstream and live. The pull was to add the ability to
extract these x.509 certificates from UEFI PE binaries, as this is the only
format they are available in from the only CA UEFI secure boot computers are
guaranteed to trust - Microsoft's CA.

Linus decided he didn't like it because he didn't like the idea of extracting
a certificate instead of having it alone. Understandable, probably, except
that leaves you in a situation where a secure kernel that was executed due to
a microsoft CA chain of trust now can't make use of that CA's code signing
services to decide if it wants to run a module solely because linus doesn't
approve of parsing the file format that contains the key.

The biggest place this comes up is binary only graphics drivers from ati and
nvidia - without changes os's like fedora are going to refuse to run them
because they're unsigned, which is unfortunate considering how uneven some of
the open source 3d drivers are and the heavy reliance on 3d in all modern
desktops environments.

Meanwhile microsoft is perfectly willing to sign these drivers and has an
existing substantial CA operation. Both ati and nvidia submit their windows
drivers for signing to this CA all the time, so it'd be almost no extra effort
for them to get their linux shims signed as well.

But because linus thinks parsing a PE for a signed module key is asinine, he
goes on to provide a series of rather off the cuff alternatives:

a) Every distro should parse the PEs and add every key of every 3rd part
module they wish to allow to run and embed these in their signed kernels,
issuing a new kernel every time a driver revs.

b) ok, maybe that's not ideal. how about every distro that wants to allow
binary drivers to run builds their own CA infrastructure, verification and
qualification team and revocation infrastructure. So that's a team at
cannonical, redhat, novell, mint, oracle, ibm, etc. etc.

c) ok, maybe full ca teams are a bit burdensome. How about all you distro guys
just blind sign the binary drivers with your own signing key - worrying that
MS might revoke your key because you blind signed an exploit is pointless
fearmongering.

d) ok, you're right this is harder than i thought. let's just collectively
decide that users with secure boot enabled will be prevented from running any
module not shipped by the os vendor. Aka fuck off unless you're using intel
video.

e) alright, maybe that's a little severe. Instead let's just punt entirely -
even though we're going through the trouble of a chain of trust from firmware
to boot loader to kernel to most modules, let's allow any unsigned binary
module to be loaded by default.

f) ok, i guess that kind of defeats the purpose. None of this is good security
anyway - what we should be requiring is any user that wants to use secure boot
should generate their own signing keys, add them to the firmware and then
parse and sign everything they trust, repeating the process every time they
update while of course protecting the signing key from attackers.

I think that about covers it. Linus is really smart, but sometimes he makes a
snap decision and then will perform whatever mental gymnastics are necessary
to defend it to the death. And most of his inner circle will publicly go along
with it because of the real chance he'll pay you back by randomly torpedoing
something of yours sometime in the future.

Linux's signed code infrastructure is currently the worst in the industry and
Matthew and Redhat have provided the bulk of the improvements that everyone is
using. It's going to provide real user benefit, even if the users are
paralyzed by FUD. Getting in the way of the process or trying to punt it out
of mainline and onto everyone who ships a distro isn't going to help anyone.

~~~
mcgwiz
> Linus is really smart, but sometimes he makes a snap decision and then will
> perform whatever mental gymnastics are necessary to defend it to the death.

Hmm, could it be argued that this is less a snap judgement and more one of
strengthening the long-term political and technical health of the OS? Rather
than take the easier short-term path, which may eventually put Linux's
metaphorical balls into a Microsoft vice, he would rather expose some pain now
to defend as much as possible long-term autonomy. I would imagine this to be
true given Torvald's historic ability to keep Linux healthy and viable in
spite of one of the world's most powerful corporations.

Thus, in the short term, the user must perform some gymnastics to boot new
kernels, but if this inconvenience is really that painful, it will create
market disequilibrium that will motivate creative solutions. Some naive, off-
the-cuff ideas:

\- vendors pre-installing trusted root certs for Linux distros or a consortium
of them,

\- vendors making it easy to disable SecureBoot (physical switch?),

\- vendors forcing SecureBoot configuration/opt-in on very first boot,

\- UI, tools, or documentation enhancements to make local key management and
signing easier, or

\- simply a slightly more aware userbase (the same way phone locking/unlocking
became a mainstream concept).

~~~
rodgerd
"Naive" is an overly polite way of describing ideas which lead in with an idea
that flies in the face of pretty much the whole history of Linux.

~~~
mcgwiz
:) DH2, or DH3, at best. <http://www.paulgraham.com/disagree.html>

Market-driven vendor support of Linux is not unprecedented. Ever heard of
Dell, Lenovo, Acer, Nvidia, or the Android ecosystem?

------
belorn
> What they've told us privately is that as long as no-one comes along with a
> plausible exploit for Windows based on using a secure boot enabled Linux
> system, they don't care what we do.

I guess we need to hide all those forensic distributions that can modify and
access data on a windows machine. To name a few: backtrack, CAINE, and DEFT.
If technology can modify and access data, it can also be used in an exploit.
Some might even argue that running a forensic on a computer without the owners
permissions is an exploit in itself.

Edit: How could such technology be used you say. Package a usb drive that once
plugged in, will reboot the machine and load a Linux distribution. Once
loaded, it automatically modify the windows system and transfer any
interesting data it find. Afterward, it erase itself and reboots, thus looking
like any empty usb drive once windows boots up. If that is not an plausible
exploit which an ordinary Windows users could trigger and become compromised,
then I would like to hear the definition of an "plausible exploit".

~~~
mjg59
Sure, it modifies Windows. But if it modifies the Windows bootloader, Windows
refuses to boot. If it modifies the Windows kernel, the bootloader refuses to
load the kernel. If it modifies any Windows drivers, the drivers won't load.
So you modify userspace, but under Windows 8 the (signed) malware checker is
started before any other userspace.

~~~
emidln
So you exploit the kernel (or some driver), do whatever evil shit you want,
then lie to the signed malware checker. You now have an APT that ignores this
whole notion of secure boot.

Come to think of it, this is every modern rootkit. You try to remove it and it
reinstalls itself.

There's not intrinsic reason why you have to modify the kernel that sits on
disc. Now there are lots of other checks and features you can add (that
already exist) to make it harder to get access to the kernel, to make sure
that unknown objects are purged or flagged on reboot, etc.

The thing is, this secure boot doesn't seem to significantly make your machine
more secure than current TPM-based methods involving sealing a hard disk
decryption key that is only unlocked based on checksums of firmware, nvram,
bootloader, kernel, etc.

~~~
mjg59
No, there's no intrinsic reason why you have to modify the on-disk kernel. It
just makes detection more difficult, because there's never a point where the
OS is running without having been compromised. That makes detection much
harder.

You're right that this is no more secure than using a TPM. But most consumer-
grade hardware has no TPM, and hardware vendors aren't going to add one just
for Microsoft.

------
foohbarbaz
Do I read this right? Is somebody suggesting teaching kernel to read some
stupid shit MS "PE binaries"!?

Go, Linus. Let kernel NOT even boot on these secure boot machines, see who
runs back crying first.

Dells and HPs of the world are already hurting from Windows 8 disaster. Let
them lose some of the server market and all the commercial customers that buy
PCs and give them to devs who install Linux right away.

------
aphexairlines
How are PC vendors hoping to sell laptops to corporate buyers whose IT
departments want to reimage all those machines (a lot of them with Linux
images) without wasting time going into UEFI setup menus to turn off Secure
Boot one machine at a time?

~~~
etherealG
these cases are more easily covered by the corporation's key being included in
those machines. big numbers of machines warrant that kind of effort from the
manufacturer. the problem is when I want to generate my own key and use that
as the only authority. the system doesn't support that model.

~~~
recoiledsnake
>the problem is when I want to generate my own key and use that as the only
authority. the system doesn't support that model.

It does. You can add your own key and even remove Microsoft's if so wish. The
facts are getting lost in this FUDstorm.

~~~
tomjen3
Well it wouldn't have been a fud storm if Microsoft hadn't insistet on it
being turned on by default.

But if I were to remove a MS key, am I right in assuming that that would
prevent anybody from running windows on that machine (at least without
installing the key or turning it of)?

~~~
recoiledsnake
If it's turned off by default, it might as well be useless to protect the
hundreds of millions of non-technical users who are more prone to get malware.

>But if I were to remove a MS key, am I right in assuming that that would
prevent anybody from running windows on that machine (at least without
installing the key or turning it of)?

Windows 8 boots fine without Secure Boot enabled or even supported.

However, if you remove Microsoft's key but leave Secure Boot enabled, you're
indicating that you don't trust Microsoft's code, in which case Windows will
be prevented from booting on that machine.

What is the value or the use case in removing Microsoft's key, leaving secure
boot on and then trying to boot Windows on that machine?

~~~
disgruntledphd2
The only real reason that I (as a Linux user) can see is for the amusement
value, as well as the opportunity to watch others fail to boot Windows on this
machine and the opportunity to engage in an extended philosophical discussion
regarding this event.

Mind you, I might be a niche case.

~~~
gizmo686
What extended philosophical discussion do you intend to have? You told the
computer not to trust MS code, then the computer refused to boot MS Windows.

------
RexRollman
What a clusterfuck this situation is.

------
Nux
I'm just going to put my fingers in my ears and not listen to anything anyone
might say (write) that gets close to excusing the current situation or
defending Secure Boot!

As such: Secure Boot is just another lame attempt by Microsoft to slow
down/control the competition; they are abusing their position on the market
once again, like they did in the past, like they will do in the future. This
is their way, "the wolf changes its coat, but not the disposition".

This shows that now more than ever Microsoft is shitting their pants because
of Linux/Android/Google/Ubuntu/RHEL/LibreOffice/FOSS SQL/etc; they are slowly
but surely losing the war, they are losing market share on every front. The
way things are now in 10-15 years I bet they will no longer have the 90% of
PCs share they have today, but Secure Boot might give them some help.

I can already imagine mr. Ballmer rubbing his hands in satisfaction: "oh,
nice, we'll have the keys to all PC hardware".

My advice: do not buy Microsoft, do not buy hardware on which Secure Boot
cannot be disabled. We _must not_ have all PC hardware controlled by a single
company - it is just stupid.

And of all systems they chose CA? Really? After the epic way it failed time
and again in the SSL cert industry - think Komodo or DigiNotar.

Not to mention keys given to USA and other governments that will be able to
easily install malware and other crap to control the "sheep" (the germans
already have some "official" trojans lol).

This is madness people.

------
ycomb7
Is it possible to "sign" windows 8 and other windows drivers with your own
root key so you can have your own key in UEFI and have windows still work?

I'm guessing that microsoft has no options for this at all, but I don't know
for sure.

~~~
gizmo686
Yes. You can sign the binary the same way Microsoft, or anyone else, would
sign the binary. At that point, you need only to add your public key to your
key database and are good to go.

Microsoft has no way to prevent this (short of requiring vendors not to allow
people to add keys).

------
guilloche
MS becomes so hateful with the secure boot trying to control everything. I
will never buy any machine with secure boot enabled and will boycott any MS
product.

------
narrator
What if Microsoft refuses to sign your kernel because it violates their
patents?

------
cooldeal
Linus posted a NSFW rant about it a few days ago. The story mysteriously went
off the HN front page and subsequent submissions of the story went [dead].

<http://news.ycombinator.com/item?id=5279531>

Rankings graph showing a deep dive.

<http://hnrankings.info/5279531/>

Part of Linus' email:

>Guys, this is not a dick-sucking contest. If you want to parse PE binaries,
go right ahead.

>If Red Hat wants to deep-throat Microsoft, that's _your_ issue. That has
nothing what-so-ever to do with the kernel I maintain. It's trivial for you
guys to have a signing machine that parses the PE binary, verifies the
signatures, and signs the resulting keys with your own key. You already wrote
the code, for chissake, it's in that f*cking pull request.

~~~
mhurron
HN dislikes anything that shows that real people have real emotions. Humour,
anger and whatnot have no place here.

~~~
kirubakaran
I think it is just a vocal minority of people who take offense to words like
fuck. Most people don't care.

~~~
mhurron
Profanity is hardly the only thing. HN, or a subset of it's users, basically
expect everyone to act like humourless, passionless robots.

~~~
SkyMarshal
It's b/c 99% of that stuff is noise not signal, and degrades the information
quality here. There are plenty of places on the net to get your fix of humour
and endelessly repeated memes, we don't need it here too.

------
_account
Physical access is god access. Admin/root is god access.

Guard them both with your life.

I fail to see how handing over control of your boot to some 3rd party who
clearly doesn't have the same interests that you do is anything but a horrible
idea.

Just physically secure your boxes(or VDI them) and use permissions and ACLs to
do what they were designed to do[control and delegate authority].

A good first step for Microsoft, if it cares so much about security, is to
stop making its users automagically admin for fogging a mirror, during new PC
setup.

~~~
csense
> handing over control of your boot to some 3rd party...a horrible idea

It's actually a good idea _if you're the party who's getting authority over
the world's computers handed over to it_.

> use permissions and ACL

I still have no idea how these work in the Windows world [1]. There's nowhere
obvious in the UI or the "dir" command that shows you what the ownership and
permission is [2], unlike Linux's ls -al.

My one experience with Windows permissions is, in the early '00s, I put an
NTFS partition on an external drive because I wanted to put >4GB files on it.
I copied them and got a bunch of permissions errors opening them on another
computer. My impression of Windows access controls from this: They're
invisible things the OS attaches to your files which will potentially make
them unreadable later.

[1] I understand there's something called ACL's in Linux too, but I never use
them.

[2] I don't have much experience with multi-user Windows systems, and Linux
has been my main OS for 3-4 years so I don't have as much experience with
post-XP OS's.

------
humanspecies
Solution: UEFI should not exist. Period.

We don't need to argue over UEFI or anything about it. We need to get rid of
it, simple as that.

If Intel goes through with this, we need an antitrust case against them and we
need Intel broken like Ma Bell.

UEFI must not exist, period.

------
Toshio
ZaReason spoke out on this issue at FOSDEM (direct link to webm file):

[http://ftp.osuosl.org/pub/fosdem/2013/maintracks/K.1.105/UEF...](http://ftp.osuosl.org/pub/fosdem/2013/maintracks/K.1.105/UEFI_SecureBoot.webm)

