[arch-general] UEFI secure boot

Jayesh Badwaik jayesh.badwaik90 at gmail.com
Tue Jun 5 09:01:02 EDT 2012

On Thursday 31 May 2012 10:48:27 Genes MailLists wrote:
>   Matthew Garret(Redhat) has written[1] an updated and interesting
> blog on this topic; which of course will impact arch too ... sharing
> in case anyone hasn't seen it:
>    http://mjg59.dreamwidth.org/12368.html
>   gene/
> [1] Also discussed some in fedora ML

My opinion on this topic is as follows:

1. Secure Boot is not completely bad. There can be legitimate purposes 
to using Secure Boot. Though in a linux community, there will be no top-
down usage. I don't think the need is with repsect to the distribution 
of the software since the package signing and similar mechanisms already 
exist for the same. However, on an individual level, the secure boot can 
be used to prevent individual tampering of machines. For example, anyone 
cannot just turn on my machine and then try to boot through USB and then 
change something on my system. He will have to either crack the BIOS or 
do something similar which is much more difficult I am guessing. I am not 
100% percent sure but this is the gist of the feature. I think Linus 
Torvalds also supports this [0].

2. While this feature is good, it is not always required and hence, may 
create additional trouble/overhead for experimental adventures or even 
some normal work. Hence, there should be an option to boot without the 
secure boot being enabled. 

3. The sole reason Fedora is going with this approach is the fact that 
target users of Fedora include people who put in the CD ROM and let the 
installer install everything automatically. They don't want people to 
have to go into BIOS and fiddle with things. ArchLinux user is a hacker 
by spirit whether competent or not. Going into BIOS and reading some 
BIOS manuals should not be much more difficult than trying to install 
/boot partition on LVM in the current state of ArchLinux installation 

4. There are problems with using a Microsoft key. Recently there was a 
news that the Microsoft key was used to insert the Flame malware into 
computers. While I don't have anything against Microsoft, it seems 
simple that trusting by default a key that can be exploited is bound to 
create problems, especially as the key is not under your control [1]

My solution to this is as follows:
a. An advanced user should be expected add his key to the BIOS and then 
use it if he wants to use the Secure Boot. There should be provision in 
the mkinitcpio or some similar utility to sign the  appropriate files 
with the appropriate key.

b. There should be an option to create the files without signing for 
normal non-secure boot. 

c. The next question is of the ArchLinux DVD distribution and the 
initial bootloader. For this, I guess, we can offer Microsoft-signed or 
ArchLinux-signed images so that people are able to boot into the 
installer without going into the BIOS. This way, people who have less 
skill set and are afraid to go into the BIOS and change things are not 
stymied at the first step itself. 

I personally delayed installing ArchLinux on my computer for around two 
months due to my semester. However, in the mean time,  I tried the 
ArchLinux CD and went on trying a new thing and going one step further 
every weekend on a different hard drive and by the end of the semester I 
did not really have to stop and learn about ArchLinux. My point is that 
people may just try out the ArchLinux CD trying to figure out what to do 
once they reach the command line root prompt. For them, having to go 
into the boot menu and disabling the option everytime they boot from a 
signed system to unsigned is irritating. This will not push away people 
but it is irritating all the same. 

Jayesh Badwaik
stop html mail      | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

[0] http://www.muktware.com/news/2865/linus-torvalds-secure-boot-good-
[1] http://arstechnica.com/security/2012/06/flame-wields-rare-collision-

More information about the arch-general mailing list