All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Mike Snitzer <snitzer@redhat.com>,
	Tudor-Dan Ambarus <tudor.ambarus@microchip.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	qat-linux@intel.com, Matthew Wilcox <willy@infradead.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	device-mapper development <dm-devel@redhat.com>,
	Eric Biggers <ebiggers@google.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alasdair Kergon <agk@redhat.com>,
	linux-crypto <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH v8 0/9] crypto: Remove VLA usage
Date: Mon, 3 Sep 2018 22:50:41 -0700	[thread overview]
Message-ID: <CAGXu5jLHkNSGhR7Tk6wg8Vw-7nHPFfAgWyJ0NLMjGQw1BOKovg@mail.gmail.com> (raw)
In-Reply-To: <20180904051905.a2vyzijz6xyxvyhb@gondor.apana.org.au>

On Mon, Sep 3, 2018 at 10:19 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
>> 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 the last of the VLA removals[1], but it's one of the
>> largest because crypto gets used in lots of places. After looking
>> through code, usage, reading the threads Gustavo started, and comparing
>> the use-cases to the other VLA removals that have landed in the kernel,
>> I think this series is likely the best way forward to shut the door on
>> VLAs forever.
>>
>> For background, the crypto stack usage is for callers to do an immediate
>> bit of work that doesn't allocate new memory. This means that other VLA
>> removal techniques (like just using kmalloc) aren't workable, and the
>> next common technique is needed: examination of maximum stack usage and
>> the addition of sanity checks. This series does that, and in several
>> cases, these maximums were already implicit in the code.
>>
>> This series is intended to land via the crypto tree for 4.19, though it
>> touches dm, networking, and a few other things as well, since there are
>> dependent patches (new crypto #defines being used, etc).
>
> I have applied patches 1-4 and 6-8.  I'd like to get an ack from
> the dm folks regarding patch 5.  As to patch 9, please fix it so
> it doesn't rely on the BUG_ON to catch things.

Great! Thanks very much. I'll get a patch prepared to plumb
crypto_skcipher_set_reqsize() failures.

-Kees

-- 
Kees Cook
Pixel Security

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@google.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	Tudor-Dan Ambarus <tudor.ambarus@microchip.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Arnd Bergmann <arnd@arndb.de>, Will Deacon <will.deacon@arm.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Matthew Wilcox <willy@infradead.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-crypto <linux-crypto@vger.kernel.org>,
	device-mapper development <dm-devel@redhat.com>,
	qat-linux@intel.com, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 0/9] crypto: Remove VLA usage
Date: Mon, 3 Sep 2018 22:50:41 -0700	[thread overview]
Message-ID: <CAGXu5jLHkNSGhR7Tk6wg8Vw-7nHPFfAgWyJ0NLMjGQw1BOKovg@mail.gmail.com> (raw)
In-Reply-To: <20180904051905.a2vyzijz6xyxvyhb@gondor.apana.org.au>

On Mon, Sep 3, 2018 at 10:19 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote:
>> 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 the last of the VLA removals[1], but it's one of the
>> largest because crypto gets used in lots of places. After looking
>> through code, usage, reading the threads Gustavo started, and comparing
>> the use-cases to the other VLA removals that have landed in the kernel,
>> I think this series is likely the best way forward to shut the door on
>> VLAs forever.
>>
>> For background, the crypto stack usage is for callers to do an immediate
>> bit of work that doesn't allocate new memory. This means that other VLA
>> removal techniques (like just using kmalloc) aren't workable, and the
>> next common technique is needed: examination of maximum stack usage and
>> the addition of sanity checks. This series does that, and in several
>> cases, these maximums were already implicit in the code.
>>
>> This series is intended to land via the crypto tree for 4.19, though it
>> touches dm, networking, and a few other things as well, since there are
>> dependent patches (new crypto #defines being used, etc).
>
> I have applied patches 1-4 and 6-8.  I'd like to get an ack from
> the dm folks regarding patch 5.  As to patch 9, please fix it so
> it doesn't rely on the BUG_ON to catch things.

Great! Thanks very much. I'll get a patch prepared to plumb
crypto_skcipher_set_reqsize() failures.

-Kees

-- 
Kees Cook
Pixel Security

  reply	other threads:[~2018-09-04  5:50 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 21:18 [PATCH v8 0/9] crypto: Remove VLA usage Kees Cook
2018-08-07 21:18 ` Kees Cook
2018-08-07 21:18 ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 1/9] crypto: xcbc: " Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 2/9] crypto: cbc: " Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 3/9] crypto: ccm: " Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 4/9] crypto: hash: " Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 5/9] dm: Remove VLA usage from hashes Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-09-04  3:13   ` Herbert Xu
2018-09-13 16:41     ` Kees Cook
2018-09-13 16:41       ` Kees Cook
2018-09-13 17:54   ` Mike Snitzer
2018-09-14  6:10     ` Herbert Xu
2018-08-07 21:18 ` [PATCH v8 6/9] crypto alg: Introduce generic max blocksize and alignmask Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 7/9] crypto: qat: Remove VLA usage Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-09-25 16:12   ` Arnd Bergmann
2018-09-25 16:12     ` Arnd Bergmann
2018-09-26  8:44     ` Ard Biesheuvel
2018-09-26  8:44       ` Ard Biesheuvel
2018-09-26  8:44       ` Ard Biesheuvel
2018-09-26  8:53       ` Arnd Bergmann
2018-09-26  8:53         ` Arnd Bergmann
2018-09-26  8:55         ` Ard Biesheuvel
2018-09-26  8:55           ` Ard Biesheuvel
2018-09-26  8:55           ` Ard Biesheuvel
2018-08-07 21:18 ` [PATCH v8 8/9] crypto: shash: Remove VLA usage in unaligned hashing Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18 ` [PATCH v8 9/9] crypto: skcipher: Remove VLA usage for SKCIPHER_REQUEST_ON_STACK Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-08-07 21:18   ` Kees Cook
2018-09-04  3:15   ` Herbert Xu
2018-09-04  5:19 ` [PATCH v8 0/9] crypto: Remove VLA usage Herbert Xu
2018-09-04  5:50   ` Kees Cook [this message]
2018-09-04  5:50     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGXu5jLHkNSGhR7Tk6wg8Vw-7nHPFfAgWyJ0NLMjGQw1BOKovg@mail.gmail.com \
    --to=keescook@chromium.org \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=dm-devel@redhat.com \
    --cc=dwmw@amazon.co.uk \
    --cc=ebiggers@google.com \
    --cc=geert@linux-m68k.org \
    --cc=giovanni.cabiddu@intel.com \
    --cc=gustavo@embeddedor.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=qat-linux@intel.com \
    --cc=snitzer@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tudor.ambarus@microchip.com \
    --cc=will.deacon@arm.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.