![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Supporting UEFI secure boot on Linux: the details
(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.
Re: In all honesty
(Anonymous) 2011-09-26 06:22 pm (UTC)(link)Re: In all honesty
(Anonymous) 2011-09-27 05:58 am (UTC)(link)Interesting.
Re: In all honesty
(Anonymous) 2011-09-28 05:50 pm (UTC)(link)Re: In all honesty
(Anonymous) 2011-10-02 02:05 pm (UTC)(link)They load the clip in omnicolour
Said they pack the 9, they fire it at prime time
Sleeping gas, every home was like Alcatraz
And motherfuckers lost their minds
No escape from the mass mind rape
Play it again jack and then rewind the tape
And then play it again and again and again
Until your mind is locked in
Believin' all the lies that they're tellin' you
Buyin' all the products that they're sellin' you
They say jump and you say how high
You're brain-dead
You've gotta fuckin' bullet in your head
Just victims of the in-house drive-by
They say jump, you say how high
Just victims of the in-house drive-by
They say jump, you say how high
Uggh! Yeah! Yea!
(You're) Standin' in line
Believin' the lies
(You're) bowin' down to the flag
You got a bullet in your head
Lyrics here: http://www.sing365.com/music/lyric.nsf/Bullet-In-The-Head-lyrics-Rage-Against-The-Machine/DEE35258A53EA716482568A50012B22C
Video clip (Warn' FLASH): http://www.youtube.com/watch?v=9TDgkOOlbwg
Rather Upside Down Reasoning
(Anonymous) 2011-10-24 04:40 pm (UTC)(link)This doesn't stop tampering from going on. It just stops your machine from running after it's been tampered with. In theory, this gives you the opportunity to reverse the tampering. In practice, we'll see.
I don't generally trust firmware/hardware based encryption. Without the ability for the user to modify the key database himself it takes away more control of the machine, and in no way is it guaranteed to be unhackable (though it may afterward be unfixable). Give the user the ability to control the key database, and then I might trust it a bit more.
Re: In all honesty
(Anonymous) 2012-01-02 04:42 pm (UTC)(link)So as an analogy, secureboot hands your keys over to a bunch of strangers and you then have to trust them with your house.... stupid idea - I trust me, not some bunch of corporations whose main aim is to make money, my security is way down their list of priorities.
And what makes you think trojans won't run quite happily within the secureboot environment - they're trojans, they'll simply masquerade as something else. Secureboot != anti-virus.
Re: In all honesty
Re: In all honesty
(Anonymous) 2012-02-27 11:08 pm (UTC)(link)