On Jun 30, 2022, at 8:44 PM, Lei He <helei.sig11@xxxxxxxxxxxxx> wrote: > > On Jun 30, 2022, at 5:07 PM, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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?
