i feel a little more comfortable with this because there are
checks that *any* key in that slot would be treated as a devkey
and would lead to key erasure. so just in case i messed up
something in the other checks, this would trigger a key erasure.
I think there is no way around signing at least a beta image
containing the third party keys if i truly want to check all
the paths, so trying to isolate what it can do is important.
by doing this we make this safer by ensuring that the public
keys are valid public keys, allowing us to sign these images
with production keys and not accidentally signing a weak
public key.
This just populates a pubkey block with random data, simulating
a third party firmware. A fake pubkey block can't boot anything
else because we can't sign a firmware that matches that. But,
it's also good enough to be able to test collateral key states.
for out of tree builds, we'll just stick with the default code
of '1': if you're doing a build out of tree, it's assumed that
you don't care about security (not tying your application to
a given OS version opens up an attack surface; presumably if
you're doing something security-critical, the extra hundred
megabytes to clone the xous-core repo isn't a big deal? but
if you're just trying to blink some LEDs you really don't care
about the anti-rollback feature).
this forces the semver to nil so that we don't get errors in
a signing routine that lacks access to versioning.
The upshot is that out of tree apps have no version assigned
to them, and they can't be checked for version compatibility.
The problem is that this feature, while neat, pulls in a huge
amount of code into the SBOM, a lot of which looks pretty scary,
and we're also including the ability to hit the network in the
build system which is also scary and potentially full of software
supply chain exploits.
So, while it would be "neat" to have the system be "smart enough"
to guess a semver based on a git rev of xous-core without having
to pull down tags or clone the full repo, the cost is a huge amount
of tooling and code and trusting a very large attack surface to
also not use the same mechanism to exfiltrate your keys, hack
your computer, or otherwise cause abuse.
For such a minor feature, I think this risk is not worth it.
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.
The developer function was decided to be overly-broad: the
issue is you could slot that in to *any* boot position and
it'd be accepted, and we already have a mechanism to deal
with developer mode (developer-signed images). Thus eliminate
the extra case and simplify the code base to reduce
potential bugs.
have to absorb a version change due to xous-semver change
might as well also update the utra/svd generator dependencies
since that's been held off for a long time now.
the data section is generally pretty small, a few k, and there
are cases where we need more initialization entries. This keeps
the structure from growing beyond 256 bytes.
The code base had evolved through several code names, interim
names, company names and chip names that alternatively did or did
not exist.
Baochip is the definitive name of the company, and the Baochip1x
(full part number BAO1X2S4F-WA) is the definitivey part number of
the SoC. For convenience, the part number is shortened to 'bao1x'
in most feature flags and variable references.
This commit fixes all of the odd names and removes some unmaintained
early targets.
