All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalyani Akula <kalyania@xilinx.com>
To: Stephan Mueller <smueller@chronox.de>
Cc: "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Sarat Chand Savitala <saratcha@xilinx.com>
Subject: RE: [RFC PATCH 4/5] crypto: Adds user space interface for ALG_SET_KEY_TYPE
Date: Wed, 8 May 2019 09:31:08 +0000	[thread overview]
Message-ID: <SN6PR02MB5135CE53C3E3FB34CA5E6BA8AF320@SN6PR02MB5135.namprd02.prod.outlook.com> (raw)
In-Reply-To: <18759853.IUaQuE38eh@tauon.chronox.de>

Hi Stephan,

Keyrings is in-kernel key-management and retention facility. User can use it to manage keys used for applications. 

Xilinx cryptographic hardware has a mechanism to store keys in its internal hardware and do not have mechanism to read it back due to security reasons. 
It stores key internally in different forms like simple key, key encrypted with unique hardware DNA, key encrypted with hardware family key, 
key stored in eFUSEs/BBRAM etc. 
Based on security level expected, user can select one of the key for AES operation. Since AES hardware internally has access to these keys, 
user do not require to provide key to hardware, but need to tell which internal hardware key user application like to use for AES operation. 

Basic need is to pass information to AES hardware about which internal hardware key to be used for AES operation. 

I agree that from general use case perspective we are not selecting key type but selecting internal hardware keys provided by user. 
How about providing option to select custom hardware keys provided by hardware (AES_SEL_HW_KEY)?

Thanks
kalyani

> -----Original Message-----
> From: Stephan Mueller <smueller@chronox.de>
> Sent: Thursday, April 25, 2019 12:01 AM
> To: Kalyani Akula <kalyania@xilinx.com>
> Cc: herbert@gondor.apana.org.au; davem@davemloft.net; linux-
> crypto@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 4/5] crypto: Adds user space interface for
> ALG_SET_KEY_TYPE
> 
> Am Montag, 22. April 2019, 11:17:55 CEST schrieb Kalyani Akula:
> 
> Hi Kalyani,
> 
> > > Besides, seem to be more a key handling issue. Wouldn't it make
> > > sense to rather have such issue solved with key rings than in the
> > > kernel crypto API?
> >
> > [kalyani] Can you please elaborate on this further ?
> 
> The kernel has a keyring support in security/keys which has a user space
> interface with keyutils. That interface is commonly used for any sort of key
> manipulation.
> 
> Ciao
> Stephan
> 


  reply	other threads:[~2019-05-08  9:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17  7:02 [RFC PATCH 0/5] Add Xilinx's ZynqMP AES driver support Kalyani Akula
2019-01-17  7:02 ` [RFC PATCH 1/5] dt-bindings: crypto: Add bindings for ZynqMP AES driver Kalyani Akula
2019-01-17  7:02 ` [RFC PATCH 2/5] ARM64: zynqmp: Add Xilinix AES node Kalyani Akula
2019-01-17  7:02 ` [RFC PATCH 3/5] firmware: xilinx: Add ZynqMP aes API for AES functionality Kalyani Akula
2019-01-17  7:02 ` [RFC PATCH 4/5] crypto: Adds user space interface for ALG_SET_KEY_TYPE Kalyani Akula
2019-01-17 11:34   ` Stephan Mueller
2019-04-22  9:17     ` Kalyani Akula
2019-04-24 18:30       ` Stephan Mueller
2019-05-08  9:31         ` Kalyani Akula [this message]
2019-05-24  6:50           ` Kalyani Akula
2019-05-24  7:19           ` Stephan Mueller
2019-05-24  7:19             ` Stephan Mueller
2019-06-10  5:20             ` Kalyani Akula
2019-06-10  6:35               ` Herbert Xu
2019-06-10  6:35                 ` Herbert Xu
2019-07-11  9:25                 ` Kalyani Akula
2019-07-11 11:10                   ` Herbert Xu
2019-07-11 11:10                     ` Herbert Xu
2019-01-17  7:02 ` [RFC PATCH 5/5] crypto: Add Xilinx AES driver Kalyani Akula
2019-01-17 10:33   ` Corentin Labbe

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=SN6PR02MB5135CE53C3E3FB34CA5E6BA8AF320@SN6PR02MB5135.namprd02.prod.outlook.com \
    --to=kalyania@xilinx.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=saratcha@xilinx.com \
    --cc=smueller@chronox.de \
    /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.