crypto/Kconfig | 1 + crypto/Makefile | 2 + crypto/akcipher.c | 10 + crypto/asymmetric_keys/pkcs8.asn1 | 2 +- crypto/asymmetric_keys/pkcs8_parser.c | 46 +++- crypto/ecdsa.c | 3 +- crypto/ecdsa_helper.c | 45 +++ drivers/crypto/virtio/Kconfig | 1 + .../virtio/virtio_crypto_akcipher_algs.c | 259 ++++++++++++++++-- include/crypto/internal/ecdsa.h | 15 + include/linux/asn1_encoder.h | 2 + lib/asn1_encoder.c | 3 +- 12 files changed, 361 insertions(+), 28 deletions(-) create mode 100644 crypto/ecdsa_helper.c create mode 100644 include/crypto/internal/ecdsa.h
From: lei he <helei.sig11@bytedance.com> This patch supports the ECDSA algorithm for virtio-crypto. V1 -> V2: - explicitly specified an appropriate base commit. - fixed the link error reported by kernel test robot <lkp@intl.com>. - removed irrelevant commits. V1: - fixed the problem that the max_signature_size of ECDSA is incorrectly calculated. - make pkcs8_private_key_parser can identify ECDSA private keys. - implement ECDSA algorithm for virtio-crypto device lei he (4): crypto: fix the calculation of max_size for ECDSA crypto: pkcs8 parser support ECDSA private keys crypto: remove unused field in pkcs8_parse_context virtio-crypto: support ECDSA algorithm crypto/Kconfig | 1 + crypto/Makefile | 2 + crypto/akcipher.c | 10 + crypto/asymmetric_keys/pkcs8.asn1 | 2 +- crypto/asymmetric_keys/pkcs8_parser.c | 46 +++- crypto/ecdsa.c | 3 +- crypto/ecdsa_helper.c | 45 +++ drivers/crypto/virtio/Kconfig | 1 + .../virtio/virtio_crypto_akcipher_algs.c | 259 ++++++++++++++++-- include/crypto/internal/ecdsa.h | 15 + include/linux/asn1_encoder.h | 2 + lib/asn1_encoder.c | 3 +- 12 files changed, 361 insertions(+), 28 deletions(-) create mode 100644 crypto/ecdsa_helper.c create mode 100644 include/crypto/internal/ecdsa.h base-commit: 018ab4fabddd94f1c96f3b59e180691b9e88d5d8 -- 2.20.1
On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote: > From: lei he <helei.sig11@bytedance.com> > > This patch supports the ECDSA algorithm for virtio-crypto. Why is this necessary? Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> On Jun 30, 2022, at 2:59 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote: >> From: lei he <helei.sig11@bytedance.com> >> >> This patch supports the ECDSA algorithm for virtio-crypto. > > Why is this necessary? > The main purpose of this patch is to offload ECDSA computations to virtio-crypto dev. We can modify the backend of virtio-crypto to allow hardware like Intel QAT cards to perform the actual calculations, and user-space applications such as HTTPS server can access those backend in a unified way(eg, keyctl_pk_xx syscall). Related works are also described in following patch series: https://lwn.net/ml/linux-crypto/20220525090118.43403-1-helei.sig11@bytedance.com/ > Thanks, > -- > Email: Herbert Xu <herbert@gondor.apana.org.au> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Jun 30, 2022 at 03:23:39PM +0800, Lei He wrote: > > > On Jun 30, 2022, at 2:59 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > > > On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote: > >> From: lei he <helei.sig11@bytedance.com> > >> > >> This patch supports the ECDSA algorithm for virtio-crypto. > > > > Why is this necessary? > > > > The main purpose of this patch is to offload ECDSA computations to virtio-crypto dev. > We can modify the backend of virtio-crypto to allow hardware like Intel QAT cards to > perform the actual calculations, and user-space applications such as HTTPS server > can access those backend in a unified way(eg, keyctl_pk_xx syscall). > > Related works are also described in following patch series: > https://lwn.net/ml/linux-crypto/20220525090118.43403-1-helei.sig11@bytedance.com/ IIUC, this link refers to testing performance of the RSA impl of virtio-crypto with a vhost-user backend, leveraging an Intel QAT device on the host. What's the status of that depolyment setup ? Is code for it published anywhere, and does it have dependancy on any kernel patches that are not yet posted and/or merged ? Does it cover both ECDSA and RSA yet, or still only RSA ? The QEMU backend part of the virtio-crypto support for ECDSA looks fine to merge, but obviously I'd like some positive sign that the kernel maintainers are willing to accept the guest driver side. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Jun 30, 2022, at 5:48 PM, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Thu, Jun 30, 2022 at 03:23:39PM +0800, Lei He wrote: >> >>> On Jun 30, 2022, at 2:59 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: >>> >>> On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote: >>>> From: lei he <helei.sig11@bytedance.com> >>>> >>>> This patch supports the ECDSA algorithm for virtio-crypto. >>> >>> Why is this necessary? >>> >> >> The main purpose of this patch is to offload ECDSA computations to virtio-crypto dev. >> We can modify the backend of virtio-crypto to allow hardware like Intel QAT cards to >> perform the actual calculations, and user-space applications such as HTTPS server >> can access those backend in a unified way(eg, keyctl_pk_xx syscall). >> >> Related works are also described in following patch series: >> https://lwn.net/ml/linux-crypto/20220525090118.43403-1-helei.sig11@bytedance.com/ > > IIUC, this link refers to testing performance of the RSA impl of > virtio-crypto with a vhost-user backend, leveraging an Intel QAT > device on the host. What's the status of that depolyment setup ? > Is code for it published anywhere, and does it have dependancy on > any kernel patches that are not yet posted and/or merged ? Does it > cover both ECDSA and RSA yet, or still only RSA ? > > The QEMU backend part of the virtio-crypto support for ECDSA looks fine > to merge, but obviously I'd like some positive sign that the kernel > maintainers are willing to accept the guest driver side. > 1. We have now been able to provide offload capability for nginx’s TLS handshake in the virtual machine(with the kctl-engine), and have achieved about 0.8~0.9 times performance improvement. But as you can see, when we were testing, both authentication and key exchange only supported RSA at the moment. 2. The code for the QAT offload backend is not posted now, it does not support the ECDSA, so it also does not depends on any other patches that have not been merged. To support ECDSA, this patch is required. At present, I have only implemented and tested the ECDSA for the builtin backend, and the ECDSA support for another backend that can offload is also in progress. By the way, the virtio part of QEMU( for support ECDSA) is also ready, I will post it soon.
On Thu, Jun 30, 2022 at 03:23:39PM +0800, Lei He wrote: > > The main purpose of this patch is to offload ECDSA computations to virtio-crypto dev. > We can modify the backend of virtio-crypto to allow hardware like Intel QAT cards to > perform the actual calculations, and user-space applications such as HTTPS server > can access those backend in a unified way(eg, keyctl_pk_xx syscall). The things is I don't see any driver support in the kernel for ECDSA. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> On Jun 30, 2022, at 3:41 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > The things is I don't see any driver support in the kernel for > ECDSA. > I have explained above why we need a driver that supports ECDSA, and this patch enables virtio-crypto to support ECDSA. I think this is a good time to support ECDSA in the kernel crypto framework, and there will be more drivers supporting ECDSA in the future. Looking forward to your opinion :-).
On Thu, Jun 30, 2022 at 4:37 PM Lei He <helei.sig11@bytedance.com> wrote: > I have explained above why we need a driver that supports ECDSA, ... I do not think we do. There are some security concerns. https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security
On 7/1/2022 7:12 AM, Sandy Harris wrote: > On Thu, Jun 30, 2022 at 4:37 PM Lei He <helei.sig11@bytedance.com> wrote: > >> I have explained above why we need a driver that supports ECDSA, ... > > I do not think we do. There are some security concerns. > https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Security But since tls1.0, the ECDSA algorithm has been retained to the current 1.3 version. https://en.wikipedia.org/wiki/Transport_Layer_Security#Algorithms Best regards, Lei He -- helei.sig11@bytedance.com
On Thu, Jun 30, 2022 at 04:30:39PM +0800, Lei He wrote: > > I have explained above why we need a driver that supports ECDSA, and this patch > enables virtio-crypto to support ECDSA. I think this is a good time to support ECDSA > in the kernel crypto framework, and there will be more drivers supporting ECDSA in the > future. > Looking forward to your opinion :-). Until there are drivers in the kernel it's pointless to implement this. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Jun 30, 2022, at 5:07 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Thu, Jun 30, 2022 at 04:30:39PM +0800, Lei He wrote: >> >> I have explained above why we need a driver that supports ECDSA, and this patch >> enables virtio-crypto to support ECDSA. I think this is a good time to support ECDSA >> in the kernel crypto framework, and there will be more drivers supporting ECDSA in the >> future. >> Looking forward to your opinion :-). > > Until there are drivers in the kernel it's pointless to implement > this. > I guess you mean that if there are no drivers in the linux kernel source tree that supports the ECDSA, then there is no way under linux to offload ECDSA to other devices, so even if the virtio-crypto can get the akcipher request, it can’t do better, right? I have some different opinions on this: 1. There does exist hardware for offloading ECDSA calculations, for example, IBM PCIe Cryptographic Coprocessor, Intel QAT, etc, and those chips are already on the market now. Of course, they also provided corresponding drivers to access these devices, but for some reason, these drivers have not been submitted to the kernel source tree now. 2. With this patch, when we use QEMU to create a virtual machine, people can directly access the virtio-crypto device without caring about where these akcipher requests are executed, and no need to update drivers(and other stuff) for guest kernel when the co-processor is updated. 3. I will communicate with the Intel QAT team about their plans to provide ECDSA support and ECDH support.
On Jun 30, 2022, at 8:44 PM, Lei He <helei.sig11@bytedance.com> wrote: > > On Jun 30, 2022, at 5:07 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > >> >> On Thu, Jun 30, 2022 at 04:30:39PM +0800, Lei He wrote: >>> >>> I have explained above why we need a driver that supports ECDSA, and this patch >>> enables virtio-crypto to support ECDSA. I think this is a good time to support ECDSA >>> in the kernel crypto framework, and there will be more drivers supporting ECDSA in the >>> future. >>> Looking forward to your opinion :-). >> >> Until there are drivers in the kernel it's pointless to implement >> this. >> > > I guess you mean that if there are no drivers in the linux kernel source tree that supports the > ECDSA, then there is no way under linux to offload ECDSA to other devices, so even if the > virtio-crypto can get the akcipher request, it can’t do better, right? I have some different opinions > on this: > 1. There does exist hardware for offloading ECDSA calculations, for example, IBM PCIe > Cryptographic Coprocessor, Intel QAT, etc, and those chips are already on the market now. > Of course, they also provided corresponding drivers to access these devices, but for some reason, > these drivers have not been submitted to the kernel source tree now. > 2. With this patch, when we use QEMU to create a virtual machine, people can directly access the > virtio-crypto device without caring about where these akcipher requests are executed, and no need > to update drivers(and other stuff) for guest kernel when the co-processor is updated. > 3. I will communicate with the Intel QAT team about their plans to provide ECDSA support and ECDH > support. Hi, xin: I would like to ask if you have any plans to support ECDSA in LKC for QAT driver, and if so how is it going?
On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote: > From: lei he <helei.sig11@bytedance.com> > > This patch supports the ECDSA algorithm for virtio-crypto. virtio parts: Acked-by: Michael S. Tsirkin <mst@redhat.com> > V1 -> V2: > - explicitly specified an appropriate base commit. > - fixed the link error reported by kernel test robot <lkp@intl.com>. > - removed irrelevant commits. > > V1: > - fixed the problem that the max_signature_size of ECDSA is > incorrectly calculated. > - make pkcs8_private_key_parser can identify ECDSA private keys. > - implement ECDSA algorithm for virtio-crypto device > > > lei he (4): > crypto: fix the calculation of max_size for ECDSA > crypto: pkcs8 parser support ECDSA private keys > crypto: remove unused field in pkcs8_parse_context > virtio-crypto: support ECDSA algorithm > > crypto/Kconfig | 1 + > crypto/Makefile | 2 + > crypto/akcipher.c | 10 + > crypto/asymmetric_keys/pkcs8.asn1 | 2 +- > crypto/asymmetric_keys/pkcs8_parser.c | 46 +++- > crypto/ecdsa.c | 3 +- > crypto/ecdsa_helper.c | 45 +++ > drivers/crypto/virtio/Kconfig | 1 + > .../virtio/virtio_crypto_akcipher_algs.c | 259 ++++++++++++++++-- > include/crypto/internal/ecdsa.h | 15 + > include/linux/asn1_encoder.h | 2 + > lib/asn1_encoder.c | 3 +- > 12 files changed, 361 insertions(+), 28 deletions(-) > create mode 100644 crypto/ecdsa_helper.c > create mode 100644 include/crypto/internal/ecdsa.h > > > base-commit: 018ab4fabddd94f1c96f3b59e180691b9e88d5d8 > -- > 2.20.1
On Thu, Jun 23, 2022 at 03:05:46PM +0800, Lei He wrote: > From: lei he <helei.sig11@bytedance.com> > > This patch supports the ECDSA algorithm for virtio-crypto. > > V1 -> V2: > - explicitly specified an appropriate base commit. > - fixed the link error reported by kernel test robot <lkp@intl.com>. > - removed irrelevant commits. > > V1: > - fixed the problem that the max_signature_size of ECDSA is > incorrectly calculated. > - make pkcs8_private_key_parser can identify ECDSA private keys. > - implement ECDSA algorithm for virtio-crypto device So this depends on core crypto changes that need Herbert's ack. I'll drop this from my radar for now. > > lei he (4): > crypto: fix the calculation of max_size for ECDSA > crypto: pkcs8 parser support ECDSA private keys > crypto: remove unused field in pkcs8_parse_context > virtio-crypto: support ECDSA algorithm > > crypto/Kconfig | 1 + > crypto/Makefile | 2 + > crypto/akcipher.c | 10 + > crypto/asymmetric_keys/pkcs8.asn1 | 2 +- > crypto/asymmetric_keys/pkcs8_parser.c | 46 +++- > crypto/ecdsa.c | 3 +- > crypto/ecdsa_helper.c | 45 +++ > drivers/crypto/virtio/Kconfig | 1 + > .../virtio/virtio_crypto_akcipher_algs.c | 259 ++++++++++++++++-- > include/crypto/internal/ecdsa.h | 15 + > include/linux/asn1_encoder.h | 2 + > lib/asn1_encoder.c | 3 +- > 12 files changed, 361 insertions(+), 28 deletions(-) > create mode 100644 crypto/ecdsa_helper.c > create mode 100644 include/crypto/internal/ecdsa.h > > > base-commit: 018ab4fabddd94f1c96f3b59e180691b9e88d5d8 > -- > 2.20.1
© 2016 - 2024 Red Hat, Inc.