User:Sakaki/Sakaki's EFI Install Guide/Configuring Secure Boot under OpenRC

In this section, which has no equivalent in the standard Gentoo handbook, we'll be setting up secure boot on your target machine.

While secure boot has received mixed reviews from the Linux community, it is a useful facility. With it activated, your machine will refuse to boot an executable that has been changed since it was signed (in an 'evil maid attack' for example), thereby closing off an important attack vector.

Windows 10 (and 8)-certified hardware ships with secure boot turned on by default (but only the Windows-sanctioned public keys installed in the machine), which is why, to get things started, we had to turn this feature off in the BIOS earlier in the tutorial. Now, however, we're going to 'take control of the platform' and add our own keys, so that we can use self-signed EFI stub kernels (which our utility can create). The original Microsoft keys will be retained as well, so both Windows and our self-signed Gentoo kernels should be able to boot with secure mode on.

The steps we'll be undertaking are as follows (see below for a brief explanation of the terms used):
 * 1) We'll begin by saving off the current contents of the PK, KEK , db and dbx variables, as all four will be cleared when we enter setup mode (in step 4).
 * 2) We will then create three new private / public keypairs, to be used respectively as:
 * 3) our platform key (this will ultimately be stored in the PK signature database);
 * 4) our key exchange key (this will ultimately be appended to the KEK signature database); and
 * 5) our kernel-signing key (this will ultimately be appended to the db signature database).
 * 6) We'll then transform these keys into various formats for subsequent upload.
 * 7) We will then reboot the machine, and en route use the BIOS GUI to clear the secure variables, thereby entering setup mode.
 * 8) Then, we'll re-install our saved values of KEK, db and dbx together with our new public keys, using one of the following three keystore update methods (because of variations in BIOS function, you'll need to see which works on your machine):
 * 9) The default approach will be to use the  utility to install compound (old+new) signature lists from the command line. A fallback approach, where the original keys are first re-uploaded, and then the new keys appended, is also described. In both cases, the process is completed by setting our own key in PK, thereby re-entering user mode. We'll use the signed signature list for this.
 * 10) An second, alternative approach is to use your UEFI BIOS GUI to insert the new keys (if it supports this operation, as some do). This approach is briefly described (with example screenshots from a Dell Inspiron 5567 15 laptop's BIOS).
 * 11) A third, alternative approach is to use the  EFI utility to insert the keys. Again, this approach will be briefly described, with screenshots.
 * 12) With our keys inserted into the machine's keystore, we will then run, to rebuild our EFI-stub kernel, this time appropriately signed with our new kernel-signing (private) key.
 * 13) Then we will restart the machine, enable secure boot, and check that our signed kernel is permitted to start up by the BIOS (it should be).
 * 14) We'll then reboot into Windows, and check that it is also still permitted to start (again, it should be). When in Windows, we'll take the chance to set the clock format to UTC.
 * 15) Finally, we'll reboot back into our signed kernel, (optionally setting a BIOS password en route) and proceed with the tutorial.

Let's get started!

Introduction
We'll begin with a (very brief) primer on secure boot. (For a more in-depth review, please refer to James Bottomley's article "The Meaning of all the UEFI Keys", Greg Kroah-Hartman's article "Booting a Self-signed Linux Kernel" , Rod Smith's article "Managing EFI Boot Loaders for Linux: Dealing with Secure Boot" ff. and of course the UEFI specification itself .)

