![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59(Update January 18th 2012 - you probably want to read this for details on why the technical details described below are not the difficult bit of the problem)
An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.
The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.
Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.
Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.
An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.
The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.
Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.
Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Is there any way for the end-user to load their own keys?
Date: 2011-09-24 12:44 am (UTC)Re: Is there any way for the end-user to load their own keys?
From:Re: Is there any way for the end-user to load their own keys?
From: (Anonymous) - Date: 2011-09-24 03:56 am (UTC) - ExpandRe: Is there any way for the end-user to load their own keys?
From: (Anonymous) - Date: 2011-09-24 05:08 am (UTC) - ExpandRe: Is there any way for the end-user to load their own keys?
From:Re: Is there any way for the end-user to load their own keys?
From: (Anonymous) - Date: 2011-09-24 08:23 pm (UTC) - ExpandRe: Is there any way for the end-user to load their own keys?
From:Re: Is there any way for the end-user to load their own keys?
From: (Anonymous) - Date: 2011-09-25 12:16 am (UTC) - ExpandRe: Is there any way for the end-user to load their own keys?
From: (Anonymous) - Date: 2011-09-25 10:25 am (UTC) - Expandwhy is this needed?
From: (Anonymous) - Date: 2011-09-26 02:54 pm (UTC) - ExpandRe: why is this needed?
From:Re: why is this needed?
From: (Anonymous) - Date: 2011-10-24 04:24 pm (UTC) - ExpandRe: why is this needed?
From: (Anonymous) - Date: 2012-01-02 04:32 pm (UTC) - ExpandRe: why is this needed?
From:seem a tramp, here lasted on sun 24 sep 2011
Date: 2011-09-24 07:13 am (UTC)http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx
umm seems a tramp..
no subject
Date: 2011-09-25 11:52 am (UTC)Look for the mobile coverage outage news in the Net. And for the blackout in Chile.
Thees were hardware Trojans, NOT software viruses.
This is the only beginning. The USA President Barack Obama is the terrorist Number One in the world, but this is not clear to everyone
Masha Lukyanova
Please be serious
From: (Anonymous) - Date: 2011-09-26 08:44 am (UTC) - ExpandRe: Please be serious
From:DMCA. Unjail your PC, jail yourself.
From: (Anonymous) - Date: 2011-10-20 12:45 am (UTC) - ExpandIn all honesty
Date: 2011-09-26 02:15 am (UTC)With security, we've been running reactively for a very long time and I do not really see the issue. In fact, reactive is how humans are. When we get sick, we respond appropriately. Look up projects like ABACUS, where computers could potentially heal themselves on detection of 'misuse'. We also run retroactively. We have the best of both worlds. Preventing boot-ups because the system detected 'misuse'? That would NEVER fly with me and NEVER would fly with anyone else. What is Microsoft trying to do here? INCREASE downtime? Microsoft has costed the world over 100 billion USD in security problems. When are they going to give that back?
And also, let's just imagine that we had keys and all nice things worked out (as some people seem to state here). So now I have to find some 'authority' who can give me the keys to do WHAT I WANT to with MY (potentially custom built) machine? That is absolute nonsense! Any of you are suggesting that there be 'Linux keys', or 'Ubuntu keys' (yuck) means that you do not see an underlying problem. Sure, today for some odd reason we trust CA's like VeriSign to secure our websites (honestly I still find this a strange deal). Why? Why should we trust anyone other than ourselves in this regard? Who made them king?
In a hacker sense: if a motherboard has this functionality, hack it to death and REMOVE IT ENTIRELY. Do not even have a bit of this. It's absolute nonsense!
In another sense: I should NEVER have to do anything like just mentioned just to do get the OS I want running, nor should I have to do any key fiddling.
The fight will go on. In fact, I hope UEFI+secure boot turn out to be a disaster and the security problems for Windows users go UP instead of down. Go on malware writers! Keep doing what you do until Microsoft is bankrupt!
Things the way they are just fine if you ask me, if you NEVER use Windows. Linux (almost any distro) and Mac OS X are 2 fine operating systems that don't need this crap.
Re: In all honesty
From: (Anonymous) - Date: 2011-09-26 06:22 pm (UTC) - ExpandRe: In all honesty
From: (Anonymous) - Date: 2011-09-27 05:58 am (UTC) - ExpandRe: In all honesty
From: (Anonymous) - Date: 2011-09-28 05:50 pm (UTC) - ExpandRe: In all honesty
From: (Anonymous) - Date: 2011-10-02 02:05 pm (UTC) - ExpandRather Upside Down Reasoning
From: (Anonymous) - Date: 2011-10-24 04:40 pm (UTC) - ExpandRe: In all honesty
From: (Anonymous) - Date: 2012-01-02 04:42 pm (UTC) - ExpandRe: In all honesty
From:Re: In all honesty
From: (Anonymous) - Date: 2012-02-27 11:08 pm (UTC) - Expandno subject
Date: 2011-09-27 08:03 pm (UTC)Moving to Windows 8 is a hard choice for most users - new investment, brand new pc and not able to upgrade to Windows 9 or a better OS - is a curse.
What I expect is - this feature will have an option to disable it, if it does not, then we will see it in court.
So, in short, its pretty much useless and back to the 80s BIOS stuff. I also suspect this will be enabled by default by major manufacturers and ignored by 99% of computer users, until Win 9 comes out/switching OS/PC needs rescue they realized they need the D F Manuals.
Windows OEM manufacturer will get blamed and users at a losing side, OEM manuf is playing with fire.
Lets watch in 2 years time
http://www.google.com.my/search?hl=en&q=disabling+EUFI
Current: 444,000 results
Early problem winner goes to-
http://forums.lenovo.com/t5/W-Series-ThinkPad-Laptops/W520-UEFI-and-Bitlocker/td-p/439857
no subject
Date: 2011-09-27 08:19 pm (UTC)no subject
Date: 2011-09-28 05:57 pm (UTC)So far everyone is discussing a problem, but I think what most people would love to hear is potential solutions to this.
What would you point as a potential solution for this mess ?
All the best,
NM
Screw Microscum
From: (Anonymous) - Date: 2011-09-29 07:26 am (UTC) - ExpandRe: Screw Microscum
From: (Anonymous) - Date: 2011-10-08 04:33 pm (UTC) - Expanddeath to MS find new enemy
From: (Anonymous) - Date: 2011-09-29 01:05 pm (UTC) - ExpandMatthew described a solution in a previous post
From: (Anonymous) - Date: 2011-10-02 11:41 am (UTC) - ExpandSpread the word...
Date: 2011-10-14 04:53 pm (UTC)http://software.intel.com/en-us/forums/showthread.php?t=87355
This is really about losing the ability to modify both the hardware and the software -- in other words, you cannot use your own PC in a way you want. People who say "there will be Linux/Ubuntu keys" forget that they most likely won't be able to compile their own bootloader and/or kernel and sign them.
Instead of punishing those who abuse PCs for cyber crime they want to make sure that it is impossible to commit it. If they used the same principles in real life, firing a weapon would require a signed key for every bullet.
What happens if one of the supported keys gets leaked/discovered?
Date: 2011-10-20 02:18 pm (UTC)I guess the problem revolves around the signing key which is unlikely to make its way into the public. What if it does? Also, what happens when the certificates expire? Surely I'm either insane for asking these questions or they have already been addressed (or both)..
Re: What happens if one of the supported keys gets leaked/discovered?
From:UEFI and Linux
Date: 2011-10-27 08:18 am (UTC)solution ?
Date: 2011-12-30 12:36 am (UTC)So, if you want to install Windows 8, it will install the extension, but it can also be uninstalled ?