On Mon, Dec 12, 2016 at 11:18:32PM +0100, Jason A. Donenfeld wrote:
> + for (; data != end; data += sizeof(u64)) {
> + m = get_unaligned_le64(data);
> + v3 ^= m;
> + SIPROUND;
> + SIPROUND;
> + v0 ^= m;
> + }
> +#if defined(CONFIG_
===
GENIV Template cipher
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from the
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code
From: Pan Bian
In function public_key_verify_signature(), returns variable ret on
error paths. When the call to kmalloc() fails, the value of ret is 0,
and it is not set to an errno before returning. This patch fixes the
bug.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188891
Signed-o
From: Alex Yashchenko
When src and dst both are specified and they point to the same file
the sign-file utility will write only signature to the dst file and
the module (.ko file) body will not be written.
That happens because we open the same file with "rb" and "wb" flags,
from fopen man:
w
On 12/13/2016 09:49 AM, Binoy Jayan wrote:
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in hardware for performance
Andy Lutomirski writes:
> Eric Biggers pointed out that the orinoco driver pointed scatterlists
> at the stack.
>
> Fix it by switching from ahash to shash. The result should be
> simpler, faster, and more correct.
>
> Cc: sta...@vger.kernel.org # 4.9 only
> Reported-by: Eric Biggers
> Signed-o
Hello!
On 12/12/2016 11:54 PM, Andy Lutomirski wrote:
smbencrypt() points a scatterlist to the stack, which is breaks if
s/is//.
CONFIG_VMAP_STACK=y.
Fix it by switching to crypto_cipher_encrypt_one(). The new code
should be considerably faster as an added benefit.
This code is nearly
From: Andy Lutomirski
> Sent: 12 December 2016 20:53
> The driver put a constant buffer of all zeros on the stack and
> pointed a scatterlist entry at it in two places. This doesn't work
> with virtual stacks. Use a static 16-byte buffer of zeros instead.
...
I didn't think you could dma from st
On Mon, 2016-12-12 at 12:54 -0800, Andy Lutomirski wrote:
> smbencrypt() points a scatterlist to the stack, which is breaks if
> CONFIG_VMAP_STACK=y.
>
> Fix it by switching to crypto_cipher_encrypt_one(). The new code
> should be considerably faster as an added benefit.
>
> This code is nearly
Hi Linus:
Here is the crypto update for 4.10:
API:
- Add skcipher walk interface.
- Add asynchronous compression (acomp) interface.
- Fix algif_aed AIO handling of zero buffer.
Algorithms:
- Fix unaligned access in poly1305.
- Fix DRBG output to large buffers.
Drivers:
- Add support for iMX
The new skcipher walk API may crash in the following way. (Interestingly,
the tcrypt boot time tests seem unaffected, while an explicit test using
the module triggers it)
Unable to handle kernel NULL pointer dereference at virtual address
...
[] __memcpy+0x84/0x180
[] skcipher_wal
Hello
I have some comment below
On Mon, Dec 12, 2016 at 04:04:37PM +0100, Jan Glauber wrote:
> From: Mahipal Challa
>
[...]
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o
> obj-$(CONFIG_CRYPTO_DEV_TALITOS) += ta
On Thu, Dec 08, 2016 at 05:06:18PM +0800, Herbert Xu wrote:
> On Wed, Dec 07, 2016 at 01:51:27PM +0100, Corentin Labbe wrote:
> >
> > So I must expose it as a crypto_rng ?
>
> If it is to be exposed at all then algif_rng would be the best
> place.
>
> > Could you explain why PRNG must not be use
Enable the CPT VF driver. CPT is the cryptographic Accelaration Unit
in Octeon-tx series of processors.
Signed-off-by: George Cherian
---
drivers/crypto/cavium/cpt/Makefile | 3 +-
drivers/crypto/cavium/cpt/cptvf.h| 145
drivers/crypto/cavium/cpt/cptvf_algs.c |
Add the CPT options in crypto Kconfig and update the
crypto Makefile
Signed-off-by: George Cherian
---
drivers/crypto/Kconfig | 1 +
drivers/crypto/Makefile | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..15f9040 100644
--- a/
THe major content of drivers/crypto/Makefile is sorted, only recent
addition break this sort.
This patch bring back this alphabetical sorting.
Signed-off-by: Corentin Labbe
---
drivers/crypto/Makefile | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypt
In the common case of !PageHighMem we can do zero copy crypto
even if sg crosses a pages boundary.
Signed-off-by: Ilya Lesokhin
---
arch/x86/crypto/aesni-intel_glue.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/c
This patch move the define for hwrng's miscdev minor number to
include/linux/miscdevice.h.
It's better that all minor number are in the same place.
Rename it to HWRNG_MINOR (from RNG_MISCDEV_MINOR) in he process since
no other miscdev define have MISCDEV in their name.
Signed-off-by: Corentin Labb
This patch fix the checkpatch warning "Please don't use multiple blank lines"
Signed-off-by: Corentin Labbe
---
drivers/char/hw_random/core.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index d2d2c89..00cbb81 100644
--- a/
This patch remove the unused PFX macro.
Signed-off-by: Corentin Labbe
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 1e1e385..5c654b5 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers
This patch fix the checkpatch warning about asm/uaccess.h.
In the same time, we sort the headers in alphabetical order.
Signed-off-by: Corentin Labbe
---
drivers/char/hw_random/core.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/char/hw_random/core
linux/sched.h is useless for hw_random/core.c.
This patch remove it.
Signed-off-by: Corentin Labbe
---
Change since v1:
- linux/fs.h was needed, keep it
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.
checkpatch have lot of complaint about header.
Furthermore, the header have some offtopic/useless information.
This patch rewrite a proper header.
Signed-off-by: Corentin Labbe
---
drivers/char/hw_random/core.c | 38 +-
1 file changed, 9 insertions(+), 29 del
This patch fix the checkpatch warning "Comparison to NULL could be written
"!ptr"
Signed-off-by: Corentin Labbe
---
drivers/char/hw_random/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 00cbb81..70
> What do you think about those two solutions ?
I prefer the second solution's idea of using two files (/dev/hwrng and
/dev/hwprng). Upon having a quick glance it looks like (based on
current_rng == prng check) that your current implementation allows
only one rng device to be in use at a time. It
On Tue, Dec 13, 2016 at 08:53:54PM +0530, PrasannaKumar Muralidharan wrote:
> > What do you think about those two solutions ?
>
> I prefer the second solution's idea of using two files (/dev/hwrng and
> /dev/hwprng). Upon having a quick glance it looks like (based on
> current_rng == prng check) t
Enable the Physical Function diver for the Cavium Crypto Engine (CPT)
found in Octeon-tx series of SoC's. CPT is the Cryptographic Acceleration
Unit. CPT includes microcoded GigaCypher symmetric engines (SEs) and
asymmetric engines (AEs).
Signed-off-by: George Cherian
---
drivers/crypto/cavium/c
On 12/12/2016 11:05 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 12, 2016 at 06:54:07PM +0800, Herbert Xu wrote:
>> On Mon, Dec 12, 2016 at 06:25:12AM +, Gonglei (Arei) wrote:
>>> Hi, Michael & Herbert
>>>
>>> Because the virtio-crypto device emulation had been in QEMU 2.8,
>>> would you pleas
This series adds the support for Cavium Cryptographic Accelerarion Unit (CPT)
CPT is available in Cavium's Octeon-Tx SoC series.
The series was tested with ecryptfs and dm-crypt for in kerne
[add some people who might know]
On Tue, Dec 13, 2016 at 4:20 AM, David Laight wrote:
> From: Andy Lutomirski
>> Sent: 12 December 2016 20:53
>> The driver put a constant buffer of all zeros on the stack and
>> pointed a scatterlist entry at it in two places. This doesn't work
>> with virtual st
On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo wrote:
> Andy Lutomirski writes:
>
>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>> at the stack.
>>
>> Fix it by switching from ahash to shash. The result should be
>> simpler, faster, and more correct.
>>
>> Cc: sta...@vger
Andy Lutomirski wrote:
> After all, rodata is ordinary memory, is backed by struct page, etc.
Is that actually true? I thought some arches excluded the kernel image from
the page struct array to make the array consume less memory.
David
--
To unsubscribe from this list: send the line "unsubscr
Andy Lutomirski writes:
> On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo wrote:
>> Andy Lutomirski writes:
>>
>>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>>> at the stack.
>>>
>>> Fix it by switching from ahash to shash. The result should be
>>> simpler, faster, and
On Tue, Dec 13, 2016 at 8:45 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> After all, rodata is ordinary memory, is backed by struct page, etc.
>
> Is that actually true? I thought some arches excluded the kernel image from
> the page struct array to make the array consume less memory.
On Mon, Dec 12, 2016 at 7:39 PM, Herbert Xu wrote:
> On Mon, Dec 12, 2016 at 10:34:10AM -0800, Andy Lutomirski wrote:
>>
>> Here's my status.
>>
>> > drivers/crypto/bfin_crc.c:351
>> > drivers/crypto/qce/sha.c:299
>> > drivers/crypto/sahara.c:973,988
>> > drivers/cr
On 12/13/16 04:32 PM, Ilya Lesokhin wrote:
> --- a/arch/x86/crypto/aesni-intel_glue.c
> +++ b/arch/x86/crypto/aesni-intel_glue.c
> @@ -903,9 +903,11 @@ static int helper_rfc4106_encrypt(struct aead_request
> *req)
> *((__be32 *)(iv+12)) = counter;
>
> if (sg_is_last(req->src) &&
> -
On Tue, Dec 13, 2016 at 12:39 AM, Eric Biggers wrote:
>
> Hmm, I don't think you can really do load_unaligned_zeropad() without first
> checking for 'left != 0'.
Right you are. If the allocation is at the end of a page, the 0-size
case would be entirely outside the page and there's no fixup.
Of
On Mon, Dec 12, 2016 at 3:04 PM, Jason A. Donenfeld wrote:
>
> Indeed this would be a great first candidate. There are lots of places
> where MD5 (!!) is pulled in for this sort of thing, when SipHash could
> be a faster and leaner replacement (and arguably more secure than
> rusty MD5).
Yeah,. t
On Tue, Dec 13, 2016 at 09:31:16AM +0800, Ryder Lee wrote:
> Add DT bindings documentation for the crypto driver
>
> Signed-off-by: Ryder Lee
> ---
> .../devicetree/bindings/crypto/mediatek-crypto.txt | 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644
> Doc
Andy Lutomirski wrote:
> I don't know whether you're right, but that sounds a bit silly to me.
> This is a *tiny* amount of memory.
Assuming a 1MiB kernel image in 4K pages, that gets you back a couple of pages
I think - useful if you've only got a few MiB of RAM.
David
--
To unsubscribe from t
Hi Herbert,
I am sorry to interrupt your merge window, but may I ask to consider
this patch for the current development cycle as well as for stable
back to v4.1 where the algif_skcipher AIO support was added?
It fixes the two bug reports which I reported back in September
that allow crashing the k
Am Dienstag, 25. Oktober 2016, 10:35:49 CET schrieb Herbert Xu:
Hi Jonathan,
> > > > the attached patch set converts the existing crypto API documentation
> > > > from DocBook to Sphinx.
> > >
> > > This looks generally good to me - thanks for doing it!
> > >
> > > Is there any chance of runnin
On Tue, 13 Dec 2016 22:25:07 +0100
Stephan Müller wrote:
> Considering that a large batch of documentation updates just landed in Linus'
> tree, I am wondering why the crypto API documentation update is not among it.
Well, I'd asked if I could run the documentation-specific parts through
docs-n
Am Dienstag, 13. Dezember 2016, 14:50:59 CET schrieb Jonathan Corbet:
Hi Jonathan,
> On Tue, 13 Dec 2016 22:25:07 +0100
>
> Stephan Müller wrote:
> > Considering that a large batch of documentation updates just landed in
> > Linus' tree, I am wondering why the crypto API documentation update is
SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function.
SipHash isn't just some new trendy hash function. It's been around for a
while, and there really isn't any
Hi Eric,
On Tue, Dec 13, 2016 at 9:39 AM, Eric Biggers wrote:
> Hmm, I don't think you can really do load_unaligned_zeropad() without first
> checking for 'left != 0'. The fixup section for load_unaligned_zeropad()
> assumes that rounding the pointer down to a word boundary will produce an
> add
Hi Linus,
On Tue, Dec 13, 2016 at 8:25 PM, Linus Torvalds
wrote:
> Yeah,. the TCP sequence number md5_transform() cases are likely the
> best example of something where siphash might be good. That tends to
> be really just a couple words of data (the address and port info) plus
> the net_secret[]
On Tue, 13 Dec 2016 23:06:14 +0100
Stephan Müller wrote:
> I am sorry, then I may have misunderstood you.
>
> I would think that Herbert agreed that you push the entire patch set through
> your tree, including the documentation changes to the crypto header files.
>
> I just did a patch on the
The driver put a constant buffer of all zeros on the stack and
pointed a scatterlist entry at it in two places. This doesn't work
with virtual stacks. Use ZERO_PAGE instead.
Cc: sta...@vger.kernel.org # 4.9 only
Reported-by: Eric Biggers
Signed-off-by: Andy Lutomirski
---
security/keys/encryp
The driver put a constant buffer of all zeros on the stack and
pointed a scatterlist entry at it. This doesn't work with virtual
stacks. Use ZERO_PAGE instead.
Cc: sta...@vger.kernel.org # 4.9 only
Reported-by: Eric Biggers
Signed-off-by: Andy Lutomirski
---
drivers/usb/wusbcore/crypto.c | 3
On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote:
> The driver put a constant buffer of all zeros on the stack and
> pointed a scatterlist entry at it in two places. This doesn't work
> with virtual stacks. Use ZERO_PAGE instead.
Wait a second...
> - sg_set_buf(&sg_out[1], pad, siz
This duplicates the current algorithm for get_random_int/long, but uses
siphash24 instead. This comes with several benefits. It's certainly
faster and more cryptographically secure than MD5. This patch also
hashes the pid, entropy, and timestamp as fixed width fields, in order
to increase diffusion
SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function.
SipHash isn't just some new trendy hash function. It's been around for a
while, and there really isn't any
Many jhash users currently rely on the Nwords functions. In order to
make transitions to siphash fit something people already know about, we
provide analog functions here. This also winds up being nice for the
networking stack, where hashing 32-bit fields is common.
Signed-off-by: Jason A. Donenfe
This duplicates the current algorithm for get_random_int/long, but uses
siphash24 instead. This comes with several benefits. It's certainly
faster and more cryptographically secure than MD5. This patch also
hashes the pid, entropy, and timestamp as fixed width fields, in order
to increase diffusion
This gives a clear speed and security improvement. Siphash is both
faster and is more solid crypto than the aging MD5.
Rather than manually filling MD5 buffers, we simply create
a layout by a simple anonymous struct, for which gcc generates
rather efficient code.
Signed-off-by: Jason A. Donenfeld
On Tue, Dec 13, 2016 at 09:06:31AM -0800, Andy Lutomirski wrote:
>
> > Having 0 as type and CRYPTO_ALG_ASYNC as mask in general means
> > that we're requesting a sync algorithm (i.e., ASYNC bit off).
> >
> > However, it is completely unnecessary for shash as they can never
> > be async. So this co
On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote:
> On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote:
> > The driver put a constant buffer of all zeros on the stack and
> > pointed a scatterlist entry at it in two places. This doesn't work
> > with virtual stacks. Use ZERO_P
On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote:
>
> I have found two solutions:
No we already have algif_rng so let's not confuse things even
further by making hwrng take PRNGs.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.a
On Wed, Dec 14, 2016 at 01:05:51PM +0800, Herbert Xu wrote:
> On Tue, Dec 13, 2016 at 03:10:59PM +0100, Corentin Labbe wrote:
> >
> > I have found two solutions:
>
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.
>
But algif_rng is not accessi
Hi Milan,
Thank you for the reply.
On 13 December 2016 at 15:31, Milan Broz wrote:
> I really do not think the disk encryption key management should be moved
> outside of dm-crypt. We cannot then change key structure later easily.
Yes, I agree. but the key selection based on sector number rest
Am Dienstag, 13. Dezember 2016, 16:40:01 CET schrieb Jonathan Corbet:
Hi Jonathan,
> Clearly there was a bit of misunderstanding going around :)
Yep, it seems like it :-)
>
> I've applied the patch set to docs-next. Oddly I had no trouble with #7,
> but #2 was badly mailer-mangled and took som
63 matches
Mail list logo
