Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <858709fa-5f2a-4e32-a54c-5241d211b588@huaweicloud.com>
Date:   Sat, 3 Jun 2023 18:06:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [GIT PULL] Asymmetric keys fix for v6.4-rc5
Content-Language: en-US
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        David Howells <dhowells@redhat.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Andrew Morton <akpm@linux-foundation.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
References: <4d7e38ff5bbc496cb794b50e1c5c83bcd2317e69.camel@huaweicloud.com>
 <CAHk-=wj4S0t5RnJQmF_wYwv+oMTKggwdLnrA9D1uMNKq4H4byw@mail.gmail.com>
 <CAHk-=wgCUzRNTg4fC8DF=UFnznK0M=mNUBDcsnLt7D4+HP2_1Q@mail.gmail.com>
 <97fd9066-9afc-9faa-a604-46110ed1268c@huaweicloud.com>
 <20230603160208.GA677@quark.localdomain>
From:   Roberto Sassu <roberto.sassu@huaweicloud.com>
In-Reply-To: <20230603160208.GA677@quark.localdomain>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 6/3/2023 6:02 PM, Eric Biggers wrote:
> On Sat, Jun 03, 2023 at 12:41:00PM +0200, Roberto Sassu wrote:
>> 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?
>>
> 
> I don't think there was any "finding" here.  The setkey methods in the crypto
> API aren't allowed to reuse the buffer they are passed, so the patch is fine.

That was the information I was missing.

Thanks!

Roberto