[Cryptech Tech] Getting sync_fmc branch to work

[Павел Шатов]

08.01.2019 15:11, Joachim Strömbergson пишет:
> Aloha!
> 

Hi,

> Pavel: Did you perform the suggested test? Any result?

yes, unfortunately waiting (for up to an hour or so) didn't help. One 
thing I've discovered is that if I run all the unit-tests with 60 MHz 
and then switch FMC clock to 90 MHz without resetting the FPGA, the 
first unit test (hal_get_random) passes, but further tests that need 
random numbers lock up. I don't know the internals of the TRNG, it looks 
like at 90 MHz entropy pool is not replenished or something like that.

> 
> Regards
> JoachimS
> 
> 
> On 2018-12-20 13:48, Joachim Strömbergson wrote:
>> Aloha!
>>
>> First: Great work. That was one blizzard of commits.
>>
>> On 2018-12-20 12:57, Pavel Shatov wrote:
>>> Now the bad news. For some reason the new bitstream (`fpga show cores'
>>> should report ECDSA version 0.20 instead of 0.11 now) fails
>>> unit-tests.py. It locks up in hal_get_random() waiting for the valid bit
>>> of CSPRNG core to go high. If I disable this test, it locks up a bit
>>> further in 'test_attribute_bloat_token_big' which calls hal_uuid_gen()
>>> which in its turn again calls hal_get_random(). If I drop FMC clock to
>>> 60 MHz (line 156 of stm-fmc.c sets the divisor: 2 is for 90 MHz, 3 is
>>> for 60 MHz), then all the tests pass just fine. This is strange because
>>> we've already seen this situation, but then we clearly had failed
>>> timing, while now everything should be fine. I haven't done any thorough
>>> investigation yet, my very preliminary guess is that maybe we need to
>>> change the number of taps in the ring oscillator entropy source or
>>> something like that. I do have a platform cable, so given hints on where
>>> to look I can try to debug, but I suggest that someone first tries to
>>> reproduce the situation, because maybe I'm doing something wrong (not
>>> pulled latest changes from Joachim, etc...)
>>
>> Strange.
>>
>> Could you try and rerun the unit-tests a while later (as in minutes)
>> without resetting the FPGA. Basically run unit-tests, see that it hangs
>> and abort. Wait a while and run unit-tests later.
>>
>> If it is the ROSC core not delivering values, and that the RNG hasn't
>> yet initalized the CSPRNG and isn't ready to deliver random values it
>> should get to that point eventually. There are timeouts for the mixer to
>> wait for entropy from the entropy providers. As long as the external
>> avalanche source is alive, the mixer will end up with enough entropy
>> words. It will just take a number of timeouts for each word that it
>> should get from the ROSC core.
>>
>>
>> _______________________________________________
>> Tech mailing list
>> Tech at cryptech.is
>> https://lists.cryptech.is/listinfo/tech
>>
> 
> 


-- 
С уважением,
Шатов Павел