All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Will Deacon <will@kernel.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH v3 1/7] crypto: handle zero sized AEAD inputs correctly
Date: Fri, 21 May 2021 15:55:44 +0800	[thread overview]
Message-ID: <20210521075544.kywxswbfyoauvhmg@gondor.apana.org.au> (raw)
In-Reply-To: <CAMj1kXHofDrzEs4qc8VNCLpyL-Hc4PSg-JXKTckJvfD6qoK78Q@mail.gmail.com>

On Wed, May 12, 2021 at 11:24:09PM +0200, Ard Biesheuvel wrote:
>
> The difference is that zero sized inputs never make sense for
> skciphers, but for AEADs, they could occur, even if they are uncommon
> (the AEAD could have associated data only, and no plain/ciphertext)

I don't see what a zero-sized input has to do with this though.
When the walk->nbytes is zero, that means that you must never
call the done function, because the walk state could be in error
in which case everything would have been freed already and calling
the done function may potentially cause a double-free.

I don't understand why in the case of AEAD you cannot structure
your code such that the done function is not called when nbytes
is zero.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

WARNING: multiple messages have this Message-ID (diff)
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Will Deacon <will@kernel.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH v3 1/7] crypto: handle zero sized AEAD inputs correctly
Date: Fri, 21 May 2021 15:55:44 +0800	[thread overview]
Message-ID: <20210521075544.kywxswbfyoauvhmg@gondor.apana.org.au> (raw)
In-Reply-To: <CAMj1kXHofDrzEs4qc8VNCLpyL-Hc4PSg-JXKTckJvfD6qoK78Q@mail.gmail.com>

On Wed, May 12, 2021 at 11:24:09PM +0200, Ard Biesheuvel wrote:
>
> The difference is that zero sized inputs never make sense for
> skciphers, but for AEADs, they could occur, even if they are uncommon
> (the AEAD could have associated data only, and no plain/ciphertext)

I don't see what a zero-sized input has to do with this though.
When the walk->nbytes is zero, that means that you must never
call the done function, because the walk state could be in error
in which case everything would have been freed already and calling
the done function may potentially cause a double-free.

I don't understand why in the case of AEAD you cannot structure
your code such that the done function is not called when nbytes
is zero.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-21  7:55 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 18:44 [PATCH v3 0/7] running kernel mode SIMD with softirqs disabled Ard Biesheuvel
2021-05-12 18:44 ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 1/7] crypto: handle zero sized AEAD inputs correctly Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 20:04   ` Eric Biggers
2021-05-12 20:04     ` Eric Biggers
2021-05-12 21:24     ` Ard Biesheuvel
2021-05-12 21:24       ` Ard Biesheuvel
2021-05-21  7:55       ` Herbert Xu [this message]
2021-05-21  7:55         ` Herbert Xu
2021-05-21  9:28         ` Ard Biesheuvel
2021-05-21  9:28           ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 2/7] crypto: aead - disallow en/decrypt for non-task or non-softirq context Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 20:06   ` Eric Biggers
2021-05-12 20:06     ` Eric Biggers
2021-05-12 21:24     ` Ard Biesheuvel
2021-05-12 21:24       ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 3/7] crypto: skcipher " Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 4/7] crypto: arm64/gcm-aes-ce - remove non-SIMD fallback path Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 5/7] crypto: arm64/aes-neonbs - stop using SIMD helper for skciphers Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 20:08   ` Eric Biggers
2021-05-12 20:08     ` Eric Biggers
2021-05-12 21:25     ` Ard Biesheuvel
2021-05-12 21:25       ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 6/7] crypto: arm64/aes-ce " Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 18:44 ` [PATCH v3 7/7] crypto: arm64/aes-ccm - remove non-SIMD fallback path Ard Biesheuvel
2021-05-12 18:44   ` Ard Biesheuvel
2021-05-12 20:11 ` [PATCH v3 0/7] running kernel mode SIMD with softirqs disabled Eric Biggers
2021-05-12 20:11   ` Eric Biggers
2021-05-12 21:31   ` Ard Biesheuvel
2021-05-12 21:31     ` Ard Biesheuvel

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=20210521075544.kywxswbfyoauvhmg@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=will@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.