On Wed, Aug 08, 2018 at 01:07:03PM +0800, xiao jin wrote:
> We hit the BUG() report at include/linux/scatterlist.h:144!
> The callback is as bellow:
> => verity_work
> => verity_hash_for_block
> => verity_verify_level
> => verity_hash
> => verity_hash_update
> => sg_init_one
> =>
And this one too.
On 07/01/2018 05:55 PM, Xose Vazquez Perez wrote:
> Cc: Christophe Varoqui
> Cc: DM-DEV ML
> Signed-off-by: Xose Vazquez Perez
> ---
> libmultipath/hwtable.c | 39 +--
> 1 file changed, 13 insertions(+), 26 deletions(-)
>
> diff --git
Missing.
On 06/26/2018 03:52 PM, Xose Vazquez Perez wrote:
> Cc: Matthias Rudolph
> Cc: Matthias Rudolph
> Cc: Christophe Varoqui
> Cc: DM-DEV ML
> Signed-off-by: Xose Vazquez Perez
> ---
> libmultipath/hwtable.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Mon, 2018-08-06 at 17:55 -0500, Benjamin Marzinski wrote:
> I'm confused here. If the data is only read by multiple threads, I don't
> see why we need to synchronize it. Unless I'm missing something, my
> patch does make sure that the only time ct->devt is written is when
> there is only one
On Mon, 2018-08-06 at 18:12 -0500, Benjamin Marzinski wrote:
> On Sun, Aug 05, 2018 at 03:43:18PM +, Bart Van Assche wrote:
> > On Wed, 2018-08-01 at 15:57 -0500, Benjamin Marzinski wrote:
> > > when tur_thread() was calling tur_check(), it was passing ct->message as
> > > the copy argument,
In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize. Since this is always a cipher
blocksize, use the existing cipher max blocksize.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by:
In the quest to remove all stack VLA usage from the kernel[1], this
exposes a new general upper bound on crypto blocksize and alignmask
(higher than for the existing cipher limits) for VLA removal,
and introduces new checks.
At present, the highest cra_alignmask in the kernel is 63. The highest
In the quest to remove all stack VLA usage from the kernel[1], this uses
the maximum blocksize and adds a sanity check. For xcbc, the blocksize
must always be 16, so use that, since it's already being enforced during
instantiation.
[1]
In the quest to remove all stack VLA usage from the kernel[1], this
caps the skcipher request size similar to other limits and adds a sanity
check at registration. Looking at instrumented tcrypt output, the largest
is for lrw:
crypt: testing lrw(aes)
crypto_skcipher_set_reqsize: 8
In the quest to remove all stack VLA usage from the kernel[1], this uses
the newly defined max alignment to perform unaligned hashing to avoid
VLAs, and drops the helper function while adding sanity checks on the
resulting buffer sizes. Additionally, the __aligned_largest macro is
removed since
In the quest to remove all stack VLA usage from the kernel[1], this
removes the VLAs in SHASH_DESC_ON_STACK (via crypto_shash_descsize())
by using the maximum allowable size (which is now more clearly captured
in a macro), along with a few other cases. Similar limits are turned into
macros as
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new HASH_MAX_DIGESTSIZE from the crypto layer to allocate the upper
bounds on stack usage.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
v8 cover letter:
I continue to hope this can land in v4.19, but I realize that's unlikely.
It would be nice, though, if some of the "trivial" patches could get taken
(e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them.
*fingers crossed*
Series cover letter:
This is nearly
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new upper bound for the stack buffer. Also adds a sanity check.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
[Please don't top-post.. it really compromises the ability to provide
proper context for inlined replies, etc]
On Fri, Aug 03 2018 at 11:13pm -0400,
Drew Hastings wrote:
>Thank you for that insight, I appreciate it.
>Can you elaborate on your concern related to running out of space?
>
>
On Tue, Aug 7, 2018 at 2:47 AM, Herbert Xu wrote:
> On Thu, Aug 02, 2018 at 03:51:45PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> uses the upper bounds on blocksize. Since this is always a cipher
>> blocksize, use the existing cipher max
On Tue, Aug 07, 2018 at 03:39:55PM +0200, Christophe Varoqui wrote:
>Hi,
>The backlog is merged, mostly.
>Ben, your latest aggregated patchset is merged up to 15/32 included,
>pending consensus about tur locking with Bart.
>Would you rather have a release tag at this point or
Hi,
The backlog is merged, mostly.
Ben, your latest aggregated patchset is merged up to 15/32 included,
pending consensus about tur locking with Bart.
Would you rather have a release tag at this point or can it wait the merge
of your pending patches ?
Thanks,
Christophe.
On Wed, Aug 1, 2018
On Thu, Aug 02, 2018 at 03:51:45PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> uses the upper bounds on blocksize. Since this is always a cipher
> blocksize, use the existing cipher max blocksize.
>
> [1]
>
On Wednesday, July 25, 2018 8:01:47 PM CEST Kees Cook wrote:
> On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> > On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
> >> In the quest to remove all stack VLA usage from the kernel[1], this
> >> removes the discouraged use of
20 matches
Mail list logo
