linux-next/include
Lukas Wunner 5b553e06b3 crypto: virtio - Drop sign/verify operations
The virtio crypto driver exposes akcipher sign/verify operations in a
user space ABI.  This blocks removal of sign/verify from akcipher_alg.

Herbert opines:

   "I would say that this is something that we can break.  Breaking it
    is no different to running virtio on a host that does not support
    these algorithms.  After all, a software implementation must always
    be present.

    I deliberately left akcipher out of crypto_user because the API
    is still in flux.  We should not let virtio constrain ourselves."
    https://lore.kernel.org/all/ZtqoNAgcnXnrYhZZ@gondor.apana.org.au/

   "I would remove virtio akcipher support in its entirety.  This API
    was never meant to be exposed outside of the kernel."
    https://lore.kernel.org/all/Ztqql_gqgZiMW8zz@gondor.apana.org.au/

Drop sign/verify support from virtio crypto.  There's no strong reason
to also remove encrypt/decrypt support, so keep it.

A key selling point of virtio crypto is to allow guest access to crypto
accelerators on the host.  So far the only akcipher algorithm supported
by virtio crypto is RSA.  Dropping sign/verify merely means that the
PKCS#1 padding is now always generated or verified inside the guest,
but the actual signature generation/verification (which is an RSA
decrypt/encrypt operation) may still use an accelerator on the host.

Generating or verifying the PKCS#1 padding is cheap, so a hardware
accelerator won't be of much help there.  Which begs the question
whether virtio crypto support for sign/verify makes sense at all.

It would make sense for the sign operation if the host has a security
chip to store asymmetric private keys.  But the kernel doesn't even
have an asymmetric_key_subtype yet for hardware-based private keys.
There's at least one rudimentary driver for such chips (atmel-ecc.c for
ATECC508A), but it doesn't implement the sign operation.  The kernel
would first have to grow support for a hardware asymmetric_key_subtype
and at least one driver implementing the sign operation before exposure
to guests via virtio makes sense.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-10-05 13:22:04 +08:00
..
acpi Power management updates for 6.12-rc1 2024-09-16 07:47:50 +02:00
asm-generic asm-generic updates for 6.12 2024-09-26 11:54:40 -07:00
clocksource
crypto crypto: rsassa-pkcs1 - Migrate to sig_alg backend 2024-10-05 13:22:04 +08:00
cxl cxl: Move mailbox related bits to the same context 2024-09-12 08:38:01 -07:00
drm drm next for 6.12-rc1 2024-09-19 10:18:15 +02:00
dt-bindings soc: convert ep93xx to devicetree 2024-09-26 12:00:25 -07:00
keys KEYS: Remove unused declarations 2024-09-20 18:28:26 +03:00
kunit The core clk framework is left largely untouched this time around except for 2024-09-23 15:01:48 -07:00
kvm
linux crypto: rsassa-pkcs1 - Migrate to sig_alg backend 2024-10-05 13:22:04 +08:00
math-emu
media media: cec: move cec_get/put_device to header 2024-09-05 20:12:15 +02:00
memory
misc
net tcp: check skb is non-NULL in tcp_rto_delta_us() 2024-09-23 11:43:09 +01:00
pcmcia
ras
rdma RDMA/nldev: Add support for RDMA monitoring 2024-09-13 08:29:14 +03:00
rv
scsi SCSI misc on 20240919 2024-09-19 11:28:51 +02:00
soc soc: driver updates for 6.12 2024-09-17 10:48:09 +02:00
sound ASoC: Updates for v6.12 2024-09-14 09:09:59 +02:00
target
trace dma-mapping fixes for Linux 6.12 2024-09-29 09:35:10 -07:00
uapi crypto: virtio - Drop sign/verify operations 2024-10-05 13:22:04 +08:00
ufs Many singleton patches - please see the various changelogs for details. 2024-09-21 08:20:50 -07:00
vdso random: vDSO: add a __vdso_getrandom prototype for all architectures 2024-09-13 17:28:35 +02:00
video
xen xen: sync elfnote.h from xen tree 2024-09-25 14:15:04 +02:00