> In our plan, the feature is designed for HTTPS offloading case and
> other applications which use kernel RSA/ecdsa by keyctl syscall.
Hi Zhenwei,
what is the % of time spent doing asymmetric key operations in your
benchmark? I am not very familiar with crypto acceleration but my
understanding has always been that most time is spent doing either
hashing (for signing) or symmetric key operations (for encryption).
If I understand correctly, without support for acceleration these
patches are more of a demonstration of virtio-crypto, or usable for
testing purposes.
Would it be possible to extend virtio-crypto to use keys already in the
host keyctl, or in a PKCS#11 smartcard, so that virtio-crypto could also
provide the functionality of an HSM? Or does the standard require that
the keys are provided by the guest?
Paolo
On 4/12/22 17:47, Paolo Bonzini wrote:
>
>> In our plan, the feature is designed for HTTPS offloading case and
>> other applications which use kernel RSA/ecdsa by keyctl syscall.
>
> Hi Zhenwei,
>
> what is the % of time spent doing asymmetric key operations in your
> benchmark? I am not very familiar with crypto acceleration but my
> understanding has always been that most time is spent doing either
> hashing (for signing) or symmetric key operations (for encryption).
>
> If I understand correctly, without support for acceleration these
> patches are more of a demonstration of virtio-crypto, or usable for
> testing purposes.
>
Hi, Paolo
This is the perf result of nginx+openssl CPU calculation, the heavy load
from openssl uses the most time(as same as you mentioned).
27.37% 26.00% nginx libcrypto.so.1.1 [.]
__bn_sqrx8x_reduction
20.58% 19.52% nginx libcrypto.so.1.1 [.]
mulx4x_internal
16.73% 15.89% nginx libcrypto.so.1.1 [.]
bn_sqrx8x_internal
8.79% 0.00% nginx [unknown] [k]
0000000000000000
7.26% 0.00% nginx [unknown] [.]
0x89388669992a0cbc
7.00% 0.00% nginx [unknown] [k]
0x45f0e480d5f2a58e
6.76% 0.02% nginx [kernel.kallsyms] [k]
entry_SYSCALL_64_after_hwframe
6.74% 0.02% nginx [kernel.kallsyms] [k]
do_syscall_64
6.61% 0.00% nginx [unknown] [.]
0xa75a60d7820f9ffb
6.47% 0.00% nginx [unknown] [k]
0xe91223f6da36254c
5.51% 0.01% nginx [kernel.kallsyms] [k]
asm_common_interrupt
5.46% 0.01% nginx [kernel.kallsyms] [k]
common_interrupt
5.16% 0.04% nginx [kernel.kallsyms] [k]
__softirqentry_text_start
4.92% 0.01% nginx [kernel.kallsyms] [k]
irq_exit_rcu
4.91% 0.04% nginx [kernel.kallsyms] [k]
net_rx_action
This is the result of nginx+openssl keyctl offload(virtio crypto + host
keyctl + Intel QAT):
30.38% 0.08% nginx [kernel.kallsyms] [k]
entry_SYSCALL_64_after_hwframe
30.29% 0.07% nginx [kernel.kallsyms] [k]
do_syscall_64
23.84% 0.00% nginx [unknown] [k]
0000000000000000
14.24% 0.03% nginx [kernel.kallsyms] [k]
asm_common_interrupt
14.06% 0.05% nginx [kernel.kallsyms] [k]
common_interrupt
12.99% 0.11% nginx [kernel.kallsyms] [k]
__softirqentry_text_start
12.27% 0.12% nginx [kernel.kallsyms] [k]
net_rx_action
12.13% 0.03% nginx [kernel.kallsyms] [k] __napi_poll
12.06% 0.06% nginx [kernel.kallsyms] [k]
irq_exit_rcu
10.49% 0.14% nginx libssl.so.1.1 [.]
tls_process_client_key_exchange
10.21% 0.12% nginx [virtio_net] [k]
virtnet_poll
10.13% 0.04% nginx libc-2.28.so [.] syscall
10.12% 0.03% nginx kctl-engine.so [.]
kctl_rsa_priv_dec
10.02% 0.02% nginx kctl-engine.so [.]
kctl_hw_rsa_priv_func
9.98% 0.01% nginx libkeyutils.so.1.10 [.]
keyctl_pkey_decrypt
9.95% 0.02% nginx libkeyutils.so.1.10 [.] keyctl
9.77% 0.03% nginx [kernel.kallsyms] [k]
keyctl_pkey_e_d_s
8.97% 0.00% nginx [unknown] [k]
0x00007f4adbb81f0b
8.78% 0.08% nginx libpthread-2.28.so [.]
__libc_write
8.49% 0.05% nginx [kernel.kallsyms] [k]
netif_receive_skb_list_internal
The RSA part gets reduced, and the QPS of https improves to ~200%.
Something may be ignored in this cover letter:
[4] Currently RSA is supported only in builtin driver. This driver is
supposed to test the full feature without other software(Ex vhost
process) and hardware dependence.
-> Yes, this patch is a demonstration of virtio-crypto.
[5] keyctl backend is in development, we will post this feature in
Q2-2022. keyctl backend can use hardware acceleration(Ex, Intel QAT).
-> This is our plan. Currently it's still in developing.
> Would it be possible to extend virtio-crypto to use keys already in the
> host keyctl, or in a PKCS#11 smartcard, so that virtio-crypto could also
> provide the functionality of an HSM? Or does the standard require that
> the keys are provided by the guest?
>
> Paolo
I'm very interested in this, I'll try in Q3-2022 or later.
--
zhenwei pi