On Wed, 5 Jul 2023, Eric Biggers wrote:
> On Wed, Jul 05, 2023 at 05:40:08PM +0100, Giovanni Cabiddu wrote:
>
> > Algorithms that do not set this flag will guarantee
>
> "will guarantee" => "guarantee"
>
> > that memory is not allocated during request processing, except in
> > the avoidable exception cases described below.
>
> "avoidable exception cases" => "exception cases"
>
> Whether they are avoidable depends on the user.
>
> > * Users can request an algorithm with this flag unset if they can't handle
> > * memory allocation failures or sleeping during request processing.
>
> Why add the "sleeping during request processing" part? Isn't that controlled on
> a per-request basis by CRYPTO_TFM_REQ_MAY_SLEEP which is a separate thing?
>
> > * They should also follow the constraints below.
>
> "should" => "must"
>
> > + * - The input and output scatterlists must have no more than 4 entries.
> > + * If the scatterlists contain more than 4 entries, the algorithm may
> > + * allocate memory.
>
> "If the scatterlists contains" => "If either scatterlist contains"
>
> Otherwise it is unclear whether this is talking about the length of each
> scatterlist individually, or the sum of their lengths.
>
> - Eric
Hi
I wouldn't change the meaning of CRYPTO_ALG_ALLOCATES_MEMORY (because
people will forget about this subtle change anyway).
Also note that dm-integrity allocates arbitrarily large sg-lists when
encrypting the journal, so if you change the meaning of
CRYPTO_ALG_ALLOCATES_MEMORY, there would be no flag left for dm-integrity
to test.
I would introduce a new flag, something like
CRYPTO_ALG_ALLOCATES_MEMORY_FOR_5_OR_MORE_SG_ENTRIES. dm-crypt can then
filter the algorithms based on this flag - and the rest of the kernel code
may stay unchanged.
Mikulas