View source for UEFI SecureBoot mini-HOWTO

= Introduction =

This document aims to help Linux distributions cope with UEFI SecureBoot; it focuses on SecureBoot part primarily although working implementation of plain UEFI boot support is required in the first place<ref>those implementing are advised to have a look at [http://www.rodsbooks.com/efi-bootloaders/principles.html introduction into UEFI boot process]; the topic is clearly out of this document's scope, a separate HOWTO of comparable size could be written if available distributions wiki pages are not enough</ref>.

Getting seamless boot<ref>as in missing "access denied" with no apparent way around it</ref> on x86 systems with SecureBoot enabled out-of-box basically requires dealing with UEFI CA<ref>there's a single UEFI Certification Authority currently and it's Microsoft Corp, incidentally; by a chance, Microsoft's "Windows 8 Logo" certification for hardware results in SecureBoot enabled by default with Microsoft's certificate enrolled into firmware as well as Fast Boot enabled which can pose [http://mjg59.dreamwidth.org/24869.html another serious issue] ([http://mjg59.dreamwidth.org/24869.html?thread=941861#cmt941861 5 second press?])</ref>.  They offer to sign EFI binaries which have passed their review with "Microsoft Windows UEFI Driver Publisher" key for 3rd party drivers.

As it would be highly impractical at best to have to sign bootloaders this way though<ref>even worse for kernels as the review process does take time and sometimes updates are urgent</ref>, the nice folks at Red Hat and SUSE have developed UEFI shim<ref>shim.efi: a program that can be built with a distribution's certificate embedded to be able to verify the binaries signed with it and that can be further signed with Microsoft's key so that generic PC hardware will agree to run it</ref> which makes the review/sign process much more rare but it still has to be done at least once<ref>shim also enables the user to sign binaries with their own Machine Owner Keys (MOK), you're encouraged to read up on that and provide your users with corresponding tools and/or documentation</ref>.

This document relates to [http://www.altlinux.com/ ALT Linux] case and thus has some inevitable peculiarities.  We hope that it will be helpful to those willing to take the trouble for their users though.

You should also comprehend FSF statement on the problem: [http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web "We reject the recommendation that others join the Microsoft developer program"].

Thanks go to:
* Peter Jones (Red Hat) -- for his kind replies and implementation advice<ref>see also [https://fedoraproject.org/wiki/Features/SecureBoot Fedora SecureBoot feature page]</ref>;
* Matthew Garrett (Red Hat->Nebula) -- for [http://mjg59.dreamwidth.org/20303.html?thread=783183#cmt783183 this terse walkthrough] and the many articles;
* Gary Ching-Pang Lin (SUSE) -- for [https://www.suse.com/communities/conversations/uefi-secure-boot-details/ MOK concept] implementation;
* all of them for the resulting [https://github.com/mjg59/shim shim] and other code required;
* Roderick Smith -- for his solid [http://www.rodsbooks.com/efi-bootloaders/ documentation] and beautiful [http://www.rodsbooks.com/refind/ refind] bootloader;
* Suhas Manangi (Microsoft) -- for patient CA-side explanations.

This document has been written by [mailto:mike@altlinux.org Michael Shigorin] for [http://altlinux.com/ ALT Linux]; feel free to provide criticism, suggestions, feedback but please understand that I can't answer every single question, especially within areas not trodden during this work.

= The Plan =

# prepare the assets
# obtain shim.efi signed by UEFI CA
# wire the rest of the distro to make use of it

= Implementation =
<tt>
X-Ears: red<br />X-Plug: shameful<br />Subject: [[Rescue|ALT Linux Rescue]]

Hello everybody out there needing rescue -

I've implemented a [http://nightly.altlinux.org/sisyphus/flavours/rescue/ CD/Flash, BIOS/UEFI hybrid rescue image] that<br />can stand SecureBoot and still help you get your system to just boot.<br />
It's been brewing for a few years and actually works for me now.

Being a part of weekly [[Regular|regular builds]], it's ever-relevant since<br />these images are baked from "current" ALT Linux Sisyphus repository.

--&nbsp;<br />
&nbsp;---- WBR, Michael Shigorin / http://altlinux.org<br />
&nbsp;&nbsp;------ http://opennet.ru / http://anna-news.info
</tt>

== Assets ==

You will need:
* $99+, several days to a few weeks, and a Windows host/VM
* hardware or KVM stand with SB-capable firmware
* some more packages (or whatever you do)

The suggested steps are:
# start obtaining Symantec certificate for a company (or private person)
# prepare the binary builds of a signing tool, shim and grub2 (or another bootloader)
# bring up a distribution-specific certification authority and create a pair of certificate+key pairs (CA and Signer)
# build and test shim.efi containing the public part of your CA cert
# build and test at least one EFI capable bootloader signed by your Signer key

The result should be "ready to start approaching UEFI CA".

=== Verisign/Symantec certificate ===

==== Why ====

This one [http://msdn.microsoft.com/library/windows/hardware/89cf1c2c-9342-4bf4-a8ee-fe33d7c024e5 is needed] ''once'' to authorize the company<ref>Matthew Garrett [http://mjg59.dreamwidth.org/20303.html?thread=783183#cmt783183 notes] that "you can do this as an individual" regarding creating the new company account</ref> when registering at UEFI CA portal and then ''each time'' you prepare the upload to be reviewed and signed.  It's an Authenticode class 3 certificate; one can be [https://products.verisign.com/orders/enrollment/winqualOrder.do obtained with discount]<ref>at $99/year instead of the usual [https://www.symantec.com/popup.jsp?popupid=csc_ms_authenticode_buy&footer=0 $499+]; [http://msdn.microsoft.com/en-us/windows/hardware/gg463054.aspx#_Establishing_a_Hardware_Dashboard_Account you may need to renew the certificate with standard fees, depending on the validity of the certificate]</ref> via [https://sysdev.microsoft.com/en-US/Hardware/signup/ Windows Dev Center].

==== How ====

The process requires IE7+<ref>that doesn't mean Firefox, strangely enough</ref> with a [https://knowledge.verisign.com/support/code-signing-support/index?page=content&id=SO13931 peculiar setup of ActiveX]<ref>note that options might be quite hard to reverse-translate in case of localized Windows, you're likely to end up doing [https://knowledge.verisign.com/support/code-signing-support/index?page=content&id=SO13931 LC_MESSAGES=C windows-way]</ref> to get a certificate generated and imported to be exported into a file.  See the [http://nftb.saturdaymp.com/dealing-with-microsofts-smartscreen-filter-part-2-getting-a-code-signing-certificate/ walkthrough]<ref>here's [http://web.archive.org/web/20131209144507/http://nftb.saturdaymp.com/dealing-with-microsofts-smartscreen-filter-part-2-getting-a-code-signing-certificate/ archive.org copy just in case]</ref>.  Do not dispose of that host/VM at once, you will need it later<ref>...which might involve something like prolonged MSDN subscription</ref>.

It took three business days for us<ref>and yet another check method as compared to the two cases described above and by Matthew (but we're a company indeed)</ref>.

==== Where to ====

Get the certificate+private key obtained from Import Export software into a standalone file:
# Options > Content > Certificates > Personal
# choose the certificate
# click Export
# choose "Yes, export the private key" and "Personal Information Exchange - PKCS #12 (.PFX)"

The password should be strong enough but care not to lose it (reasonable offline storage like a paper in an envelope inside a safe is recommended backup).  Backup the file and keep it in safe dry location as well.

'''Deliverable:''' .pfx file including the private key exported to PKCS#12 form.

=== Testing facility ===

This could be a notebook, desktop, server or barebone/improvised system which is declared to be "Windows 8 Ready" which means it supports UEFI 2.3.1 spec version or later.  We chose a notebook shipping with Windows 8 to be able to test dualboot as well.

This could also be a [http://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm Linux KVM instance booted with TianoCore firmware] build supporting that spec version; virtualized approach has both upsides (ease of reversion) and downsides (burden of re-initialization) but one can use both real and virtual stands after all.

'''Deliverable:''' something that can boot PE binaries or refuse to due to the "wrong" signature or the lack thereof.

=== Specific software ===

You need to make sure that several packages<ref>let's call these entities this way, substitute whatever form of deliverables your distribution uses</ref> are available: signing utilities, UEFI shim and a EFI capable bootloader<ref>...until you want to work out a scheme booting the kernels directly</ref>; <tt>nss-utils</tt> will and <tt>openssl</tt> might come handy too but you should be able to just install these.

A few more utilities are needed ''each time'' to prepare shim for upload and to prepare <tt>winqual.exe</tt> ''once'' as well.

'''Deliverables:''' at least the working binaries for initial experiments; proper packages are highly preferred for reproducibility.

==== winqual and shim related ====

<tt>cabextract</tt> is probably there already; you will most likely still need to build [http://sourceforge.net/projects/osslsigncode/files/ osslsigncode] and [http://ohnopub.net/~ohnobinki/lcab/ lcab].

==== gnu-efi ====

Your distribution might be carrying this toolchain already, most likely so if it does support UEFI.  In case it does not, take a look at [http://sourceforge.net/projects/gnu-efi/files/ 3.0r and 3.0u]: 3.0s and 3.0t have known regressions while earlier versions had other kinks not worked out yet, this tends to result in EFI binaries hanging upon the start; my 3.1 experiments weren't successful so far either.

Sticking with 3.0r for bootloaders looks good so far, 3.0u gets some interesting CWD handling differences in resulting binaries for me.  Fedora RPM spec [http://pkgs.fedoraproject.org/cgit/gnu-efi.git/tree/gnu-efi.spec here].

I've built shim binaries with 3.0u before having discovered those differences and have settled for multiple gnu-efi versions available in repository<ref>this should also make testing/deploying new gnu-efi versions somewhat easier</ref>; YMMV.

==== pesign ====

We'll discuss Fedora's <tt>pesign</tt> which is more capable and versatile than Ubuntu's <tt>sbsigntools</tt><ref>you're still free to examine more docs and use/write whatever you like of course</ref>.  It can do client/server and provides a few more useful tools like <tt>efikeygen</tt>.

Grab [https://github.com/vathpela/pesign pesign source] and make sure you have 0.106 to 0.109 (as of today) built and working.  Fedora spec is [http://pkgs.fedoraproject.org/cgit/pesign.git/tree/pesign.spec here].  I chose to leave Red Hat Test Certificate as the default packaged one to avoid needless duplication and to give some extra credit. :)

==== shim ====

Basically there are two flavours of EFI shim<ref>I didn't really try my hand at LF's [http://www.linuxfoundation.org/news-media/blogs/browse/2012/10/linux-foundation-uefi-secure-boot-system-open-source PreLoader] finding it somewhat less apt than shim for ALT's purposes</ref>: <0.5 and >0.5.

0.5 itself is broken (it won't work on UEFI firmware without SecureBoot implementation) so you'll likely choose 0.7 or later which also implement [https://github.com/mjg59/shim/commit/f95ccd0a7f64c0a63b06fddd278a3e35aa96eba9 further restrictions] on subsequent bootloader basically blowing it up if the bootloader doesn't verify a signature.  This ends up requiring at least the kernel images to be signed as well.

0.4 lacks this kind of behaviour but [http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx there's no warranty that these builds will get signed].

You want as few patches as possible, ideally just [https://github.com/mjg59/shim clean upstream commits].  If using 0.7 or later, the upstream-recommended procedure is:

 git checkout 0.7
 make test-archive

...and to use the resulting tarball; this will cause the output of

 git log -1 --pretty=format:%H > /tmp/shim-$(VERSION)/commit

to exist in the tarball, which will make the commit ID show up in an ident string.  This should greatly aid the CA's efforts in knowing what's being signed and might come handy to you too.

==== grub2 ====

You can choose between several implementations that share the ability to be built as EFI binaries and to start other EFI binaries passing the commandline to Linux kernels<ref>in alphabetic order</ref>:

* [https://github.com/mfleming/efilinux efilinux]
* [http://elilo.sf.net/ elilo]
* [http://www.gnu.org/software/grub/ grub2]
* [http://refind.sf.net/ refind]

We use <tt>refind</tt> and <tt>elilo</tt> either but <tt>grub2</tt> is the most "generic" layer of code that can also boot something else on occasion.

You want 2.00 with considerable number of patches or later versions if/when these get released and work for you.

The most important choice is whether you will get it to verify the kernel's signature (required by recent shim versions).  I chose not to but we've got shim-0.4 build signed.

=== Your CA ===

The method covered here is a pretty standard basic CA scheme: there's one self-signed CA certificated (cacert) and at least one signing certificate which is signed by that one<ref>...so that signing certificates can be changed without having to change CA certificate and corresponding loss of ability to verify the trust chain up to the deployed one</ref>.  Other methods were not considered reasonable.

You need to generate and store those in a reasonably safe manner so that private key material leak is not feasible.  It is strongly recommended that everybody use FIPS 140-2 Level 2 hardware security modules<ref>The cheapest smartcard/USB/etc HSMs you can buy satisfy this requirement, it's basically "you can lock a private key on a card and never be able to extract it"</ref> for all key storage.

These should be [http://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ RSA2048/SHA256] [https://support.ssl.com/index.php?/Knowledgebase/Article/View/19 X.509] certificates.

It is recommended to use <tt>efikeygen(1)</tt> utility from pesign package as it will set up the NSS DB as intended with minimal hassle:

 mkdir ~/ca/altlinux
 
 certutil -d ~/ca/altlinux -N
 
 efikeygen -d ~/ca/altlinux \
   --ca --self-sign \
   --nickname='ALT Linux UEFI SB CA' \
   --common-name='CN=ALT UEFI SB CA 2013,OU=ALT Certification Authority,O=ALT Linux Team,C=RU' \
   --url='http://altlinux.org/UEFI' --serial=00
 
 efikeygen -d ~/ca/altlinux \
   --signer='ALT Linux UEFI SB CA' \
   --nickname='ALT Linux UEFI SB Signer' \
   --common-name='CN=ALT UEFI SB Signer 2013,OU=ALT Certification Authority,O=ALT Linux Team,C=RU' \
   --url='http://altlinux.org/UEFI' --serial=01
 
 pk12util -d ~/ca/altlinux -o signer.p12 -n 'ALT Linux UEFI SB Signer'
 
 mkdir ~/ca/signer
 
 certutil -d ~/ca/signer -N
 
 pk12util -d ~/ca/signer -i signer.p12
 
 shred signer.p12

You might want to read up a bit: [http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html SSL Certificates HOWTO], [http://www.openssl.org/docs/HOWTO/certificates.txt OpenSSL Certificate HOWTO], [http://www.mozilla.org/projects/security/pki/psm/help_21/glossary.html Mozilla's Glossary].

[http://blog.hansenpartnership.com/uefi-secure-boot/ Note that when the UEFI spec says “key”, it doesn’t mean the same as an openssl key.  In UEFI parlance, the “key” or “public key” means the public part (i.e. the X509 certificate); openssl uses the term key to mean the private key used to sign stuff with.]

'''Deliverable:''' a password-protected NSS database holding cacert and signer cert with corresponding private keys.

=== Signing EFI binaries ===

pesign<ref>we've settled with pesign, those interested in sbsigntools are advised to have a look at [http://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools openSUSE documentation]</ref> can work in both standalone and client/server modes; the process doing the actual signing (pesign) must be given at least read-only access to the NSS database directory containing the Signer certificate or a [https://fedoraproject.org/wiki/User:Pjones/SecureBootSmartCardDeployment smart card token] capable of signing.

==== standalone ====

 pesign -s -n ~/ca/signer -c "ALT Linux UEFI SB Signer" -i grub.efi -o grub-signed.efi

==== server ====

Example of manual debug start:

 # pesign -D -N -v -n /path/to/ca/signer

==== client ====

Running client/server requires that the client process is started by a user with enough permissions to access /var/run/pesign/socket.

 $ pesign-client -u
 $ pesign-client -s -c "ALT Linux UEFI SB Signer" -i grub.efi -o grub-signed.efi

The former command asks for the NSS DB password and provided the correct one triggers unlocking the database; the latter command feeds the binary to the server to get it signed.

== Preparing sysdev account ==

You will need once:
* Windows host/VM
* Symantec/Verisign certificate
* live.com account
* several days to a few months

The suggested steps are: 
# obtain a live.com account
# authenticate/link the company to that account
# read and accept Microsoft's agreements

=== Logging in ===

sysdev.microsoft.com requires a live.com account to work with it so you're forced to obtain one.

=== Authenticating the company ===

This process is set up by means of signing a test binary with [http://msdn.microsoft.com/en-us/windows/hardware/gg463054.aspx#_Establishing_a_Hardware_Dashboard_Account Symantec/Verisign provided certificate] and needs to be done once.

You will have to:
# create a certificate database with Symantec certificates imported into that
# download winqualexe.zip from sysdev.microsoft.com, unpack and pesign it
# upload the signed winqual.exe back to sysdev.microsoft.com

==== Preparing NSS database ====

Our file holding the exported certificate+private key in PKCS#12 form is referred to as "altlinux.pfx" below, adjust as appropriate.

Additionally, save [https://knowledge.verisign.com/support/code-signing-support/index?page=content&id=AR1739 Symantec intermediate certificates] into primary.crt and secondary.crt files.

Then import these into a separate certificate database:

 mkdir -p ~/ca/symantec
 certutil -N -d ~/ca/symantec
 certutil -A -n 'Symantec primary' -d ~/ca/symantec -t CT,CT,CT -i primary.crt
 certutil -A -n 'Symantec secondary' -d ~/ca/symantec -t CT,CT,CT -i secondary.crt
 pk12util -A -n 'ALT Linux (authenticode)' -d ~/ca/symantec -i altlinux.pfx
 certutil -L -d ~/ca/symantec

The last command should list the three certificates with the last one having xx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx form of certificate nickname and "u,u,u" trust attributes.

==== Obtaining the test binary ====

See [http://msdn.microsoft.com/en-us/library/windows/desktop/br230783.aspx this MSDN article], download [http://sysdev.microsoft.com/downloads/winqualexe.zip winqualexe.zip] and unzip it.

==== Signing with Symantec certificate ====

Use that last certificate nickname to sign the downloaded binary:

 pesign -n ~/ca/symantec -c xx-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
   -s -i ~/unsigned/winqual.exe -o ~/signed/winqual.exe

This one is to be uploaded to confirm that the registered company name relates to a real company<ref>...or at least that Symantec says so</ref>.

=== Legal Agreements ===

These are "Windows Logo Program Testing Agreement V3" and "UEFI Firmware Agreement" as of autumn 2013.

You'll need to give permissions to sign agreements to the account used (which is administrative) or another user's one if there are several involved:
* Dev Center - Hardware > Administration > Legal agreements

== Getting your shim signed ==

You will need this each time you build new production shim:
* Windows host/VM with [http://mjg59.dreamwidth.org/20303.html?thread=783183#cmt783183 Silverlight available]
* shim.efi containing your cacert's public part and verified to work generally
* Symantec certificate to sign the submission
* sysdev account with UEFI signing permission
* several days to several weeks

The suggested steps are:
# prepare shim.efi for submission
# upload shim.cab to sysdev.microsoft.com
# send a questionnaire to [mailto:sysdev@microsoft.com sysdev@microsoft.com]
# wait and check both inbox and spambox of the account used periodically
# download the signed binary if/when completed

You might choose to further sign the obtained binary with the Signer key to have two signatures thus supporting the case when firmware is clean of Microsoft's ones but yours is enrolled.

=== Preparing the upload ===

The EFI binary to be signed by UEFI CA has to be extracted from the package you have built already, wrapped up as a CAB file and signed:

 lcab shim.efi shim-unsigned.cab

<tt>osslsigncode</tt> is weird enough to only accept the password via the commandline<ref> instead of asking for that interactively by default, what a shame for security related utility</ref>; so don't forget to prevent it to be stored in shell history in its entirety, e.g. for <tt>bash</tt>:

 export HISTCONTROL=$HISTCONTROL:ignorespace
  osslsigncode sign -pkcs12 altlinux.pfx -pass xxxx -in shim-unsigned.cab -out shim.cab

'''Deliverable:''' shim.cab file ready for upload.

=== Uploading shim ===

# boot that Windows host/VM up
# start a web browser with Silverlight plugin available
# log into sysdev.microsoft.com
# go to Hardware Certification > Create UEFI submission
# choose the prepared shim.cab file
# enter something like "shim.efi (upstream 0.7)" as a Name<ref>it's not explained at all and should rather be named "Description" actually</ref>
# submit

'''Deliverable:''' submission ID.

=== Posting the answers ===

You can expect a query from sysdev@microsoft.com for some additional details or care to [http://msdn.microsoft.com/en-us/windows/hardware/dn167637.aspx provide these beforehand] with a reference to the obtained submission ID in Subject: line.  The questions to be expected are:

# Does your company have an external URL?  If so, please provide an external link to the website.
# Does the UEFI submission contain product quality code?
# Include a brief statement on the purpose or goal for the UEFI submission.
# Is the UEFI submission associated with another program?
# Does the UEFI submission include license terms that would mandate the transmission of keys used for signing? (i.e., GPLv3 or similar)
# Does your submission load and execute any other code prior to ExitBootServices()? If so, please explain how the code is loaded, authorized, and executed.  For example, All images are loaded by EFI LoadImage() and executed by EFI StartImage(), and a prompt is displayed to the user requesting authorization.

=== A long wait ===

Looks like the sysdev guys are going through the queue once or twice a week; expect at least three days of normal silence, if that's longer than a week or so:
* query Hardware certification > Manage submissions page for the status
* re-check the spambox
* ask sysdev@microsoft.com referring to that submission id

It took three weeks in our case as we didn't know about that questionnaire yet.

=== Downloading shim ===

UEFI CA will send a notification email including the download link with Subject: including "UEFI Submission Processing Complete" to the email address of live.com account which has done the submission -- provided that the binary has passed the review and ended up with "Approved" status.

The cabextracted binary should manifest a signature:

<pre>
$ pesign -S -i shim.efi
---------------------------------------------
certificate address is 0x7f5ec2a4a8e8
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
---------------------------------------------
</pre>

'''Deliverable:''' the precious shim binary :-|

== Re-fit boot bits together ==

You will need:
* hardware or virtual stand with SecureBoot enabled
* existing support for [http://www.rodsbooks.com/linux-uefi/ UEFI boot/install]<ref>it is specifically ''not'' covered in this document, another one of similar volume can be written regarding this topic</ref>
* further patience to tweak the already working parts

=== In a nutshell ===

You have to ensure that there's a verified boot chain when SecureBoot is enabled for both install/live media and the installed operating system:

# bootx64.efi or shim.efi (shim)
# grubx64.efi<ref>this name gets hardcoded into shim binary at build time</ref> (some primary bootmanager/bootloader)
# vmlinuz (kernel) or some secondary bootloader

This chain can vary after shim but [https://www.suse.com/communities/conversations/uefi-secure-boot-details/ the main principles stay]:
* shim is verified by a key that is available to firmware via KEK/DB and further verifies the loaded binary via its embedded certificate, MOK or firmware;
* the subsequent bootloaders can communicate to shim to make use of your certificate information embedded into it and of MOKs added by the user of a particular machine.

Trying your hand at plain FAT-formatted USB flash drive first is recommended<ref>...but you knew that already, right?</ref>.

=== ALT way ===

Your implementation may vary significantly; ALT Linux one is:

* shim -> refind -> elilo -> vmlinuz for install/live/rescue media
* shim -> grub2 -> vmlinuz for installed system

[http://www.rodsbooks.com/refind/ refind] is a wonderful piece of software of the same high quality as [http://www.rodsbooks.com/efi-bootloaders/ Rod Smith's manuals] are; we use it as a comprehensive boot manager for media as some UEFI implementations have inferior ones or even lack a proper boot manager completely.

elilo acts as a "filter" to only allow Linux kernels to be booted; we need that<ref>feasible with shim < 0.5</ref> as we want to give our users the ability to boot non-signed kernels still not to provide a gaping way to boot unsigned anything.

=== GRUB ===

Note that you might need to teach grub-install script to:
* avoid rebuilding EFI binary image if SecureBoot is enabled but rather to copy over the prebuilt signed binary;
* install signed shim,
ALT Linux way of doing that is a [http://git.altlinux.org/people/mike/packages/?p=grub2.git;a=blob;f=grub-2.00-install-uefi-signed.patch;h=9f9086078d5fa88faed8f4d2300316e1631a2590;hb=refs/heads/master simplified version] of [http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/grub2/saucy/view/head:/debian/patches/install_signed.patch Ubuntu/Debian patch] for GRUB 2.00.

You might also prefer to review [http://patch-tracker.debian.org/package/grub2 Debian], [https://build.opensuse.org/package/show/openSUSE:Factory/grub2 openSUSE] and [http://git.pld-linux.org/?p=packages/grub2.git;a=tree PLD] patches; [http://pkgs.fedoraproject.org/cgit/grub2.git/tree/ Fedora package] is somewhat hard to follow by now as it contains 9-bit number of patches at the moment which rather look as [http://git.savannah.gnu.org/cgit/grub.git/log/ upstream git] presented as patch series.

= References =

== Overviews ==

* [http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Free Software Foundation recommendations for free operating system distributions considering Secure Boot ]
* [http://mjg59.dreamwidth.org/20303.html?thread=783183#cmt783183 Matthew Garrett's terse shim signing walkthrough]
* [http://blog.hansenpartnership.com/adventures-in-microsoft-uefi-signing/ James Bottomley's Adventures in Microsoft UEFI Signing]
* [http://nftb.saturdaymp.com/dealing-with-microsofts-smartscreen-filter-part-2-getting-a-code-signing-certificate/ Getting a Code Signing Certificate]
* [http://www.rodsbooks.com/efi-bootloaders/secureboot.html Managing EFI Boot Loaders for Linux: Dealing with Secure Boot]
* [http://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ The Meaning of all the UEFI Keys]

== Project pages ==

* [http://docs.fedoraproject.org/en-US/Fedora/18/html-single/UEFI_Secure_Boot_Guide/index.html Fedora 18 UEFI Secure Boot Guide]
* [http://en.opensuse.org/openSUSE:UEFI#Secure_Boot openSUSE:UEFI]
* [https://www.suse.com/communities/conversations/uefi-secure-boot-details/ SUSE and Secure Boot: The Details]
* [https://wiki.ubuntu.com/SecurityTeam/SecureBoot SecureBoot]

== Footnotes ==
<references />

[[Category:ALT Linux]]
[[Category:Distributions]]
[[Category:HOWTO]]