On Mon, Jun 25, 2018 at 3:56 PM, Eric Biggers wrote:
> On Mon, Jun 25, 2018 at 02:10:25PM -0700, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this caps
>> the ahash request size similar to the other limits and adds a sanity
>> check at registration.
On Mon, Jun 25, 2018 at 02:10:25PM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this caps
> the ahash request size similar to the other limits and adds a sanity
> check at registration. Unfortunately, these reqsizes can be huge. Looking
> at all callers
On Sun, Jun 24, 2018 at 09:09:34PM +0200, Martin Wilck wrote:
> Hi Christophe,
>
> this is v3 of my small set of libmpathpersist fixes. It's based
> on your latest push. Sorry again for missing that.
>
> Changes wrt v2:
> - rebased to latest upstream (39ad8dc8)
> - added another gcc 8.1 fix,
On Mon, 2018-06-25 at 14:32 -0700, Kees Cook wrote:
> On Mon, Jun 25, 2018 at 2:23 PM, Joe Perches wrote:
> > On Mon, 2018-06-25 at 14:10 -0700, Kees Cook wrote:
> > > In the quest to remove all stack VLA usage from the kernel[1], this uses
> > > the maximum blocksize and adds a sanity check. For
On Mon, Jun 25, 2018 at 2:23 PM, Joe Perches wrote:
> On Mon, 2018-06-25 at 14:10 -0700, Kees Cook wrote:
>> 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
On Mon, 2018-06-25 at 14:10 -0700, Kees Cook wrote:
> 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.
Is it
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
Cc: Giovanni Cabiddu
Cc: Herbert Xu
Cc: "David S.
In the quest to remove all stack VLA usage from the kernel[1], this uses
the new SHASH_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
Cc: Alasdair Kergon
Cc: Mike
In the quest to remove all stack VLA usage from the kernel[1], this
uses the newly defined max digest size macro. Also adds a sanity-check
at use-time.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc:
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 caps
the ahash request size similar to the other limits and adds a sanity
check at registration. Unfortunately, these reqsizes can be huge. Looking
at all callers of crypto_ahash_set_reqsize(), the largest appears to be
664 bytes,
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
introduces max size macros for ahash, as already done for shash, and
adjust the crypto user to max state size.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Cc: Herbert Xu
Cc:
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). Similar limits are turned into macros as well.
[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. In a manual review of the callers of
crypto_skcipher_set_reqsize(), the largest was 384:
4 sun4i_cipher_req_ctx
6
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 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
Cc: Herbert Xu
Hi,
v2:
- use 512 instead of PAGE_SIZE / 8 to avoid bloat on large-page archs.
- swtich xcbc to "16" max universally.
- fix typo in bounds check for dm buffer size.
- examine actual reqsizes for skcipher and ahash instead of guessing.
- improve names and comments for alg maxes
This is nearly
partition_delimiter is UNSET by default, falling back to the kernel
default behavior to use "p" for devices ending in a digit, and ""
for others. However, the udev rules for kpartx have always used the
delimiter "-part". If a map name is changed (e.g. if an alias is
reconfigured), multipathd first
On Sun, 24 Jun 2018, Milan Broz wrote:
> (added cc to dm-devel annd Mikulas)
>
> Hi,
>
> On 06/24/2018 11:53 AM, Harald Braumann wrote:
> > Hi!
> >
> > I'm using the dm-integrity target standalone with crc32c for component
> > devices of a RAID. I don't use journaling, because the
In my previous patch f0462f0c8338, I overlooked that during path removal,
the path that mpp->hwe references may be removed and and thus mpp->hwe
may become stale. Fix it.
Fixes: f0462f0c8338 "libmultipath: use vector for for pp->hwe and mp->hwe"
Signed-off-by: Martin Wilck
---
multipathd/main.c
On Mon 25-06-18 10:42:30, Mikulas Patocka wrote:
>
>
> On Mon, 25 Jun 2018, Michal Hocko wrote:
>
> > > And the throttling in dm-bufio prevents kswapd from making forward
> > > progress, causing this situation...
> >
> > Which is what we have PF_THROTTLE_LESS for. Geez, do we have to go in
>
On Mon, 25 Jun 2018, Michal Hocko wrote:
> > And the throttling in dm-bufio prevents kswapd from making forward
> > progress, causing this situation...
>
> Which is what we have PF_THROTTLE_LESS for. Geez, do we have to go in
> circles like that? Are you even listening?
>
> [...]
>
> > And
On Mon 25-06-18 09:53:34, Mikulas Patocka wrote:
> y
>
> On Mon, 25 Jun 2018, Michal Hocko wrote:
>
> > On Fri 22-06-18 14:57:10, Mikulas Patocka wrote:
> > >
> > >
> > > On Fri, 22 Jun 2018, Michal Hocko wrote:
> > >
> > > > On Fri 22-06-18 08:52:09, Mikulas Patocka wrote:
> > > > >
> > > >
y
On Mon, 25 Jun 2018, Michal Hocko wrote:
> On Fri 22-06-18 14:57:10, Mikulas Patocka wrote:
> >
> >
> > On Fri, 22 Jun 2018, Michal Hocko wrote:
> >
> > > On Fri 22-06-18 08:52:09, Mikulas Patocka wrote:
> > > >
> > > >
> > > > On Fri, 22 Jun 2018, Michal Hocko wrote:
> > > >
> > > > >
On Fri 22-06-18 14:57:10, Mikulas Patocka wrote:
>
>
> On Fri, 22 Jun 2018, Michal Hocko wrote:
>
> > On Fri 22-06-18 08:52:09, Mikulas Patocka wrote:
> > >
> > >
> > > On Fri, 22 Jun 2018, Michal Hocko wrote:
> > >
> > > > On Fri 22-06-18 11:01:51, Michal Hocko wrote:
> > > > > On Thu
On Thu, Jun 21, 2018 at 05:13:39AM +0300, Andy Shevchenko wrote:
> On Tue, Jun 19, 2018 at 2:10 AM, Andrew Morton
> wrote:
> > On Mon, 18 Jun 2018 15:01:43 -0700 Dmitry Torokhov
> > wrote:
>
> >> We can't as we end up including bitmap.h (by the way of cpumask.h)
> >> form slab.h, so we gen
27 matches
Mail list logo
