From: Stephan Mueller <smueller@chronox.de>
To: Kalyani Akula <kalyania@xilinx.com>, keyrings@vger.kernel.org
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: Fri, 24 May 2019 09:19:56 +0200 [thread overview]
Message-ID: <2554415.t45IJDmies@tauon.chronox.de> (raw)
In-Reply-To: <SN6PR02MB5135CE53C3E3FB34CA5E6BA8AF320@SN6PR02MB5135.namprd02.prod.outlook.com>
Am Mittwoch, 8. Mai 2019, 11:31:08 CEST schrieb Kalyani Akula:
Hi Kalyani,
> 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)?
I am not intimately familiary with the keyring facility. Thus, let us ask the
experts at the keyring mailing list :-)
>
> 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
Ciao
Stephan
next prev parent reply other threads:[~2019-05-24 7:20 UTC|newest]
Thread overview: 17+ 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
2019-05-24 6:50 ` Kalyani Akula
2019-05-24 7:19 ` Stephan Mueller [this message]
2019-06-10 5:20 ` Kalyani Akula
2019-06-10 6:35 ` Herbert Xu
2019-07-11 9:25 ` Kalyani Akula
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=2554415.t45IJDmies@tauon.chronox.de \
--to=smueller@chronox.de \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kalyania@xilinx.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=saratcha@xilinx.com \
/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®