mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Morris <jmorris@intercode.com.au>
To: linux-kernel@vger.kernel.org
Cc: "David S. Miller" <davem@redhat.com>,
	cryptoapi-devel <cryptoapi-devel@kerneli.org>
Subject: [RFC] Hardware support notes for the kernel crypto API (2.5+)
Date: Sun, 15 Dec 2002 00:51:25 +1100 (EST)	[thread overview]
Message-ID: <Mutt.LNX.4.44.0212150025190.24712-100000@blackbird.intercode.com.au> (raw)

Below are some initial notes on hardware support for the kernel crypto
API, discussing some initial requirements, vendor documentation status,
GPL driver status, and pointers to resources and earlier discussions on
the topic.

The focus at the moment is on gathering the requirements for generic
hardware crypto devices, which can be used to assist kernel components
(e.g. IPsec, CIFS), and userspace applications (e.g. SSL, IKE).  Some work 
has begun on obtaining documentation from vendors and developing clean GPL 
drivers.

Comments welcome, please consider following up to cryptoapi-devel for 
ongoing discussion.

(This document is also maintained at http://samba.org/~jamesm/crypto/)

------------------------------------------------------------------------------
Linux Kernel Crypto API - Hardware Support Notes
Last updated 15 Dec 2002
------------------------------------------------------------------------------

Requirements
  
  - Crypto hardware will require an asynchronous API with callbacks via
    softirq.
    
  - Multiple card support:
      Request dispatcher, needs to ensure requests are balanced
      across cards.
      
      Allow parallel operation for the same session: need to
      reserve session across all boards and dispatch appropriately.

  - Request dispatcher therefore required, and must have knowledge
    of cards: session support, session id format, algorithms, 
    batching capability, SG support etc.
  
  - Driver might be passed a logical request from the dispatcher
    in the form of:
      
      command = {operation, context, source, destination}
    
    How to handle scatter/gather?

      command = { operation, context, source sg, destination sg}
  
    If the card supports batching, multiple commands may be grouped:
    
      { command, command, command, ... }

  - How to handle card / queue full? (top level API change: all operations
    can fail).  Fall back to software? (async api will be required to
    support software implementations as well).

  - Pipeline management (where appropriate).
  
  - How to support IPsec offload to onboard NIC?
  
  - What will the Kernel & Userspace APIs look like?
  
    Kernel:
      crypto_alloc_tfm() - current simple interface
      crypto_alloc_session() - batching of commands, IPsec offload[?] etc.
                               specify algorithm bundle, preferences, then
                               use api helpers to build and send dispatcher
                               requests.

    Userspace:
      cryptoapifs? (see
      http://www.kerneli.org/pipermail/cryptoapi-devel/2002-December/000320.html)
    
  - Asymmetric crypto?

  - Existing kernel APIs with hardware support:
    - OpenBSD crypto queue
    - Cryptolib by Martin Gadbois,
      http://sources.colubris.com/en/projects/FreeSWAN/
      (what license does cryptolib use?)
    
  - Other discussions/proposals/code:
    - Michael Richardson
      http://mail.nl.linux.org/linux-crypto/2002-07/msg00054.html
      (also see followup threads on cryptoapi-devel)
    - Bart Trojanowski's Generic Engine
      http://www.jukie.net/~bart/genericengine/
      

Hardware documentation status:

  HiFn
    Documentation for Hifn cards available via download at their web site.
  
  IBM
    Can provide driver source for the card, and some general documentation is
    available at http://www.ibm.com/security/cryptocards/
    Software development toolkit is export controlled (contact IBM for more
    info).
    
  Motorola
    Unknown (Steve is working on some Linux drivers though).
    
  Intel
    Crypto documentation for NICs unavailable.
    
  3COM
    Crypto documentation for NICs unavailable.
    
  Broadcom
    No response to emails.
    
  AEP/Baltimore
    Unknown (not contacted yet, Linux driver available).
    
  Corrent
    Unknown (not contacted yet).
   
  Eracom
    Contacted some time ago, documentation had to be purchased (expensive).
    Not sure if this has changed.
    
  Safenet
    Unknown (not contacted yet).  
  

GPL Driver status:

  HiFn 7751
    James Morris (in progress).
  
  HiFn 7951
    David Bryson (in progress).
    Also see http://sourceforge.net/projects/hifn7951/
  
  HiFn 7901
    See http://sources.colubris.com/en/projects/FreeSWAN/
    
  Motorola MPC190, MPC184
    Steve (in progress).
    
  IBM 4758
    Available from IBM on request.

  AEP paep
    A dual licensed GPL/BSD driver is available somewhere.


Summary:
   I don't think we have enough documentation yet, notably none for NICs
   with crypto hardware.

------------------------------------------------------------------------------


- James
--
James Morris
<jmorris@intercode.com.au>



             reply	other threads:[~2002-12-14 13:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Mutt.LNX.4.44.0212150025190.24712-100000@blackbird.intercode.co m.au>
2002-12-14 13:51 ` James Morris [this message]
2002-12-14 21:28   ` Andrew McGregor
2002-12-15  1:15     ` James Morris
2002-12-15  4:34       ` [CryptoAPI-devel] " Justin Clift
2002-12-17 16:54         ` Jean-Luc Cooke
2002-12-17  0:15   ` [CryptoAPI-devel] " Steve Isaacs
2002-12-17  0:56   ` Steve Isaacs

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=Mutt.LNX.4.44.0212150025190.24712-100000@blackbird.intercode.com.au \
    --to=jmorris@intercode.com.au \
    --cc=cryptoapi-devel@kerneli.org \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®