All of lore.kernel.org
 help / color / mirror / Atom feed
From: Salvatore Mesoraca <s.mesoraca16@gmail.com>
To: David Laight <David.Laight@aculab.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Kees Cook <keescook@chromium.org>,
	Eric Biggers <ebiggers3@gmail.com>,
	Laura Abbott <labbott@redhat.com>
Subject: Re: [PATCH v2 0/2] crypto: removing various VLAs
Date: Mon, 9 Apr 2018 18:38:18 +0200	[thread overview]
Message-ID: <CAJHCu1+YynzroRkfZC9ki0b=RwiDOoOJB0S97uUVWSxLgac74A@mail.gmail.com> (raw)
In-Reply-To: <ca31b95a8b8e4dab90c5ea2eb6e6477f@AcuMS.aculab.com>

2018-04-09 16:35 GMT+02:00 David Laight <David.Laight@aculab.com>:
> From: Salvatore Mesoraca
>> Sent: 09 April 2018 14:55
>>
>> v2:
>>       As suggested by Herbert Xu, the blocksize and alignmask checks
>>       have been moved to crypto_check_alg.
>>       So, now, all the other separate checks are not necessary.
>>       Also, the defines have been moved to include/crypto/algapi.h.
>>
>> v1:
>>       As suggested by Laura Abbott[1], I'm resending my patch with
>>       MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they
>>       can be used in other places.
>>       I took this opportunity to deal with some other VLAs not
>>       handled in the old patch.
>
> If the constants are visible they need better names.
> Maybe CRYPTO_MAX_xxx.

You are right, in fact I renamed them, but forget to write about this
in the change log.
The new names look like MAX_CIPHER_*.

> You can also do much better than allocating MAX_BLOCKSIZE + MAX_ALIGNMASK
> bytes by requesting 'long' aligned on-stack memory.
> The easiest way is to define a union like:
>
> union crypto_tmp {
>         u8 buf[CRYPTO_MAX_TMP_BUF];
>         long buf_align;
> };
>
> Then in each function:
>
>         union tmp crypto_tmp;
>         u8 *keystream = PTR_ALIGN(tmp.buf, alignmask + 1);
>
> I think CRYPTO_MAX_TMP_BUF needs to be MAX_BLOCKSIZE + MAX_ALIGNMASK - sizeof (long).

Yeah, that would be nice, it might save us 4-8 bytes on the stack.
But I was thinking, wouldn't it be even better to do something like:

u8 buf[CRYPTO_MAX_TMP_BUF] __aligned(__alignof__(long));
u8 *keystream = PTR_ALIGN(buf, alignmask + 1);

In this case __aligned should work, if I'm not missing some other
subtle GCC caveat.

Thank you,

Salvatore

  reply	other threads:[~2018-04-09 16:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09 13:54 [PATCH v2 0/2] crypto: removing various VLAs Salvatore Mesoraca
2018-04-09 13:54 ` [PATCH v2 1/2] crypto: api - laying defines and checks for statically allocated buffers Salvatore Mesoraca
2018-04-09 13:54 ` [PATCH v2 2/2] crypto: remove several VLAs Salvatore Mesoraca
2018-04-09 14:35 ` [PATCH v2 0/2] crypto: removing various VLAs David Laight
2018-04-09 16:38   ` Salvatore Mesoraca [this message]
2018-04-11 16:20     ` David Laight
2018-04-20 16:51 ` Herbert Xu
2018-04-26 17:27   ` Salvatore Mesoraca

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='CAJHCu1+YynzroRkfZC9ki0b=RwiDOoOJB0S97uUVWSxLgac74A@mail.gmail.com' \
    --to=s.mesoraca16@gmail.com \
    --cc=David.Laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers3@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.