From: Jakub Kicinski <kuba@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Howells <dhowells@redhat.com>,
dm-devel@redhat.com, keyrings@vger.kernel.org,
Alasdair Kergon <agk@redhat.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
Tyler Hicks <code@tyhicks.com>, Paolo Abeni <pabeni@redhat.com>,
Johan Hedberg <johan.hedberg@gmail.com>,
Marcel Holtmann <marcel@holtmann.org>,
ecryptfs@vger.kernel.org, Mike Snitzer <snitzer@kernel.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
netdev@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
Jon Maloy <jmaloy@redhat.com>,
linux-bluetooth@vger.kernel.org,
Jarkko Sakkinen <jarkko@kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Ying Xue <ying.xue@windriver.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [dm-devel] [PATCH 0/17] crypto: api - Change completion callback argument to void star
Date: Mon, 6 Feb 2023 23:10:08 -0800 [thread overview]
Message-ID: <20230206231008.64c822c1@kernel.org> (raw)
In-Reply-To: <Y+DUkqe1sagWaErA@gondor.apana.org.au>
On Mon, 6 Feb 2023 18:21:06 +0800 Herbert Xu wrote:
> The crypto completion function currently takes a pointer to a
> struct crypto_async_request object. However, in reality the API
> does not allow the use of any part of the object apart from the
> data field. For example, ahash/shash will create a fake object
> on the stack to pass along a different data field.
"different data field" == copy the value to a different structure?
A bit hard to parse TBH.
> This leads to potential bugs where the user may try to dereference
> or otherwise use the crypto_async_request object.
>
> This series changes the completion function to take a void *
> argument instead of crypto_async_request.
>
> This series touches code in a number of different subsystems.
> Most of them are trivial except for tls which was actually buggy
> as it did exactly what was described above.
Buggy means bug could be hit in real light or buggy == did not use
the API right?
> I'd like to pull all the changes through the crypto tree. But
> feel free to object if you'd like the relevant patches to go
> through your trees instead and I'll split this up.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
dm-devel@redhat.com, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, Tyler Hicks <code@tyhicks.com>,
ecryptfs@vger.kernel.org, Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-bluetooth@vger.kernel.org,
Steffen Klassert <steffen.klassert@secunet.com>,
Jon Maloy <jmaloy@redhat.com>, Ying Xue <ying.xue@windriver.com>,
Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kerne>
Subject: Re: [PATCH 0/17] crypto: api - Change completion callback argument to void star
Date: Mon, 6 Feb 2023 23:10:08 -0800 [thread overview]
Message-ID: <20230206231008.64c822c1@kernel.org> (raw)
In-Reply-To: <Y+DUkqe1sagWaErA@gondor.apana.org.au>
On Mon, 6 Feb 2023 18:21:06 +0800 Herbert Xu wrote:
> The crypto completion function currently takes a pointer to a
> struct crypto_async_request object. However, in reality the API
> does not allow the use of any part of the object apart from the
> data field. For example, ahash/shash will create a fake object
> on the stack to pass along a different data field.
"different data field" == copy the value to a different structure?
A bit hard to parse TBH.
> This leads to potential bugs where the user may try to dereference
> or otherwise use the crypto_async_request object.
>
> This series changes the completion function to take a void *
> argument instead of crypto_async_request.
>
> This series touches code in a number of different subsystems.
> Most of them are trivial except for tls which was actually buggy
> as it did exactly what was described above.
Buggy means bug could be hit in real light or buggy == did not use
the API right?
> I'd like to pull all the changes through the crypto tree. But
> feel free to object if you'd like the relevant patches to go
> through your trees instead and I'll split this up.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
dm-devel@redhat.com, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, Tyler Hicks <code@tyhicks.com>,
ecryptfs@vger.kernel.org, Marcel Holtmann <marcel@holtmann.org>,
Johan Hedberg <johan.hedberg@gmail.com>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-bluetooth@vger.kernel.org,
Steffen Klassert <steffen.klassert@secunet.com>,
Jon Maloy <jmaloy@redhat.com>, Ying Xue <ying.xue@windriver.com>,
Boris Pismenny <borisp@nvidia.com>,
John Fastabend <john.fastabend@gmail.com>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
keyrings@vger.kernel.org
Subject: Re: [PATCH 0/17] crypto: api - Change completion callback argument to void star
Date: Mon, 6 Feb 2023 23:10:08 -0800 [thread overview]
Message-ID: <20230206231008.64c822c1@kernel.org> (raw)
In-Reply-To: <Y+DUkqe1sagWaErA@gondor.apana.org.au>
On Mon, 6 Feb 2023 18:21:06 +0800 Herbert Xu wrote:
> The crypto completion function currently takes a pointer to a
> struct crypto_async_request object. However, in reality the API
> does not allow the use of any part of the object apart from the
> data field. For example, ahash/shash will create a fake object
> on the stack to pass along a different data field.
"different data field" == copy the value to a different structure?
A bit hard to parse TBH.
> This leads to potential bugs where the user may try to dereference
> or otherwise use the crypto_async_request object.
>
> This series changes the completion function to take a void *
> argument instead of crypto_async_request.
>
> This series touches code in a number of different subsystems.
> Most of them are trivial except for tls which was actually buggy
> as it did exactly what was described above.
Buggy means bug could be hit in real light or buggy == did not use
the API right?
> I'd like to pull all the changes through the crypto tree. But
> feel free to object if you'd like the relevant patches to go
> through your trees instead and I'll split this up.
next prev parent reply other threads:[~2023-02-07 7:56 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 10:21 [dm-devel] [PATCH 0/17] crypto: api - Change completion callback argument to void star Herbert Xu
2023-02-06 10:21 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 1/17] dm: Add scaffolding to change completion function signature Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 12:23 ` crypto: api - Change completion callback argument to void star bluez.test.bot
2023-02-06 17:29 ` [dm-devel] [PATCH 1/17] dm: Add scaffolding to change completion function signature Mike Snitzer
2023-02-06 17:29 ` Mike Snitzer
2023-02-06 17:29 ` Mike Snitzer
2023-02-06 10:22 ` [dm-devel] [PATCH 2/17] net: macsec: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-10 0:43 ` [dm-devel] " Jarkko Sakkinen
2023-02-10 0:43 ` Jarkko Sakkinen
2023-02-10 0:43 ` Jarkko Sakkinen
2023-02-06 10:22 ` [dm-devel] [PATCH 3/17] fs: ecryptfs: Use crypto_wait_req Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-10 0:42 ` [dm-devel] " Jarkko Sakkinen
2023-02-10 0:42 ` Jarkko Sakkinen
2023-02-10 0:42 ` Jarkko Sakkinen
2023-02-06 10:22 ` [dm-devel] [PATCH 4/17] Bluetooth: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 5/17] net: ipv4: Add scaffolding to change completion function signature Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 6/17] net: ipv6: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 7/17] tipc: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 8/17] tls: Only use data field in crypto completion function Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-07 7:15 ` [dm-devel] " Jakub Kicinski
2023-02-07 7:15 ` Jakub Kicinski
2023-02-07 7:15 ` Jakub Kicinski
2023-02-07 8:18 ` [dm-devel] [PATCH] tls: Pass rec instead of aead_req into tls_encrypt_done Herbert Xu
2023-02-07 8:18 ` Herbert Xu
2023-02-07 8:18 ` Herbert Xu
2023-02-07 8:41 ` bluez.test.bot
2023-02-07 18:50 ` [dm-devel] [PATCH] " Jakub Kicinski
2023-02-07 18:50 ` Jakub Kicinski
2023-02-07 18:50 ` Jakub Kicinski
2023-02-06 10:22 ` [dm-devel] [PATCH 9/17] KEYS: DH: Use crypto_wait_req Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 10/17] crypto: api - Use data directly in completion function Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-08 5:58 ` [dm-devel] [v2 PATCH " Herbert Xu
2023-02-08 5:58 ` Herbert Xu
2023-02-08 5:58 ` Herbert Xu
2023-02-08 6:17 ` [v2,10/17] " bluez.test.bot
2023-02-06 10:22 ` [dm-devel] [PATCH 11/17] dm: Remove completion function scaffolding Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 17:29 ` [dm-devel] " Mike Snitzer
2023-02-06 17:29 ` Mike Snitzer
2023-02-06 17:29 ` Mike Snitzer
2023-02-06 10:22 ` [dm-devel] [PATCH 12/17] net: macsec: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 13/17] net: ipv4: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 14/17] net: ipv6: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 15/17] tipc: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 16/17] tls: " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-06 10:22 ` [dm-devel] [PATCH 17/17] crypto: api - " Herbert Xu
2023-02-06 10:22 ` Herbert Xu
2023-02-10 0:56 ` [dm-devel] " Jarkko Sakkinen
2023-02-10 0:56 ` Jarkko Sakkinen
2023-02-10 0:56 ` Jarkko Sakkinen
2023-02-07 7:10 ` Jakub Kicinski [this message]
2023-02-07 7:10 ` [PATCH 0/17] crypto: api - Change completion callback argument to void star Jakub Kicinski
2023-02-07 7:10 ` Jakub Kicinski
2023-02-07 7:16 ` [dm-devel] " Jakub Kicinski
2023-02-07 7:16 ` Jakub Kicinski
2023-02-07 7:16 ` Jakub Kicinski
2023-02-07 8:03 ` [dm-devel] " Herbert Xu
2023-02-07 8:03 ` Herbert Xu
2023-02-07 8:03 ` Herbert Xu
2023-02-07 18:51 ` [dm-devel] " Jakub Kicinski
2023-02-07 18:51 ` Jakub Kicinski
2023-02-07 18:51 ` Jakub Kicinski
2023-02-08 4:02 ` [dm-devel] " Herbert Xu
2023-02-08 4:02 ` Herbert Xu
2023-02-08 4:02 ` Herbert Xu
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=20230206231008.64c822c1@kernel.org \
--to=kuba@kernel.org \
--cc=agk@redhat.com \
--cc=borisp@nvidia.com \
--cc=code@tyhicks.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dm-devel@redhat.com \
--cc=ecryptfs@vger.kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmaloy@redhat.com \
--cc=johan.hedberg@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=snitzer@kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=ying.xue@windriver.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 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.