All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
	Stefan Berger <stefanb@linux.ibm.com>,
	David Howells <dhowells@redhat.com>,
	Vitaly Chikunov <vt@altlinux.org>,
	Tadeusz Struk <tstruk@gigaio.com>,
	Andrew Zaborowski <andrew.zaborowski@intel.com>,
	Saulo Alessandre <saulo.alessandre@tse.jus.br>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	linux-crypto@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH 2/5] crypto: akcipher - Drop usage of sglists for verify op
Date: Thu, 22 Aug 2024 14:25:18 +0200	[thread overview]
Message-ID: <ZscuLueUKl9rcCGr@wunner.de> (raw)
In-Reply-To: <ZrG6w9wsb-iiLZIF@gondor.apana.org.au>

On Tue, Aug 06, 2024 at 01:55:15PM +0800, Herbert Xu wrote:
> The link between sig and akcipher is meant to be temporary.  The
> plan is to create a new low-level API for sig and then migrate
> the signature code over to that from akcipher.
> 
> Yes we do want to get rid of the unnecessary SG list ops but is
> it possible to side-step this for your work? If not perhaps you
> could help by creating the low-level API for sig? :)

Status update -- I've done that and pushed an initial version to:

  https://github.com/l1k/linux/commits/spdm-future

in commits:

  629611b crypto: sig - Introduce sig_alg backend
  39b2f45 crypto: ecdsa - Migrate to sig_alg backend
  e603b20 crypto: ecrdsa - Migrate to sig_alg backend
  299f197 crypto: rsa-pkcs1pad - Deduplicate set_{pub,priv}_key callbacks
  6c5ec06 crypto: rsassa-pkcs1 - Migrate to sig_alg backend
  6d95a64 crypto: rsassa-pkcs1 - Harden digest length verification
  17ac60d crypto: rsassa-pkcs1 - Avoid copying hash prefix
  c6c7360 crypto: drivers - Drop bogus sign/verify operations
  fb4fa6c crypto: akcipher - Drop sign/verify operations
  fb5f4d2 crypto: sig - Move crypto_sig_*() API calls to include file

I'll have to polish and test this a little more before submission.

However, I came across a snag:

There's a virtio interface for akcipher implemented by:

  drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
  include/uapi/linux/virtio_crypto.h

That's user space ABI, so we're stuck with it.  The user space ABI
combines sign/verify and encrypt/decrypt in common structs.

But it should be possible to change virtio_crypto_akcipher_algs.c
so that it uses crypto_sig or crypto_akcipher depending on the
virtio request.

That will take some more time and because I also need to prepare
for Plumbers, this work may get delayed until the next cycle.

If you want to review and maybe apply a first batch of patches to
migrate the algorithms, I can submit that.  But the removal of
sign/verify from akcipher with the above-mentioned commit fb4fa6c
("crypto: akcipher - Drop sign/verify operations") cannot happen
until virtio is migrated.

Thanks,

Lukas

  parent reply	other threads:[~2024-08-22 12:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 13:46 [PATCH 0/5] Templatize ecdsa signature decoding Lukas Wunner
2024-07-29 13:47 ` [PATCH 1/5] ASN.1: Add missing include <linux/types.h> Lukas Wunner
2024-07-30 13:50   ` Stefan Berger
2024-08-01 14:42   ` Jonathan Cameron
2024-07-29 13:48 ` [PATCH 2/5] crypto: akcipher - Drop usage of sglists for verify op Lukas Wunner
2024-08-01 16:02   ` Jonathan Cameron
2024-08-02 21:40     ` Lukas Wunner
2024-08-06  5:55   ` Herbert Xu
2024-08-06  8:32     ` Lukas Wunner
2024-08-06  8:58       ` Herbert Xu
2024-08-22 12:25     ` Lukas Wunner [this message]
2024-09-06  6:59       ` Herbert Xu
2024-07-29 13:49 ` [PATCH 3/5] crypto: ecdsa - Avoid signed integer overflow on signature decoding Lukas Wunner
2024-07-30 13:50   ` Stefan Berger
2024-08-01 16:12   ` Jonathan Cameron
2024-07-29 13:50 ` [PATCH 4/5] crypto: ecdsa - Move X9.62 signature decoding into template Lukas Wunner
2024-08-01 16:58   ` Jonathan Cameron
2024-08-03 10:13     ` Lukas Wunner
2024-07-29 13:51 ` [PATCH 5/5] crypto: ecdsa - Support P1363 signature decoding Lukas Wunner
2024-08-01 17:06   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZscuLueUKl9rcCGr@wunner.de \
    --to=lukas@wunner.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=andrew.zaborowski@intel.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=saulo.alessandre@tse.jus.br \
    --cc=stefanb@linux.ibm.com \
    --cc=tstruk@gigaio.com \
    --cc=vt@altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.