On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Wed, Jun 10, 2020 at 08:02:23AM -0400, Mikulas Patocka wrote:
> >
> > Yes, fixing the drivers would be the best - but you can hardly find any
> > person who has all the crypto hardware and who is willing to rewrite all
> > the drivers for it.
>
> W
On Wed, Jun 10, 2020 at 08:02:23AM -0400, Mikulas Patocka wrote:
>
> Yes, fixing the drivers would be the best - but you can hardly find any
> person who has all the crypto hardware and who is willing to rewrite all
> the drivers for it.
We don't have to rewrite them straight away. We could mar
On Wed, 10 Jun 2020, Herbert Xu wrote:
> On Tue, Jun 09, 2020 at 01:11:05PM -0400, Mikulas Patocka wrote:
> >
> > Do you have another idea how to solve this problem?
>
> I think the better approach would be to modify the drivers to not
> allocate any memory. In general, any memory needed by t
On Tue, Jun 09, 2020 at 01:11:05PM -0400, Mikulas Patocka wrote:
>
> Do you have another idea how to solve this problem?
I think the better approach would be to modify the drivers to not
allocate any memory. In general, any memory needed by the driver
to fulfil a request *should* be allocated wit
On Tue, Jul 30, 2019 at 04:51:15PM +, Pascal Van Leeuwen wrote:
> Hi,
>
> Quick question about skcipher algorithms supporting only
> a single keysize, i.e. having min_keysize = max_keysize:
>
> Do I need to do a key size check here or does the crypto
> API already ensure the key size is betwe
On Mon, Apr 22, 2019 at 11:29:55AM +, Pascal Van Leeuwen wrote:
>
> Even so, for the in-place case, checking the AAD data would ensure the crypto
> implementation didn't *accidentally* corrupt it ...
Yes we probably should check it just in case some driver does
something weird with it.
Cheers
On 10/12/2017 12:49 PM, Herbert Xu wrote:
> On Thu, Oct 12, 2017 at 09:39:34AM +, Horia Geantă wrote:
>>
>> Taking ascii art from crypto API docs:
>>
>> DATA ---.
>> v
>> .init() -> .update() -> .final() ! .update() might not be called
>> ^|
On Thu, Oct 12, 2017 at 09:39:34AM +, Horia Geantă wrote:
>
> Taking ascii art from crypto API docs:
>
> DATA ---.
> v
> .init() -> .update() -> .final() ! .update() might not be called
> ^| |at all in this scenario.
>
On 10/12/2017 9:44 AM, Herbert Xu wrote:
> On Wed, Oct 11, 2017 at 12:36:11PM +, Horia Geantă wrote:
>> Hi Herbert,
>>
>> I am evaluating whether ahash implementation in caam crypto driver
>> behaves correctly.
>> One thing I've noticed is that for each ahash tfm there is support for
>> at most
On Wed, Oct 11, 2017 at 12:36:11PM +, Horia Geantă wrote:
> Hi Herbert,
>
> I am evaluating whether ahash implementation in caam crypto driver
> behaves correctly.
> One thing I've noticed is that for each ahash tfm there is support for
> at most two in-flight requests, and I would like to kno
On Wed, Apr 22, 2015 at 04:29:16PM +0930, Rusty Russell wrote:
> Herbert Xu writes:
> > Currently we're hiding mod->sig_ok under an ifdef in open code.
> > This patch adds a module_sig_ok accessor function and removes that
> > ifdef.
> >
> > Cc: Rusty Russell
> > Signed-off-by: Herbert Xu
>
Herbert Xu writes:
> Currently we're hiding mod->sig_ok under an ifdef in open code.
> This patch adds a module_sig_ok accessor function and removes that
> ifdef.
>
> Cc: Rusty Russell
> Signed-off-by: Herbert Xu
Did you want me to take this via modules-next? Assuming not.
So:
Ac
On Thu, Apr 02, 2015 at 05:13:23PM +0200, Stephan Mueller wrote:
>
> In crypto_remove_instance, the code dereferences inst->tmpl. If you say that
> it is not guaranteed that the alg is always wrapped by an inst, wouldn't we
> have a potential invalid pointer?
This particular spot is always an in
Am Donnerstag, 2. April 2015, 22:59:11 schrieb Herbert Xu:
Hi Herbert,
>On Thu, Apr 02, 2015 at 04:54:03PM +0200, Stephan Mueller wrote:
>> >@@ -316,7 +316,7 @@ static int crypto_del_alg(struct sk_buff *skb, struct
>> >nlmsghdr *nlh, if (atomic_read(&alg->cra_refcnt) != 1)
>> >
>> >re
On Thu, Apr 02, 2015 at 04:54:03PM +0200, Stephan Mueller wrote:
>
> >@@ -316,7 +316,7 @@ static int crypto_del_alg(struct sk_buff *skb, struct
> >nlmsghdr *nlh, if (atomic_read(&alg->cra_refcnt) != 1)
> > return -EBUSY;
> >
> >-return crypto_unregister_instance(alg);
> >+return
Am Donnerstag, 2. April 2015, 22:39:40 schrieb Herbert Xu:
Hi Herbert,
>This patch makes crypto_unregister_instance take a crypto_instance
>instead of a crypto_alg. This allows us to remove a duplicate
>CRYPTO_ALG_INSTANCE check in crypto_unregister_instance.
>
>Signed-off-by: Herbert Xu
>
>dif
On Wed, Jun 16, 2010 at 3:43 PM, Dmitry Kasatkin
wrote:
> Hi,
>
> BTW.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
>
> Has this kernel anything about cryptodev as well?
>
> Thanks,
> - Dmitry
>
> On 15/06/10 19:24, ext Nikos Mavrogiannopoulos wrote:
>> Dmitry Kasatk
Hi,
BTW.
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
Has this kernel anything about cryptodev as well?
Thanks,
- Dmitry
On 15/06/10 19:24, ext Nikos Mavrogiannopoulos wrote:
> Dmitry Kasatkin wrote:
>
>> Hi,
>>
>> Can I use kernel Crypto API from user space?
>> I
Dmitry Kasatkin wrote:
> Hi,
>
> Can I use kernel Crypto API from user space?
> I remember 2 or 3 projects about it.
>
> But what is the one and only one I need? :)
I don't know which is the one you need, but I know the one I use. Check
http://home.gna.org/cryptodev-linux/
regards,
Nikos
--
To
Dmitry Kasatkin wrote:
>
> I develop some drivers for crypto HW and met some difficulties.
> Some algorithm functions are called behind crypto_kmap()
>
> data = crypto_kmap(sg_page(sg), 0);
>
> It will do inc_preempt_count();
>
> I try to use DMA controller to perform memory transfers and try
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 17:17:57 +1100
> On Tue, Jan 08, 2008 at 05:15:48PM +1100, Herbert Xu wrote:
> >
> > Good point. I'll get rid of that too.
>
> I've replaced that patch with this:
>
> [CRYPTO] api: Set default CRYPTO_MINALIGN to unsigned long long
Loo
On Tue, Jan 08, 2008 at 05:15:48PM +1100, Herbert Xu wrote:
>
> Good point. I'll get rid of that too.
I've replaced that patch with this:
[CRYPTO] api: Set default CRYPTO_MINALIGN to unsigned long long
Thanks to David Miller for pointing out that the SLAB (or SLOB/SLUB)
cache uses the alignmen
On Mon, Jan 07, 2008 at 10:14:25PM -0800, David Miller wrote:
>
> Not to nit-pick but the CRYPTO_MINALIGN ifdef there at the
> end is superfluous. It will always be defined.
Good point. I'll get rid of that too.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 8 Jan 2008 17:09:11 +1100
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index 0aba104..6a20fc9 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -90,6 +90,8 @@
> #define CRYPTO_MINALIGN ARCH_KMALLOC_MINALIG
On Tue, 31 Jul 2007, Felipe Balbi wrote:
> On 7/31/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > [...]
> > Ugh, you should at least be checking if you've built the kernel with the
> > same config options :-) Of course, if you did a simple "make oldconfig"
> > but still lost some config option
On 7/31/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> On Tue, 31 Jul 2007, Felipe Balbi wrote:
>
> > On 7/31/07, Akinobu Mita <[EMAIL PROTECTED]> wrote:
> > > > > "Failed to setup dm-crypt key mapping.
> > > > > Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and
> > >
Hi,
On Tue, 31 Jul 2007, Felipe Balbi wrote:
> On 7/31/07, Akinobu Mita <[EMAIL PROTECTED]> wrote:
> > > > "Failed to setup dm-crypt key mapping.
> > > > Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and
> > > > verify that /dev/hda4 contains at least 133 sectors.
> > > > Fai
On 7/31/07, Akinobu Mita <[EMAIL PROTECTED]> wrote:
> > > "Failed to setup dm-crypt key mapping.
> > > Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and
> > > verify that /dev/hda4 contains at least 133 sectors.
> > > Failed to read from key storage"
> >
> > Looks like a "crypts
> > "Failed to setup dm-crypt key mapping.
> > Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and
> > verify that /dev/hda4 contains at least 133 sectors.
> > Failed to read from key storage"
>
> Looks like a "cryptsetup" error message, not kernel's.
I can't find CONFIG_DM_CRYPT
On Thu, Mar 22, 2007 at 01:13:59AM +0100, Nicolas Boullis wrote:
>
> First of all, sorry to bother you. I thought I'd rather ask my question
> to a list dedicated to the crypto API, but only found
> linux-crypto@vger.kernel.org that appears to be dead...
Actually that list is alive and well.
>
30 matches
Mail list logo
