this, in conjunction with the centralised exit scheme now
used by nvmutil, means that we have portable exit status.
notwithstanding the use of non-portable unix functions, and
especially the use of non-standard err.c (which GNU and BSD
libc implementations all have anyway, as does musl).
this code should now run on essentially any computer with
Linux or BSD on it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
exit with 0 or 1, as is proper.
errno is an int, but the return value on a shell
can be e.g. byte, and depending how that number (errno)
is valued, could overflow and cause a zero exit, where
you want a non-zero exit.
the code has been changed, in such a way to maintain
current behaviour (don't change errno), except that when
errno is set upon exit, the exit value is now one.
Signed-off-by: Leah Rowe <leah@libreboot.org>
pointless optimisation. we know that when a user requests an
operation that would write, it will probably result in a change.
therefore, this change is the real optimisation. to avoid
writing the same half of a file twice, when using cmd_copy,
we check (in writeGbe) whether gbe part 0 and 1 are the same;
if they are, then we only loop once. this is important, because
otherwise we would call swap() twice.
this means that the optimisations in cmd_copy and cmd_swap must
be removed. the point of this and other changes is to improve
memory safety in nvmutil, so frivolous use of pointers has to go.
Signed-off-by: Leah Rowe <leah@libreboot.org>
modern file systems work in 4KB blocks. reading only
a small part of it doesn't really make much difference
in terms of performance.
simplify the code instead.
Signed-off-by: Leah Rowe <leah@libreboot.org>
modern malloc implementations make the optimisation here
pretty pointless.
modern computers make this modification pointless.
i'm not planning to run nvmutil on a VAX. openbsd removed
support for it ages ago. 8KB fixed buffer is fine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it doesn't save any time on modern systems, and it's just
confusing for some people to read. i mean, i understand it
instinctively, but normal people do it with a swap variable.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we always want unveil/pledge calls to be in main, when
possible, so that they are more transparent and easier
to understand when re-factoring, because it's extremely
important that these syscalls be done correctly.
main is small enough now, from other re-factoring changes,
that i'm happy to have this back in main now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the current check is too liberal. make it sticter.
the issue is that the previous check did not take
into account that it's a check on a uint16_t array,
against nf which refers to a number of bytes.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was the other complication with doing it as a macro.
for something this fundamental, we really want to ensure
that every access is safe.
Signed-off-by: Leah Rowe <leah@libreboot.org>
merge the urandom handling back into this function.
it's called immediately after in main anyway, so we
may as well. this reduces the size of main.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in the given call, we then do an equivalent call
immediately after that is the same, but without
unveil, so we'll just defer to that.
this changes no behaviour.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in general, we should ensure that the pledge calls only happen
inside main. this means we can more easily see them, in future
re-factoring.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this will enable hardening of the pledge syscalls.
it also means that the program will error out much
earlier, when an invalid command is given, rather
than opening a bunch of files first, and it will
do so under reduced privilege already, notwithstanding
the further pledge/unveil hardening that is planned.
Signed-off-by: Leah Rowe <leah@libreboot.org>
urandom in main. this is because i'm going to further
harden the use of pledge and unveil in a future patch,
and this is a prerequisite.
Signed-off-by: Leah Rowe <leah@libreboot.org>
also for other variants
i removed it because it was reported broken. it's not.
the removal was always temporary, pending further testing.
next time, i will be more sceptical.
everything works fine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
