Is this the right place to ask questions about writing a Linux device
driver to make some crypto hardware on an ARM SoC work under the Linux
crypto API?
I have some hardware documentation that I don't yet know whether I can
talk about (I know, if I can't then the driver will have difficulty
Tobias Karnat wrote:
In case it is based on TI OMAP, there are already drivers available:
No, unfortunately, it isn't.
-kb, the Kent who has looked through the existing crypto drivers to
learn how they work, and who would have loved to have found one that
matched his hardware.
--
To
Hardware crypto drivers all seem to have encryption modes, but
aes-generic.c does not. But it must. What is the mode of
aes-generic.c? ECB seems the most bare-bones...but if it is ECB, why
not say so?
Thanks,
-kb the Kent who is trying to get some new crypto hardware working and
is
In struct shash_alg what are the various sizes for? (WOuld be cool to
know what everything is for in those alg structures...)
My most recent discovery is that if I want to do an shash_desc_ctx() and
use the result, cra_ctxsize doesn't seem to mean a thing. Rather,
unless I set descsize,
Does HW acceleration of IPSEC work? I am trying to get it working on
some new hardware, and for comparison I tried it on a Sheevaplug,
various Linus kernels from 2.6.35 to 2.6.39. All fail. I reboot and
rmmod mv_cesa and it IPSEC works on all of them.
Is the kernel broken? Is mv_cesa
Kent Borg wrote:
Does HW acceleration of IPSEC work?
[...sounds of crickets...]
Let me re-phrase the question.
Should loading a crypto module (in this case mv_cesa in a Sheevaplug)
cause IPSec to break? (Is the crypto system wired up with IPSec? Does
that wiring work?)
Thanks,
-kb
Herbert Xu wrote:
Since your IPsec is actually breaking, then mv_cesa is probably
getting used.
Yes, that makes sense.
Did you compile in the self-test suite (unset
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS)?
I have it unset, and /proc/crypto is reporting all tests as passed for
mv_cesa. (My
H. Peter Anvin wrote:
Those already are doing this.
They used to via IRQF_SAMPLE_RANDOM, but these are being removed
(according to Documentation/feature-removal-schedule.txt). In 2.6.39 I
can only find 10 remaining instances, out of many more network drivers.
The alternative is supposed to
Matt Mackall wrote:
Kent Borg wrote:
So network entropy is being eradicated, and nothing is being done to
replace it.
Nothing is being done is a more accurate summary of the situation.
So the feature-removal-schedule.txt entry about IRQF_SAMPLE_RANDOM is
obsolete?
(Then the trend from
Matt Mackall wrote:
[network adapters are] a great source of potential entropy, a bad
source of guaranteed entropy. The current RNG tries to do
accounting on the latter. Accounting on the former is extremely
suspect.
So we need a patch that:
- Deletes the IRQF_SAMPLE_RANDOM mention in
Herbert Xu wrote:
If that works then it's probably a bug in your driver, otherwise
we may have an issue in IPsec itself.
I think I found my bug. I discovered DMA_API_DEBUG, and it complains
when my sha1 module loads. Looking it over it seems I can't do DMA from
an shash, I will have to
11 matches
Mail list logo
