complete cleanup of grub.cfg docs

remove all the redundant information, and merge some of it
between the two articles (grub hardening and grub cbfs guides)

Signed-off-by: Leah Rowe <info@minifree.org>
master
Leah Rowe 2024-08-27 01:38:53 +01:00
parent 30cae6536a
commit c50c0e1676
2 changed files with 330 additions and 419 deletions

View File

@ -3,11 +3,11 @@ title: Modifying grub.cfg in CBFS
x-toc-enable: true
...
NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
now, as of 27 January 2024, which is a fork of flashrom.
Read [Libreboot flashing guides](../install/) before continuing, and make sure
to back up the current flash contents before you consider following this guide.
Before you follow this guide, it is advisable that you have the ability to
flash externally, just in case something goes wrong.
[flash externally](../install/spi.md), just in case something goes wrong.
Libreboot's own GRUB configuration automatically scans for one provided by
your distro, and this automation will usually work. Sometimes, you might wish
@ -15,82 +15,89 @@ to override it with your own custom menuentry or additional logic in the GRUB
config. You can configure GRUB however you like, and this topic is vast so what
to actually *put in the config* will not be covered here.
This guide will simply teach you how to modify the config, but not what to put.
This guide will simply teach you how to modify the config, but not what to put,
whereas the [GRUB hardening](../linux/grub_hardening.md) guide specifically
says what to modify; cross reference that page and this page.
Compile flashprog and cbfstool
=============================
**Disable security before continuing**
================================
libreboot does not currently distribute utilities pre-compiled. It only
provides ROM images pre-compiled, where feasible. Therefore, you have to build
the utilities from source.
**Before internal flashing, you must first disable `/dev/mem` protections. Make
sure to re-enable them after you're finished.**
As for the ROM, there are mainly three methods for obtaining a libreboot ROM
image:
**See: [Disabling /dev/mem protection](../install/devmem.md)**
1. Dump the contents of the the main *boot flash* on your system, which already
has libreboot installed (with GRUB as the default payload). Extract the
GRUB configuration from *that* ROM image.
2. Extract it from a libreboot ROM image supplied by the libreboot project, on
the libreboot website or mirrors of the libreboot website.
3. Build the ROM yourself, using the libreboot build system. Instructions for
how to do this are covered in the following article:
[How to build libreboot from source](../build/)
This only applies if you're following these instructions via internal
flashing, from an existing installation. If you're externally flashing the
machine, you can ignore this advice.
In either case, you will use the `cbfstool` supplied in the libreboot build
system.
This can be found under `coreboot/*/util/cbfstool/` as source code,
where `*` can be any coreboot source code directory for a given mainboard.
The directory named `default` should suffice.
Build dependencies
==================
Install the build dependencies. For Debian and similar, you can run
the following command in the libreboot build system, from the root directory
of the libreboot Git repository.
**Please first [install build dependencies](../build/).**
./mk dependencies debian
Coreboot utilities
------------------
Determine what coreboot tree you need for your board. For example, if building
for `x200_8mb`, check `config/coreboot/x200_8mb/target.cfg` and it might
say `tree="default"` - in this case, the coreboot tree is named `default`.
You need `cbfstool` from coreboot. For whatever board you have, check which
coreboot tree it uses in Libreboot's build system, lbmk. For example, let's
say your board is `x200_8mb`, you would do:
Then, download coreboot (we'll assume the `default` tree is correct):
grep tree= config/coreboot/x200_8mb/target.cfg
./mk -f coreboot default
In this example, the output might be:
Finally, compile the `cbutils` payload (and you will then have the utils):
tree="default"
./mk -b grub
GRUB is multi-tree, but for GRUB utilities that's fine because we don't patch
those in any tree; we only patch the GRUB kernel to add various drivers and
extra crypto such as argon2.
Among other things, this will produce a `cbfstool` executable under any of the
subdirectories in `src/coreboot/` under `util/cbfstool/cbfstool`.
For example: `src/coreboot/default/util/cbfstool/cbfstool`
The `cbfstool` utility is what you shall use. It is used to manipulate CBFS
(coreboot file system) which is a file system contained within the coreboot
ROM image; as a *coreboot distribution*, libreboot inherits this technology.
You can compile cbfstool and ifdtool for the given coreboot tree, e.g.:
This means you should compile `cbfstool` from the `default` coreboot tree,
like so:
./mk -d coreboot default
This will create `elf/cbfstool/default/cbfbstool`
and `elf/ifdtool/default/ifdtool`.
This will result in the following binary: `elf/cbfstool/default/cbfstool`
You will also want to build `flashprog` which libreboot recommends for reading
from and/or writing to the boot flash. In the libreboot build system, you can
build it by running this command:
We won't assume the path to cbfstool, in the remainder of this guide, so
adapt accordingly.
GRUB utilities
--------------
Again, let's assume the coreboot board is `x200_8mb`. Check the
file `config/coreboot/x200_8mb/target.cfg` for `grubtree` - if it's not set,
then the GRUB tree is `default`. We will assume `default`:
./mk -b grub default
This will compile GRUB for the given tree. If you need to use any of the GRUB
utilities, this command will build them and in this example, they will be
available under `src/grub/default/`.
Flashprog
---------
Compile flashprog like so:
./mk -b flashprog
An executable will be available at `elf/flashprog/flashprog` after you have done
this.
A binary will appear at `elf/flashprog/flashprog`.
Default GRUB config
===================
The coreboot image has its own filesystem, CBFS, and within CBFS is the GRUB
binary, and within the GRUB binary is another filesystem called memdisk, where
the default GRUB configuration is located.
You can override it by inserting your own GRUB config within CBFS.
Acquiring a GRUB config
=======================
Dump the boot flash
===================
-------------------
This is only useful if you already inserted a GRUB config in CBFS. Otherwise,
you can grab it from Libreboot's build system, lbmk.
[Learn how to externally reprogram these chips](../install/spi.md) and use
the `-r` option in flashprog; alternatively, for internal flash access,
@ -98,6 +105,28 @@ look at the [main flashing guide](../install/).
Those guides show how to dump the flash contents, which you are advised to do.
Default GRUB config location
----------------------------
We'll assume that your GRUB tree is `default`, so the
file `config/grub/default/config/payload` is your GRUB config; this will be the
same as what you have in memdisk. Make a copy of this file, for modification.
Modify *that* file, or the one you extracted if you already inserted a custom
one before, and you will re-insert it when you're done.
Insert grubtest.cfg
===================
Before reading the next section, please note: if you only have the fallback
GRUB config in memdisk, and no configs in CBFS, you can test the modified
version by inserting it as `grubtest.cfg`, instead of `grub.cfg`:
cbfstool libreboot.rom add -f grubtest.cfg -n grubtest.cfg
Libreboot will not automatically load it, but it will be available from the
default GRUB menu. This can be useful for test purposes, hence the name.
Insert new grub.cfg
===================
@ -110,32 +139,20 @@ Now remove it:
cbfstool libreboot.rom remove -n grub.cfg
It's important that you re-add `grub.cfg` before flashing:
It's important that you re-add `grub.cfg` before flashing (or just add it, if
it was never there in the first place):
cbfstool libreboot.rom add -f grub.cfg -n grub.cfg
Repeat this for `grubtest.cfg` if you wish.
**If you flash the Libreboot image without a `grub.cfg` in CBFS, it will
default back to the one in GRUB memdisk.
If you're using a default Libreboot image, there *is no `grub.cfg` in flash*.
This is because there is also a default one embedded inside the GRUB binary,
which is inside CBFS. So:
AGAIN:
The coreboot image has its own filesystem, CBFS, and within CBFS is the GRUB
binary, and within the GRUB binary is another filesystem called memdisk, where
the default GRUB configuration is located.
You can insert a `grub.cfg` into CBFS and it will override the one in memdisk.
Check your board, e.g. `x200_8mb`, look at the file: `config/coreboot/x200_8mb/target.cfg`
and check for `grubtree` - if it's not sot, then it's `default`, otherwise check
what it's set to.
We'll assume it's `default`, so the
file `config/grub/default/config/payload` is your GRUB config; this will be the
same as what yo uhave in memdisk.
Modify *that* file, or the one you extracted if you already inserted a custom
one before, and you will re-insert it when you're done.
If you only want to test your changes first, insert it first as `grubtest.cfg`
and ensure that no `grub.cfg` exists in flash. This will let you access the
test config from the default menu, before deciding whether to make it the
main config, as `grub.cfg`, overriding the one in GRUB memdisk.
Flash the modified ROM image
============================

