2023-06-13 11:09:01 +00:00
|
|
|
#!/usr/bin/env sh
|
2023-09-25 01:19:30 +00:00
|
|
|
# SPDX-License-Identifier: GPL-3.0-or-later
|
2024-05-26 00:54:36 +00:00
|
|
|
# Copyright (c) 2014-2016,2020-2021,2023-2024 Leah Rowe <leah@libreboot.org>
|
|
|
|
# Copyright (c) 2021-2022 Ferass El Hafidi <vitali64pmemail@protonmail.com>
|
|
|
|
# Copyright (c) 2022 Caleb La Grange <thonkpeasant@protonmail.com>
|
|
|
|
# Copyright (c) 2022-2023 Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
|
|
# Copyright (c) 2023 Riku Viitanen <riku.viitanen@protonmail.com>
|
2021-05-18 12:56:12 +00:00
|
|
|
|
|
|
|
set -u -e
|
|
|
|
|
2024-05-26 11:10:27 +00:00
|
|
|
. "include/lib.sh"
|
2023-08-23 17:56:31 +00:00
|
|
|
|
2024-06-22 23:15:19 +00:00
|
|
|
tmprom="$tmpdir/rom"
|
|
|
|
|
2023-10-05 02:23:07 +00:00
|
|
|
seavgabiosrom="elf/seabios/default/libgfxinit/vgabios.bin"
|
|
|
|
cfgsdir="config/coreboot"
|
2024-06-18 00:44:25 +00:00
|
|
|
rp2040src="src/pico-serprog"
|
2024-06-18 00:50:40 +00:00
|
|
|
rp2040x="$rp2040src/build/pico_serprog.uf2"
|
2024-05-26 00:54:36 +00:00
|
|
|
picosdk="src/pico-sdk"
|
2024-06-19 23:12:00 +00:00
|
|
|
rp2040dir="$picosdk/src/boards/include/boards"
|
2024-05-26 00:54:36 +00:00
|
|
|
stm32src="src/stm32-vserprog"
|
2024-06-18 00:50:40 +00:00
|
|
|
stm32x="$stm32src/stm32-vserprog.hex"
|
2024-06-19 23:12:00 +00:00
|
|
|
stm32dir="$stm32src/boards"
|
2023-09-30 12:05:57 +00:00
|
|
|
|
2023-10-05 02:23:07 +00:00
|
|
|
# Disable all payloads by default.
|
|
|
|
# target.cfg files have to specifically enable [a] payload(s)
|
roms: only support SeaBIOS/SeaGRUB on x86
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 21:57:39 +00:00
|
|
|
pv="payload_uboot payload_seabios payload_memtest t payload_grub"
|
2024-06-24 17:24:50 +00:00
|
|
|
v="romdir initmode displaymode targetdir tree release ubootelf"
|
roms: only support SeaBIOS/SeaGRUB on x86
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 21:57:39 +00:00
|
|
|
v="$v board grub_scan_disk uboot_config grubtree grubelf tmpmv"
|
2024-06-22 03:06:07 +00:00
|
|
|
eval `setvars "n" $pv`
|
|
|
|
eval `setvars "" $v boards targets serdir ser`
|
2023-10-05 02:23:07 +00:00
|
|
|
|
|
|
|
main()
|
2023-09-30 12:21:15 +00:00
|
|
|
{
|
2023-10-05 02:23:07 +00:00
|
|
|
while [ $# -gt 0 ]; do
|
2024-06-19 23:12:00 +00:00
|
|
|
if [ "$1" = "serprog" ]; then
|
2024-06-22 02:55:04 +00:00
|
|
|
[ $# -lt 2 ] && $err "serprog type not set"
|
|
|
|
[ "$2" != "rp2040" ] && [ "$2" != "stm32" ] && \
|
|
|
|
$err "invalid serprog type"
|
2024-06-19 23:12:00 +00:00
|
|
|
eval "x_ ./update trees -f \"\${${2}src##*/}\""
|
|
|
|
ser="$2" && shift 2 && continue
|
|
|
|
fi
|
|
|
|
[ "$1$ser" = "list" ] && x_ ls -1 config/coreboot && return
|
2024-06-14 13:19:44 +00:00
|
|
|
[ "$1" = "all" ] && shift && continue
|
|
|
|
boards="$1 $boards"; shift 1
|
2023-10-05 02:23:07 +00:00
|
|
|
done
|
|
|
|
|
2024-06-19 23:12:00 +00:00
|
|
|
[ -n "$boards" ] || [ -n "$ser" ] || boards="$(ls -1 \
|
|
|
|
config/coreboot)" || $err "can't list coreboot boards"
|
|
|
|
|
|
|
|
[ -n "$ser" ] && \
|
|
|
|
eval "serlist \"\$${ser}dir\" > \"\$tmpdir/ser\" || $err \"!ser\""
|
|
|
|
[ -n "$ser" ] && [ -z "$boards" ] && boards="$(cat "$tmpdir/ser")"
|
|
|
|
|
2024-06-14 08:11:07 +00:00
|
|
|
for x in $boards; do
|
2024-06-19 23:12:00 +00:00
|
|
|
[ -n "$ser" ] && mkserprogfw "$ser" "$x"
|
|
|
|
[ -z "$ser" ] && [ -d "config/coreboot/$x/config" ] && \
|
2024-06-24 16:35:44 +00:00
|
|
|
configure_target "$x" && build_roms && \
|
2024-06-19 23:12:00 +00:00
|
|
|
[ -d "bin/$board" ] && targets="$targets, $x"; continue
|
2024-06-14 08:11:07 +00:00
|
|
|
done
|
2023-10-06 02:03:31 +00:00
|
|
|
|
2024-06-19 23:12:00 +00:00
|
|
|
[ -n "$ser" ] && [ "$xbmk_release" = "y" ] && \
|
|
|
|
mkrom_tarball "bin/serprog_$ser" && return 0
|
|
|
|
|
|
|
|
[ -z "$ser" ] && [ -z "$targets" ] && $err "No images were compiled"
|
2024-06-24 16:41:43 +00:00
|
|
|
[ -z "$ser" ] && printf "ROMs built in bin/ for: %s\n" "${targets#, }"
|
2024-06-24 16:42:58 +00:00
|
|
|
printf "Please flash from bin/, NOT elf/ - ALSO:\n%s\n" "$kbnotice"
|
2023-09-30 12:21:15 +00:00
|
|
|
}
|
|
|
|
|
2024-06-18 00:20:40 +00:00
|
|
|
mkserprogfw()
|
2024-05-09 12:52:49 +00:00
|
|
|
{
|
2024-06-19 23:12:00 +00:00
|
|
|
x_ mkdir -p "bin/serprog_$1"
|
2024-06-22 23:15:19 +00:00
|
|
|
[ "$1" = "rp2040" ] && x_ cmake -DPICO_BOARD="$2" \
|
|
|
|
-DPICO_SDK_PATH="$picosdk" -B "$rp2040src/build" "$rp2040src" && \
|
|
|
|
x_ cmake --build "$rp2040src/build"
|
|
|
|
[ "$1" = "stm32" ] && x_ make -C "$stm32src" libopencm3-just-make \
|
|
|
|
BOARD=$2 && x_ make -C "$stm32src" BOARD=$2
|
2024-06-18 00:50:40 +00:00
|
|
|
eval "x_ mv \"\$${1}x\" \"bin/serprog_$1/serprog_$2.\${${1}x##*.}\""
|
2024-05-09 12:52:49 +00:00
|
|
|
}
|
|
|
|
|
2024-06-15 23:53:21 +00:00
|
|
|
serlist()
|
2024-05-09 12:52:49 +00:00
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
basename -a -s .h "$1/"*.h || $err "$1: can't list boards"
|
2024-05-09 12:52:49 +00:00
|
|
|
}
|
|
|
|
|
2024-06-14 15:34:05 +00:00
|
|
|
configure_target()
|
2024-05-05 04:09:23 +00:00
|
|
|
{
|
2024-06-22 03:06:07 +00:00
|
|
|
eval `setvars "n" $pv`
|
|
|
|
eval `setvars "" $v`
|
2024-05-05 04:09:23 +00:00
|
|
|
|
2024-06-22 23:15:19 +00:00
|
|
|
board="$1"; targetdir="$cfgsdir/$board"; romdir="bin/$board"
|
2023-10-05 02:23:07 +00:00
|
|
|
|
|
|
|
# Override the above defaults using target.cfg
|
lib.sh: more unified config handling
replace it with logic that simply uses "." to load
files directly. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources
config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash
this change results in a noticeable reduction in code
complexity within the build system.
unified reading of config files: new function setcfg()
added to lib.sh
setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.
there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 01:35:25 +00:00
|
|
|
eval `setcfg "$targetdir/target.cfg"`
|
2024-06-24 16:28:25 +00:00
|
|
|
x_ ./update trees -b coreboot $board
|
2023-10-05 02:23:07 +00:00
|
|
|
|
roms: only support SeaBIOS/SeaGRUB on x86
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 21:57:39 +00:00
|
|
|
[ -z "$tree" ] && $err "$board: tree not defined"
|
|
|
|
[ "$xbmk_release" = "y" ] && [ "$release" = "n" ] && return 1
|
|
|
|
[ "$board" = "$tree" ] && return 1
|
|
|
|
|
2024-06-22 23:15:19 +00:00
|
|
|
cbdir="src/coreboot/$tree"
|
|
|
|
cbfstool="elf/cbfstool/$tree/cbfstool"
|
|
|
|
[ -f "$cbfstool" ] || x_ ./update trees -b coreboot utils $tree
|
|
|
|
|
roms: only support SeaBIOS/SeaGRUB on x86
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 21:57:39 +00:00
|
|
|
[ -n "$uboot_config" ] || uboot_config="default"
|
|
|
|
[ "$payload_uboot" = "y" ] || payload_seabios="y"
|
|
|
|
[ "$payload_grub" = "y" ] && payload_seabios="y"
|
|
|
|
[ "$payload_seabios" = "y" ] && [ -n "$payload_uboot" = "y" ] && \
|
|
|
|
$err "$board: U-Boot and SeaBIOS/GRUB are both enabled."
|
|
|
|
|
grub.cfg: use grub_scan_disk to set boot order
Previously, grub_scan_disk could set ata, ahci or "both",
which would make both be tried (ahci first). This worked
when we only dealt with ata and ahci devices, but now we
support nvme devices so the logic is inherently flawed.
Instead, use grub_scan_disk to store the boot order, e.g.:
grub_scan_disk="ahci nvme ata"
grub_scan_disk="nvme ata"
In the first example, it would make GRUB scan ahci first,
then nvme and then ata.
In the secontd example, it would make GRUB scan nvme first,
and then ata.
If "both" is set, or anything other than ahci/ata/nvme,
grub_scan_disk is now changed to "nvme ahci ata".
Actual grub_scan_disk entries in target.cfg files will now
be modified, to match each machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27 19:16:49 +00:00
|
|
|
[ -z "$grub_scan_disk" ] && grub_scan_disk="nvme ahci ata"
|
2024-06-09 17:48:58 +00:00
|
|
|
|
make GRUB multi-tree and re-add xhci patches
Re-add xHCI only on haswell and broadwell machines, where
they are needed. Otherwise, keep the same GRUB code.
The xHCI patches were removed because they caused issues
on Sandybridge-based Dell Latitude laptops. See:
https://codeberg.org/libreboot/lbmk/issues/216
The issue was not reported elsewhere, including on the
Haswell/Broadwell hardware where they are needed, but the
build system could only build one version of GRUB.
The older machines do not need xHCI patches, because they
either do not have xHCI patches, or work (in GRUB) because
they're in EHCI mode when running the payload.
So, the problem is that we need the xHCI patches for GRUB
on Haswell/Broadwell hardware, but the patches break
Sandybridge hardware, and we only had the one build of GRUB.
To mitigate this problem, the build system now supports
building multiple revisions of GRUB, with different patches,
and each given coreboot target can say which GRUB tree to use
by setting this in target.cfg:
grubtree="xhci"
In the above example, the "xhci" tree would be used. Some
generic GRUB config has been moved to config/data/grub/
and config/grub/ now looks like config/coreboot/ - also,
the grub.cfg file (named "payload" in each tree) is copied
to the GRUB source tree as ".config", then added to GRUB's
memdisk in the same way, as grub.cfg.
Several other design changes had to be made because of this:
* grub.cfg in memdisk no longer automatically jumps to one
in CBFS, but now shows a menuentry for it if available
* Certain commands in script/trees are disabled for GRUB,
such as *config make commands.
* gnulib is now defined in config/submodule/grub/, instead
of config/git/grub - and this mitigates an existing bug
where downloading gnulib first would make grub no longer
possible to download in lbmk.
The coreboot option CONFIG_FINALIZE_USB_ROUTE_XHCI has been
re-enabled on: Dell OptiPlex 9020 MT, Dell OptiPlex 9020 SFF,
Lenovo ThinkPad T440p and Lenovo ThinkPad W541 - now USB should
work again in GRUB.
The GRUB payload has been re-enabled on HP EliteBook 820 G2.
This change will enable per-board GRUB optimisation in the
future. For example, we hardcode what partitions and LVMs
GRUB scans because * is slow on ICH7-based machines, due
to GRUB's design. On other machines, * is reasonably fast,
for automatically enumerating the list of devices for boot.
Use of * (and other wildcards) could enable our GRUB payload
to automatically boot more distros, with minimal fuss. This
can be done at a later date, in subsequent revisions.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-01 22:01:30 +00:00
|
|
|
[ -n "$grubtree" ] || grubtree="default"
|
|
|
|
grubelf="elf/grub/$grubtree/payload/grub.elf"
|
|
|
|
|
roms: only support SeaBIOS/SeaGRUB on x86
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 21:57:39 +00:00
|
|
|
[ "$payload_memtest" = "y" ] || payload_memtest="n"
|
2024-06-22 23:15:19 +00:00
|
|
|
[ "$(uname -m)" = "x86_64" ] || payload_memtest="n"; return 0
|
2023-10-05 02:23:07 +00:00
|
|
|
}
|
|
|
|
|
2024-06-24 16:35:44 +00:00
|
|
|
build_roms()
|
2023-10-05 02:23:07 +00:00
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
x_ rm -Rf "$romdir"
|
2023-12-23 16:16:26 +00:00
|
|
|
|
2024-06-24 17:24:50 +00:00
|
|
|
for cbcfg in "$targetdir/config/"*; do
|
|
|
|
[ -f "$cbcfg" ] || continue; cn="${cbcfg##*/}"; dt="${cn#*_}" \
|
|
|
|
&& [ "$dt" = "$cn" ] && dt="txtmode"; displaymode="$dt"
|
|
|
|
initmode="${cn%%_*}"; chkvars initmode displaymode
|
|
|
|
e "$cbcfg" f not || add_payloads
|
|
|
|
done; x_ rm -f "$tmprom"
|
2023-10-05 02:23:07 +00:00
|
|
|
}
|
|
|
|
|
2024-06-24 16:35:44 +00:00
|
|
|
add_payloads()
|
2023-10-05 02:23:07 +00:00
|
|
|
{
|
2024-06-22 23:15:19 +00:00
|
|
|
cbuild="$cbelfdir/$board/${initmode}_$displaymode"
|
|
|
|
[ "$initmode" = "normal" ] && cbuild="${cbuild%"_$displaymode"}"
|
|
|
|
x_ cp "$cbuild/coreboot.rom" "$tmprom"
|
2023-10-05 02:23:07 +00:00
|
|
|
|
2024-06-24 16:35:44 +00:00
|
|
|
[ "$payload_seabios" = "y" ] && add_seabios_payload
|
2024-06-22 23:15:19 +00:00
|
|
|
[ "$payload_uboot" = "y" ] || return 0
|
2024-05-26 00:54:36 +00:00
|
|
|
|
2024-06-24 16:35:44 +00:00
|
|
|
# add u-boot payload
|
2024-06-24 17:30:48 +00:00
|
|
|
ubdir="elf/u-boot/$board/$uboot_config"; ubootelf="$ubdir/u-boot.elf" \
|
|
|
|
&& [ ! -f "$ubootelf" ] && ubootelf="$ubdir/u-boot"
|
|
|
|
[ -f "$ubootelf" ] || x_ ./update trees -b u-boot $board
|
2024-06-22 23:15:19 +00:00
|
|
|
[ -f "$ubootelf" ] || $err "$board: Can't find u-boot"
|
2024-06-19 13:11:54 +00:00
|
|
|
|
2024-06-22 23:15:19 +00:00
|
|
|
cbfs "$tmprom" "$ubootelf" "fallback/payload"
|
|
|
|
cprom "$romdir/uboot_payload_${board}_${initmode}_$displaymode.rom"
|
2023-10-05 02:23:07 +00:00
|
|
|
}
|
|
|
|
|
2024-06-24 16:35:44 +00:00
|
|
|
add_seabios_payload()
|
2024-06-22 23:15:19 +00:00
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
_seabioself="elf/seabios/default/$initmode/bios.bin.elf"
|
2024-06-22 23:15:19 +00:00
|
|
|
x_ ./update trees -b seabios
|
|
|
|
|
|
|
|
pstr="seabios" && [ "$payload_grub" = "y" ] && pstr="seabios_withgrub"
|
|
|
|
newrom="$romdir/${pstr}_${board}_$initmode.rom"
|
|
|
|
[ "$initmode" = "normal" ] || newrom="${newrom%.rom}_$displaymode.rom"
|
2023-10-05 02:23:07 +00:00
|
|
|
|
roms: only support SeaBIOS/SeaGRUB on x86
Never, ever build images where GRUB is the primary payload.
These options have been removed from target.cfg handling:
* seabios_withgrub
* grub_withseabios
The "payload_grub" variable now does the same thing as
the old "seabios_withgrub" variable, if set.
The "grubonly" configuration is retained, and enabled by
default when SeaGRUB is enabled (non-grubonly also available).
Due to lbmk issue #216, it is no longer Libreboot policy to
make GRUB the primary payload on any board. GRUB's sheer size
and complexity, plus the large number of memory corruption issues
similar to it that *have* been fixed over the years, tells me
that GRUB is a liability when it is the primary payload.
SeaBIOS is a much safer payload to run as primary, on x86, due
to its smaller size and much more conservative development; it
is simply far less likely to break.
If GRUB breaks in the future, the user's machine is not
bricked. This is because SeaBIOS is the default payload.
Since I no longer wish to ever provide GRUB as a primary
payload, supporting it in lbmk adds needless bloat that
will later probably break anyway due to lack of testing,
so let's just assume SeaGRUB in all cases where the user
wants to use a GRUB payload.
You can mitigate potential security issues with SeaBIOS
by disabling option ROM execution, which can be done at
runtime by inserting integers into CBFS. The SeaBIOS
documentation says how to do this.
Libreboot's GRUB hardening guide still says how to add
a bootorder file in CBFS, making SeaBIOS only load GRUB
from CBFS, and nothing else. This, combined with the
disablement of option ROM execution (if using Intel
graphics), pretty much provides the same security benefits
as GRUB-as-primary, for example when setting a GRUB password
and GPG checks, with encrypted /boot as in the hardening guide.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 21:57:39 +00:00
|
|
|
cbfs "$tmprom" "$_seabioself" "fallback/payload"
|
2023-12-22 13:05:32 +00:00
|
|
|
x_ "$cbfstool" "$tmprom" add-int -i 3000 -n etc/ps2-keyboard-spinup
|
2023-10-05 02:23:07 +00:00
|
|
|
|
2023-12-24 09:04:36 +00:00
|
|
|
z="2"; [ "$initmode" = "vgarom" ] && z="0"
|
|
|
|
x_ "$cbfstool" "$tmprom" add-int -i $z -n etc/pci-optionrom-exec
|
|
|
|
x_ "$cbfstool" "$tmprom" add-int -i 0 -n etc/optionroms-checksum
|
2024-06-22 23:15:19 +00:00
|
|
|
[ "$initmode" = "libgfxinit" ] && cbfs "$tmprom" "$seavgabiosrom" \
|
2024-06-15 19:22:19 +00:00
|
|
|
vgaroms/seavgabios.bin raw
|
2023-10-05 02:23:07 +00:00
|
|
|
|
2024-06-22 23:15:19 +00:00
|
|
|
if [ "$payload_grub" = "y" ]; then
|
|
|
|
x_ ./update trees -b grub $grubtree
|
|
|
|
cbfs "$tmprom" "$grubelf" "img/grub2"
|
|
|
|
printf "set grub_scan_disk=\"%s\"\n" "$grub_scan_disk" \
|
|
|
|
> "$tmpdir/tmpcfg" || $err "$board: !insert scandisk"
|
|
|
|
cbfs "$tmprom" "$tmpdir/tmpcfg" scan.cfg raw
|
|
|
|
fi
|
2023-10-05 02:23:07 +00:00
|
|
|
|
2024-06-22 23:15:19 +00:00
|
|
|
[ "$payload_memtest" = "y" ] && x_ ./update trees -b memtest86plus && \
|
|
|
|
cbfs "$tmprom" "elf/memtest86plus/memtest.bin" img/memtest
|
|
|
|
|
|
|
|
cprom "$newrom" && [ "$payload_grub" = "y" ] && \
|
|
|
|
cbfs "$tmprom" "$grubdata/bootorder" bootorder raw && \
|
|
|
|
cprom "${newrom%.rom}_grubfirst.rom"; return 0
|
2023-10-05 02:23:07 +00:00
|
|
|
}
|
|
|
|
|
2024-05-26 00:54:36 +00:00
|
|
|
cprom()
|
don't delete microcode updates in rom images
at present, lbmk can remove microcode updates on images for
a given target, if the target specifies
microcode_required="n" in target.cfg
lbmk then provides images with microcode, and images without,
in a given release. although the user can also remove them
manually, this just makes it a bit more convenient, for those
users who do wish to run without the updates. this functionality
is provided only on those platforms where no-microcode is tested.
well, this behaviour implements a compromise on libreboot policy,
which is to always include microcode updates by default. see:
Binary Blob Reduction Policy
the *canoeboot* project now exists, developed in parallel with
libreboot, and it ships without microcode updates, on the same
targets where lbmk also handled this.
running without microcode updates is foolish, and should not
be encouraged. clean up lbmk by not providing this kludge.
the libreboot documentation will be updated, telling such users
to try canoeboot instead, or to remove the update from a given
libreboot rom - this is still possible, and mitigations such as
PECI disablement on GM45 are still in place (and will be kept),
so that this continues to work well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23 06:54:56 +00:00
|
|
|
{
|
2024-06-22 23:15:19 +00:00
|
|
|
x_ mkdir -p "${1%/*}"; x_ cp "$tmprom" "$1"
|
|
|
|
[ "$xbmk_release" = "y" ] && mksha512sum "$1" "vendorhashes" && \
|
|
|
|
x_ ./vendor inject -r "$1" -b "$board" -n nuke; return 0
|
2023-10-05 02:23:07 +00:00
|
|
|
}
|
|
|
|
|
2023-05-10 04:39:11 +00:00
|
|
|
main $@
|