linear, top-down order. re-order the prototypes
also some general cleanup:
argc enums now validated. ifdefs for pledge
and arc4random now use a consistent naming
scheme.
feature change:
the "dump" command now fails if both checksums
are invalid, and won't show anything.
my next commit will disable setchecksum when
both checksums are invalid. this and the other
insane auditing i've done over the last few
days has been part of a major effort to make
nvmutil extremely safe, and robust.
Signed-off-by: Leah Rowe <leah@libreboot.org>
setchecksum and setmac update the checksum.
other commands don't.
this patch unified the logic, handling it
in write_gbe based on command[].chksum_write
Signed-off-by: Leah Rowe <leah@libreboot.org>
only pledge/unveil where available, on versions
that have it. this patch disables it on older
versions, allowing nvmutil to compile.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i previously had this as a speed optimisation, but
removed it because it wouldn't make any real speed
difference, on most modern file systems / kernels.
however, this also has the dual purpose of ensuring
only what was verified gets written, on operations
that only touch the NVM area, since this relies on
checksum verification.
therefore, i have re-added this feature, but under
the new design of nvmutil. it is done policy-based,
instead of having if/else for specific commands.
Signed-off-by: Leah Rowe <leah@libreboot.org>
their functions now only return. not needed anymore.
these commands are still available, but they no longer
need helper functions.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the existing verification is retained, an a few commands.
this is an additional security mechanism. redundancy is
best.
Signed-off-by: Leah Rowe <leah@libreboot.org>
strnlen is not available on some older systems,
so now we provide our own portable version.
this version also aborts on NULL input, unlike
the standard function.
this version also does not permit empty strings.
this version also does not permit unterminated
strings.
Signed-off-by: Leah Rowe <leah@libreboot.org>
arc4random is superior, so using /dev/urandom
would be a mistake. we only use that on linux,
or old/weird unix.
we would also use it on linux, but GNU prohibits
nice things (its implementations are spotty, and
old glibc doesn't have it - before 2022 there is
libbsd, but i'm not importing that).
not that it matters. we're not doing encryption.
i'm just a stickler for technical correctness.
Signed-off-by: Leah Rowe <leah@libreboot.org>
There, we use arc4random_buf which does not directly
access /dev/urandom on BSD; it uses a userspace method
instead, which bypasses this.
This is therefore much more restrictive, which is
exactly the point of unveil(2) and pledge(2); restrict
your program's operation while ensuring that it has what
it needs, to help with debugging and prevent common bugs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe