- Point out licensing terms in docs.
- Add missing SPDX tags
- Update the SPDX checker to check all the files we want to check.
- Include spdx-ensure in CI.
When starting, reset the USB controller to only enable the USB CDC
endpoint and the internal command channel. If the app resets firmware,
but had differend endpoints enabled, we want to go back to a known
state.
The qemu_firmware is too large for the real hardware's 8k of ROM. The
emulator, however, has lots of ROM. Use a different linker script for
to reflect this.
Add a new syscall to enable an app to get the data left for it by the
previous app in chain.
- Change testloadapp to leave some data for the next app to read.
- Call system call with:
uint8_t next_app_data[RESET_DATA_SIZE];
syscall(TK1_SYSCALL_GET_APP_DATA, (uint32_t)next_app_data, 0, 0);
Since we want to keep the user of the timer to the device apps, remove
the use of the timer for implementing a delay when writing to flash.
Let's try without any delay what so ever, just busylooping the query
to the chip.
- Set LED color to white when firmware has initialized
- Set LED color to black when changing state to loading
- Set LED color to blue when starting testloadapp
- Update mgmt app allowed digest since testloadapp changed
Instead of using 16 byte BLAKE2s with a dummy key, use plain vanilla
unkeyed 32 byte BLAKE2s for partition checksum.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
- Rename functions, defines, et c to indicate that it's a checksum
over the partition, not necessarily a cryptographic hash digest even
though we use a version of BLAKE2s.
- Add comments describing where the checksum is stored and what it is
used for.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
When we pass pointers in system calls these pointers should point to
app RAM, not any other parts of the memory map, and especially not to
memory like FW_RAM that is only available in in a higher privilege
mode.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
Limit flash offsets passed to syscalls. Be sure to check the limits
before doing any form of calculation with the passed values.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
- Add per app flash storage
- Adds four data areas. An app can allocate an area. Once allocated
the area is tied to the CDI of the app and can only be
read/written/deallocated by the same app.
- Add two pre loaded app slots to flash
- Load an app from the first slot at boot. The app digest must match a
specific digest specified in firmware.
- Optionally load an app from the second slot
- Add a resetinfo area in FW_RAM which is used to signal an app's intent
of resetting the system and, optionally, pass data to firmware or the
next app in a bootchain.
Co-authored-by: Jonas Thörnblad <jonas@tillitis.se>
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
Co-authored-by: Daniel Jobson <jobson@tillitis.se>
From now on the canonical home of the tk1_mem.h header file describing
the memory map of the TKey lives in tkey-libs:
https://github.com/tillitis/tkey-libs
Build firmware, testfw and testapp using tkey-libs:
https://github.com/tillitis/tkey-libs
In an effort not to have more or less identical code maintained in two
places, use tkey-libs when developing firmware, testfw and the
firmware testapp, too.
You can place the Git directory directly under hw/application_fpga
and then an ordinary make should work.
Or build with:
make LIBDIR=/path/to/tkey-libs
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
Introduce new syscall TK1_SYSCALL_GET_VIDPID to get Vendor ID and
Product ID from the protected Unique Device Identification number.
UDI is protected from device apps to protect the serial number, so
apps won't know the exact TKey they are running on other than the CDI.
It may, however, be important to know what *kind* of TKey they are
running on, so we want to expose the Vendor ID and Product ID.
- fpga: Allow UDI to be read when doing syscalls.
- Add the new syscall to firmware.
- Add test to testapp directly after negative test of reading UDI to
read out VID/PID through a syscall.
Since the introduction of the syscall mechanism we don't allow
execution in ROM anymore so it's impossible to call the firmware's
blake2s() function.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
In order to be able to leave data for firmware signalling the
intention with a reset or to leave data for the next app in a chain of
apps, we introduce a part of FW_RAM that can be used to store this
data. In order to do this, we:
- Change size of ROM from 6 KB to 8 KB.
- Change size of FW_RAM, from 2 KB to 4 KB.
- Add RESETINFO memory partition inside FW_RAM.
- Add generation of map file.
- Change CFLAGS from using -O2 to using -Os.
- Update address ranges for valid access to ROM and FW_RAM.
- Move stack to be located before data+bss and the RESETINFO data
above them. This also means we introduce hardware stack overflow
protection through the Security Monitor.
- Revise firmware README to the new use of FW_RAM.
Throwing away mode and length from incoming data. Adding mode and
length to outgoing data.
Splitting responses into frames small enough for the USB<->UART
transceiver to handle.
- The API changes name from `_SWITCH_APP` to `_SYSTEM_MODE_CTRL`.
- The registers and wires changes name to `system_mode_*`, instead of a
mix of `switch_app_*` and `fw_app_mode`.
- Remove the define `NOCONSOLE`, add define `QEMU_CONSOLE`
- Inverse the use of it, add the define to have QEMU debug output in fw.
- Add a make target `qemu_firmware.elf` which builds the firmware with
QEMU console enabled.
Co-authored-by: Mikael Ågren <mikael@tillitis.se>
Update:
- README
- testbench
- Symbolic names and variables in fw
- registers
- port name and wires
- Update fpga and fw digests
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
The RAM address and data scrambling API was called twice, once before filling
RAM with random values, and once after. Since moving to a significantly
better PRNG (xorwow) this is now deemed unnecessary. See issue #225.
This changes both FPGA and firmware hashes.
Modify the loop to zeroise the FW-RAM instead of the
RAM. RAM is filled with random data at the start of main().
Changes firmware and bitstream digests.
Signed-off-by: Joachim Strömbergson <joachim@assured.se>
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>
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.
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.
