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

[Basil Dolmatov]

Do not think that this interrupt stuff is necessary. 

Отправлено с iPhone

> 30 сент. 2015 г., в 16:31, Joachim Strömbergson <joachim at secworks.se> написал(а):
> 
> -----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-----
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech