[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:
> Assuming I understood you correctly, there would appear to be three 
> basic options here:
> 
> 1) Error wires that trigger some kind of hardware condition 
> (interrupt?) in the main CPU;
> 
> 2) Error status bits which the main CPU has to poll; or
> 
> 3) No error signal.

No, that is not what I intended to say and thought. If we agree is
another thing.

I'm fairly (as in very) certain that we want to be able to trigger
interrupt events in the CPU when things go bad in the FPGA. Typically
that the TRNG monitor detected that it is b0rked. There might also be
other rather important error events that we want to inerrupt the CPU for.

Now, in order to limit the number of IRQ wires from the FPGA to the CPU
and also be able to keep an event history I proposed am IRQ trigger
module in the FPGA that collects error signals from modules, stores them
and also pulls the IRQ wire to the CPU. The CPU can then find out what
error event it was in the FPGA that triggered the IRQ and take
appropriate action.

We could have no IRQ, but then SW would have to read status in each
module very often and esp both before and after doing anything in the
FPGA. There are also probable race conditions lurking with a setup lile
this.

The second issue is if we should also flag for impproper use of the API,
which is what the error signal in the modules implement today.


> Interrupt handlers are tricky; in practice, the safest thing to do
> in an interrupt handler is usually just to set a status bit.  There
> are situations where a hardware interrupt is the right answer, but
> just signalling a condition to software that has to poll for other 
> conditions anyway is probably not one of them.

Not sure. It is how IRQs I see it in embedded space are done. Either you
have a single point of entry in the vector table and the code then looks
at status to determine what specific event it was. Or you have multiple
vectors and which one is triggered by the specific IRQ number.


> So my preference, if we're trying to signal errors from FPGA to CPU, 
> would be option (2).  We already have a status word with READY and 
> VALID bits as part of the standard core API, I'd just add an ERROR
> bit to that word (or bits, if we want to have actual codes instead of
> just a single flag).  Software would have to poll for this, but we
> have to poll for status after most operations anyway, so this isn't a
> change.
> 
> Have I missed anything here?

That things can go bump in the dark between usages of cores since they
have a life of their own. And some of those events you should probably
be able to react to as soon as possible.

- -- 
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/

iQIcBAEBCAAGBQJWC+Q3AAoJEF3cfFQkIuyNhWgQALvUp8Kixg+P/9K9doqD1soa
KWHNW1yhZXGMbhtJLFXIx7n5cvYFNvghN/5wQTtAPrqR59uSUmfJgbnqVqEWBG+9
zC/njKyPd3cAEYpSruZbydkeR4Qi9376B03plJ22tZDitwzFfO/jyxz2s4k0TUzB
TA1X9I/cMLHjvo5FcFtxsyOkNgmIgtwxXvXxo0fNUUGlCmWodNfv5Hr+SxjxPIL7
QoRe/rHFqBD9zVemTHApwO5Etf+CSqXuYPdgTT1ikDWxuyK7i7bwFfVRCYikcwjN
G1qdCr6HRXgiL05soOLik0IMN7JOP9f5h6Q1TmCuwcUwBbqaIjFGFH41+alk2Lx5
Y+iYwI0Bf6uMITMaI3vnSw4N9CSRpJIj+cmmgH42ZAHEvRNtxNCqV9uaEKikcfSr
QnVsec0e607naY3z6+rvQ4wqzNZAGq+DQd1FxuoWq01SLfLTSnrdc77JGIFNp6Mu
3GjjmudMSfHOvhCaLhI0ZbCnnBwh/lU2IPWQiXVghHU86vQNEG6kRBt2RoLtJ6nb
T4qSTUJnlFE7AqvNyCrZTThEU+JZv45T5TA8+fx5tmIEMf9s2+ZavRKgXWjCy+yD
aLDhBeafkDFw0qcHdWJjIqLW5OVObKSwBfZwy667kpXDE1xqw4kf4HtHotYaNwqY
AOjoJFbVRrX12qRSmLsN
=booM
-----END PGP SIGNATURE-----