io_uring and crypto

io_uring and crypto

[David Howells]

Hi Jens,

I was wondering if it might be possible to adapt io_uring to make crypto
requests as io_uring primitives rather than just having io_uring call sendmsg
and recvmsg on an AF_ALG socket.

The reason I think this might make sense is that for the certain crypto ops we
need to pass two buffers, one input and one output (encrypt, decrypt, sign) or
two input (verify) and this could directly translate to an async crypto
request.

Or possibly we should have a sendrecv socket call (RPC sort of thing) and have
io_uring drive that.

The tricky bit is that it would require two buffers and io_uring seems geared
around one.

David

Re: io_uring and crypto

[Eric Biggers]

On Tue, Oct 07, 2025 at 06:11:22PM +0100, David Howells wrote:
> Hi Jens,
> 
> I was wondering if it might be possible to adapt io_uring to make crypto
> requests as io_uring primitives rather than just having io_uring call sendmsg
> and recvmsg on an AF_ALG socket.
> 
> The reason I think this might make sense is that for the certain crypto ops we
> need to pass two buffers, one input and one output (encrypt, decrypt, sign) or
> two input (verify) and this could directly translate to an async crypto
> request.
> 
> Or possibly we should have a sendrecv socket call (RPC sort of thing) and have
> io_uring drive that.
> 
> The tricky bit is that it would require two buffers and io_uring seems geared
> around one.
> 
> David

What problem are you trying to solve that can't be solved with a
userspace crypto library?

- Eric

Re: io_uring and crypto

[Jens Axboe]

On 10/7/25 11:11 AM, David Howells wrote:
> Hi Jens,
> 
> I was wondering if it might be possible to adapt io_uring to make
> crypto requests as io_uring primitives rather than just having
> io_uring call sendmsg and recvmsg on an AF_ALG socket.
> 
> The reason I think this might make sense is that for the certain
> crypto ops we need to pass two buffers, one input and one output
> (encrypt, decrypt, sign) or two input (verify) and this could directly
> translate to an async crypto request.
> 
> Or possibly we should have a sendrecv socket call (RPC sort of thing)
> and have io_uring drive that.

You could certainly wire it up via io_uring in either way. I don't know
the crypto API, but ideally you need something where you the issue and
completions ide split, rather than just a boring sync syscall type
thing. For the latter, io_uring can't really help you outside of punting
to a thread. Having a reliable way to do non-blocking issue and then
poll for readiness if non-blocking failed would suffice, ideally you
want a way to issue/start the operation and get a callback when it
completes.

> The tricky bit is that it would require two buffers and io_uring seems
> geared around one.

io_uring doesn't care, it's just a transport in that sense. You can
define what the SQE looks like entirely for your opcode, and have 3
buffers per operation if you like.

-- 
Jens Axboe