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 figu
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 fe
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
obsole
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
H. Peter Anvin wrote:
> However, the big issue with this is that it's recursive... what
causes this to
> be invoked... probably an interrupt, which is going to have been
> invoked by a timer, quite possible the TSC deadline timer. Oops.
I was assuming that drivers, responding to an interrupt fr
Venkatesh Pallipadi wrote:
On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson wrote:
TSC is high enough resolution that we can use its low-order byte to
stir new data into the random number generator entropy pool.
From what I vaguely remember from years past, rdtsc, especially last
few bits of
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
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
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 broke
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, memo
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 looki
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
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
b
13 matches
Mail list logo
