Problem: relative .toml config paths don't resolve
when cargo is invoked from a subdirectory like kernel/.
Solution: convert relative paths to absolute against
the project root in the cargo() helper.
Problem: there is no way to pass extra cargo config
(e.g. vendored sources) through xtask to the
underlying cargo invocations.
Solution: accept --config flags in cargo xtask and
thread them through all internal cargo invocations.
The cargo() helper now returns a Command with the
config flags already applied.
Problem: env!() bakes the path at compile time,
so it breaks when the binary runs from a different
location (e.g. a Guix/Nix sandbox or container).
Solution: use std::env::var() to read it at runtime.
- add a function we can re-use to check if a file needs updating
- change the wording of the baobit commit when it's not specified
to "unspecified" vs. "unknown"
Adds BAOBIT_COMMIT constant to boot0/boot1 version.rs, allowing
the Guix build channel commit to be embedded in firmware for
reproducibility verification.
- Add --baobit-commit CLI flag to xtask
- Generate BAOBIT_COMMIT in boot version files
- Display in audit command output
- Simplify versioning.rs to always write files
somehow some formatting regressions snuck in despite previously
being CI-clean on formatting.
I suspect this might have to do with the Rust 1.93.1 bump
that happened just recently, sometimes new versions of Rust
introduce small formatting changes.
Pass semver from --git-describe to swap image signing code path.
PR #817 added --git-describe and --git-rev support but the swap
image code path in xous-create-image was not updated to use the
semver for signing.
Changes:
- swap_writer.rs: Add semver parameter to encrypt_to()
- xous-create-image.rs: Parse --git-describe and pass to encrypt_to()
- xous-app-uf2.rs: Same changes for consistency
- builder.rs: Pass --git-describe to xous-create-image
Fixes#818
Enable reproducible builds without git state by accepting
version info as CLI arguments:
- --git-describe: version string for signing (e.g., v0.10.0-19-g0d934e1)
- --git-rev: commit hash for swap nonce (last 16 hex chars used)
Renames xtask --gitrev to --git-describe for clarity.
this picks a toolchain that matches the actual target we're building
instead of just the first toolchain in the list (which with the addition
of -emc toolchain causes things to break).
When SOURCE_DATE_EPOCH is set, use it instead of Local::now() for the
embedded build timestamp. This enables deterministic builds via Guix,
Nix, and other reproducible build systems.
See: https://reproducible-builds.org/docs/source-date-epoch/
Design notes:
- Panics on invalid SOURCE_DATE_EPOCH rather than warn-and-fallback,
because silent fallback would produce non-reproducible output while
the user expects reproducibility. Build systems should fail loudly
on misconfiguration.
- Preserves Local::now() fallback when SOURCE_DATE_EPOCH is unset,
keeping local timezone for developer convenience during debugging.
this allows build systems that lack git state to build an image.
The effective git revision must be correctly computed by the build
system or substituted for everything to work correctly.
Note that completely faking the entry will lead to subtle problems
down the road; for example, a purpose of the revision is to check
which versions are compatible for upgrades against each other
(some upgrade paths require a hop through an older version). Faking
this can bypass the mechanism and then lead to instability down
the road.
However, some build systems (such as guix) strip out the git state,
but the revision can be safely generated in the calling environment
and passed as a variable.
Default apps for base xous configs are now eliminated - this
allows third party builds to add their apps without having to
delete the default apps used for initial testing (the upshot is
that the CI scripts elsewhere are now all modified to include the
apps I'm using to test the system; which is fine).
So now, `dabao` and `baosec` build what is a baseline set of
services that I think are expected in either platform. In the case
of dabao, apps get stuck in the detached-app area; in the case of baosec,
apps are stick in swap.
So:
`cargo xtask baosec bao-console vault2`
by default sticks the app `bao-console` and `vault2` into swap.
If you want one of these programs to go into RRAM instead, you would
specify the build like this:
`cargo xtask baosec bao-console~flash vault2`
The `~<region>` syntax indicates that the thing to the left of `~`
is the name of the app; and to the right is a region spec, one of:
[swap, flash, ram].
No checking is done that these regions are valid or even good
for placing these things, the image just tries its best to whack 'em
in there. If you blow out the size of the kernel, at least, a
warning will be emitted.
This change enables more flexible out-of-tree options for
developers who don't want to build the whole Xous kernel, but
at the moment, caveat hacker - things are still in flux and under
heavy development. I think in about 2-3 months things will settle
down enough that we'll cut a release and then the APIs should be
cleaner/more stable, but for now anyone developing with a pre-release
dabao board is recommended to either build kernel from scratch or
at least fetch the latest CI image off of the CI server if things
seem squirrelly.
also add `xous-` prefix to binaries like copy-object
this allows us to publish the tools as a package and allow
people to `cargo install` them with less chance of name space
conflicts.
baosec-lite strategy is to use the OEM board type, and then diff
off of the baosec target.
The assumption is that if you're building for a baosec-lite target,
you're committing to re-doing the bootloader from the stock bootloader
and pivoting into a full-custom baosec-lite build.
This assumption allows us to "hard code" more of the baosec-lite
differences, instead of having to leave other board options available
for a more portable firmware.
- dabao now includes debug-proc by default
- gdb-stub now passes to both kernel and user programs, so that
uart switching can be achieved
- print-panics activated in the kernel, so we can see the panic
messages. They had disappeared for a while, and didn't notice.
we've got the space - might as well.
there's about 300k of space left in the xous image after this
modification. This is starting to cut it close, so this is
the last item that makes it into the "fixed" xous image.
After some contemplation, we should include the keystore in the
core service set featured by the dabao-xous configuration.
The pros are: any compatibility/sharing of resources
that require access to RRAM, one-way counters, UUIDs, etc.
will either require a wholly separate implementation that is
"insecure" or it could just reuse the baosec work. Furthermore,
as cryptographic accelerators are laid into the keystore,
the APIs become available to the dabao environment
The cons are: more space is used in a space-constrained
dabao environment (roughly 140k "deadweight" at the start, but
as cryptographic APIs get layered in this can grow substantially);
the key slots are "used up" in part by the scheme, which leaves
less key slots available for user-defined purposes.
This is mitigated by the fact that there are a couple thousand
key slots, and so even though we use a couple hundred of them
it's still not the whole range.
Also, the baosec/dabao feature flag can be used to feature-out
cryptographic APIs/accelerators that are too obscure or not
useful for the dabao environment, to "lighten up" the
firmware load.
this ensures that a given app is not included more than once
significantly, this allows for an app to be in the default list
and also selectable from the menu and you don't end up with
two copies of it in the binary.
