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>
Subject: RE: [RFC PATCH 4/5] crypto: Adds user space interface for ALG_SET_KEY_TYPE
Date: Mon, 22 Apr 2019 09:17:55 +0000 [thread overview]
Message-ID: <BN7PR02MB5124AC0C75B15E5FB66DF2B6AF220@BN7PR02MB5124.namprd02.prod.outlook.com> (raw)
In-Reply-To: <4735882.YQOrfzxm5S@tauon.chronox.de>
Hi Stephan,
Sorry for the delayed response.
Please find my response/doubts inline.
> -----Original Message-----
> From: Stephan Mueller <smueller@chronox.de>
> Sent: Thursday, January 17, 2019 5:04 PM
> 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; Kalyani Akula
> <kalyania@xilinx.com>; Sarat Chand Savitala <saratcha@xilinx.com>
> Subject: Re: [RFC PATCH 4/5] crypto: Adds user space interface for
> ALG_SET_KEY_TYPE
>
> Am Donnerstag, 17. Januar 2019, 08:02:20 CET schrieb Kalyani Akula:
>
> Hi Kalyani,
>
> > ALG_SET_KEY_TYPE requires caller to pass the key_type to be used for
> > AES encryption/decryption.
> >
> > Sometimes the cipher key will be stored in the device's hardware. So,
> > there is a need to specify the information about the key to use for
> > AES operations.
> >
> > In Xilinx ZynqMP SoC, below key types are available
> >
> > 1. Device key, which is flashed in the HW.
> >
> > 2. PUF KEK, which can be regenerated using the
> > helper data programmed in the HW.
> >
> > 3. User supplied key.
> >
> > So to choose the AES key to be used, this patch adds key-type attribute.
>
> You expose your particular driver interface to user space. So, user space
> would need the details of you driver to know what to set. If another driver
> has such key type support, user space would need to know about that, too. I
> do not think this is a wise idea.
>
> If we are going to have such a keytype selection, there must be a common
> user space interface for all drivers. I.e. define common key types the drivers
> then can map to their particular key type interface.
[kalyani] Agree, now we have 3 basic key types and we can define them as below
eFuse key
PUF KEK
User supplied key
But for our upcoming platform there are multiple flavors of above keys,
those may not be common for other drivers.
I will check on this further and update.
>
> 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 ?
>
> Ciao
> Stephan
>
next prev parent reply other threads:[~2019-04-22 9:18 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 [this message]
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
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=BN7PR02MB5124AC0C75B15E5FB66DF2B6AF220@BN7PR02MB5124.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=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.