The UEFI specification defines four secure, non-volatile variables, which are used to control the secure boot subsystem. They are:
 * 1) The Platform Key (PK). The  PK  variable contains a UEFI (small 's', small 'd') 'signature database' which has at most one entry in it. When PK is emptied (which the user can perform via a BIOS GUI action), the system enters setup mode (and secure boot is turned off). In setup mode, any of the four special variables can be updated without authentication checks. However, immediately a valid platform key is written into PK (in practice, this would be an X.509 public key, using a 2048-bit RSA scheme), the system (aka, 'platform') enters user mode. Once in user mode, updates to any of the four variables must be digitally signed with an acceptable key. The private key counterpart to the public key stored in PK may be used to sign user-mode updates to PK or KEK, but not db or dbx (nor can it be used to sign executables).
 * 2) The Key Exchange Key (KEK). This variable holds a signature database containing one (or more) X.509 / 2048-bit RSA public keys (other formats are possible). In user mode, any db / dbx (see below) updates must be signed by the private key counterpart of one of these keys (the PK cannot be used for this). While KEK keys (or, more accurately, their private-key counterparts) may also be used to sign executables, it is uncommon to do so, since that's really what db is for (see below).
 * 3) The (caps 'S', caps 'D') Signature Database (db). As the name suggests, this variable holds a UEFI signature database which may contain (any mixture of) public keys, signatures and plain hashes. In practice, X.509 / RSA-2048 public keys are most common. It functions essentially as a boot executable whitelist (described in more detail shortly).
 * 4) The Forbidden Signatures Database (dbx). This variable holds a signature database of similar format to db . It functions essentially as a boot executable blacklist.

Now, here's the key point (excuse the pun): when the system is in user mode, and secure boot is enabled, the machine will only boot EFI executables which:
 * are unsigned, but have a hash (message digest) in db and not in dbx ; or
 * are signed, where that signature appears in db but not in dbx ; or
 * are signed, where that signature is verifiable by a public key in db, or a public key in KEK , and where neither that key, not the signature itself, appears in dbx.

When you buy a new Windows (10 or 8) machine, it will usually be set up as follows:
 * The PK variable will be loaded with a public key issued by the hardware vendor (for example, Panasonic).
 * The KEK variable will be loaded with a public key issued by Microsoft.
 * The db variable will be loaded with a set of public keys issued by various vendors authorized by Microsoft).
 * The dbx variable will generally contain some revoked signatures or hashes (although it may also be empty, it depends on the revision of Windows on your machine).

Saving Current Keystore Values, and Creating New Keys
We begin by re-establishing an connection, as before (as it will make the work of entering commands etc. easier). From the helper PC, issue:

