[Cryptech Tech] [Cryptech-Commits] [core/platform/novena] 21/21: Sick hacks to compensate for sparse MUX within TRNG core.

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Rob Austein wrote:
> Sorry, that should have been "error wires", not "debug wires".
> 
> Most of the cores have a single wire port named "error", which feeds 
> into core_selector's sys_error output wire via the sys_error_mux 
> register.  ModExp and ModExpS6 don't have error ports, so the old 
> math_selector.v code explicitly zeros sys_error_mux to compensate.
> 
> Without claiming to understand the internal details of these cores,
> it seems a bit improbable that two of the most complex cores we have
> are the only ones that never encounter any error conditions.

The error signal is from me and is/was part of the core api. The purpose
of the error signal is to allow a core to signal a caller that the api
operation attempted breaks the api. Things like writing to a read only
register or trying to access an address that is undefined in the core
address space.

On the Novena we have little abilities to signal back to the CPU that
these things happen and we have therefore ignored these signals. On the
Alpha board we have penned specific wires to allow the FPGA to trigger
interrupts in the MCU.

For some cores, esp the TRNG with on-line monitoring we will need to
have at least one error signal out from the TRNG core. modexp(6), ec,
key wrapping, master key interface etc might also have detection of
erroneous internal states, events that should be flagged to the MCU for
proper handling (whatever that means.)

The question is if we should use the same error signal as the one in the
api, or separate error signals from the block for these events? Also, do
we really care about improper API usage? I used to think so, and it
makes the API more robust, it is also a very simple function inside the
cores.

One small core we probably need to add is an event handler that can
detect error signals from different cores inside the FPGA, signal the
MCU and keep track of which of the cores that had problems.) When
something happens, SW can read out info about which core it was from the
handler. This allows us to also capture several events from cores.

Other solutions is to have separate wires for all cores to the MCU or
just ORing them together and then have SW probing status in the
different cores to figure out which one it was that needed help.

What solution would you prefer Rob?

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJWC5j0AAoJEF3cfFQkIuyN5iAQAKxIIDHl2tLVnQFXZgZsdaZd
VYqc9GBGLSUrsSvq8uG0l47CBBIgS3dI8qWwLTxZNY9kZapyxUgbLY5Fubrhk4oG
W8AzBjjxBHnIuPJIiqLuVkBiVGxNkhVdAfJib1ZUai4OUH2oi41/Ty8XkaN9oBmL
rPO3prEQ4tlwyfSaWz10KC72CIj3nL/jXbufjGBYBVo2rTm/QoBnIu3EQbxX2mjE
bphQStStXluClKYwLh1b2cY05/Hbq6Ssq8ILu4qheLnLTVvyP2YqC/x/+qKKTeZG
M82xVkv83MlSAV2xjzqOLVQaYYUuKZCxYOwsgrIVk4xHMMJlN2HpKyTPJMX0WSVy
tyM+P94DTGdEn4JW5S/eTwL5gIolvSDWTwqlNfqVtTIiLilbxSHCWFYfhJ+WyeUp
QaLr++Bup1VS865ES0Ywpvtg5kktb4l6XNfWsRJI+klnAf94oG2Ex7Udbu29nmKi
9n4K9vJQ71EeCs6qTxI+9dNJK8Y9qxO3LDJ+OwebaNZTAKQDShT+FG1CC7Zk8paq
znmcYHMie+afLnXeWiENIp6kyXl6RXKWLgNIxtifT3oQpZo+zXRrYqLkpwaK2zr/
6PnLE9zHqhbfYBWcX/eKRIsYcf5H+0FkCneUD8A+ve0ghEJZZjeQlJ/EPL2Uwvz1
YeQYu/7KpwzeLUByDnMy
=cE73
-----END PGP SIGNATURE-----