1. nonce should be generated from the LSB of the commit hash.
security doesn't come from the nonce, and having the commit hash
in the nonce is helpful for version control of the swap image
(although it doesn't capture "dirty" builds, e.g. builds
made with uncommitted changes).
2. fix IniS regions to not require special alignment. Since the
data is copied (similar to IniE), we don't have to waste space
page-aligning things so that offsets map perfectly between
the image on disk and in RAM.
3. add checks that the loading position of data inside the
swap image matches our expectations. We should have 0x1000
bytes of unencrypted header, then 0x1000 bytes of XArgs + padding,
and then image data should start.
There is a "just so" coincidence in that the image data by
the MiniElf program always lines up at an address > 0x1000, making
space for the XArgs. I actually don't know why this padding is
there, but the "section" doesn't decode to anything we
can parse. Maybe it's some reserved space for OS-specific
loader shenanigans?
Not sure how this even worked in the first place....I think we
always just got lucky with the size of .gcc_except_table. However,
something changed in the last rustc update that causes this section
to align to a 256-byte boundary instead of a 4-byte boundary, which
exposes downstream alignment issues.
This patch now captures the actual offset alignment + padding,
which is somewhat complicated by the fact that we throw away
the first section (not sure why??? it doesn't seem to have
a valid name or header, but the first 0x114 bytes are non-existent)
so we have to factor this into all the downstream padding efforts.
Make the first word in the signature block a jump past the block
this is for the cramium target, where the best memory efficiency
happens if we align the data to the bottom of the memory. This
means that the signature block ends up "in the way" of the boot
process, because the reset vector can only be configured to something
on a 16k-page boundary (e.g., we'd waste 15k of memory without this).
This will require some reworking of the existing code base for
checking signatures down the line.
Each platform interprets this differently.
On Precursor, it's the offset in FLASH of the swap region.
Probably, flags should be added to configure this somehow for each
platform, but still figuring a lot of things out.
The plan is on Cramium for the swap data to always be at 0
in the external SPI, so, we don't store an offset (field is
ignored).
This is set to 0 in the image creator, but the keying ceremony
should set this to something more secure after the device has
been initialized (and likewise, re-encrypt the swap region
to match the new, secure key).
The loader image uses the original signing method, because changing
that would require us to modify the gateware ROM, which is a huge
pain in the ass, and doesn't buy us anything.
Thus only the kernel signing uses the pre-hash method.
This requires us to modify our dependencies to have dalek-ed25519
as one of our dependencies.
Which requires another patch in this commit set to implement
sha512 for hosts, since we patch the sha2 crate for all targets
to our local version.
This patch set goes across all the toolchains and brings
in the support for split SVD descriptions of SoCs.
This is helpful for dealing with designs that have multiple
"top" files for the same core IP set. For exmaple, you may have
a SoC that you are developing that targets silicon, but
you have a version that wraps this in additional peripherals
available only in an FPGA emulator that are used for debugging.
In this case, you can have one SVD file be the description of
the SoC itself, and another SVD file describe just the "delta"
introduced by the FPGA wrapper that emulates/controls the SoC.
this somehow causes the build to break, and I just checked and
I don't see warnings on our build. There must be some config
differences on hosts, but I'm not sure what it is...
quick-xml 0.19.0, a dependency of svd2utra, uses features
that Rust will deprecate.
Unfortunately, the only versions of quick-xml that do not
use the deprecated language features also break a portion
of the API. In particular, quick-xml will no longer take
a `File` as an input: it will only take a `Path`.
This means that the API for svd2utra is also broken, because
originally it was designed to take a `File`
This patch refactors svd2utra to work with the latest quick-xml,
but also breaks any code that calls svd2utra's generate
APIs.
Fortunately this is fairly easy to fix, the calling code
will typically already have the Path somewhere in it, so
instead of opening the Path and passing it into the function,
one may simply pass in the Path.
this commit adds the facilities to extract eh_frame[_header]
sections and pass it to each process.
A bump is required to `std` to extract the passed parameters.
Sections of the MiniElf are now aligned as required by the
source ELF requirements. This is required for direct-mapping
with XIP.
the overhead is just a few bytes every couple of programs, so it's
a small price to pay for XIP.
figured out a way to modify the trait so that alignments
are 0 by default, and only set/reported for IniF,
on a per-process basis so if for some reason the alignments
change we should be OK.
Turns out, the pointing end of the stick for ELF sections don't start
at a page boundary. For example:
5 IniF: entrypoint @ 0001e42e, loaded from 000440f4. Sections:
Loaded from 000440f4 - Section .rodata 16924 bytes loading into 000100f4..00014310 flags: NONE
Loaded from 00048310 - Section .eh_frame_hdr 1772 bytes loading into 00014310..000149fc flags: NONE
Loaded from 000489fc - Section .eh_frame 6004 bytes loading into 000149fc..00016170 flags: NONE
Loaded from 0004a170 - Section .text 59876 bytes loading into 00017170..00025b54 flags: EXECUTE
Loaded from 00058b54 - Section .sdata 48 bytes loading into 00026b54..00026b84 flags: WRITE
Loaded from 00058b84 - Section .sbss 48 bytes loading into 00026b84..00026bb4 flags: WRITE | NOCOPY
Loaded from 00058bb4 - Section .bss 516 bytes loading into 00026bb8..00026dbc flags: WRITE | NOCOPY
Here you can see, the data is "loading into" 0x100f4, not
0x10000. The original PR would align things to a page, which means
you'd still have an offset mismatch if you tried to map these directly
over.
This patch causes IniF to insert extra padding to target
the offset necessary for the MiniElf to map 1:1.
An important assumption is the offset is constant across all
programs being linked. This seems to be the case, but, if this
assumption breaks, then the padding will also break.
GCC will set the text size to `0` in a certain case that `rust-lld` did
not. This causes the elf copier to add about 512 MB to the image which
it otherwise shouldn't be doing.
Add a workaround that appears to fix the issue.
Signed-off-by: Sean Cross <sean@xobs.io>
During the previous port, we only wrote the first 4096 bytes. Write the
remainder of the file to the destination.
Signed-off-by: Sean Cross <sean@xobs.io>
This experimental tool can be used to create all-in-one images based
on precomputed file lists. It generates "test images" using just the
bare minimum number of processes.
This program includes all the keys, kernel, and initial images required
to support a simple program.
Signed-off-by: Sean Cross <sean@xobs.io>
Instead of assuming everything is a file or a path, allow
loading ELF files from u8 slices. This will enable us to create
images with `include_bytes!()`.
Signed-off-by: Sean Cross <sean@xobs.io>
Move the code used to sign images into its own library file. This will
enable us to use the image signing functions from other code.
Signed-off-by: Sean Cross <sean@xobs.io>
the loader is a little funky, and requires some maintainer hand-holding
due to the split of the page ownership between the root-keys
crate and the graphics-server crate.
Improved docs so I don't forget this detail in the future.
