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

[Rob Austein]

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?

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

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

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!