From: Yanjiang Jin
This is to eliminate the below compile error:
crypto/rsa_helper.c:19:29: fatal error: rsaprivkey-asn1.h: No such file or
directory
#include "rsaprivkey-asn1.h"
^
compilation terminated.
Signed-off-by: Yanjiang Jin
---
crypto/{rsaprivkey.asn1 =
On Thu, Nov 3, 2016 at 4:10 PM, Eric Biggers wrote:
> On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote:
>> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
>> >
>> > Also, Herbert, it seems like the considerable majority of the crypto
>> > code is acting on kernel virtu
On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote:
> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
> >
> > Also, Herbert, it seems like the considerable majority of the crypto
> > code is acting on kernel virtual memory addresses and does software
> > processing. Wou
Hi David,
On Thu, Nov 3, 2016 at 6:08 PM, David Miller wrote:
> In any event no piece of code should be doing 32-bit word reads from
> addresses like "x + 3" without, at a very minimum, going through the
> kernel unaligned access handlers.
Excellent point. In otherwords,
ctx->r[0] = (le32_t
With the new (in 4.9) option to use a virtually-mapped stack
(CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
the scatterlist crypto API because they may not be directly mappable to
struct page. get_crypt_info() was using a stack buffer to hold the
output from the encryption o
With the new (in 4.9) option to use a virtually-mapped stack
(CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
the scatterlist crypto API because they may not be directly mappable to
struct page. For short filenames, fname_encrypt() was encrypting a
stack buffer holding the pad
On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
>
> Also, Herbert, it seems like the considerable majority of the crypto
> code is acting on kernel virtual memory addresses and does software
> processing. Would it perhaps make sense to add a kvec-based or
> iov_iter-based interfa
On Thu, Nov 3, 2016 at 11:16 AM, Eric Biggers wrote:
> Hello,
>
> I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code
> in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y:
>
> /* carry flag will be set if starting x was >= PAGE_OFFSET */
>
This code is unlikely to be useful in the future because transforms
don't know how often keys will be changed, new algorithms are unlikely
to use lle representation, and tables should be replaced with
carryless multiplication instructions when available.
Signed-off-by: Alex Cope
---
crypto/gf128
Hello,
I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code
in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y:
/* carry flag will be set if starting x was >= PAGE_OFFSET */
VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x));
The problem
From: "Jason A. Donenfeld"
Date: Thu, 3 Nov 2016 08:24:57 +0100
> Hi Herbert,
>
> On Thu, Nov 3, 2016 at 1:49 AM, Herbert Xu
> wrote:
>> FWIW I'd rather live with a 6% slowdown than having two different
>> code paths in the generic code. Anyone who cares about 6% would
>> be much better off w
Hi Herbert,
On Thu, Nov 3, 2016 at 1:49 AM, Herbert Xu wrote:
> FWIW I'd rather live with a 6% slowdown than having two different
> code paths in the generic code. Anyone who cares about 6% would
> be much better off writing an assembly version of the code.
Please think twice before deciding th
12 matches
Mail list logo
