Torvalds clarifies Linux's Windows 8 Secure Boot position
zdnet.com
zdnet.com
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.
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.
And theoretically, Grub (or something) can have the key signed.
And you dont think that is a political choice?
More importantly, how much would this sway a decision of a consumer (one place where I find 'consumer' better than 'customer') who sees two similar laptops with very similar prices except one say "With Windows 8" and the other says "Windows 8 Certified".
Could the manufacturers not come up with their own marketing campaign or something like "OpenSource Initiative Certified" or something like that[obviously they can't use OSI's name but you get the idea].
Secondly, every single iPhone/iPad is locked to boot iOS; most of the phones with Android are locked as well. (And obviously Windows phones are locked too). And by locked I mean locked, not few clicks away from using the device as you wish (as is the case with notebooks and desktop computers). How come it's not rendered illegal?
Sidenote: I agree with the fact that Microsoft shouldn't be the one deciding who gets the key and who doesn't. My opinion on this is that if everyone can't agree on one impartial organization then hardware manufacturers should be the one deciding it. Obviously it would be best if users could add their own keys.
This should never be accepted, full stop.
Hope they get sued to high hell, but in the meanwhile I'm just not buying them as a computer that's useless outside of Google's cloud is also outside of my interests.
Admittedly, it's harder for some than others: http://www.chromium.org/chromium-os/developer-information-fo...
That would not be unprecedented. Part of the US anti-trust code says you cannot tie one product to a monopoly product. It's one of the reasons MS lost their anti-trust case vs the US DOJ back in the 90s, illegally tying secondary products to their Windows monopoly.
That might not directly apply in this case, not sure, but to answer your question, yes being a monopoly or not does effect how anti-trust laws are applied to you.
Turn it off , and you can boot whatever you want.
The analogy is sorely broken.
Does that apply to Macs, Chromebooks, iPads too?
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).
The right to enter the nightclub is an immaterial good, along with software or cellphone service.
Actually this is a really well-thought-out law.
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.
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.
Are you sure this isn't just a regional sales thing, not selling a Windows Free version in that teritory?
Maybe in Vietnam it happens just the opposite. It's easy to sell a computer _without_ Windows that with it.
I don't get why the companies cannot sell "empty" laptops without OS installed, thought.
Handy for a quick memory test
That is because most of the PCs end up being installed with pirated Windows by the local tech guru.
My Vietnamese friend had to explain that the staff in the shop expected to earn $5 installing the pirated windows on it... They where not best pleased that I intended to do it myself (with a licensed copy obviously!)
Care to explain why or how, instead of just throwing a general statement around?
In before "everyone should be able to use computers and they should just work" - I agree, it should be like this; however, the hardware, software, and usability has just never been at that level - and won't be for some time. Thus I dislike that argument.
I do understand this means we should be making things better as we go, I just don't see how this is one of those things, nor do I see how proper education should be lacking for the time being. To put that in the car analogy: Should we let people drive around because they need to get to work today but don't have time to sit the license right now?
Disclaimer: Opinion, and I'm a huge usability fan and hope one day things do "just work", I'm just also a realist and don't see the logic behind letting people use something before they or the thing is ready for them.
Edit: Just realised I went on a bit of a mad rant and kind of went a bit off topic. Apologies.
Is that really the appropriate response to a company that basically made a choice to not offer the type of product you are seeking? Buy what you want from someone else ... problem solved. When you can't buy from someone else...then there's a problem.
Windows, OTOH, is something that you pay for, but generally comes in an OEM license. This license is non-transferable in most cases.
Why is the residual value so small? Lack of standardization. A lot of automakers use their own mounting system for the head unit, which means if I bought a Lexus and asked the dealer to take out the head unit, the dealer wouldn't be able to turn around and sell it to somebody who wanted a better unit in their Ford. It goes beyond the mounting system though.
A lot of automakers have their own plug and wiring standards too. If you buy an aftermarket head unit, you usually get a pigtail that plugs into it with unterminated wires on the other side. Then you buy a wiring harness kit specific to your car which has unterminated wires running into a plug that connects to the vehicle harness. Soldering ensues (or wire nuts or electrical tape for the lazy...). Since the aftermarket does have a strong incentive to standardize, the wires on the pigtail that come with the head unit match the colors of the wires in the harness kit, which actually make the process pretty straightforward if you're even halfway handy.
What all of that means is that the unit out of your hypothetical Lexus (which doesn't come with a pigtail with unterminated wires) is going to be hell to get working in somebody else's Ford. Between the physical and electrical incompatibility, the residual value of a head unit has to be pretty close to zero for anybody who doesn't own basically the same car.
You can ask here for cars without sound system, air conditioner, airbag, electric windows....
Never saw a lawsuit on that though, maybe because I never saw a manufacturer be stubborn regarding that.
It might fit if speeder was trying to buy a laptop without RAM or a hard drive so he could put in his own, but my reading of your comment is that you're talking about having a physical part of the product removed and wanting a refund. What speeder is asking for seems more like asking Lenovo to offer an option to order a car with an upgraded the sound system, tires, seats, or engine. This is something many auto makers offer.
It seems that Lenovo, in this case, has decided that the market for cars with steel wheels is too small, and is selling cars without that option. You can only get alloy wheels on your Lenovo car.
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.
"They are almost certainly going to be more secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card."
Not to mention this kind of thing: https://bugzilla.mozilla.org/show_bug.cgi?id=476766
Also, when it comes to stuff this important, there is no such thing as a trusted neutral party.
The main issue with the internet model is how uncompetitive the whole thing is. You have just a few companies handing out keys and they charge upwards of $50 a year just for the "pleasure" of having secured communications.
Secure boot would likely suffer from the same problem. But yet I'd still take that over this...
It's just that, well, there's only really one software manufacturer with enough clout to get all the hardware vendors to include its key, and it's a heck of a lot easier to just get a sub-key signed by their master key than pretty much anything else.
None of the linux vendors banded together to create a NPO which would simply manage keys, ensure it was avialable to all manafacturers. Maybe even provide a logo/stamp/certification/brand so people can instantly see it's supported.
The fact that ONLY Microsoft have done this isn't really the fault of Microsoft. The fact that devs can't agree on the most elegant way of providing the chain of trust, in a manner which plays nicely is again, not Microsofts fault.
Yet Microsoft is being flamed for this.... Why exactly is this their fault?
MS is at fault for pushing this whole system. Whether Linux distros could or not join the system is a red herring.
What?!
Pushing UEFI, which isn't their design, which has been used by Apple and other for years, or pushing secure boot?
Secure Boot is a damned good idea, and whilst IANAL it appears that for a windows sticker you MUST allow it to be switched off.
So its Microsoft are in fact pressuring OEMs to ensure that people can run other OS's on their kit (except ARM).
What this is about is how the other OS's can get the benefit of SecureBoot, well, if they can't get their act together as I mentioend above, why should they fuss that someone else gets SecureBoot. Lets be hoenst too, most people who need such simple "mum proof protection" are on Windows anyway.
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.
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.
There is nothing whatsoever stopping Linux bootkits technically. Please stop spreading FUD.
No matter how you do it, it seems to have the same problems as SSL CAs and certificates (that is, some CAs are corrupt/negligent/compromised).
And in your proposal, what do you do if the root key ever gets compromised?
Such as?
Should Microsoft trust WC3?
Or Foxconn trust the United Nations?
Every organization requires funding. How would this party receive it?
Because the world is unfortunately short of philosopher kings, we are probably better served by the marketplace when it comes to hardware manufacture.
Any PKI based system is a shit idea unless you are personally in control of the trusted root CA, which in this case you're not. I think that is what Linus is saying.
Google for "certificate authority compromised" and you'll see what utter wads of shit for brains this could be entrusted to.
With UEFI secure boot, you can delete Microsoft's key and add you own.
1. http://blog.hansenpartnership.com/owning-your-windows-8-uefi...
It should ship with no PKI/certificate scheme at all. We don't need it and it doesn't work and its blatantly obvious.
Secure boot is entirely worthless from end to end.
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.
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.
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.
Anyway, thanks for an excellent and detailed technical take on the situation as opposed to the knee jerk bashing in many of the other posts.
There's also some excellent detail in the below article without the histrionics.
Signing something from an untrusted source (Having dealt with having to revoke a bunch of Microsoft signed stuff not too long ago, I assure you Microsoft is not infallible) doesn't buy you a whole lot. If you build a driver yourself and sign it, ok. Actually that's probably the best way, download the nvidia driver, sign it with your own one-time key, and voila, even if someone pulls a Folgers Commercial on your driver, they really can't sign it, they don't even know where the one-time key came from.
For a normal user, the effort to try and hack your own signing mechanism seems like it would be non-trivial. Figuring out how to hack a giant 'trusted' signer is a pot of gold at the end of the rainbow. I would not be suprised if there are more compromised signing authorities right now. Flame was signed with a msft key that was actually not meant to sign code, but for several years, since this key was from msft, people happily loaded and ran flame.
I don't really think it's FUD to say trusting your security to the entity that attracts the most attention is not a great plan.
Your points are good, except I disagree that Linux's only beef is parsing PE files, I think that's really the least of his concerns. Msft could deliver up its keys in any form, it won't solve the insecurity of not knowing if your signer has been breached.
Good security is hard, I think that's the main problem with all of Linus's ideas.
It isn't a big deal to the average user because os internals aren't a big deal to the average user. Never the less, linux hasplenty of industry standard security measures like IOMMU support, DEP, ASLR, containers, RBAC, seccomp and so on.
You can't expect the average user to know what technical countermeasures they need anymore than you can expect them to know what garbage collection or interrupt coalescence strategy suits them best. It's important for folks with domain knowledge and pull requests to look out for them. The only problem in this case is the politicization rooted in hatred of a version of microsoft that differs considerably from the one that exists today.
Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy.
That's advice from a different era. On the desktop (any flavor) the attack vectors are almost entirely malicious attachements, plugin exploits, browser and supporting library exploits, other random outbound clients and social engineering.
While linux isn't a popular target, it is at least as vulnerable to these attacks as the others. And due to design issues in X windows, once you can run client native code it is trivial to sniff credentials from the next elevation event.
While it's not infallibile, requiring the rootkit or bootkit to be signed by a CA raises the bar dramatically.
I don't think running as an unprivileged user as often as possible is out of date. Yes, there are plenty of attack vectors, but there's no reason to make it easy. You could run your browser as a different user, so it can't ever see your sudo commands or whatever, just common sense. I'm not familiar with X window exploits to sniff credentials, but I would assume the application being run as a different user than the x session would add difficulty?
FYI my day job is dealing with Windows, driver signing/loading issues, and what have you. I have very low expectations for the security-mindedness of average users. Many people will click on a link after an AV "warning", because "Hey, the AV will stop it if it's really an issue!"
If you, as a vendor, want to support secure boot (as a new, optional, extra feature), I think option B (be the CA) is the only right way to do it. If vendors don't like having to do duplicate work then they can cooperate and form a shared organization to be the central Linux CA. Relying on Microsoft to do the signing is not a good idea long term.
The Linux kernel is simply not the place to parse Windows binaries. It's not Linus's fault the de facto standard is a Windows binary, it's just another harmful side-effect of the Windows monopoly.
Really SecureBoot should just die on the vine. But the monopolist wants to force it on their customers, so here it is.
Why do they have to embed the ID of whitelisted modules in the signed kernel? Why not have a kernel that will load any module the root user tells it to load, then have userland insmod utility verify the signatures using a configuration file like /etc/accepted_module_signers.conf?
Otherwise, you can easily construct a harmful payload consisting of the distro-signed Shim, that kernel, and a modified userspace that loads an arbitrary module which takes over the kernel and runs arbitrary code in ring 0. And then that distro's Secure Boot signing key gets revoked.
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).
Market-driven vendor support of Linux is not unprecedented. Ever heard of Dell, Lenovo, Acer, Nvidia, or the Android ecosystem?
If that was the primary concern where was the criticism when his employer, The Linux Foundation, announced with great fanfare that they had released a microsoft ca signed boot loader to support linux uefi secure boot with the default oem trust setups.
If there is anyone that has a chance at providing a FOSS UEFI signing alternative to Microsoft it's the Linux Foundation. But they're unwilling or unable to do it. Redhat is unwilling to and has proven they have trouble securing their signing keys. Canonical tried and failed to sell vendors on including a ubuntu key, and they weren't even looking to sign for other companies.
There will soon be plenty of people running linux on their computers with secure boot enabled and relying on Microsoft's CA for a chain of trust. It's a done deal and no one is out there stepping up to provide a viable FOSS PKI alternative.
The only thing being debated here is if many of them will be running rather slow and buggy video drivers.
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".
"This 'plausible exploit' has to be some way of getting ordinary Windows users to run the code and become compromised, it's not an experienced Linux user becoming root and subverting Windows on their local box."
Pen testers are already familiar with the idea of leaving compromised USBs in a parking lot. A lot of normal users will pick one up, carry it in, and plug it into their computer to see what's on it.
If the USB key will send your data to a third party, without user understanding or intervention, then that's a security problem.
The usb drive install a linux system over the previous windows installation. Then it install a VM, and set it to run the old windows installation. Have boot set to quiet and on startup, load up the VM.
While a bit slower, you now have hypervisor control over the machine, and the user can install how much anti-virus and anti-rootkits they want. You effectively eradicated the secure boot scheme with the help of the Red Hat key.
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.
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.
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.
It does. You can add your own key and even remove Microsoft's if so wish. The facts are getting lost in this FUDstorm.
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)?
>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?
Mind you, I might be a niche case.
Yes, as I understand it, if you remove the Microsoft key but leave secure boot on, it will refuse to boot Windows. So long as it's on, it will only boot an OS signed with a key it trusts. If you turn it off, it will try to boot whatever's on the disk.
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.
I'm guessing that microsoft has no options for this at all, but I don't know for sure.
Microsoft has no way to prevent this (short of requiring vendors not to allow people to add keys).
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.
My guess is the voting ring detector got triggered or it was mod action. The subsequent submissions of the same story from other outlets going dead suggests that it was mod action.
Every day someone comments saying that HN is biased against their team (see your sibiling “MS astroturfers” comment), and it’s always a different team, often opposites.
Yes, it’s annoying.
I doubt that many members of the upper class (see Fussell's book for a definition of upper class, it is roughly the tastes of "old money" but not dependent upon actual wealth) read Hacker News. It is likely that those who do not object to obscenities such as the word "fuck" are more socially liberal freethinkers who dislike formality. Those who do object are likely to be members of the middle class who believe (foolishly) that in censoring profanities and vulgarities, they are emulating the upper class.
[1] http://www.amazon.com/Class-Through-American-Status-System/d...
For certain, information-sparse, emotionally invested and biased definitions of 'humour, anger, and whatnot'.
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.
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.
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.
http://ftp.osuosl.org/pub/fosdem/2013/maintracks/K.1.105/UEF...