commands now fed from a file, include/common.sh
which in turn also includes other lib files
this makes mk completely generic, and means
that changes will now be completely in sync
with cbmk, ensuring a lack of merge conflicts,
though the file was already pretty small anyway.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i made several modificatinos to several files
thus for in 2026, in the main part of the build system.
i've added 2026 to the ones that i modified.
Signed-off-by: Leah Rowe <leah@libreboot.org>
with this new function, i can turn commands on and
off by virtue of config. for now, behaviour is
unchanged, but this new design means i will be
able to disable certain commands in child processes
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 1b65e8914c.
NOTE: cleanup of xbmk_git_init was retained
this "cleanup" actually made the code harder to read.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this will make managing updates easier. which will
be soon, because i have a lot of patches.
no idea why i didn't add this before. normally, i just
copy a directory and git-fetch, then cherry-pick as
i please. this will make it trivial to just update
a revision and merge the patches. then i can just
intervene only when necessary, on a given src tree.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the previous patch was half the battle. now that
annoying person who complained on irc should be
happy.
someone complained about having to enter git
name/email when just doing e.g. ./mk inject
a valid complaint, but their attitude kinda
stunk. oh well. this patch should satisfy them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Some users have it in a file e.g. inside ~/.gitconfig
Those users are currently forced to set git config
globally by lbmk. We only need to check that a git
config is set, regardless of scope, because coreboot
needs it in parts of its build system when used on
lbmk.
This prevents a pointless error report for users who
have their git config on such a scope. Thanks go to
Hendrik Jäger for reporting this to me.
Yes, thank you. Further context:
https://lore.kernel.org/git/20260720113402.0dc16abe@frustcomp.hnjs.home.arpa/T/#u
Signed-off-by: Leah Rowe <leah@libreboot.org>
i'm trying to make nvmutil work on openbsd. the new code
in lbutils is a bit buggy, likely somewhere in mkhtemp.
i'm still debugging it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i added a fake -t option, which doesn't actually
read optarg, so that -t usage can just override
the normal template. mkhtemp isn't ready for
distros yet, but it's ready for lbmk.
i hacked the makefile to also copy the binary to
mktemp, and i set PATH in lbmk so that this binary
is used insttead of the one on your system.
that way, upstream projects use it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This will also be used in lbmk itself at some point,
which currently just uses regular mktemp, for tmpdir
handling during the build process.
Renamed util/nvmutil to util/libreboot-utils, which
now contains two tools. The new tool, mkhtemp, is a
hardened implementation of mktemp, which nvmutil
also uses now. Still experimental, but good enough
for nvmutil.
Mkhtemp attempts to provide TOCTOU resistance on
Linux, by using modern features in Linux such as
Openat2 (syscall) with O_EXCL and O_TMPFILE,
and many various security checks e.g.
inode/dev during creation. Checks are done constantly,
to try to detect race conditions. The code is very
strict about things like sticky bits in world writeable
directories, also ownership (it can be made to bar even
root access on files and directories it doesn't own).
It's a security-first implementation of mktemp, likely
even more secure than the OpenBSD mkstemp, but more
auditing and testing is needed - more features are
also planned, including a compatibility mode to make
it also work like traditional mktemp/mkstemp. The
intention, once this becomes stable, is that it will
become a modern drop-in replacement for mkstemp on
Linux and BSD systems.
Some legacy code has been removed, and in general
cleaned up. I wrote mkhtemp for nvmutil, as part of
its atomic write behaviour, but mktemp was the last
remaining liability, so I rewrote that too!
Docs/manpage/website will be made for mkhtemp once
the code is mature.
Other changes have also been made. This is from another
experimental branch of Libreboot, that I'm pushing
early. For example, nvmutil's state machine has been
tidied up, moving more logic back into main.
Mktemp is historically prone to race conditions,
e.g. symlink attacks, directory replacement, remounting
during operation, all sorts of things. Mkhtemp has
been written to solve, or otherwise mitigate, that
problem. Mkhtemp is currently experimental and will
require a major cleanup at some point, but it
already works well enough, and you can in fact use
it; at this time, the -d, -p and -q flags are
supported, and you can add a custom template at
the end, e.g.
mkhtemp -p test -d
Eventually, I will make this have complete parity
with the GNU and BSD implementations, so that it is
fully useable on existing setups, while optionally
providing the hardening as well.
A lot of code has also been tidied up. I didn't
track the changes I made with this one, because
it was a major re-write of nvmutil; it is now
libreboot-utils, and I will continue to write
more programs in here over time. It's basically
now a bunch of hardened wrappers around various
libc functions, e.g. there is also a secure I/O
wrapper for read/write.
There is a custom randomisation function, rlong,
which simply uses arc4random or getrandom, on
BSD and Linux respectively. Efforts are made to
make it as reliable as possible, to the extent
that it never returns with failure; in the unlikely
event that it fails, it aborts. It also sleeps
between failure, to mitigate certain DoS attacks.
You can just go in util/libreboot-utils and
type make, then you will have the nvmutil and
mkhtemp binaries, which you can just use. It
all works. Everything was massively rewritten.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is a special mode that skips FPTR checks, which is
needed on the topton x2e_n150
we currently set this, when MEclean="n", but we may want to
skip cleaning while still checking FPTR on some boards (in
a future lbmk revision)
Signed-off-by: Leah Rowe <leah@libreboot.org>
it is currently only initialised inside case
conditions. this is fine on most shells, but
some of them can be a bit buggy here.
initialise it empty and then override.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Courtesy of Kat Inskip who ported this board.
Headphone output doesn't work at the moment, due to incorrect verb.
Intel VBT is also wrong. Both are taken from another board.
This will be amended later with the correct verb and VBT.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Surprisingly, SeaBIOS VGA output works (coreboot documentation says it
doesn't).
I'm using a static CMOS option table currently (like most other boards
supported in libreboot), but maybe it would be better to switch to the
CBFS file option table. The default option table enables
hyperthreading, overriding the compile-time setting.
I'm also using a ME/SPS image extracted from the official BIOS update
for this board. Unfortunately, https://www.supermicro.com/Bios/* is
excluded from crawlers in robots.txt so it's not in archive.org, so I
haven't been able to find a backup download URL. I also needed to set
the user-agent for fetching the update to "curl/8.6.0" because the
default user-agent override used by lbmk resulted in a 403 error.
deguard is not required (there's no bootguard on this board).
SPS does not implement CPU replacement detection which means that the
MRC cache does not work and RAM training needs to happen on every
boot. To avoid this it may be possible to run ME instead of SPS on
this board, but I tried both the ME image used on the OptiPlex 3050
Micro in libreboot and one from the ASRock C236 WSI and they both hung
at "[INFO ] POST: 0x92" (POSTCODE_FSP_MEMORY_INIT).
The memtest86+ build included with libreboot doesn't work with USB
keyboards and this board doesn't have a PS/2 port, which is annoying.
during previous re-factoring, i sorted variable initialisations.
that was all well and good, but prior to that, i initialised
the new_mac string to empty at first, and then to
the "xx" letters; the latter made the first initialisation
redundant, but in the re-factoring, I put the blanking of
the string afterward.
this disabled mac address insertion, because the way the script
works is precisely to avoid mac address insertion when the mac
string is empty. this is used when running the "nuke" command.
silly me.
yes, i'm very silly. very very silly. so silly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I intend to merge every Chromebook that Mrchromebox supports,
into Libreboot, ready for the Libreboot 25.12 release. Work
is still ongoing, and several changes need to happen in lbmk.
I started working on it a few weeks ago (today is
14 November 2025 as I push this).
Still TODO:
* Automatically create lbmk coreboot targets, based
on the configs present in MrChromebox git
* Re-work git repository management in lbmk, such that
a list of upstreams is used, instead of a hardcoded
list per configuration; this will allow us to use
different remotes across the same project, even where
they diverge. This would then allow us to use the
MrChromebook repository directly, instead of cherry-picking
patches into upstream coreboot
* The note above about remotes would also mean that we can
use MrChromebox's own edk2 repository directly. All of this
would reduce the burden on lbmk.git
* Support building edk2 payloads, exactly mirroring the
setups used on MrChromebox builds
There are some things that need to be checked first, for
boards that use MMC-based or eMMC-based storage, for the
GRUB and SeaBIOS payloads, also U-Boot, because I will
also be using these.
As such, this current script shall sit in lbmk master, but
it is not yet finished.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is the true fix, replacing the fixes previously
reverted.
the problem with the old fix was that it was a hack,
and could result in the archived backup of a code repo
being the wrong one; the destination was the one for
the main repo, but what if we were cloning the backup?
Signed-off-by: Leah Rowe <leah@libreboot.org>
this fixes a regression in a previous patch, this time
also taking account for the different cache locations.
all of get.sh needs to be purged, and re-written clean.
it looks clean. but it's years of hacks.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe
Zoomm Deka
Leah Rowe
Baraa Al-Masri
Ron Nazarov