Asynchronous Crypto API

Herbert Xu

Netconf 2005

Background

Needed to support hardware crypto devices. Most notably PCI-based devices.

Sync interface best for CPU crypto solution. 5Gb/s achieved with VIA 1GHz processor.

Async support musn't degrade sync performance.

Current Top API

Entry points for cipher/digest/compression.

Keys and other info stored in crypto_tfm.

I/O based on scatterlist (except compression).

Reentrant under certain conditions.

Changes to Top API

Leave entry points intact.

Add callback function to crypto_tfm. Callback data to be provided separately.

Keep scatterlist, possibly merging with others.

Preserve reentrancy.

Current Cipher Bottom API

Must provide single block operations.

Option for multi-block operations.

Crypto layer converts scatterlist to blocks.

New Cipher Bottom API

Standardise on scatterlist interface.

Provide helpers that adapt single/multi block impelmentations to the scatterlist interface.

Invoke callback on completion if present.

Extend this to digest/compression.

Changes to Crypto Layer

Support for multiple implementations. Extend algorithm key to (type, name, priority) tuple. Solves the algorithm selection problem too.

Provide helpers but leave the work to the implementations.

Helpers include scatterlist walking, request queueing, etc.

Scheduling and Fail-Over

Present normal bottom interface. Sits above hardware/software drivers with the same interface. May even include other schedulers.

Flexibility with no cost to users who don't need it.

Policy should come from user-space.

Start with something simple.

Impact on Kernel Users

Sync users unaffected.

Async support requires break-up of processing. With care sync performance shouldn't degrade.

IPsec/dmcrypt are prime candidates.

Open Problems

Configuring algorithm/drivers.

User-space API (only meaningful for async).

Composite actions (cipher + digest).

Full IPsec offload.

IPsec Roadmap

Netfilter integration (and make tcpdump work).

Packet queueing.

Crypto enhancements (async, type/name, etc.).

Matching interfaces in selector.

Locking cleanup and general housekeeping.

Unified Flow Cache, v6/v4, etc.

Misc

Too many hashes. Room for code (and bug fix) reuse.

Too few netlink protocols. Extend protocol list to be a hash table with u32 key.

Drop queues completely from netlink or go for a stream version?

2005-07-09T14:41:46