On Mon, Nov 07, 2016 at 08:47:09PM +0100, Jason A. Donenfeld wrote:
> By using the unaligned access helpers, we drastically improve
> performance on small MIPS routers that have to go through the exception
> fix-up handler for these unaligned accesses.
>
> Signed-off-by: Jason A. Donenfeld
> ---
On Mon, Nov 07, 2016 at 08:02:35PM +0100, Jason A. Donenfeld wrote:
> On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers wrote:
> >
> > I was not referring to any users in particular, only what users could do.
> > As an
> > example, if you did crypto_shash_update() with 32, 15, then 17 bytes, and
> >
By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 34 +++---
1 file chang
By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 33 ++---
1 file change
On Mon, Nov 7, 2016 at 8:25 PM, Eric Biggers wrote:
> No it does *not* buffer all incoming blocks, which is why the source pointer
> can
> fall out of alignment. Yes, I actually tested this. In fact this situation
> is
> even hit, in both possible places, in the self-tests.
Urgh! v3 coming ri
By using the unaligned access helpers, we drastically improve
performance on small MIPS routers that have to go through the exception
fix-up handler for these unaligned accesses.
Signed-off-by: Jason A. Donenfeld
---
crypto/poly1305_generic.c | 12 ++--
1 file changed, 6 insertions(+), 6
On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers wrote:
>
> I was not referring to any users in particular, only what users could do. As
> an
> example, if you did crypto_shash_update() with 32, 15, then 17 bytes, and the
> underlying algorithm is poly1305-generic, the last block would end up
> misa
On Mon, Nov 07, 2016 at 07:08:22PM +0100, Jason A. Donenfeld wrote:
> Hmm... The general data flow that strikes me as most pertinent is
> something like:
>
> struct sk_buff *skb = get_it_from_somewhere();
> skb = skb_share_check(skb, GFP_ATOMIC);
> num_frags = skb_cow_data(skb, ..., ...);
> struct
On Mon, Nov 7, 2016 at 7:08 PM, Jason A. Donenfeld wrote:
> Hmm... The general data flow that strikes me as most pertinent is
> something like:
>
> struct sk_buff *skb = get_it_from_somewhere();
> skb = skb_share_check(skb, GFP_ATOMIC);
> num_frags = skb_cow_data(skb, ..., ...);
> struct scatterli
Hi Eric,
On Fri, Nov 4, 2016 at 6:37 PM, Eric Biggers wrote:
> I agree, and the current code is wrong; but do note that this proposal is
> correct for poly1305_setrkey() but not for poly1305_setskey() and
> poly1305_blocks(). In the latter two cases, 4-byte alignment of the source
> buffer is *n
> -Ursprüngliche Nachricht-
> Von: Horia Geanta Neag [mailto:horia.gea...@nxp.com]
> Gesendet: Montag, 7. November 2016 08:14
> An: Sven Ebenfeld ; linux-
> cry...@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: herb...@gondor.apana.org.au; da...@davemloft.net; Cata Vasile
>
> Betreff:
When using AES-XTS on a Wandboard, we receive a Mode error:
caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error.
According to the Security Reference Manual, the Low Power AES units
of the i.MX6 do not support the XTS mode. Therefore we must not
register XTS implementations in the Cryp
On Sat, Nov 05, 2016 at 07:13:49AM -0800, Kent Overstreet wrote:
> Vmalloc memory does have struct pages - you just need to use vmalloc_to_page()
> instead of virt_to_page. Look at drivers/md/bcache/util.c bch_bio_map() if you
> want an example.
That example seems to be clearly broken on virtually
On 11/5/2016 1:17 AM, Sven Ebenfeld wrote:
> When using AES-XTS on a Wandboard, we receive a Mode error:
> caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error.
>
> Due to the Security Reference Manual, the Low Power AES units
s/Due to/According to
> of the i.MX6 do not support the XT
On 03.11.2016 23:03, Eric Biggers wrote:
> 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 stac
On 03.11.2016 23:03, Eric Biggers wrote:
> 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_encryp
16 matches
Mail list logo
