This imports the serprog pico2 fixes from libreboot,
in addition to GRUB security fixes, various GRUB LVM
fixes, and improvements to nvmutil.
Signed-off-by: Leah Rowe <leah@libreboot.org>
You can find information about these patches here:
https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html
GRUB has been on a crusade as of late, to proactively audit
and fix many security vulnerabilities. This lbmk change brings
in a comprehensive series of patches that fix bugs ranging from
possible buffer overflows, use-after frees, null derefs and so on.
These changes are critical, so a revision release *will* be issued,
for the Libreboot 20241206 release series.
This change imports the following 73 patches which
are present on the upstream GRUB repository (commit IDs
matched to upstream):
* 4dc616657 loader/i386/bsd: Use safe math to avoid underflow
* 490a6ab71 loader/i386/linux: Cast left shift to grub_uint32_t
* a8d6b0633 kern/misc: Add sanity check after grub_strtoul() call
* 8e6e87e79 kern/partition: Add sanity check after grub_strtoul() call
* 5b36a5210 normal/menu: Use safe math to avoid an integer overflow
* 9907d9c27 bus/usb/ehci: Define GRUB_EHCI_TOGGLE as grub_uint32_t
* f8795cde2 misc: Ensure consistent overflow error messages
* 66733f7c7 osdep/unix/getroot: Fix potential underflow
* d13b6e8eb script/execute: Fix potential underflow and NULL dereference
* e3c578a56 fs/sfs: Check if allocated memory is NULL
* 1c06ec900 net: Check if returned pointer for allocated memory is NULL
* dee2c14fd net: Prevent overflows when allocating memory for arrays
* 4beeff8a3 net: Use safe math macros to prevent overflows
* dd6a4c8d1 fs/zfs: Add missing NULL check after grub_strdup() call
* 13065f69d fs/zfs: Check if returned pointer for allocated memory is NULL
* 7f38e32c7 fs/zfs: Prevent overflows when allocating memory for arrays
* 88e491a0f fs/zfs: Use safe math macros to prevent overflows
* cde9f7f33 fs: Prevent overflows when assigning returned values from read_number()
* 84bc0a9a6 fs: Prevent overflows when allocating memory for arrays
* 6608163b0 fs: Use safe math macros to prevent overflows
* fbaddcca5 disk/ieee1275/ofdisk: Call grub_ieee1275_close() when grub_malloc() fails
* 33bd6b5ac disk: Check if returned pointer for allocated memory is NULL
* d8151f983 disk: Prevent overflows when allocating memory for arrays
* c407724da disk: Use safe math macros to prevent overflows
* c4bc55da2 fs: Disable many filesystems under lockdown
* 26db66050 fs/bfs: Disable under lockdown
* 5f31164ae commands/hexdump: Disable memory reading in lockdown mode
* 340e4d058 commands/memrw: Disable memory reading in lockdown mode
* 34824806a commands/minicmd: Block the dump command in lockdown mode
* c68b7d236 commands/test: Stack overflow due to unlimited recursion depth
* dad8f5029 commands/read: Fix an integer overflow when supplying more than 2^31 characters
* b970a5ed9 gettext: Integer overflow leads to heap OOB write
* 09bd6eb58 gettext: Integer overflow leads to heap OOB write or read
* 7580addfc gettext: Remove variables hooks on module unload
* 9c1619773 normal: Remove variables hooks on module unload
* 2123c5bca commands/pgp: Unregister the "check_signatures" hooks on module unload
* 0bf56bce4 commands/ls: Fix NULL dereference
* 05be856a8 commands/extcmd: Missing check for failed allocation
* 98ad84328 kern/dl: Check for the SHF_INFO_LINK flag in grub_dl_relocate_symbols()
* d72208423 kern/dl: Use correct segment in grub_dl_set_mem_attrs()
* 500e5fdd8 kern/dl: Fix for an integer overflow in grub_dl_ref()
* 2c34af908 video/readers/jpeg: Do not permit duplicate SOF0 markers in JPEG
* 0707accab net/tftp: Fix stack buffer overflow in tftp_open()
* 5eef88152 net: Fix OOB write in grub_net_search_config_file()
* aa8b4d7fa net: Remove variables hooks when interface is unregisted
* a1dd8e59d net: Unregister net_default_ip and net_default_mac variables hooks on unload
* d8a937cca script/execute: Limit the recursion depth
* 8a7103fdd kern/partition: Limit recursion in part_iterate()
* 18212f064 kern/disk: Limit recursion depth
* 67f70f70a disk/loopback: Reference tracking for the loopback
* 13febd78d disk/cryptodisk: Require authentication after TPM unlock for CLI access
* 16f196874 kern/file: Implement filesystem reference counting
* a79106872 kern/file: Ensure file->data is set
* d1d6b7ea5 fs/xfs: Ensuring failing to mount sets a grub_errno
* 6ccc77b59 fs/xfs: Fix out-of-bounds read
* 067b6d225 fs/ntfs: Implement attribute verification
* 048777bc2 fs/ntfs: Use a helper function to access attributes
* 237a71184 fs/ntfs: Track the end of the MFT attribute buffer
* aff263187 fs/ntfs: Fix out-of-bounds read
* 7e2f750f0 fs/ext2: Fix out-of-bounds read for inline extents
* edd995a26 fs/jfs: Inconsistent signed/unsigned types usage in return values
* bd999310f fs/jfs: Use full 40 bits offset and address for a data extent
* ab09fd053 fs/jfs: Fix OOB read caused by invalid dir slot index
* 66175696f fs/jfs: Fix OOB read in jfs_getent()
* 1443833a9 fs/iso9660: Fix invalid free
* 965db5970 fs/iso9660: Set a grub_errno if mount fails
* f7c070a2e fs/hfsplus: Set a grub_errno if mount fails
* 563436258 fs/f2fs: Set a grub_errno if mount fails
* 0087bc690 fs/tar: Integer overflow leads to heap OOB write
* 2c8ac08c9 fs/tar: Initialize name in grub_cpio_find_file()
* 417547c10 fs/hfs: Fix stack OOB write with grub_strcpy()
* c1a291b01 fs/ufs: Fix a heap OOB write
* ea703528a misc: Implement grub_strlcpy()
Signed-off-by: Leah Rowe <leah@libreboot.org>
genisoimage is not a an AUR package as suggested by aur_notice. It is
available in the "cdrtools" package in the repositories.
References: https://archlinux.org/packages/extra/x86_64/cdrtools/
Signed-off-by: Runxi Yu <me@runxiyu.org>
after setting the checksum too
this is functionally no different, but setting it
at the start didn't sit right with me.
it's more logically correct to set it at the end,
in case any error did not result in an exit.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We're checking if errno is ENOTDIR, not setting it;
the previous code would always return true, and then
set errno 0, which in the context of this code was
actually OK, so this patch makes no functional difference
in practise.
However, I'm a stickler for technical correctness. I caught
this when trying to compile with clang, because clang is
quite pedantic about checking for exactly this type of bug.
Signed-off-by: Leah Rowe <leah@libreboot.org>
previously, if the user ran:
./nvm GBE [MAC address]
it would error, treating the MAC as a command
now if only 3 arguments are provided, and the
3rd argument ins't a valid command, it's treated
as a MAC address and validated accordingly.
this should make nvmutil easier to use, because
I imagine a lot of users forget to use setmac
there's no reason we should be so pedantic. we
should allow it to be used flexibly like this
Signed-off-by: Leah Rowe <leah@libreboot.org>
On the 16KB and 128KB files, we still only need to
operate on 4KB at the start of each block, where the
block size is larger than 4KB.
The reason we deal with the entire 4KB block is because
the nvm words (in the 128 byte section) can define an
extended nvm area anywhere after 128 bytes, within the
128 byte block.
We could systematically read where that is being handled,
and handle it; we could then allocate less memory, and
read/write fewer bytes, but many block devices like SSDs
and flash drives have at least a 4KB erase block anyway,
so it's kinda pointless. saving memory would be nice, but
I don't really want to bloat the code.
This is a nice easy optimisation, to avoid wasting an
additional 8KB of memory when handling 16KB files, and
additional 120KB if handling 128KB files, since nf is
what determines how much memory will be allocated.
the alternative would be to use an mmap, and then we
could reasonably handle the idea above for only writing,
surgically, what we need: nvm words and extended nvm
words.
Signed-off-by: Leah Rowe <leah@libreboot.org>
./nvm gbe.bin
with this patch, the above example does the same as:
./nvm gbe.bin setmac
now you can simply specify the gbe file, and it will
randomise the mac address within it, and update the
nvm checksum word.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this way, we still get an error exit for example
when trying to invalidate an already invalid
checksum; this error exit was disabled by the
last revisions.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is for user friendliness. Otherwise, many users
might try to dump afterward if they specified a random
MAC address.
This saves the user from having to re-run with the dump
command, thus saving time for the user.
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of setting errno in the for loop, set a variable
declaring that the mac was updated, and reset errno based
on that.
Signed-off-by: Leah Rowe <leah@libreboot.org>
if checksum verification passed, then we should reset
in case we're operating on a given part and the last
one checked was bad.
a catch-all reset is already performed in writeGbe,
but it's good to do it here too.
in practise, if the 2nd part (part 1) is what failed,
errno still wouldn't be reset.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it will probably never happen, and this is technically
not an error condition of pread/pwrite, but we need it
to read and write that exact number of bytes, as per nf
Signed-off-by: Leah Rowe <leah@libreboot.org>
it wouldn't occur, on the current logic, but i wasn't
comfortable having the starting point (on little endian)
being higher than the checked endpoint, in case of
possible integer overflow as a result of future
modifications.
this is therefore a pre-emptive bug fix, because it doesn't
yet fix a bug, but it prevents a bug from being introduced.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The 128-byte nvm area is all that we need to handle,
since that is the only thing we actually work on in
nvmutil, based on checksum verification; the latter
implies that bytes must be in the correct order.
The swap() function previously worked on the entire
block, e.g. 4KB on 8KB files, 8KB on 16KB files and
64KB on 128KB files, and it did this twice, so it would
have operated on anywhere between 8KB to 128KB of data.
It now only operates on 256 bytes at a maximum, or 128
bytes if only handling one block. This is a significant
performance optimisation, on big endian host CPUs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
previous audits sizecoded nvmutil.c, reducing the sloccount,
but this resulted in unreadable code.
move the swap logic (swap parts) back to its own function,
for clarity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
also cmd_brick
where the checksum is being corrected or bricked, we
only need to handle the 128-byte nvm area on one of
the parts
similarly, we only need to allocate half the gbe file
size when doing a copy command.
256 bytes still allocated for setmac (see previous
commit), because we verify both checksums and set both
parts if possible.
with this, nvmutil is now much more memory-efficient.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Allocate memory based on nf instead of partsize.
nf is the number of bytes actually read from each
part of the file.
Now if the user is running setmac for example,
256 bytes of memory will be allocated regardless
of gbe file size, whereas it would have previously
allocated 8KB, 16KB or 128KB depending on the file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We were allocating 128KB even if we only needed 8KB, for
example. It's not a lot of memory, but the principle of
the matter is that we must respect the user by not wasting
their memory.
The design of nvmutil is that it will never overflow, because
operations are mapped in memory to the exact size of the gbe
file, which can be 8KB, 16KB or 128KB, and this is enforced.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The buf variable is only used once, and only so
that we can get a pointer. We can point to buf16
instead, for the same result.
The gbe pointer (size_t) is later converter to
a char * when writing back to the file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
For example, if the brick command is used without specifying
a part number. Instead of saying "Invalid argument", show a
much more useful error message to help the user adapt.
Signed-off-by: Leah Rowe <leah@libreboot.org>
call pledge *much* earlier, and and lock everything down
much sooner. the point of pledge/unveil is precisely that
your program must operate under the most restrictive set
of conditions possible, and still function.
Signed-off-by: Leah Rowe <leah@libreboot.org>
tell the user exactly what they got wrong, instead
of simply printing "bad mac address", which is not
very helpful to the user
Signed-off-by: Leah Rowe <leah@libreboot.org>
See:
https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-mobile-p/intel-600-series-chipset-family-on-package-platform-controller-hub-pch-datash/spi0-for-flash/
The rules described there are universal, and replicated elsewhere
for many other platforms. The rules are simply:
* Flash descriptor is one block size, e.g. 4KB
* GbE is two block sizes, so if IfD is 4KB, GbE is 8KB
Intel defines 16KB and 128KB GbE files in specs, pertaining to
8KB and 64KB block sizes respectively.
The minimum size is 4KB blocksize, for 8KB GbE files which
we already supported. On larger block sizes, the same 4KB
parts are observed: a single 4KB IfD area at the start of
the block, and:
4KB GbE part at the start of the GbE region, and:
4KB GbE part at the start of GbE region plus block size
The empty space inbetween is padding, and we ignore it,
except when running swap/copy commands.
The nvmutil code has been modified, to create a 128KB buffer in
memory instead of 8KB, for loading GbE files.
Partsize is set to GbE file size divided by 2, and only the
area of memory we need to use is mapped; for example, if
we're loading a 8KB GbE file into memory, we only touch
the first 8KB part of the buffer, or first 16KB for 128KB
files.
In practise, we almost never see GbE files with sizes higher
than 8KB, but *we have seen it*, *AND NOW IT'S SUPPORTED!"
Signed-off-by: Leah Rowe <leah@libreboot.org>
We were checking directories *after* calling unveil, which
means that the sandboxing was incomplete; we only want files
to be accessed, not directories.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe