Darren J Moffat wrote:
> I've created a Mercurial workspace for the VIA Padlock work.
>
> At the moment this is an empty workspace since I don't know if David
> has done his work standalone or inside a clone of ON. Ultimately it
> would be highly desirable to integrate this into ON but I'll leave it
> to David to push what he has in what ever form it is first.
>
> The repository is:
>
> ssh://hg.opensolaris.org/hg/crypto/padlock
>
> To pull from it you can do that anonymously like this:
>
> $ hg clone ssh://anon at hg.opensolaris.org/hg/crypto/padlock mypadlockws
>
> To push you need to be a listed as a crypto project leader or an
> explicit committer for this repository. To be a committer if you are
> not already a project leader you first have to mark yourself as an
> observer or the crypto project. Once you have done that mail this
> list and one of the project leaders will update the permissions to
> give you commit access.
>
> I've already marked Derrick and Garrett as committers for this
> repository.
>
I'm looking at this work so far, and I am wondering about the
synchronous nature of the implementation. More specifically, I know
that the dca drivers runs completely asynchronously, waiting for jobs to
be handled off-chip. This allows other threads to run synchronously.
I think the software provider cannot do this, so it registers with
CRYPTO_SW_PROVIDER. This ultimately changes the scheduling properties,
such that crypto requests are dispatched onto a separate thread for
processing. (Look at kcf_sched.c.)
The padlock crypto engine has properties of being hardware, but it has
one substantial software property. That property is that the crypto
runs synchronous to the thread submitting the job. I think this could
have some undesirable effects for some things. (Think transmit side
IPsec, for example.)
There are a couple of approaches we could use to solve this problem:
1) use CRYPTO_SW_PROVIDER, and "replace" the default software
providers. (Perhaps via some as-yet-unknown ELF/kernel loader magic,
sort of the way sparcv9 or platform specific modules, etc are handled.)
At some level, this would be the most logic way of handling this, but it
requires some special handling outside of the crypto framework. (I'd
really love to see a new ISA defined for these CPUs, ala sparcv9b, etc.
Think "via686[abc]")
2) use CRYPTO_HW_PROVIDER, but provide a separate taskq to provide
asynchronous scheduling semantics. This potentially increases the
overhead of using the hw provider.
3) create a new crypto provider class for CRYPTO_CPU_PROVIDER or
somesuch, that indicates that we should receive higher priority
scheduling than CRYPTO_SW_PROVIDER, but that we should also be assumed
to run synchronously like a normal software provider.
Those are the approaches I can think of. Thoughts?
-- Garrett
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
