[Cryptech Core] Proposal for new FPGA architecture

Joachim Strömbergson joachim at assured.se
Tue Oct 30 15:25:37 UTC 2018


Aloha!

On 2018-10-30 15:57, Peter Stuge wrote:
> Joachim Strömbergson wrote:
>> What I propose is to add API functionality to the core selector that
>> would expose a DMA mechanism with from-to copy functionality to the MCU.
> 
> Do you mean DMA only within the FPGA, between different cores?

For starters between the FPGA memory (described in my posting) and the
different cores. One could consider having the DMA do transfers between
cores to to elliminate core-buffer-core operations. But I want to do
this in small steps.

> Maybe, but I think this does require core_selector to change a fair
> bit beyond just the DMA API, because it will also have to deal with SW
> commands that conflict with ongoing DMA operations. Rife for races.

I'm pretty confident that the changes to the core selecor would fall
under "a little bit" category. And the important issue is thar it would
be the only core that would have to change.

Regarding the races - that is what the MUX is for. SW can check if DMA
operation has completed and if so will have access to the other cores.
If the DMA i busy, access to the other cores are simply blocked.


> Why would the contents be exposed to the outside? Isn't the point of
> a DMA engine in the FPGA to keep everything within the FPGA?

No, the point is to to make it possible to keep everything within the
FPGA. Not to ensure that SW can't access everything. At least not for
starters.


> Operations that may write to SW-accessible memory could be whitelisted,
> with no key-disclosing operations on that list.

Whitelisting in HW you mean? Possibly, that is a thing we might want to
explore. But then you start moving some sense semantic intelligence to
the HW.


>> Today it is generated by a python program based on the core
>> configuration. This generator would have to be modified and possibly be
>> a bit more complicated to include its own API. implement a MUX that can
>> be controlled by the DMA engine. And instantiate the the buffer memory
>> and the DMA engine.
> 
> Why the MUX and buffer memory?
> 
> How about core_selector simply keeping track of what core is busy,
> and either stalling or NAKing requests to that core?

Stalling as in buffering? NAKing is what the DMA busy status would
indicate. Note that right now the "error" api signal, which is present
in all core APIs is not sent to the MCU.


-- 
Med vänlig hälsning, Yours

Joachim Strömbergson
========================================================================
                               Assured AB
========================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cryptech.is/archives/core/attachments/20181030/af823052/attachment.sig>


More information about the Core mailing list