From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Eric Biggers <ebiggers@kernel.org>,
Stefan Berger <stefanb@linux.ibm.com>,
davem@davemloft.net, zohar@linux.ibm.com,
dmitry.kasatkin@gmail.com, paul@paul-moore.com,
jmorris@namei.org, serge@hallyn.com,
Jarkko Sakkinen <jarkko@kernel.org>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [GIT PULL] Asymmetric keys fix for v6.4-rc5
Date: Sat, 3 Jun 2023 12:41:00 +0200 [thread overview]
Message-ID: <97fd9066-9afc-9faa-a604-46110ed1268c@huaweicloud.com> (raw)
In-Reply-To: <CAHk-=wgCUzRNTg4fC8DF=UFnznK0M=mNUBDcsnLt7D4+HP2_1Q@mail.gmail.com>
On 6/3/2023 2:02 AM, Linus Torvalds wrote:
> On Fri, Jun 2, 2023 at 1:38 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> The patch re-uses the allocation it already does for the key data, and
>> it seems sane.
>
> Ugh. I had to check that it was ok to re-use the key buffer, but it
> does seem to be the case that you can just re-use the buffer after
> you've done that crypto_akcipher_set_priv/pub_key() call, and the
> crypto layer has to copy it into its own data structures.
Yes, we could not do it if the set_pub_key/set_priv_key methods use
internally the passed pointer. I guess it depends on the methods, for
RSA and ECDSA it seems fine (they copy to a different location).
The doubt comes because the buffer is freed after crypto_wait_req() and
not after crypto_akcipher_set_*_key(), suggesting that it could be
actually used during the crypto operation.
Rechecked the thread, and the suggestion to reuse the buffer and not
append the signature and digest at the end was by Eric Biggers.
Eric, in light of this finding, should we still reuse the buffer?
Thanks
Roberto
> I absolutely abhor the crypto interfaces. They all seem designed for
> that "external DMA engine" case that seems so horrendously pointless
> and slow. In practice so few of them are that, and we have all those
> optimized routines for doing it all on the CPU - but have in the
> meantime wasted all that time and effort into copying everything,
> turning simple buffers into sg-bufs etc etc. The amount of indirection
> and "set this state in the state machine" is just nasty, and this
> seems to all be a prime example of it all. With some of it then
> randomly going through some kthread too.
>
> I still think that patch is probably fine, but was also going "maybe
> the real problem is in that library helper function
> (asymmetric_verify(), in this case), which takes those (sig, siglen,
> digest, digestlen) arguments and turns it into a 'struct
> public_key_signature' without marshalling them.
>
> Just looking at this mess of indirection and different "helper"
> functions makes me second-guess myself about where the actual
> conversion should be - while also feeling like it should never have
> been done as a scatter-gather entry in the first place.
>
> Anyway, I don't feel competent to decide if that pull request is the
> right fix or not.
>
> But it clearly is *a* fix.
>
> Linus
next prev parent reply other threads:[~2023-06-03 10:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 14:41 [GIT PULL] Asymmetric keys fix for v6.4-rc5 Roberto Sassu
2023-06-02 17:38 ` Linus Torvalds
2023-06-02 17:52 ` Roberto Sassu
2023-06-03 0:02 ` Linus Torvalds
2023-06-03 10:41 ` Roberto Sassu [this message]
2023-06-03 16:02 ` Eric Biggers
2023-06-03 16:06 ` Roberto Sassu
2023-06-05 8:49 ` Herbert Xu
2023-06-06 11:00 ` Ard Biesheuvel
2023-06-05 14:47 ` David Howells
2023-06-05 15:36 ` pr-tracker-bot
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=97fd9066-9afc-9faa-a604-46110ed1268c@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=stable@vger.kernel.org \
--cc=stefanb@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=zohar@linux.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox