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>
A lot of size-coding was performed in prior audits, to
make the sloccount lower on nvmutil, but this resulted in
code that wasn't very human readable.
I've reversed some of it and added comments, for clarity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Mention Riku's copyright in the COPYING file, and update
my years in that file. Add Riku to the AUTHORS file.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The user might wish to uninstall, but not remove the
build that they just did.
The user can still do make clean if they wish.
Signed-off-by: Leah Rowe <leah@libreboot.org>
DESTDIR is the root directory where it goes, which
is normally an empty string; PREFIX is where the
bin directory is located, relative to DESTDIR
Default to /usr/local for PREFIX, not /usr, because
/usr/bin is for system utilities.
nvmutil is a local utility.
Signed-off-by: Leah Rowe <leah@libreboot.org>
We don't want to clobber anything that the user set themselves.
Instead, we should respect the user's choice.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This makes the code easier to understand.
All 2-byte words, stored in little endian order within
the 128-byte GbE NVM area, must add up to 0xBABA.
If it doesn't, then software is supposed to reject that
GbE config. The nvmutil software works on that basis.
Signed-off-by: Leah Rowe <leah@libreboot.org>
make it look like hexdump -C, where individual bytes are
spaced, and there is an additional space after 8 bytes,
per row.
i won't bother with a character display, since that is
meaningless on gbe nvm words.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Must not exceed 79 lines. Some variables and functions have
been renamed, and there has been some minor re-factoring.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I don't like using SPDX for actual copyright declarations.
I only want it to be used for the license identifier.
Also:
I made a *single* change to nvmutil.c in 2024, which means
that I have copyright in all years since and including 2022;
the file said 2022, 2023, 2025, but it's actually 2022-2025.
Signed-off-by: Leah Rowe <leah@libreboot.org>
under the current logic, errno would be ECANCELED
if neither checksum is valid, or I/O related if
pwrite fails; alternatively, the for loop exits
and the file has been written, where it is quite
correctly reset already.
ergo, the errno reset at the start of
writeGbeFile is superfluous. remove this bloat.
Signed-off-by: Leah Rowe <leah@libreboot.org>
previously, a bad checksum would have caused a non-zero
exit, even if the other checksum was correct (observed
when using the swap command)
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe
Riku Viitanen