Hi:
[CRYPTO] api: Allow replacement when registering new algorithms
We already allow asynchronous removal of existing algorithm modules. By
allowing the replacement of existing algorithms, we can replace algorithms
without having to wait for for all existing users to complete.
Signed-off-by: He
Hi:
[CRYPTO] api: Removed const from cra_name/cra_driver_name
We do need to change these names now and even more so in future with
instantiated algorithms. So let's stop lying to the compiler and get
rid of the const modifiers.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Op
Hi:
[CRYPTO] api: Added cra_init/cra_exit
This patch adds the hooks cra_init/cra_exit which are called during a tfm's
construction and destruction respectively. This will be used by the instances
to allocate child tfm's.
For now this lets us get rid of the coa_init/coa_exit functions which are
On Wed, May 24, 2006 at 12:19:21PM +1200, Michal Ludvig wrote:
>
> Have you got any pointers to the source? Which parts of kernel do this,
> where can I learn about it? Or at least some keywords that I can grep
> for ;-)
Checkout include/asm-i386/uaccess.h and arch/i386/lib/getuser.S.
Cheers,
--
Herbert Xu wrote:
> On Wed, May 24, 2006 at 11:31:41AM +1200, Michal Ludvig wrote:
>> Can we safely handle these pagefaults in the atomic context? Or is it a
>> nonsense?
>
> It should work. You need to setup an exception table to trap the
> fault.
Have you got any pointers to the source? Which
On Wed, May 24, 2006 at 11:31:41AM +1200, Michal Ludvig wrote:
>
> Lots of troubles with the fallback thing, isn't it?
It is pretty ugly.
> Is it possible to implement in the kernel the approach with arbitrary
> page faults that I did in phe_sum
> (http://www.logix.cz/michal/devel/padlock/phe_su
Herbert Xu wrote:
> On Mon, May 22, 2006 at 03:38:36PM +1200, Michal Ludvig wrote:
>> +static void padlock_sha_init(struct crypto_tfm *tfm)
>> +{
>> +CTX(tfm)->used = 0;
>> +CTX(tfm)->bypass = 0;
>> +CTX(tfm)->data = (char*)__get_free_page(GFP_KERNEL);
>> +if (!CTX(tfm)->data)
>> +
The Hog wrote:
> I have read some docs about dm-crypt and the crypto-api. It seems that the
> crypto stuff is added to the kernel since 2.6.4. A possibility thus would be
> to use an older kernel that does not contain the crypto stuff. Will a 2.4
> kernel do, or does that also contain crypto algo's
Hi Evgeniy,
Just interested in the results you are getting below for
comparison to what I see under OCF with Openswan.
What sort of hifn card were you using in the test below,
was it a 7956 PCIX (ie., 64bit?)
How did you measure the throughput ?
I can post the OCF numbers, but it doesn't mea
Jivin The Hog lays it down ...
>
> I have read some docs about dm-crypt and the crypto-api. It seems that the
> crypto stuff is added to the kernel since 2.6.4. A possibility thus would be
> to use an older kernel that does not contain the crypto stuff. Will a 2.4
> kernel do, or does that also c
I have read some docs about dm-crypt and the crypto-api. It seems that the
crypto stuff is added to the kernel since 2.6.4. A possibility thus would be
to use an older kernel that does not contain the crypto stuff. Will a 2.4
kernel do, or does that also contain crypto algo's?
As I recall, the De
- Oorspronkelijk bericht -
From: Andy Gay <[EMAIL PROTECTED]>
> On Tue, 2006-05-23 at 19:18 +0200, The Hog wrote:
> > Hi,
> >
> > I have ben told that the Linux kernel contains cryptographic code in many
> > places. U.S. export restrictions forbid to export software that contains
> > cryp
On Tue, 2006-05-23 at 19:18 +0200, The Hog wrote:
> Hi,
>
> I have ben told that the Linux kernel contains cryptographic code in many
> places. U.S. export restrictions forbid to export software that contains
> cryptographic code to certain countries, such as Iran. This also applies to
> the Linux
On Tue, May 23, 2006 at 08:37:07PM +0200, The Hog ([EMAIL PROTECTED]) wrote:
> > > Would it be possible to build a kernel that does not contain cryptographic
> > > algorithms? I understand that several cryptographic options can be
> disabled
> > > through "make menuconfig". But, will that be enough
> > Would it be possible to build a kernel that does not contain cryptographic
> > algorithms? I understand that several cryptographic options can be
disabled
> > through "make menuconfig". But, will that be enough or are there crypto
> > routines in the kernel that cannot be removed?
>
> Disable
On Tue, May 23, 2006 at 07:18:50PM +0200, The Hog ([EMAIL PROTECTED]) wrote:
> Hi,
>
> I have ben told that the Linux kernel contains cryptographic code in many
> places. U.S. export restrictions forbid to export software that contains
> cryptographic code to certain countries, such as Iran. This
Hi,
I have ben told that the Linux kernel contains cryptographic code in many
places. U.S. export restrictions forbid to export software that contains
cryptographic code to certain countries, such as Iran. This also applies to
the Linux kernel.
Would it be possible to build a kernel that does not
On Mon, May 22, 2006 at 03:38:36PM +1200, Michal Ludvig wrote:
>
> +static void padlock_sha_init(struct crypto_tfm *tfm)
> +{
> + CTX(tfm)->used = 0;
> + CTX(tfm)->bypass = 0;
> + CTX(tfm)->data = (char*)__get_free_page(GFP_KERNEL);
> + if (!CTX(tfm)->data)
> + padlock_s
18 matches
Mail list logo
