Add EXE monitor about tillitis-key1

[secworks]

If we could expose the instruction pointer (PC) inside the CPU core we can observe where the CPU is trying to to read instructions. We can also already observe write operations (the CS and WE flags in combination with the address).

A monitor core that exposes registers for FW (and possibly Apps themselves) to set boundary limits for execution er write operations could then simply compare the PC or the write address against the boundaries. This monitor would be very cheap in hardware to implement. And if it is not used it would also not change the behavior of the TKey compared to today.

The big question is what the proper response to an access violation should be? Reset the whole FPGA? Would that make it easier to perform warm-boot attacks? Another possible response is to force the CPU to load an instruction that hangs the CPU. Possibly then also trigger flashing of the LED.

[secworks]

The branch https://github.com/tillitis/tillitis-key1/tree/exe_monitor contains a first implementation of an execution monitor. The monitor allows SW (FW or APP) to define a region that the CPU should not fetch instructions from. SW can also set an instruction that should be returned if instructions are being fetched from that area. The monitor can be enabled by SW. (This allows SW to set up the area and proper response before the monitor starting doing its job.)

The monitor allocates 272 LCs and the design meet timing.

The monitor does not observe write operations to areas writes should not be allowed. This can be added. However the forced execution becomes trickier. Therefore we wait with this function.

Another limitation is that the monitor only works with ROM. It should of course work with the complete memory system.

[secworks]

The force jump-functionality has now been moved from ROM to top level memory system. This allows us to perform the force jump for all the whole memory space. This means that we can protect from cpu instruction access in MMIO cores. in RAM, ROM and FW_RAM.

This move increased the number of allocated LCs to 342. The design still meet timing.

[secworks]

Changed the design. Now the exe monitor will cause a trap instruction to be read by the CPU, which will cause it to hang. This simplifies the exe monitor a bit (removing the API register for the instruction). It also clearly defines what happens when the exe monitor triggers.

This simplification reduce the allocated LCs to 205, which is 136 less. Surprisingly many.

[secworks]

The exe monitor should not be possible to disable after being enabled in app mode.
The first and last addresses should not be possible to change when enabled.

[secworks]

The exe-monitor should really look at prefix bits and then just part of the address. Currently we use the complete 32-bit address.

[secworks]

There is now a change pushed that adds the fw_ram to be observed by the monitor at all times. And apps can only enable, not disable the monitor.

[secworks]

The exe monitor has been merged into main.