Now proceed as below, using the connection to enter all commands unless otherwise specified (incidentally, there is no need to use  at this point, since we'll be rebooting again shortly). Issue:

Ensure only the superuser can access this directory, using Filesystem/Security - issue:

Next, we'll use the tool (from the ) to store off the current values of PK, KEK , db and dbx , in machine-readable signature list format. Issue:

Now we can create a new platform keypair, key-exchange keypair and kernel-signing keypair. We'll use to do this. The requested keys will:
 * use X.509 certificate format for the public key (this allows various additional data fields to be passed with the key if desired, for subsequent identification);
 * utilise the RSA asymmetric cryptosystem, with a 2048 bit key length;
 * have 10 years (3650 days) to run until expiry;
 * use SHA-256 as the public key's message digest.

Issue:

This will have created three X.509 public-key certificate files (, and ), and three counterpart private key files (,  and ). We'll make the private keys readable only by root (an extra precaution, since they already in a directory readable only by root). Issue:

Preparing Keystore Update Files from Keys
Now we have the old keys archived, and our new keys produced, we will create a variety of files that may be used to update the keystore. There is a degree of redundancy in what follows, but creating the variants does not take long, and will provide you with maximum flexibility in the next step (different BIOSes have different requirements for keystore update files, so it is impossible to be prescriptive).

We'll begin by creating a 'signed signature list' (aka '') format version of the PK variable, as (and even many BIOS GUIs that afford the option) will only accept it in this format. We can create this in a two step process (using two command line tools from ). First, we make a signature list (which requires a unique ID, the value of which is essentially unimportant), and then we use our own (private) platform key to sign it. Let's do both now - issue:

The file we need out of this is.

Next, since with some machine BIOSes it can be useful to generate a file for your custom KEK as well, issue:

(Notice that the PK private key was used to sign, in this case, and that we used the  option, to indicate that this is to be used to append data, rather than replace it.) The file we need out of this is.

We'll do the same for your custom db as well, issue:

(Notice that the KEK private key was used to sign, in this case, and again,  was specified.) The file we need out of this is.

Lastly, we'll do the same for the saved dbx :

(Notice that the KEK private key was again used to sign, but that  was not specified.) The file we need out of this is.

Next, we'll create DER versions of each of our three new public keys, as follows:

Finally, we'll create compound (i.e., old+new) esl files for the KEK and db (esl files can simply be concatenated ), and also create counterparts for these. Issue:

That's it, we now have our keystore update files prepared. Next, we'll enter setup mode, after which we'll update the keystore, using one of three possible keystore update methods.

Entering Setup Mode (Clearing Keystore)
To enter setup mode (wherein your target PC's keystore is emptied, allowing unsigned updates to be made to it), first reboot the machine (leave the boot USB key inserted):

Immediately your target PC starts to come back up again, enter the BIOS setup screen. As mentioned before, the exact method of entering the BIOS varies greatly from machine to machine (as does the BIOS user interface itself). On the Panasonic CF-AX3, press during startup (you may need to press it repeatedly, and you do this directly on the target machine's keyboard).

Once the BIOS setup screen comes up, using the same navigation techniques as before, perform the following steps:
 * 1) clear the UEFI secure boot variables, thereby entering setup mode; and
 * 2) restart your machine (saving changes).

It's impossible to be precise about the GUI actions required to achieve the above, as they will vary from BIOS to BIOS. However, to give you some idea, here's how you go about it on the Panasonic CF-AX3 (which has an AMT BIOS).

To achieve step 1, use the arrow keys to navigate across to the 'Security' tab. Then, navigate down to the 'Secure Boot' item, and press. This enters a special 'Security' sub-page. Navigate down to the 'Clear Secure Boot Keys' item, and press. Confirm that you wish to proceed by selecting 'Yes' in the popup which appears, then press. If asked to reconfirm, select 'Yes' and press again:

Note that on some UEFI implementations it is required to set a supervisor password in order for the option to clear the Secure Boot keys to be available.

Next, ensure that your boot USB key is still inserted, then press to restart (step 2), and confirm if prompted.

The machine should restart, and, just as before, you will see the passphrase screen. Enter your LUKS keyfile passphrase (the one you created earlier), directly at the target machine keyboard, and wait for the text console login to appear.

Installing New Keys into the Keystore
As mentioned briefly in the introduction, having cleared your PC's keystore, there are three main methods that may be used to update it with our new keys (in addition to the Microsoft keys, which, by default, we are retaining). You will need to experiment to see which of these methods works for you. Unfortunately, it is impossible to be prescriptive, as UEFI BIOSes vary greatly in what they will accept. For most systems, method 1 (immediately below) is the most likely to work (and it is certainly the most straightforward), so, we shall try that first, only falling back to methods 2 or 3 if necessary. Let's go!

Method 1: Inserting Keys using
Begin by re-connecting to the machine via. From the helper PC, issue:

Now proceed as below, using the connection to enter all commands unless otherwise specified (again, we will not need ). Issue:

You can verify that the secure variables have been cleared. To do so, enter:

and check that the output is as shown above.

<span id="set_new_values">Next, we'll reload the 'compound' (old+new) contents of the dbx, db and KEK , using the 'compound' signature list files we created earlier (although the dbx will just use the old file, as we have nothing to add to it).

Issue:

The  option specifies that an EFI signature list file is to be loaded (and the   option precedes the filename itself). Because we are in setup mode, no private key is required for these operations (which it would be, if we were in user mode).

If you experience errors when running the preceding commands (the most likely being a message of  when running ), then method 1 is not usable on your BIOS, and you should jump now to method 2 and try that, instead.

<span id="set_PK">Having made our changes, we can now write our own platform key into PK, using the signed signature list we created earlier. Issue:

If this succeeds, the target machine will have been switched back to user mode (although secure boot is not yet enabled).

Display the contents of all the secure variables now. Issue:

and verify that both your new keys, and Microsoft's original set, are present.

Now, let's make a backup (in machine readable signature list format) of the current (i.e., new) state of the variables. Issue:

If all of the above went through without error, congratulations, your augmented keystore has now been set up, so continue reading at Testing Secure Boot with a Signed Kernel, below. Do not carry out the commands in method 2 or method 3; your setup is already complete.

However, if you did experience errors when running the preceding commands (the most likely being a message of  when running  above), you should continue reading and try method 2, immediately below.

<span id="install_new_keys_2">Method 2: Inserting Keys via PC's BIOS GUI
Some higher-end or developer-oriented PCs will allow direct manipulation of the keystore variables through the UEFI BIOS GUI. If yours does, you will very likely be able to load your key-material setup files (stored temporarily on the USB boot key, so that the EFI BIOS can read them) in this way instead.

Assuming you are currently logged in to your target PC as and are working the  directory, proceed as follows. First, ensure the boot USB key is still inserted into the target PC. Then, temporarily mount it; issue:

to locate the drive, and then issue

to mount it.

<span id="copy_keys_to_boot_usb">Then, copy all the (non-private) key material onto this key (none of these files is very large). Issue:

Now, and unmount the boot USB key again:

then, leaving the boot USB key inserted, reboot the machine:

Immediately your target PC starts to come back up again, enter the BIOS setup screen. As mentioned before, the exact method of entering the BIOS varies greatly from machine to machine (as does the BIOS user interface itself). On the Panasonic CF-AX3, you press during startup (you may need to press it repeatedly, and you do this directly on the target machine's keyboard; as it happens the same BIOS entry method works for the Dell Inspiron 5567 15 laptop, which was used for the screenshots below).

Once the BIOS setup screen comes up, using the same navigation techniques as before, perform the following steps:
 * 1) clear the UEFI secure boot variables (again), thereby entering setup mode;
 * 2) use the BIOS GUI to load,  and , in that order;
 * 3) use the BIOS GUI to load, thereby setting the machine back into user mode; then
 * 4) restart your machine (saving changes).