View File

@ -3,316 +3,40 @@ title: Hardening GRUB
x-toc-enable: true
...
**NOTE: [Encrypted /boot with LUKS2 on argon2 key derivation is now
possible](../../news/argon2.md). This is covered in
the [main Linux guide](./).**
GRUB supports various security mechanisms that are not enabled by default.
This page will tell you how to enable them, for the purpose of boot security,
both detecting and attempting to prevent certain types of attack.
GRUB can have password protection at boot, prevent unauthorised access to the
shell and to menuentries. You can also boot from fully encrypted distros, where
the `/boot` directory is already encrypted, containing your kernel. You can
additionally verify each file, including GRUB configuration files and Linux
kernels, using GPG; GRUB supports putting a GPG pubkey in CBFS, and using it
to verify all files that it accesses.
**Make sure you have an [external SPI programmer](../install/spi.md), for
recovery purposes, just in case you brick your machine. The modifications
documented here are highly invasive and it would be easy to make mistakes.**
Let's begin.
Full disk encryption
====================
**Disable security before flashing**
================================
[Encrypted /boot with LUKS2 on argon2 key derivation is now
possible](../../news/argon2.md).
**Before internal flashing, you must first disable `/dev/mem` protections. Make
sure to re-enable them after you're finished.**
This is covered in
the [main Linux guide](./#encrypted-boot-via-luks2-with-argon2), in the
section pertaining to LUKS2/argon2.
**See: [Disabling /dev/mem protection](../install/devmem.md)**
You are strongly advised to create an encrypted Linux installation, before
setting up GRUB as shown in the guide below. Adapt it for whichever distro
you're installing (documenting every distro on the Libreboot documentation
would be a futile exercise and will not be attempted).
This only applies if you're following these instructions via internal
flashing, from an existing installation.
You are advised to do this *first*, because steps below depend on certain
configuration changes to be made on your installed Linux distro.
Back up your flash first!
=========================
**Dependencies (do this first)**
=============================
Make sure you also back up the current flash contents, before you proceed with
this guide. See: [Libreboot flashing guides](../install/) (it also says how
to read the flash, in addition to writing it)
**Please read this: [Modifying GRUB in CBFS](grub_cbfs.md)**
Build dependencies
==================
You need `cbfstool` from coreboot. For whatever board you have, check which
coreboot tree it uses in Libreboot's build system, lbmk. For example, let's
say your board is `x200_8mb`, you would do:
grep tree= config/coreboot/x200_8mb/target.cfg
In this example, the output might be:
tree="default"
This means you should compile `cbfstool` from the `default` coreboot tree,
like so:
./mk -d coreboot default
This will result in the following binary: `elf/cbfstool/default/cbfstool`
We won't assume the path to cbfstool, in the remainder of this guide, so
adapt accordingly.
Background information
=========================
By default, the `grub.cfg` file and `grubtest.cfg` file are not present in
CBFS, because the GRUB memdisk, contained within the GRUB binary itself, within
CBFS, contains a GRUB configuration file.
Libreboot will switch to `grub.cfg` from flash instead, if it exists,
skipping the one in memdisk.
Because we need to put a signature next to each file, that would mean
re-building GRUB if you wanted to use the one in memdisk. Therefore, we can
insert a custom one in CBFS, to mitigate that fact.
By doing it this way, you can avoid re-building GRUB, or indeed anything inside
your current Libreboot images.
References:
* [GRUB manual](https://www.gnu.org/software/grub/manual/html_node/Security.html#Security)
* [GRUB info pages](http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi)
* [Coreboot GRUB security howto](https://www.coreboot.org/GRUB2#Security)
GRUB Password
=============
The security of this setup depends on a good GRUB password as GPG signature
checking can be disabled through the interactive console:
set check_signatures=no
Disabling signatures, using the above command, is useful when you're booting
regular media such as live distros via USB.
You are strongly advised to use an *open diceware* passphrase (look that up).
Generate a strong passphrase of completely random words, at least 20 words in
total is ideal. Passphrases are better than pass*words* containing lots
of random letters and symbols, because pass*phrases* have higher entropy and
are therefore harder to crack.
The GRUB password can be stored in one of two ways:
* plaintext
* protected with [PBKDF2](https://en.wikipedia.org/wiki/Pbkdf2)
We will *obviously* use the latter method. Generating the PBKDF2 derived key is
done using the `grub-mkpasswd-pbkdf2` utility. You can get it by
installing GRUB version 2. Generate a key by giving it a password:
NOTE: This utility is included under the `grub/` directory, when you build
GRUB using the libreboot build system. Run the following commands (assuming
you have the correct build dependencies installed) to build GRUB, from the
libreboot Git repository:
./mk -b grub default
The following executable will then be available under `src/grub/default/`:
grub-mkpasswd-pbkdf2
Run that program. It will ask you to choose a new passphrase. Its output will
be a string of the following form:
grub.pbkdf2.sha512.10000.HEXDIGITS.MOREHEXDIGITS
Make sure to copy this into the correct GRUB config. The correct GRUB config
can be determined as follows. Again, let's assume that you have `x200_8mb`:
grep grubtree= config/coreboot/x200_8mb/target.cfg
It *may* or *may not* output anything. If it outputs *nothing*, then the
GRUB tree is `default`, otherwise it might output something like:
grubtree="nvme"
Make *sure* to use the correct GRUB tree. We will assume `default`, so you
should adapt accordingly, when doing this yourself:
cp config/grub/default/config/payload grub.cfg
Now, your `grub.cfg` file is correct for the board, and you can insert
the salted, hashed passphrase that you get from `grub-mkpasswd-pbkdf2` earlier.
Now open my.grubtest.cfg and put the following before the menu entries
(prefered above the functions and after other directives). Of course use
the pbdkf string that you had generated yourself:
Put this *before* the menuentries (just before) in `grub.cfg`, but note that
you should **not** literally use what is below; the hash below is not the one
you generated yourself. Make sure to adapt accordingly.
Example:
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711
**Again**, replace it with the correct hash that you actually obtained for the
password you entered. In other words, *do not use the hash that you see above!*
Once this configuration is inserted, you will need to enter a passphrase every
time you boot. GRUB will also ask for a username. In the above example, we
made a username `root`, but you can set it to what you want and
adapt accordingly.
Another good thing to do, if we chose to load signed on-disk GRUB
configurations, is to remove (or comment out) `unset superusers`. Find any line
that says this, in your `grub.cfg` file:
unset superusers
Change it to this:
# unset superusers
The `unset superusers` command disables password authentication, which will
allow the attacker to boot an arbitrary operating system, regardless of
signature checking. The default libreboot configuration is tweaked for *ease of
use* by end users, and it is *not* done with security in mind (though security
is preferred). Thus, libreboot is less restrictive by default. What you are
doing, per this article, is making your system *more secure* but at the expense
of user-friendliness.
That just about covers it, where password setup is concerned!
SeaBIOS first?
==============
**Very important. Make sure you read this carefully.**
In releases after Libreboot 20240504, SeaBIOS is the primary payload on
all images, but GRUB is available in the boot menu. Select a ROM image
with `grubfirst` at the end, and do this to the ROM image:
cbfstool libreboot.rom add-int -i 0 -n etc/show-boot-menu
This disables the SeaBIOS menu, so that it only loads GRUB. The `grubfirst`
image had this done to it by lbmk (Libreboot build system) during build:
cbfstool libreboot.rom add -f config/grub/bootorder -n bootorder -t raw
This `bootorder` file has the following contents:
```
/rom@img/grub2
```
You can add it yourself if your image doesn't have it. With this, SeaBIOS
only loads GRUB first. You can still put a GRUB config in CBFS to override
the default one, as of Libreboot 20240612.
NOTE: Before disabling the boot menu, make sure GRUB works. Access it using
the `bootorder` file and/or press ESC in the SeaBIOS menu. Then disable the
SeaBIOS menu:
cbfstool libreboot.rom add-int -i 0 -n etc/show-boot-menu
Although the `bootorder` file only specifies *GRUB*, this just means that
SeaBIOS won't automatically try to boot anything else. The SeaBIOS menu is still
accessible, by pressing ESC when prompted; the above `add-int` command disables
that menu, so that *only* the GRUB payload will be executed.
SeaBIOS option ROMs
===================
SeaBIOS will also still execute PCI option ROMs. Depending on your preference,
you may wish to disable this, but please note that this will break certain
things like graphics cards. More information is available here:
<https://www.seabios.org/Runtime_config>
On a laptop, you probably don't have to worry about option ROMs at all, but
desktops are much more easily upgradeable; though, in practise, anyone
inclined to insert a card with a malicious option ROM on it wouldn't do that
anyway, because if they have access to your hardware, they could just
externally re-flash the machine anyway, so I wouldn't worry, but it's up to you.
If you're using a graphics card, you *need* VGA option ROMs at least.
GPG keys
========
First, generate a GPG keypair to use for signing. Option RSA (sign only)
is ok.
WARNING: GRUB does not read ASCII armored keys. When attempting to
trust ... a key filename it will print `error: bad signature` on the screen.
```
mkdir --mode 0700 keys
gpg --homedir keys --gen-key
gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
gpg --homedir keys --export > boot.key
```
Now that we have a key, we can sign some files with it. We must sign:
- a kernel
- (if we have one) an initramfs
- (if we wish to transfer control to it) an on-disk `grub.cfg`
- `grubtest.cfg` (so that you can go back to `grubtest.cfg` after signature
checking is enforced. You can always get back to `grub.cfg` by pressing ESC,
but, afterwards, `grubtest.cfg` is not signed and it will not load. The
GRUB config we made earlier can be copied to `grubtest.cfg` and inserted,
but please only do this at the end of the guide when it tells you to insert
the GRUB config, because there are still osme things you need to do.
Suppose that we have a pair of `my.kernel` and `my.initramfs` and an
on-disk `libreboot_grub.cfg`. We will sign them by running the following
commands:
```
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign libreboot_grub.cfg
gpg --homedir keys --detach-sign my.grubtest.cfg
```
Of course, some further modifications to grubtest.cfg will be required. We
need to *trust* the key and enable signature enforcement (put this before menu
entries):
```
trust (cbfsdisk)/boot.key
set check_signatures=enforce
```
What remains now is to include the modifications into the libreboot image
(ROM):
```
cbfstool libreboot.rom add -n boot.key -f boot.key -t raw
# You might consider copying `grub.cfg` to `grubtest.cfg` and adding that.
# Otherwise, adding just `grub.cfg` is also fine.
cbfstool libreboot.rom add -n grub.cfg -f my.grub.cfg -t raw
cbfstool libreboot.rom add -n grub.cfg.sig -f my.grub.cfg.sig -t raw
cbfstool libreboot.rom add -n grubtest.cfg -f my.grubtest.cfg -t raw
cbfstool libreboot.rom add -n grubtest.cfg.sig -f my.grubtest.cfg.sig -t raw
```
Congratulations!
================
With any luck, this should work perfectly. Your system will no longer boot
anything unless it's signed by your key.
If your entire system is also encrypted, including `/boot`, then that protects
everything including the privkey much more robustly, and it further prevents
tampering with your kernel (where GPG only detects tampering, encryption can
prevent it).
Encryption, combined with a GRUB passphrase, combined with a GPG check, should
make you pretty damn secure at boot time. All that's left now is one final,
optional step:
**Assimilate that knowledge before continuing with the instructions below,
which tells you what modifications to actually perform, whereas the guide
linked above tells you how to apply your modifications for flashing.**
Flash write protection
======================
@ -322,47 +46,9 @@ except you from overwriting the flash without permission. This is important,
because you don't want some malicious software running as root from overwriting
your flash, thus removing any of the above protections.
The simplest way is to just do this:
ifdtool -x libreboot.rom -O libreboot.rom
If you did the step before, to compile `cbfstool`, you can find ifdtool in
the `elf/` directory, e.g. `elf/ifdtool/default/ifdtool`. Make sure to use
the correct version, as per `tree=` (same as before when deciding to which
cbfstool version to use based on the coreboot tree used by your board).
Note that this only works for Intel-based systems that use an Intel Flash
Descriptor, which is actually most Intel systems that Libreboot supports.
You can still flash externally, or strap `HDA_SDO` (`HDA_DOCK_EN` on older
GM45 machines) accordingly. Note that the x4x/ich10-based machines don't have
flash descriptors, and neither do the i945 machines, but the GM45 and newer
Intel platforms do.
Other facts
-----------
Strapping `HDA_SDO` or `HDA_DOCK_EN` requires physical access, because you have
to short a pin on the HDA chip on the motherboard, or there will be a header
for this on the board (e.g. "service mode" jumper).
On *Dell Latitude* laptops specifically, the EC can unlock flash by setting
the SDO/DOCK\_EN signal as described, and this is in fact what
the `dell-flash-unlock` utility does, so you can consider IFD locking there
to be basically useless.
In addition to the above, you may also consider `/dev/mem` protection.
Enable `CONFIG_STRICT_DEVMEM` in your Linux kernel, or set `securelevel` above
zero on your BSD setup (but BSD cannot be booted with GRUB very easily so
it's a moot point).
Other write-protect methods
Build-time write protect
---------------------------
The steps above do not require recompilation of the Libreboot images. However,
coreboot offers additional security at build time, which you can select if you
wish.
Let's assume your board is `x200_8mb`, do:
./mk -m coreboot x200_8mb
@ -393,6 +79,207 @@ Anyway, when you're done, save the config and then build it from source in lbmk.
See: [build from source](../build/)
IFD-based flash protection
--------------------------
The simplest way is to just do this:
ifdtool -x libreboot.rom -O libreboot.rom
If you did the step before, to compile `cbfstool`, you can find ifdtool in
the `elf/` directory, e.g. `elf/ifdtool/default/ifdtool`. Use the ifdtool
version matching the coreboot tree for your mainboard.
Note that this only works for Intel-based systems that use an Intel Flash
Descriptor, which is actually most Intel systems that Libreboot supports.
Other facts
-----------
Strapping `HDA_SDO` or `HDA_DOCK_EN` requires physical access, because you have
to short a pin on the HDA chip on the motherboard, or there will be a header
for this on the board (e.g. "service mode" jumper). If you strap those pins,
it disables descriptor-based flash protections.
On *Dell Latitude* laptops specifically, the EC can unlock flash by setting
the SDO/DOCK\_EN signal as described, and this is in fact what
the `dell-flash-unlock` utility does, so you can consider IFD locking there
to be basically useless.
In addition to the above, you may also consider `/dev/mem` protection.
Enable `CONFIG_STRICT_DEVMEM` in your Linux kernel, or set `securelevel` above
zero on your BSD setup (but BSD cannot be booted with GRUB very easily so
it's a moot point).
FLILL
-----
On Intel Flash Descriptor, you can insert up to four (4) commands on a list
within, called *FLILL*; not yet documented, but any SPI command listed here
would no longer work during internal flash operations. For example, you could
use it to disable certain erase/write commands. You could also use it to
disable *reads*.
PRx registers
-------------
Protected Range registers are available on Intel platforms, to disable flash
writes. This is not yet documented, and it varies per platform.
GRUB Password
=============
The security of this setup depends on a good GRUB password as GPG signature
checking can be disabled through the GRUB console with this command:
set check_signatures=no
The above GRUB shell command is required when you want to live USB media,
or other Linux setups that don't yet have signatures on files e.g. linux.
We will assume that you're using the `default` GRUB tree; the GRUB CBFS guide
linked above tells you how to determine which GRUB tree to use.
The following executable will then be available under `src/grub/default/`:
grub-mkpasswd-pbkdf2
Run that program. It will ask you to choose a new passphrase. Its output will
be a string of the following form:
grub.pbkdf2.sha512.10000.HEXDIGITS.MOREHEXDIGITS
Put this *before* the menuentries (just before) in `grub.cfg`, but note that
you should **not** literally use what is below; the hash below is not the one
you generated yourself. Make sure to adapt accordingly.
Example:
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711
**Again**, replace it with the correct hash that you actually obtained for the
password you entered. In other words, *do not use the hash that you see above!*
GRUB will also ask for a username in addition to the password; the "root" user
is specified above, but you can cahnge it to whatever you want.
Unset superusers
================
Find this line in `grub.cfg`:
unset superusers
Change it to this:
# unset superusers
Commenting it, as shown above, ensures that password authentication works,
because `unset superusers` in fact disables passwordh authentication, so it's
very important that you comment out this line.
Disable the SeaBIOS menu
====================
**Very important. Make sure you read this carefully.**
In releases after Libreboot 20240504, SeaBIOS is the primary payload on
all images, but GRUB is available in the boot menu.
Do this:
cbfstool libreboot.rom add-int -i 0 -n etc/show-boot-menu
This disables the SeaBIOS menu, so that it only loads GRUB.
If your ROM image doesn't auto-start GRUB, you should also insert the
bootorder file:
cbfstool libreboot.rom add -f config/grub/bootorder -n bootorder -t raw
This `bootorder` file has the following contents:
```
/rom@img/grub2
```
Release images with `seagrub` in the name already have this bootorder file,
so you only need to disable the menu on these images. If you have the
image with `seabios` in the name (instead of `seagrub`), you must do both.
SeaBIOS option ROMs
-------------------
SeaBIOS will also still execute PCI option ROMs. Depending on your preference,
you may wish to disable this, but please note that this will break certain
things like graphics cards. More information is available here:
<https://www.seabios.org/Runtime_config>
If you're using a graphics card, you *need* VGA option ROMs at least.
GPG keys
========
First, generate a GPG keypair to use for signing. Option RSA (sign only)
is ok.
WARNING: GRUB does not read ASCII armored keys. When attempting to
trust ASCII armor keys, it will print `error: bad signature` on the screen.
```
mkdir --mode 0700 keys
gpg --homedir keys --gen-key
gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
gpg --homedir keys --export > boot.key
```
Now that we have a key, we can sign some files with it. We must sign:
- a kernel
- (if we have one) an initramfs
- (if we wish to transfer control to it) an on-disk `grub.cfg`
- `grubtest.cfg` in CBFS, if it exists
- `grub.cfg` in CBFS, if it exists
You must provide a *detached signature* alongside each file. For example, if
a file in a directory is named `foo`, and GRUB uses this file, an accompaning
file `foo.sig` must exist alongside it.
Suppose that we have a pair of `my.kernel`, `my.initramfs` and an
on-disk `grub.cfg`. We will sign them by running the following
commands:
```
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign grub.cfg
```
You must also do the above on any file that goes in CBFS, and insert it
into CBFS, using instructions already provided on the GRUB CBFS guide linked
above, earlier on in this guide.
Enforce GPG check in GRUB
=========================
The following must be present in `grub.cfg`, but please note that the
background image used by GRUB is in the memdisk by default, not CBFS, so you
might want to put it *after* the command that enables a background:
```
trust (cbfsdisk)/boot.key
set check_signatures=enforce
```
What remains now is to include the modifications into the libreboot image
(ROM):
Please read and follow the [GRUB configuration guide](grub_cbfs.md); this is
the GRUB CBFS guide that was also linked above, earlier on in the article
you're currently reading.
Install the new image
=====================
@ -404,3 +291,10 @@ up just fine. Shut it down and wait a few seconds. If you screwed it up
and the system is now unbootable, that's OK because you can use an
external flasher; please
read [external flashing instructions](../install/spi.md)
References
==========
* [GRUB manual](https://www.gnu.org/software/grub/manual/html_node/Security.html#Security)
* [GRUB info pages](http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi)
* [Coreboot GRUB security howto](https://www.coreboot.org/GRUB2#Security)