| Message ID | 20220302033917.1295334-1-pizhenwei@bytedance.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce akcipher service for virtio-crypto | expand |
On Wed, Mar 02, 2022 at 11:39:13AM +0800, zhenwei pi wrote: > v2 -> v3: > Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and > minor changes of function name. > Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from > buffer if opcode is verify. > > v1 -> v2: > Fix 1 compiling warning reported by kernel test robot <lkp@intel.com> > Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of > struct virtio_crypto_config directly without size change. > Add padding in struct virtio_crypto_ecdsa_session_para to keep > 64-bit alignment. > Remove irrelevant change by code format alignment. > > Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org. > > Test with QEMU(patched by the v2 version), works fine. > > v1: > Introduce akcipher service, implement RSA algorithm, and a minor fix. > > zhenwei pi (4): > virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC > virtio-crypto: introduce akcipher service > virtio-crypto: implement RSA algorithm > virtio-crypto: rename skcipher algs > > drivers/crypto/virtio/Makefile | 3 +- > .../virtio/virtio_crypto_akcipher_algs.c | 585 ++++++++++++++++++ > drivers/crypto/virtio/virtio_crypto_common.h | 7 +- > drivers/crypto/virtio/virtio_crypto_core.c | 6 +- > drivers/crypto/virtio/virtio_crypto_mgr.c | 15 +- > ...o_algs.c => virtio_crypto_skcipher_algs.c} | 4 +- > include/uapi/linux/virtio_crypto.h | 82 ++- > 7 files changed, 693 insertions(+), 9 deletions(-) > create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c > rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%) Why is this patchset useful? That isn't explained anywhere. - Eric
On 3/3/22 4:40 AM, Eric Biggers wrote: > On Wed, Mar 02, 2022 at 11:39:13AM +0800, zhenwei pi wrote: >> v2 -> v3: >> Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and >> minor changes of function name. >> Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from >> buffer if opcode is verify. >> >> v1 -> v2: >> Fix 1 compiling warning reported by kernel test robot <lkp@intel.com> >> Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of >> struct virtio_crypto_config directly without size change. >> Add padding in struct virtio_crypto_ecdsa_session_para to keep >> 64-bit alignment. >> Remove irrelevant change by code format alignment. >> >> Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org. >> >> Test with QEMU(patched by the v2 version), works fine. >> >> v1: >> Introduce akcipher service, implement RSA algorithm, and a minor fix. >> >> zhenwei pi (4): >> virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC >> virtio-crypto: introduce akcipher service >> virtio-crypto: implement RSA algorithm >> virtio-crypto: rename skcipher algs >> >> drivers/crypto/virtio/Makefile | 3 +- >> .../virtio/virtio_crypto_akcipher_algs.c | 585 ++++++++++++++++++ >> drivers/crypto/virtio/virtio_crypto_common.h | 7 +- >> drivers/crypto/virtio/virtio_crypto_core.c | 6 +- >> drivers/crypto/virtio/virtio_crypto_mgr.c | 15 +- >> ...o_algs.c => virtio_crypto_skcipher_algs.c} | 4 +- >> include/uapi/linux/virtio_crypto.h | 82 ++- >> 7 files changed, 693 insertions(+), 9 deletions(-) >> create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c >> rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%) > > Why is this patchset useful? That isn't explained anywhere. > > - Eric > Sorry about this missing part. This feature provides akcipher service offloading capability for guest side. And I also sent a patchset of QEMU: https://patchwork.kernel.org/project/qemu-devel/cover/20220211084335.1254281-1-pizhenwei@bytedance.com/ The two patchsets work together, guest side sends encrypt/decrypt/sign/verify requests to host side, host side handles request and return response to the guest.
Hi, Michael & Lei The full patchset has been reviewed by Gonglei, thanks to Gonglei. Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue for a revoting procedure? Also cc Cornelia Huck. On 3/2/22 11:39 AM, zhenwei pi wrote: > v2 -> v3: > Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and > minor changes of function name. > Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from > buffer if opcode is verify. > > v1 -> v2: > Fix 1 compiling warning reported by kernel test robot <lkp@intel.com> > Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of > struct virtio_crypto_config directly without size change. > Add padding in struct virtio_crypto_ecdsa_session_para to keep > 64-bit alignment. > Remove irrelevant change by code format alignment. > > Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org. > > Test with QEMU(patched by the v2 version), works fine. > > v1: > Introduce akcipher service, implement RSA algorithm, and a minor fix. > > zhenwei pi (4): > virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC > virtio-crypto: introduce akcipher service > virtio-crypto: implement RSA algorithm > virtio-crypto: rename skcipher algs > > drivers/crypto/virtio/Makefile | 3 +- > .../virtio/virtio_crypto_akcipher_algs.c | 585 ++++++++++++++++++ > drivers/crypto/virtio/virtio_crypto_common.h | 7 +- > drivers/crypto/virtio/virtio_crypto_core.c | 6 +- > drivers/crypto/virtio/virtio_crypto_mgr.c | 15 +- > ...o_algs.c => virtio_crypto_skcipher_algs.c} | 4 +- > include/uapi/linux/virtio_crypto.h | 82 ++- > 7 files changed, 693 insertions(+), 9 deletions(-) > create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c > rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%) >
On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote: > Hi, Michael & Lei > > The full patchset has been reviewed by Gonglei, thanks to Gonglei. > Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" > instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue > for a revoting procedure? You can but not it probably will be deferred to 1.3. OK with you? > Also cc Cornelia Huck. > > On 3/2/22 11:39 AM, zhenwei pi wrote: > > v2 -> v3: > > Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and > > minor changes of function name. > > Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from > > buffer if opcode is verify. > > > > v1 -> v2: > > Fix 1 compiling warning reported by kernel test robot <lkp@intel.com> > > Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of > > struct virtio_crypto_config directly without size change. > > Add padding in struct virtio_crypto_ecdsa_session_para to keep > > 64-bit alignment. > > Remove irrelevant change by code format alignment. > > > > Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org. > > > > Test with QEMU(patched by the v2 version), works fine. > > > > v1: > > Introduce akcipher service, implement RSA algorithm, and a minor fix. > > > > zhenwei pi (4): > > virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC > > virtio-crypto: introduce akcipher service > > virtio-crypto: implement RSA algorithm > > virtio-crypto: rename skcipher algs > > > > drivers/crypto/virtio/Makefile | 3 +- > > .../virtio/virtio_crypto_akcipher_algs.c | 585 ++++++++++++++++++ > > drivers/crypto/virtio/virtio_crypto_common.h | 7 +- > > drivers/crypto/virtio/virtio_crypto_core.c | 6 +- > > drivers/crypto/virtio/virtio_crypto_mgr.c | 15 +- > > ...o_algs.c => virtio_crypto_skcipher_algs.c} | 4 +- > > include/uapi/linux/virtio_crypto.h | 82 ++- > > 7 files changed, 693 insertions(+), 9 deletions(-) > > create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c > > rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%) > > > > -- > zhenwei pi
On 3/7/22 5:05 PM, Michael S. Tsirkin wrote: > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote: >> Hi, Michael & Lei >> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei. >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue >> for a revoting procedure? > > You can but not it probably will be deferred to 1.3. OK with you? > OK!
On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote: >> Hi, Michael & Lei >> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei. >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue >> for a revoting procedure? > > You can but not it probably will be deferred to 1.3. OK with you? > >> Also cc Cornelia Huck. [Apologies, I'm horribly behind on my email backlog, and on virtio things in general :(] The akcipher update had been deferred for 1.2, so I think it will be 1.3 material. However, I just noticed while browsing the fine lwn.net merge window summary that this seems to have been merged already. That situation is less than ideal, although I don't expect any really bad problems, given that there had not been any negative feedback for the spec proposal that I remember.
On Mon, Apr 04, 2022 at 05:39:24PM +0200, Cornelia Huck wrote: > On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote: > >> Hi, Michael & Lei > >> > >> The full patchset has been reviewed by Gonglei, thanks to Gonglei. > >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" > >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue > >> for a revoting procedure? > > > > You can but not it probably will be deferred to 1.3. OK with you? > > > >> Also cc Cornelia Huck. > > [Apologies, I'm horribly behind on my email backlog, and on virtio > things in general :(] > > The akcipher update had been deferred for 1.2, so I think it will be 1.3 > material. However, I just noticed while browsing the fine lwn.net merge > window summary that this seems to have been merged already. That > situation is less than ideal, although I don't expect any really bad > problems, given that there had not been any negative feedback for the > spec proposal that I remember. Let's open a 1.3 branch? What do you think?
On Tue, Apr 05 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Mon, Apr 04, 2022 at 05:39:24PM +0200, Cornelia Huck wrote: >> On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: >> >> > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote: >> >> Hi, Michael & Lei >> >> >> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei. >> >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" >> >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue >> >> for a revoting procedure? >> > >> > You can but not it probably will be deferred to 1.3. OK with you? >> > >> >> Also cc Cornelia Huck. >> >> [Apologies, I'm horribly behind on my email backlog, and on virtio >> things in general :(] >> >> The akcipher update had been deferred for 1.2, so I think it will be 1.3 >> material. However, I just noticed while browsing the fine lwn.net merge >> window summary that this seems to have been merged already. That >> situation is less than ideal, although I don't expect any really bad >> problems, given that there had not been any negative feedback for the >> spec proposal that I remember. > > Let's open a 1.3 branch? What do you think? Yes, that's probably best, before things start piling up.
On Tue, Apr 05, 2022 at 10:33:42AM +0200, Cornelia Huck wrote: > On Tue, Apr 05 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Mon, Apr 04, 2022 at 05:39:24PM +0200, Cornelia Huck wrote: > >> On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote: > >> > >> > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote: > >> >> Hi, Michael & Lei > >> >> > >> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei. > >> >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;" > >> >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue > >> >> for a revoting procedure? > >> > > >> > You can but not it probably will be deferred to 1.3. OK with you? > >> > > >> >> Also cc Cornelia Huck. > >> > >> [Apologies, I'm horribly behind on my email backlog, and on virtio > >> things in general :(] > >> > >> The akcipher update had been deferred for 1.2, so I think it will be 1.3 > >> material. However, I just noticed while browsing the fine lwn.net merge > >> window summary that this seems to have been merged already. That > >> situation is less than ideal, although I don't expect any really bad > >> problems, given that there had not been any negative feedback for the > >> spec proposal that I remember. > > > > Let's open a 1.3 branch? What do you think? > > Yes, that's probably best, before things start piling up. OK, want to do it? And we can then start voting on 1.3 things straight away.
v2 -> v3: Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and minor changes of function name. Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from buffer if opcode is verify. v1 -> v2: Fix 1 compiling warning reported by kernel test robot <lkp@intel.com> Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of struct virtio_crypto_config directly without size change. Add padding in struct virtio_crypto_ecdsa_session_para to keep 64-bit alignment. Remove irrelevant change by code format alignment. Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org. Test with QEMU(patched by the v2 version), works fine. v1: Introduce akcipher service, implement RSA algorithm, and a minor fix. zhenwei pi (4): virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC virtio-crypto: introduce akcipher service virtio-crypto: implement RSA algorithm virtio-crypto: rename skcipher algs drivers/crypto/virtio/Makefile | 3 +- .../virtio/virtio_crypto_akcipher_algs.c | 585 ++++++++++++++++++ drivers/crypto/virtio/virtio_crypto_common.h | 7 +- drivers/crypto/virtio/virtio_crypto_core.c | 6 +- drivers/crypto/virtio/virtio_crypto_mgr.c | 15 +- ...o_algs.c => virtio_crypto_skcipher_algs.c} | 4 +- include/uapi/linux/virtio_crypto.h | 82 ++- 7 files changed, 693 insertions(+), 9 deletions(-) create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%)