xorwow provides significantly better random data, compared to previously
used function. Making it harder to predict what data RAM is filled with.
It adds a startup time of approx 80 ms, but can be compensated with
optimising other parts of the startup routine.
This changes both firmware and fpga hashes.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
Add simultion models of udi_rom and sb_rbga_drv
to lint-top target.
Add ignore statements in tb_sb_rgba_drv to silence
Verilator on parameters and signals not used in
the sim model.
Use RGBLEDEN in simulation model
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
- Gives a better overview of CI and the different checks, without going
into the logs too deeply.
- Cache: use a unique key for each run, and remove 'restore key' since it
could potentially retrieve the wrong bitstream. The stragegy should be
to fail if a cache is not present, not fetch a bitstream from a
different build.
Describe how the UDI and UDS are actually stored in the FPGA, how they
are accessed, and how they are initialled by the patch_uds_udi.py
script.
Co-authored-by: Joachim Strömbergson <joachim@assured.se>
The memset() responsible for the zeroisation of the secure_ctx under
the compute_cdi() function in FW's main.c, was optimised away by the
compiler. Instead of using memset(), secure_wipe() is introduced
which uses a volatile keyword to prevent the compiler to try to
optimise it. Secure_wipe() is now used on all locations handling
removal of sensitive data.
- Exclude splint from CI, so we make another target for it "splint",
which we might include in the "check" target later.
- Move the analysis runs earlier in CI so they, including indentation
checks, fail first.
- Include printouts of hashen in check-binary-hashes to easier see
what the digest are if it fails in CI.
By patching the UDS and UDI into an already built bitstream, it is now
not necessary to rebuild the entire build flow when changing the UDS
and the UDI. This lowers re-build times significantly.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
Change name of cpu_monitor to security_monitor and increase its
functionality to include RAM access violations. If addresses in RAM
but outside of physical RAM is accessed in any way the
security_monitor traps the CPU in the same way as it already did for
execution violations.
The testbenches live in their own Makefiles under
hw/application_fpga/core/*/toolruns (except picorv32). Let's add a
top-level target to build and run them.
In order to run core testbenches, use
cd hw/application_fpga
make tb
or if using Podman:
cd contrib
make run-tb
to run the same target in a container.
Use _RAM_ADDR_RAND instead of _RAM_ASLR since this is not OS-level
ASLR we're talking about. It's address randomization as seen from
outside of the CPU, not from the process running inside it. Ordinary
ASLR is visible from the CPU.
This file is also included in at least qemu (GPL-2.0-or-later) besides
tillitis-key1 (GPL-2.0-only) and tkey-libs (GPL-2.0-only) so it's
licensed as GPL v2 or later even if the rest of the project is -only.
Instead of putting memory constant into an enum we use defines.
Use the direct memory address instead of ORing constants together to
compute the address.
An enum in ISO C is a signed int. Some of are memory addresses are to
large to fit in a signed int. This is not a problem since we're not
using ISO C (-std=gnu99) but it doesn't look very nice if you turn on
pedantic warnings. Also, if someone would use another compiler which
at least supports the inline assembly we use, but possible not other
GNU extensions, things would probably break.
Instead of putting memory constant into an enum we use defines.
Use the direct memory address instead of ORing constants together to
compute the address.
An enum in ISO C is a signed int. Some of are memory addresses are to
large to fit in a signed int. This is not a problem since we're not
using ISO C (-std=gnu99) but it doesn't look very nice if you turn on
pedantic warnings. Also, if someone would use another compiler which
at least supports the inline assembly we use, but possible not other
GNU extensions, things would probably break.