It's impossible to be precise about the GUI actions required to achieve the above, as they will vary from BIOS to BIOS. However, to give you some idea, here's how you go about it on a Dell Inspiron 5567 15 laptop, which has a custom Dell BIOS.

To achieve step 1, use the mouse or touchpad to expand the 'Secure Boot' treeview item in the left panel, and click on the 'Expert Key Management' sub-item. In the right pane, make sure the 'Enable Custom Mode' checkbox is ticked, then click the 'Delete All Keys' button (and click 'Yes' when prompted to confirm), to clear the keystore:

Then, to achieve step 2, first click on the 'dbx' radio button (in the 'Custom Mode Key Management' group), then click 'Replace from File'. A dialog box will open, allowing you to select which (EFI) filesystem you wish to read from. Select the line in the 'File System List' that contains 'USB' (it should be chosen by default; the other is the Windows EFI partition on your hard drive), and then click the button marked '...' to bring up a file chooser. Then, select the file (that we prepared and copied to the boot USB key earlier) from this list, and click 'OK' to select it, then 'OK' again to load it:

Next, do the same thing with the db variable, only this time, choose the file (that we prepared and copied to the boot USB key earlier) in the file selection dialog:

With the dbx and db loaded, next do the same for the KEK secure boot variable. Here, choose the file (that we prepared and copied to the boot USB key earlier) in the file selection dialog:

Lastly, we do the same thing for the PK secure boot variable, thereby tipping the system back into user mode (but with our platform key installed). Here, choose the file (that we prepared and copied to the boot USB key earlier) in the file selection dialog:

With all four secure boot variables set up, simply click on the 'Exit' button to restart (thereby achieving step 4).

The machine should restart, and, just as before, you will see the passphrase screen. Enter your LUKS keyfile passphrase (the one you created earlier), directly at the target machine keyboard, and wait for the text console login to appear.

Then, re-connect to the machine via. From the helper PC, issue:

Now proceed as below, using the connection to enter all commands unless otherwise specified (again, we will not need ). Issue:

Display the contents of all the secure variables now. Issue:

and verify that both your new keys, and Microsoft's original set, are present.

Now, let's make a backup (in machine readable signature list format) of the current (i.e., new) state of the variables. Issue:

Obviously, in the preceding, the actual BIOS GUI operations you will need to perform will most likely be somewhat different (depending on the make and version of your UEFI BIOS), but, if you were able to insert the four files without error (and the above  shows the values correctly initialized), then congratulations, your augmented keystore has now been set up, so continue reading at Testing Secure Boot with a Signed Kernel, below. Do not carry out the commands in method 3; your setup is already complete.

However, if you did experience errors when running the preceding commands (for example, your PC's BIOS claims your files have an unrecognised format), you should continue reading and try method 3, immediately below.

<span id="install_new_keys_3">Method 3: Inserting Keys via Keytool
Even if your UEFI BIOS does not provide the ability to update the secure boot variables from file (or, if it appears to do so, but would not work for you when following method 2, above), you can still use the binary (which is bundled with ) for this purpose. It is an EFI executable program.

To use it, we'll copy the executable onto the boot USB key, and install a one-time EFI boot entry for it. Then, we'll clear the secure-boot state using the BIOS GUI, allow the BIOS to restart into, and then use this program to set our desired dbx , db , KEK and PK. Then, we'll reboot back into Gentoo again.

To do so, assuming you are currently logged in to your target PC as and are working the  directory, proceed as follows. First, ensure the boot USB key is still inserted into the target PC. Then, temporarily mount it; issue:

to locate the drive, and then issue

to mount it.

<span id="copy_keys_to_boot_usb2">Next, if you have not already done so as part of method 2, above, copy all the (non-private) key material onto this key (none of these files is very large). Issue:

Next, copy the executable to the boot USB key:

<span id="onetime_keytool">Now, we need to tell the UEFI BIOS to boot on the next restart, but after that to revert to the normal boot order (so our Gentoo system will boot again). To do so, we'll archive the current boot order into a temporary shell variable, create a new boot entry for  (at EFI boot slot 99, which should be unused; this entry will automatically go to the top of the boot list), reset the boot list to the value of   (thereby dropping bootslot 99 from the permanent boot order), then set the one-time  entry to point to 's entry (slot 99). Issue:

Now, and unmount the boot USB key again:

then, leaving the boot USB key inserted, reboot the machine:

Immediately your target PC starts to come back up again, enter the BIOS setup screen. As mentioned before, the exact method of entering the BIOS varies greatly from machine to machine (as does the BIOS user interface itself). On the Panasonic CF-AX3, you press during startup (you may need to press it repeatedly, and you do this directly on the target machine's keyboard; the same BIOS entry method works for the Dell Inspiron 5567 15 laptop, which we will continue with in the following example).

Once the BIOS setup screen comes up, using the same navigation techniques as before, perform the following steps:
 * 1) clear the UEFI secure boot variables (again), thereby entering setup mode; and
 * 2) restart your machine (saving changes).

It's impossible to be precise about the GUI actions required to achieve the above, as they will vary from BIOS to BIOS. However, to give you some idea, here's how you go about it on a Dell Inspiron 5567 15 laptop, which has a custom Dell BIOS.

To achieve step 1, use the mouse or touchpad to expand the 'Secure Boot' treeview item in the left panel, and click on the 'Expert Key Management' sub-item. In the right pane, then make sure the 'Enable Custom Mode' checkbox is ticked, then click the 'Delete All Keys' button (and click 'Yes' when prompted to confirm), to clear the keystore:

To restart, simply click on the 'Exit' button to restart (thereby achieving step 2).

Because of our earlier change to the value, the machine should then restart directly into. This will display its main menu screen, with an indication that the PC is in setup mode, and that secure boot is off. Working directly at the target machine's keyboard, use the arrow keys to highlight the 'Edit Keys' menu entry:

