On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote:
> In preparing to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
> the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
> to direct shash. By removing a
On Mon, 2017-09-25 at 12:56 +0800, Herbert Xu wrote:
> On Sun, Sep 24, 2017 at 07:42:46PM +0200, Johannes Berg wrote:
> >
> > Unrelated to this, I'm not sure whose tree this should go through -
> > probably Herbert's (or DaveM's with his ACK? not sure if there's a
&g
On Sun, 2017-09-24 at 13:21 -0400, Xiang Gao wrote:
>
> Do you mean to put more characters each line in the description
>
Huh, sorry, no - my bad. I was thinking of the code, not the
description at all.
For example here:
> -int ieee80211_aes_gcm_encrypt(struct crypto_aead *tfm, u8 *j_0, u8
On Sun, 2017-09-24 at 01:40 -0400, Xiang Gao wrote:
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line
> copy of each other. This patch reduce code redundancy by moving
> the code in these two files to crypto/aead_api.c to make it a
> higher level aead api. The aes_ccm.c and
> moved some data from the linear region to the stack, which violates
> the
> SG constraints when the stack is virtually mapped.
>
> So move idata/odata back to the request ctx struct, of which we can
> reasonably expect that it has been allocated using kmalloc() et al
On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
> It seems that there should be a better way to do it,
> but this works too.
In some cases there might be:
> --- a/drivers/s390/virtio/Makefile
> +++ b/drivers/s390/virtio/Makefile
> @@ -6,6 +6,8 @@
> # it under the terms of the GNU
On Mon, 2015-06-01 at 15:49 +0200, Stephan Mueller wrote:
The contents, now, that's a more interesting question. I believe it can
never be all zeroes, since association request frames are not
encrypted/protected and thus at least one byte in here must be non-zero.
The MAC addresses are also
On Mon, 2015-06-01 at 15:21 +0200, Stephan Mueller wrote:
Just a short question on ieee80211_aes_ccm_encrypt,
ieee80211_aes_ccm_decrypt,
ieee80211_aes_gcm_encrypt, ieee80211_aes_gcm_decrypt, ieee80211_aes_gmac: can
the aad parameter of these functions be zero?
What do you mean by zero?
On Mon, 2015-06-01 at 16:05 +0200, Johannes Berg wrote:
Ok - here the length is kinda passed a part of the AAD buffer, but this
is really just some arcane code that should be fixed to use a proper
struct. The value there, even though it is __be16 and looks like it came
from the data
On Wed, 2015-05-27 at 17:07 +0800, Herbert Xu wrote:
On Wed, May 27, 2015 at 11:00:40AM +0200, Johannes Berg wrote:
Right. Unfortunately, I can't typically rely on being able to make
changes to the kernel our driver is built against, and I don't think we
could do these changes otherwise
On Wed, 2015-05-27 at 16:39 +0800, Herbert Xu wrote:
On Wed, May 27, 2015 at 10:15:50AM +0200, Johannes Berg wrote:
Do you think it'd be feasible at all to somehow override the
aead_request_set_crypt() and aead_request_set_ad() functions or so to do
something that works on older kernels
The conversion of in-tree users is fairly straightforward.
It is pretty much - but a related question (that you totally don't have
to answer if you don't want to think about this).
I'm going to have to (continue) backport(ing) this code to older kernels
for customer support, and I prefer
On Fri, 2015-05-22 at 15:41 +0800, Herbert Xu wrote:
Did this have a code section at the end? Without it it's difficult
to pin-point the crash because your compiler produces different
output than mine.
Oops, sorry, of course - I was running in a VM :)
[ 26.143579] BUG: unable to handle
On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
This patch makes use of the new AEAD interface which uses a single
SG list instead of separate lists for the AD and plain text.
The CCM and GCM part seems to work, but GMAC causes a kernel crash:
[ 26.143579] BUG: unable to handle kernel
On Fri, 2015-05-22 at 16:05 +0800, Herbert Xu wrote:
On Fri, May 22, 2015 at 09:43:28AM +0200, Johannes Berg wrote:
Oops, sorry, of course - I was running in a VM :)
Thanks!
Does this patch on top help?
Yep, that fixes things.
johannes
--
To unsubscribe from this list: send the line
On Thu, 2015-05-21 at 19:50 +0800, Herbert Xu wrote:
On Thu, May 21, 2015 at 01:20:49PM +0200, Johannes Berg wrote:
On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
This patch makes use of the new AEAD interface which uses a single
SG list instead of separate lists for the AD
On Thu, 2015-05-21 at 18:44 +0800, Herbert Xu wrote:
This patch makes use of the new AEAD interface which uses a single
SG list instead of separate lists for the AD and plain text.
Looks fine - want me to run any tests on it?
johannes
--
To unsubscribe from this list: send the line
On Wed, 2015-04-22 at 15:04 +0800, Herbert Xu wrote:
Hi:
This series adds inclusions of aead.h to all AEAD users including
AEAD implementors (where it's internal/aead.h). This is necessary
because I'll be adding an updated AEAD interface and that will live
in aead.h instead of crypto.h.
From: Johannes Berg johannes.b...@intel.com
This is a specific implementation, asm/unaligned.h is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/crypto
On Tue, 2014-06-24 at 09:27 +1000, Julian Calaby wrote:
- x = (T)pci_alloc_consistent(E1,E2,E3);
+ x = pci_zalloc_consistent(E1,E2,E3);
if ((x==NULL) || ...) S
- memset((T2)x,0,E2);
I don't know much about SmPL, but wouldn't having that if statement
there reduce your matches?
Code
20 matches
Mail list logo
