On Thu, Apr 28, 2016 at 10:38:39AM +0530, Pramod Kumar wrote:
> Hi Herbert Xu/ James Morris/ David
>
>
>
> I was writing driver for one of my secure processing unit(SPU) which
> offloads all SHA/AEAD/ablkciphers.
>
>
>
> While registering algos for crypto subsystem I could not find any way wh
On Sat, Apr 30, 2016 at 08:32:48AM +, Jamie Heilman wrote:
> I usually build my kernels to require module signatures and use
> automatic signing. As of v4.6-rc1 I'm getting this on boot:
>
> Problem loading in-kernel X.509 certificate (-2)
>
> I bisected that to commit d43de6c780a84def056afa
On Fri, Apr 29, 2016 at 12:03:04PM +0100, Richard W.M. Jones wrote:
> Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
> This commit adds a flag 'cryptomgr.notests' which allows them to be
> disabled.
>
> Signed-off-by: Richard W.M. Jones
Please address the conflict with FIPS
On Fri, Apr 29, 2016 at 03:51:46PM +0300, Tudor Ambarus wrote:
>
> struct rsa_key {
> + u8 *n;
> + u8 *e;
> + u8 *d;
> + dma_addr_t dma_n;
> + dma_addr_t dma_e;
> + dma_addr_t dma_d;
> + size_t n_sz;
> + size_t e_sz;
> + bool coherent;
> + gfp_t flags;
Plea
On Wed, Apr 27, 2016 at 09:08:27PM -0400, Sowmini Varadhan wrote:
> On (04/28/16 09:01), Herbert Xu wrote:
> > Subject: Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in
> > mpi_write_to_sgl
> >
> > Please cc linux-crypto.
>
> Just bounced the message to linux-crypto as well.
> I think get
On Fri, Apr 29, 2016 at 11:03:05AM -0300, Paulo Flabiano Smorigo wrote:
> It gives significant improvements ( ~+15%) on some modes.
>
> These code has been adopted from OpenSSL project in collaboration
> with the original author (Andy Polyakov ).
No sign-off.
--
Email: Herbert Xu
Home Page: htt
On Fri, Apr 29, 2016 at 10:59:59AM -0700, Tadeusz Struk wrote:
> Fix copy and paste typo adf_isr.c
>
> Signed-off-by: Tadeusz Struk
Both applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from
On Thu, Apr 28, 2016 at 02:11:51PM +0800, Baolin wrote:
> Since the crypto engine framework had been merged, thus this patch integrates
> with the newly added crypto engine framework to make the crypto hardware
> engine under utilized as each block needs to be processed before the crypto
> hardware
On Fri, Apr 29, 2016 at 04:02:18PM +0300, Peter Ujfalusi wrote:
> With the new dma_request_chan() the client driver does not need to look for
> the DMA resource and it does not need to pass filter_fn anymore.
> By switching to the new API the driver can now support deferred probing
> against DMA.
>
On Fri, Apr 29, 2016 at 10:43:40AM -0700, Tadeusz Struk wrote:
> Fix undefined reference issue reported by kbuild test robot.
>
> Reported-by: kbuild test robot
> Signed-off-by: Tadeusz Struk
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.
On Sun, May 01, 2016 at 01:52:55PM +0200, Julia Lawall wrote:
> The ccp_actions structure is never modified, so declare it as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: htt
On Fri, Apr 29, 2016 at 10:09:11PM +0200, Julia Lawall wrote:
> Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch
> that makes this transformation is as follows: (http://coccinelle.lip6.fr/)
>
> //
> @@
> expression d,e;
> statement S;
> @@
>
> d =
> -
I was notified by a fellow member of the OpenWrt list that the talitos was
already fixed in the crypto-dev repo so I backported that patch into our tree.
He also pointed out (gracefully) that I was a bit naive with regard to the fact
that just setting the statesize is not enough.
Sorry for the
Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o:
Hi Theodore,
> The CRNG is faster, and we don't pretend to track entropy usage in the
> CRNG any more.
In general, I have no concerns with this approach either. And thank you that
some of my concerns are addressed.
There are few more conc
Jamie Heilman wrote:
> I usually build my kernels to require module signatures and use
> automatic signing. As of v4.6-rc1 I'm getting this on boot:
>
> Problem loading in-kernel X.509 certificate (-2)
>
> I bisected that to commit d43de6c780a84def056afaf4fb3e66bdaa1efc00
> (akcipher: Move the
v2 -> v3:
- Ignore the flag if FIPS mode is enabled.
v1 -> v2:
- Use printk_once. Because the serial console is so slow, printing
the message multiple times actually consumed about 6ms extra later
on during the boot.
- - -
I'm trying to reduce the time taken in the kernel in initcalls
Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
This commit adds a flag 'cryptomgr.notests' which allows them to be
disabled.
However if fips=1 as well, we ignore this flag as FIPS mode mandates
that the self-tests are run.
Signed-off-by: Richard W.M. Jones
---
Documentatio
> Problem loading in-kernel X.509 certificate (-2)
ENOENT? Hmmm... The only place that is generated is in the crypto layer.
That suggests missing crypto of some sort.
The attached patch enables some debugging in some relevant files if you can
try applying it to your kernel.
David
---
diff --gi
Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o:
Hi Theodore,
One more item.
> The CRNG is faster, and we don't pretend to track entropy usage in the
> CRNG any more.
>
> Signed-off-by: Theodore Ts'o
> ---
> crypto/chacha20_generic.c | 61 --
> drivers/char/random.c | 282
On Thu, Apr 28, 2016 at 10:27:43AM +0200, Steffen Klassert wrote:
>
> The problem was that if offset (in a superpage) equals
> PAGE_SIZE in hash_walk_next(), nbytes becomes zero. So
> we map the page, but we don't hash and unmap because we
> exit the loop in shash_ahash_update() in this case.
I se
On (05/03/16 16:12), Herbert Xu wrote:
>
> Sorry, but your patch doesn't apply against the current tree at all.
> Please rebase it if it is still needed.
Hello,
I had based my patch off of net-next, which is where I do my work.
I'd be happy to rebase it on the "current tree",
but given that mp
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: bc197b2a9c7e0129fa0ec1961881e2a0b3bef967
commit: 58ea8abf490415c390e0cc671e875510c9b66318 [56/77] crypto: ccp - Register
the CCP as a DMA resource
config: x86_64-randconfig-s4-05031628 (attached as .c
Hi Herb,
the following patchset introduces a new API for abstracting key-agreement
protocols such as DH and ECDH. It provides the primitives required for
implementing
the protocol, thus the name KPP (Key-agreement Protocol Primitives).
Regards,
Salvatore
Changes from v1:
* Change check in dh_c
* Implement ECDH under kpp API
* Provide ECC software support for curve P-192 and
P-256.
* Add kpp test for ECDH with data generated by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig |5 +
crypto/Makefile |3 +
crypto/ecc.c| 1037
Add key-agreement protocol primitives (kpp) API which allows to
implement primitives required by protocols such as DH and ECDH.
The API is composed mainly by the following functions
* set_params() - It allows the user to set the parameters known to
both parties involved in the key-agreement ses
* Implement MPI based Diffie-Hellman under kpp API
* Test provided uses data generad by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig | 8 ++
crypto/Makefile | 2 +
crypto/dh.c | 224
crypto/testmgr.c
Hello!
I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not
happen, if I set the following kernel option:
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
Can someone please look at https://bugzilla.kernel.org/show_bug.cgi?id=117551 ?
Thanks.
There's attached kernel config on bugzilla.
kern
On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o wrote:
> On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
>> That's far from a solution and I wouldn't recommend to anyone doing
>> that. We cannot expect each and every program to do glibc's job. The
>> purpose of a system cal
On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote:
>
> I believe their main concern is that they want to protect applications
> which do not check error codes of system calls, when running on a
> kernel which does not provide getrandom(). That way, they have an
> almost impo
On 2016-05-03 09:57, Nikos Mavrogiannopoulos wrote:
On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o wrote:
On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
That's far from a solution and I wouldn't recommend to anyone doing
that. We cannot expect each and every program t
On Tue, May 3, 2016 at 4:48 PM, wrote:
> On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote:
>> I believe their main concern is that they want to protect applications
>> which do not check error codes of system calls, when running on a
>> kernel which does not provide getrand
From: Anatoly Pugachev
Date: Tue, 3 May 2016 16:54:18 +0300
> I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not
> happen, if I set the following kernel option:
>
> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
>
> Can someone please look at https://bugzilla.kernel.org/show_bug.cgi?id=11
David Howells wrote:
> > Problem loading in-kernel X.509 certificate (-2)
>
> ENOENT? Hmmm... The only place that is generated is in the crypto layer.
> That suggests missing crypto of some sort.
>
> The attached patch enables some debugging in some relevant files if you can
> try applying it t
Herbert Xu wrote:
> On Sat, Apr 30, 2016 at 08:32:48AM +, Jamie Heilman wrote:
> > I usually build my kernels to require module signatures and use
> > automatic signing. As of v4.6-rc1 I'm getting this on boot:
> >
> > Problem loading in-kernel X.509 certificate (-2)
> >
> > I bisected that
Never use sg++, always use sg = sg_next(sg). Scatterlist entries can
be combined if the memory is contiguous but sg++ won't know about
that. It sure would run on the slower side.
But regardless, sg++ should never be used, only sg_next is safe.
Signed-off-by: Muhammad Falak R Wani
---
crypto/algi
(cc'ing Tadeusz as he did the pkcs1 padding function)
Jamie Heilman wrote:
> > > Problem loading in-kernel X.509 certificate (-2)
> >
> > ENOENT? Hmmm... The only place that is generated is in the crypto layer.
> > That suggests missing crypto of some sort.
> >
> > The attached patch enables
Hi Jamie,
On 05/03/2016 01:35 PM, David Howells wrote:
> (cc'ing Tadeusz as he did the pkcs1 padding function)
>
> Jamie Heilman wrote:
>
Problem loading in-kernel X.509 certificate (-2)
>>>
>>> ENOENT? Hmmm... The only place that is generated is in the crypto layer.
>>> That suggests mis
Tadeusz Struk wrote:
> Could you please check if this one fixes the problem for you:
> https://patchwork.kernel.org/patch/8766361/
That patch is already present by 4.6-rc5 and the problem still exists,
so no, it doesn't.
--
Jamie Heilman http://audible.transient.net/~jamie/
-
David Howells wrote:
> (cc'ing Tadeusz as he did the pkcs1 padding function)
>
> Jamie Heilman wrote:
>
> > > > Problem loading in-kernel X.509 certificate (-2)
> > >
> > > ENOENT? Hmmm... The only place that is generated is in the crypto layer.
> > > That suggests missing crypto of some sort
On Tue, May 03, 2016 at 06:19:15AM -0400, Sowmini Varadhan wrote:
> On (05/03/16 16:12), Herbert Xu wrote:
> >
> > Sorry, but your patch doesn't apply against the current tree at all.
> > Please rebase it if it is still needed.
>
> Hello,
>
> I had based my patch off of net-next, which is where
David Miller wrote:
> From: Anatoly Pugachev
> Date: Tue, 3 May 2016 16:54:18 +0300
>
>> I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not
>> happen, if I set the following kernel option:
>>
>> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
>>
>> Can someone please look at
>> https://b
Muhammad Falak R Wani wrote:
> Never use sg++, always use sg = sg_next(sg). Scatterlist entries can
> be combined if the memory is contiguous but sg++ won't know about
> that. It sure would run on the slower side.
> But regardless, sg++ should never be used, only sg_next is safe.
>
> Signed-off-b
On 05/03/2016 07:26 PM, Jamie Heilman wrote:
>>> Alrighty, presumably relevant bits:
>>> > >
>>> > > X.509: Cert Issuer: Build time autogenerated kernel key
>>> > > X.509: Cert Subject: Build time autogenerated kernel key
>>> > > X.509: Cert Key Algo: rsa
>>> > > X.509: Cert Valid period: 146182679
Tadeusz Struk wrote:
> On 05/03/2016 07:26 PM, Jamie Heilman wrote:
> >>> Alrighty, presumably relevant bits:
> >>> > >
> >>> > > X.509: Cert Issuer: Build time autogenerated kernel key
> >>> > > X.509: Cert Subject: Build time autogenerated kernel key
> >>> > > X.509: Cert Key Algo: rsa
> >>> > >
Am Dienstag, 3. Mai 2016, 11:36:12 schrieb Stephan Mueller:
Hi Ted,
> > +
> > +static ssize_t extract_crng_user(void __user *buf, size_t nbytes)
> > +{
> > + ssize_t ret = 0, i;
> > + __u8 tmp[CHACHA20_BLOCK_SIZE];
> > + int large_request = (nbytes > 256);
> > +
> > + while (nbytes) {
> >
45 matches
Mail list logo