and press to select it.

You will then be presented with a list of the secure boot keys that can manipulate. Using the cursor keys, navigate down to 'The Forbidden Signatures Database (dbx)', and press to select it. In the next menu screen (using the same navigation techniques; you can use the key to back out a level if you make a mistake) choose the 'Replace Key(s)' entry and press. You will then be prompted to select a filesystem; choose the one shown that contains 'Usb' (the other is your Windows EFI partition on the machine's hard drive, probably labelled 'ESP') and press. In the subsequent file chooser list, select (that we prepared and copied to the boot USB key earlier) and press  to load it:

The order that files are displayed in the chooser may differ on your system.

With the dbx variable loaded, you will be returned to the 'Select Key to Manipulate' screen again. Go through the same process for the db variable, only this time, choose the file (that we prepared and copied to the boot USB key earlier) in the file selection dialog:

With the dbx and db loaded, next do the same for the KEK secure boot variable. Here, choose the file (that we prepared and copied to the boot USB key earlier) in the file selection dialog:

Lastly, we do the same thing for the PK secure boot variable, thereby tipping the system back into user mode (but with our platform key installed). Here, choose the file (that we prepared and copied to the boot USB key2 earlier) in the file selection dialog:

With all four secure boot variables set up, press to return from the 'Select Key to Manipulate' screen to 's main menu. It should show you that the 'Platform is in User Mode', if the previous steps were successful. Navigate to the the 'Exit' menu option, ensure the boot USB key is still inserted, and press to quit, thereby automatically triggering a reboot.

Now, as we only added a one-time ('BootNext') entry for the executable, your target PC should restart back into Gentoo. Just as before, you will see the passphrase screen. Enter your LUKS keyfile passphrase (the one you created earlier), directly at the target machine keyboard, and wait for the text console login to appear.

Then, re-connect to the machine via. From the helper PC, issue:

Now proceed as below, using the connection to enter all commands unless otherwise specified (again, we will not need ). Issue:

Display the contents of all the secure variables now. Issue:

and verify that both your new keys, and Microsoft's original set, are present.

Now, let's make a backup (in machine readable signature list format) of the current (i.e., new) state of the variables. Issue:

Obviously, in the preceding, the actual BIOS GUI operations you will need to perform will most likely be somewhat different (depending on the make and version of your UEFI BIOS), but, if you were able to insert the four files without error using  (and the above  shows the values correctly initialized), then congratulations, your augmented keystore has now been set up, so continue reading at Testing Secure Boot with a Signed Kernel, immediately below.

However, if you did experience errors when running the preceding commands (and have already tried methods 1 and 2 also, without success) then unfortunately secure boot will not be usable (for non-Windows use) on your particular target PC. You'll need to ensure it is turned off when booting Gentoo.

<span id="test_secure_boot">Testing Secure Boot with a Signed Kernel
Our next step is to create an appropriately signed kernel. The script will do this automatically for us, provided that the files  (the private kernel-signing key) and  (its public key counterpart) exist (which they now do). Ensure that the boot USB key is still inserted, then issue:

This should not take long to complete (as by default it does not ).

Assuming the kernel build completed successfully, we can now restart, turn on secure boot, and try it out! Ensure the boot USB key is still inserted, then issue:

Immediately your target PC starts to come back up again, enter the BIOS setup screen. As mentioned before, the exact method of entering the BIOS varies greatly from machine to machine (as does the BIOS user interface itself). On the Panasonic CF-AX3, press during startup (you may need to press it repeatedly, and you do this directly on the target machine's keyboard).

Once the BIOS setup screen comes up, using the same navigation techniques as before, perform the following steps:
 * 1) turn on secure boot; and
 * 2) restart your machine (saving changes).

It's impossible to be precise about the GUI actions required to achieve the above, as they will vary from BIOS to BIOS. However, to give you some idea, here's how you go about it on the Panasonic CF-AX3 (which has an AMT BIOS).

