do it in the macro. this way, if a given error is
present, it's not overridden. this enables easier
debugging.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i renamed filename to fname, so that certain lines would
still fit within 80 characters without introducing a new
line break.
Signed-off-by: Leah Rowe <leah@libreboot.org>
handle it in a separate function, for clarity.
the main function just checks each part whether it
changed, and then passes control to writeGbe_part.
Signed-off-by: Leah Rowe <leah@libreboot.org>
use the ERR macro instead, so that an existing value
will not be overridden. this is useful for debugging.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this has to do with memory allocation, not actual reading
of the gbe file into memory. split it up, for clarity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
when nf and nr/nw are not the same, we know there
is an error condition, so defer to the following err()
call, but use ERR() there instead of hardcoding use
of ECANCELED.
this actually improves the error handling, by being
more verbose, while reducing the amount of logic.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is the program I recently wrote, that generated
the submodule entries for the GRUB PO file fix
this utility is for reference only. i'll probably do
away with the fix at some point, replacing it with
my own git-based submodule repository, containing the
PO files. this would make things easier, and then
that repository would contain the utility instead.
i'm just putting this in lbmk for now, so that we
have it somewhere.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i currently use the output of sha512sum in several
places of xbmk, which is a bit unreliable in case
output changes.
other cases where i use util outputs in variables
are probably reliable, because i'm using mostly
posix utilities in those.
to mitigate this, i now import suckless sbase, which
has a reasonable sha512sum implementation.
*every* binary it builds is being placed in build.list,
because i'll probably start using more of them.
for example, i may start modifying the "date"
implementation, adding the GNU-specific options that
i need as mentioned on init.sh
i'm importing it in util/ because the sha512sum
util is needed for verifying project sources, so
if sbase itself is a "project source", that means
we can into a chicken and egg bootstrapping problem.
this is sbase at revision:
055cc1ae1b3a13c3d8f25af0a4a3316590efcd48
Signed-off-by: Leah Rowe <leah@libreboot.org>
A user reported that '?' causes an error on zsh. See:
https://codeberg.org/libreboot/lbmk/issues/261
For example:
./mk inject libreboot-XXXXXX.tar.xz setmac ??:??:??:??:??:??
The user got:
zsh: no matches found: ??:??:??:??:??:??
The mitigation here is to double-quote, e.g.:
./mk inject libreboot-XXXXXX.tar.xz setmac "??:??:??:??:??:??"
However, a lot of people won't do that. Therefore, I will
retain the current behaviour but support x/X for randomness.
Now lbmk uses x by default, instead. I will now update the
documentation, accordingly.
Signed-off-by: Leah Rowe <leah@libreboot.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>
Leah Rowe