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

[Pavel Shatov]

On 29.09.2015 15:12, Rob Austein wrote:
> At Tue, 29 Sep 2015 09:50:56 +0200, Joachim Strömbergson wrote:
>>
>> We could fix this in TRNG instead.
>
> Indeed.
>
> Sorry, I should have provided some explanation, but it was late, and
> having finally gotten something that mostly worked, I wanted to push
> code to the public repository so that Paul could have a look at it.
>
> While blundering around here I stumbled across a few a few other minor
> things that it'd be nice to clean up (none of this specific to the
> TRNG, and none of it intended to pick on any particular author, just
> notes from someone trying to understand what we've built so far):
>
> - Some cores do reset high, some do reset low.  Why?  Is one better?
>    Perhaps we should just pick one and be consistent?

Oh, we've already had a *huge* discussion on that topic. This all ended 
up nowhere, can we just not start this all over once again, please?

Active-high vs. active-low and sync vs. async reset is more of a 
religion for most people. My personal view is that internal reset 
signals must be sync and active-high. I think, I've already explained why.

I believe, there are three possible solutions.

1) Just leave everything as it is right now with mixed resets.

2) We start a voting process and decide, what kind of reset we will be 
using from now on. Everyone will then modify his cores accordingly.

3) Someone will take responsibility and decide for the whole team, what 
kind of reset is the right one for us. Again everyone will then modify 
his cores accordingly.

> - Most cores have debug wires, a few don't.  Why?  Should the few that
>    don't need them be changed to have them and just ground internally?

Errr, I think, that adding dummy debug signals to cores, that don't 
actually need them, is not the right decision. What are those debug 
wires used for? Are they actually being used anywhere?

> - "modexps6_wrapper" should be "modexps6" according to the naming
>    scheme that all the other cores follow.

Maybe.

> None of these are show-stoppers.  Just trying to reduce the number of
> cases down to the ones that have some serious purpose, in a (perhaps
> futile) attempt to make the build system more comprehensible.
>
> There's one other small issue that affects not just the build-time
> Python code but also the runtime C code:
>
> - Right now the C code has to guess how much bus address space each
>    core consumes in order to probe for cores.  This is nasty and
>    fragile.
>
>    Perhaps there should be a fourth word in each core header (just
>    after the two words of core name and one word of core version)
>    telling the C code how much bus address space each core consumes.
>    For most of the current cores that's 0x100 words, for modexps6 it's
>    0x400 words, and it'll probably be something larger than 0x100 for
>    the EC cores (for the same reason as for modexps6: large arguments).
>
>    Having an explicit length would also give us a way to skip over
>    holes in the bus address space (as with the current TRNG MUX) if for
>    any reason we can't just fix them.
>
>    Alert readers will notice that having a length word in the core
>    header doesn't help the build-time Python script, but we can handle
>    that in the build-time configuration file.  Solving this for the
>    runtime code is a much higher priority,
>
>    We could of course just generate a static address map for the C code
>    at build time, but that has its own form of fragility (tighter
>    coupling between rtl and sw than would otherwise be necessary).
>
> Last: it's not obvious to me that this dynamic configuration mechanism
> really belongs in core/platform/novena, it seems likely to end up
> being more general than that.  My guess is that it's in
> core/platform/novena because that's where the Makefiles are, but I
> suspect we'll end up moving it, eg, to core/platform/common.
>
>> What I would like is to reserve space for one more entropy source (the
>> feedback from the output of the CSPRNG.). But besides that, we could
>> compress the address space.
>
> That'd be fine.
>
> BTW, I'm assuming that we do want to keep the TRNG's internal MUX.
> I'm fine with the answer to that being "yes, we want to keep that",
> it's just that sometimes the easiest way to confirm something is to
> ask a silly question. :)
>
>> Lets just decide on it and fix.
>
> Cool.  Thanks!
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech
>


-- 
With best regards,
Pavel Shatov