To achieve step 1 on the CF-AX3, use the arrow keys to select the 'Security' tab, then navigate down to the 'Secure Boot' item, and select it by pressing. This enters a 'Security' page; navigate to the 'Secure Boot control' item, and press. In the popup that appears, select 'Enabled' using the arrow keys, and press :

Next, ensure that your USB boot key is still inserted, then press to restart (step 2), and confirm if prompted.

The machine should restart, and, if all goes well (and your kernel is reasonably modern) you should see the console message  displayed briefly, followed shortly by the by now familiar  passphrase screen. If so, then congratulations, you are running a self-signed kernel under secure boot! Enter your LUKS keyfile passphrase (the one you created earlier), directly at the target machine keyboard, and wait for the text console login to appear.

<span id="verify_win8_secure_boot">Verifying Secure Boot with Windows (and Fixing RTC)
Having successfully booted our own self-signed kernel, we next have to check that Windows still works. Remove the boot USB key from the target machine, then (while it is still running Gentoo) log in directly at the target machine's keyboard (at the login prompt, enter 'root' as the user (without quotes), and then type the root password you set up earlier). Then issue (directly at the machine's keyboard):

As the boot USB key is not inserted, Windows should start automatically. If it does boot, you have just verified that Windows also starts properly under your modified secure boot settings (and if it does not, follow the troubleshooting hints above).

Now, while Windows is running, let's take the chance to switch its clock to UTC, to match that used by (which is the default as specified in the  file).

To achieve this, login to your Windows account (which must have administrator rights - the first user created on a new Windows install has these by default), as usual. Next, perform the following steps (I have noted where things differ between Windows 10, 8.1 and 8):


 * 1) First we'll check the Windows time, date and timezone is correct. Hit the, which will bring up the start menu in Windows 10 (or the "start screen" in Windows 8.1 and 8), and type  . Then click on the 'Date and Time' item which appears (in Windows 10 and 8.1; Windows 8 users will need to click the 'Settings' icon to see this result; note also that in Windows 8.1 and 8, as well as in more modern versions of Windows 10, the item you need to click is entitled 'Date and time settings'). A 'Date and time' dialog appears. Set appropriate values for your locale, and close the dialog when done.
 * 2) Next, we'll instruct Windows to use UTC (this will require a registry edit). Hit the, which will bring up the start menu in Windows 10 (or the "start screen" in Windows 8.1 and 8), and type  . Then click on the 'regedit' item that appears. If prompted (via a dialog) whether to allow it to make changes to your computer, click 'Yes'. The  program now opens; using the navigation tree-view on the left, select  (you need to click on the little arrows to see the lower levels of the tree). Once this item has been selected, various time-zone related information will display on the right-hand pane. Right-click in the white area at the bottom of this pane, and choose  from the context menu that appears. A fresh DWORD entry is added to the end of the list with its name selected &mdash; overtype this with   then press . Now double-click on the name, and a dialog will appear, in which you can edit the key's value. Type in   (the number one) for the value, as shown below:Win8Regedit.png Close the dialog by clicking on 'OK'. Then exit the  application (using the menu item ).
 * 3) Now we'll disable the Windows Time Service. This is most easily done from the Windows command line. Hit the , which will bring up the start menu in Windows 10 (or the "start screen" in Windows 8.1 and 8), and type  . Now right-click on the 'Command Prompt' icon that appears, then click on 'Run as administrator' item in the context menu (in Windows 10 and 8.1; it appears at the bottom of the screen in Windows 8). If asked whether you wish to proceed, click 'Yes'. You will be presented with an open command window. Now enter  . Hopefully, this should report  . Close out the command window (by clicking on the 'x' in its title bar).
 * 4) Next, we'll force Windows to update the time. Hit the, which will bring up the start menu in Windows 10 (or the "start screen" in Windows 8.1 and 8), and type  . Then click on the 'Date and Time' item which appears (in Windows 10 and 8.1; Windows 8 users will need to click the 'Settings' icon to see this result; note also that in Windows 8.1 and 8, as well as in more modern versions of Windows 10, the item you need to click is entitled 'Date and time settings'). A 'Date and time' dialog (which we used above) appears again. Now, on older versions of Windows 10, select the 'Internet Time' tab, click on 'Change settings...' and click 'Update now', then press 'OK'. On Windows 8.1 and 8, as well as on more modern versions of Windows 10, instead move the 'Set time automatically' slider to 'Off', and then back to 'On' again. In either case, assuming you have a network connection, the time should immediately update when you do this (and, assuming your locale is set correctly, it should be accurate). Close out the dialog once complete.

<span id="set_bios_password">Setting BIOS Password (Optional), and Restarting Gentoo Linux
Next, we will <span id="reboot_from_win8_to_linux">reboot back into Gentoo. Re-insert the boot USB key into the target PC. Then, in Windows-8, hit, then click on the power icon at the bottom right of the screen, and choose 'Restart' from the pop-up menu.

Immediately your target PC starts to come back up again, enter the BIOS setup screen. As mentioned a number of times now, the exact method of entering the BIOS varies greatly from machine to machine (as does the BIOS user interface itself). On the Panasonic CF-AX3, press during startup (you may need to press it repeatedly, and you do this directly on the target machine's keyboard).

Once you have the BIOS configuration screen up, you need to perform the following steps:
 * 1) select the "" EFI boot item as top priority;
 * 2) (optionally) set a BIOS password; then
 * 3) restart your machine (saving changes).

It's impossible to be precise about the GUI actions required to achieve the above, as they will vary from BIOS to BIOS. However, to give you some idea, here's how you go about it on the Panasonic CF-AX3 (which has an AMT BIOS).

To <span id="set_boot_order_gentoo">achieve step 1 on the CF-AX3, use the arrow keys the arrow keys to navigate to the 'Boot' tab, and then down to the 'UEFI Priorities' item. Press, and a sub-page is displayed. Ensure the item 'UEFI Boot from USB' is enabled (if it isn't, enable it now, and then press to restart, and come back to this point). Navigate down to 'Boot Option #1' and press. In the pop-up menu that appears, select the "" item (which was added to the boot list when we ran earlier):

Press to set this as the top boot option. Finally, press to exit the subpage.

<span id="set_bios_pw">The next step (#2, installing a BIOS password) is optional, but it is sensible to ensure that secure boot cannot be switched off by an attacker with temporary access to your machine (to permit a tampered kernel to run without your knowledge, for example). Most machines support some form of BIOS password, but the means of setting it varies widely. On the CF-AX3, use the arrow keys to navigate to the 'Security' tab, and then move down to the 'Set Supervisor Password' item, and press. Type your password into the pop-up that appears: When done, press. Then, when prompted, re-type the password to confirm and press.

It is then sensible (on the CF-AX3, at any rate) to disable the BIOS's boot password prompt (otherwise, you'll have to type in the BIOS (supervisor) password every time you boot from USB). On the CF-AX3, navigate up to the 'Password On Boot' item, and press. Then, in the pop-up that appears, use the arrow keys to select 'Disabled', and press to select:

That's it! Now ensure that the boot USB key is still inserted, then press to restart (step 3), and confirm if prompted.

The machine should restart, and, if all goes well, you should shortly be prompted with the familiar passphrase screen. Enter your LUKS keyfile passphrase (the one you created earlier), directly at the target machine keyboard, and wait for the text console login to appear, just as before.

Then, re-connect to the machine via. From the helper PC, issue:

Use the connection to enter all subsequent commands unless otherwise specified (do not start up  at this point, we'll do so again shortly).

The final thing thing we must do here is to check that our system time details have not been messed up by Windows (which, given the changes we have just made, they should not have been). Issue:

and make sure the time and date are still correct.

If the local time is not correct, issue:

to set it

<span id="next_steps">Next Steps
Congratulations, setup of secure boot is complete! Next, we can install the GNOME 3 graphical environment. Click here to go to the next chapter, "Setting up the GNOME 3 Desktop under OpenRC".