Subject: Re: Please review design of Security Engine driver for Au1550
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Shigeyuki Fukushima <shige@netbsd.org>
List: port-evbmips
Date: 03/10/2006 18:51:10
Thank you for your reply.
Garrett D'Amore wrote:
> You're jumping ahead of me now -- I was planning on implementing this
> myself. :-) A few considerations:
>
> 1) This is a SafeNet core. It might be a good idea to see if we can use
> a common safenet driver and au1550 specific attachment code.
> (safenet_aubus.c and safenet_pci.c?)
There is already a device entry 'aucrypto' in
sys/arch/mips/alchemy/au1550.c.
Is 'safenet' preferred rather that 'aucrypto'?
> 2) OpenCrypto is definitely the right way to go.
Ok. I think so.
> 3) The RNG code should be a part. I was going to write the RNG code
> last weekend but got caught up. The "rnd" framework really needs some
> enhancements so that we can register a callback routine where the rnd
> framework can poll for entropy. This was the topic of a long discussion
> off-list last week. :-) I've promised to do this, I just haven't got to
> it yet.
Humm..
A memory map for RNG is in the middle area of Security Engine
memory map.
In my Attachment code, allocating memory map from 0x0000 to 0x07ff.
A plan of implementation an OpenCrypto device and an RNG device of
Au1550 is either plan1 or plan2 (following):
plan 1: split implementation
opencrypto device:
allocate two bus_space_map 0x0000-0x00ff and 0x0200-0x07ff
rng device:
allocate one bus_space_map 0x0100-0x01ff
plan2: one implementation
opencrypto & rng device:
allocate one bus_space_map 0x0000-0x07ff
Which do you like for it?
IMHO, I like plan2-implementation.
--
Kind Regards,
--- shige
Shigeyuki Fukushima <shige@{FreeBSD,jp.FreeBSD,NetBSD}.org>