[lowrisc-dev] Fabrication process

Reinoud Zandijk reinoud at NetBSD.org
Fri Jan 2 08:42:42 GMT 2015

Hi folks, best wishes for 2015 :)

On Wed, Dec 31, 2014 at 09:33:39AM +0000, L.R. d S. wrote:
> >I think that it would be interesting to have insight into the process,
> >problems and solutions that you have experienced in the fabrication process
> >for lowRISC.
> As sr. McGee, I have the same think about this.
> Problems I see here: - How we can trust on crypto processor manufacturing?
> -The ROM's We will can compile everything from source and put it on ROM?
> Boads like BeagleBone have a ROM inside that can't be replaced (it's Mask
> ROM)... I hope this don't happen on lowRISC.
> -A method to make a write prottection on ROM?  If so, we can compile,
> replace ROM, and then apply the write protection. With this we can trust on
> what we run, without the preocupation with deliberate third parties ROM
> write.

If its my call, i'd opt for a (serial) FlashROM to hold the more secure
firmware parts. In my design (see my other posts) this FlashROM can only be
accessed by the Minion side, and then even only by the `master' Minion that
boots, programs and guards the other Minions; this Minion can then also
reprogram the FlashROM if allowed to. If this FlashROM is also holding the
firmware of the `master' minion then the coverage is complete. As for
mechanisms for allowing such programming think of say a hardware switch to
indicate open-for-programming or specific settings in the boot
environmenti/Hypervisor. If the boot environment is then disallowing the
(re)programming it can be seen as walling of the Minion side for tampering
until another hardware reset.

This firmware on FlashROM could also provide the boot environment and the
Hypervisor. No OS can then mess with harddiscs/SDcards/whatever to create a
compromised boot environment while still allowing it to be updated later on.

> http://www.chesworkshop.org/ches2013/presentations/CHES2013_Session4_3.pdf

This is a very scary trend yes if its that pervasive; phew... wel we could
create error-detecting/correcting logic in it but i expect that to be a bit
out-of-reach now. Better stick to software encryption for now i'd say.

With regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
Url : http://listmaster.pepperfish.net/pipermail/lowrisc-dev-lists.lowrisc.org/attachments/20150102/0b9abbb8/attachment.sig

More information about the lowrisc-dev mailing list