we assume the fallback will be rare, so now we
make the mix static and keep xoring it, on the
theory that the number of failures on urandom
will be random, and tthat the fallback may only
apply once or twice in thousands of calls.
the time jitter is adjusted; rather than judge
the difference between two points close to each
other in time, we judge tthe randomness in
difference of time elapsed. this mitigates fast
CPUs being very fast and introducing rounding
errors, and also improves performonce on much
slower CPUs
Signed-off-by: Leah Rowe <leah@libreboot.org>
i was being cute earlier, but the rewrite
defeats the purpose of atomic file handling
in nvmutil, by not actually renaming! it was
more like, doing an actual copy, which meant
that corruption is likely during power loss
i've commented the code because i may
use it in a library in the future.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this improves reliability, making it more
likely that data actually gets synced,
since fsync can return -1 with EINTR,
indicating that a re-try should be
attempted.
Signed-off-by: Leah Rowe <leah@libreboot.org>
arandom probably isn't available on super old obsd right??????
rather, unveil isn't. on systems that have arandom
yet we should not unveil something that may not
exist on modern systems
just don't unveil arandom, and don't check arandom
if unveil is enabled
Signed-off-by: Leah Rowe <leah@libreboot.org>
some systems may not even have it
works with /dev/fd (bsd/mac etc)
works with linux (/proc/self/fd)
and falls back on super old systems
that have neither
Signed-off-by: Leah Rowe <leah@libreboot.org>
try a few more times until success
explicitly return EEXIST when needed
we try multiple times and check more
thoroughly if a file exists, thus
reducing the risk of race conditions
Signed-off-by: Leah Rowe <leah@libreboot.org>
not portable. some old systems don't have it,
or handle it very poorly
unsigned long is a reasonable way to refer
to indexes inside pointters
Signed-off-by: Leah Rowe <leah@libreboot.org>
if the global file is created on a different file
system than the gbe file, unveil would trigger an
abort trap, since we rely on created a second
temporary file, whose path we can't know ahead
of time.
i could get rid of unveil, or unveil a directory,
but neither is acceptable. just use localtmp on
openbsd. a temporary file is created next to
the gbe file, in the same directory.
Signed-off-by: Leah Rowe <leah@libreboot.org>
now the custom fallback code is very unlikely
to ever actually be used, on any system,
except really old systems.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i have urandom again. it's enough
the fallback rand implementation
is used if needed
now i don't have to worry about any
weird version of unix from 1992 and
deal with weird hacks. in fact, with
this change, my code will probably
compile on irix now
Signed-off-by: Leah Rowe <leah@libreboot.org>
i had to loosen the pledges for the new i/o
framework, which needs more permissions
as a result, i can now open urandom in
this function statically, rather than
in nvmutil's control logic
and because of that, it's less buggy now
arc4random is disabled on linux by default,
because it's not universally available
on all libc, and only since about 2022
in some glibc versions
better for portability to let linux users
justt use urandom
the new logic is different. now it falls
back to rand per-byte, but in practise
it almost never will.
Signed-off-by: Leah Rowe <leah@libreboot.org>
linux only had it since 2022.
lots of people will complain if i leave this enabled.
not all libc have it either
Signed-off-by: Leah Rowe <leah@libreboot.org>
i simplified it in the last commits, but i sttill
need this loop to properly handle parts
otherwise yeah, all it's doing is copying a file
verbatim. duh.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we now read twice, verify the two, to make sure
one read isn't faulty
we operate on a tmp file, then rename back. this
reduces the risk of power cuts corrupting data
we properly verify the contents that we wrote
back
inspired largely by flashprog. i wanted to have
an insanely over-engineered and extremely safe
tool that edits intel gbe nvm files
and now i have one. the only one in existence.
i'm basically writing my own libc code at this
point, to be honest. i'll probably start puttting
these functions in libraries
e.g. that tmpfile generator
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe