From: Eric Biggers <ebiggers@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>
Cc: Gaurav Kashyap <quic_gaurkash@quicinc.com>,
linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-block@vger.kernel.org,
linux-fscrypt@vger.kernel.org, omprsing@qti.qualcomm.com,
quic_psodagud@quicinc.com, avmenon@quicinc.com,
abel.vesa@linaro.org, quic_spuppala@quicinc.com
Subject: Re: [PATCH v2 07/10] qcom_scm: scm call for create, prepare and import keys
Date: Fri, 21 Jul 2023 21:11:13 -0700 [thread overview]
Message-ID: <20230722041113.GA5660@sol.localdomain> (raw)
In-Reply-To: <uezt2yq7i4msohz27g2j6apngjp6frvxlj2qt46vg7hnds5hrs@quyhskyzui4b>
On Fri, Jul 21, 2023 at 08:40:32PM -0700, Bjorn Andersson wrote:
> On Wed, Jul 19, 2023 at 10:04:21AM -0700, Gaurav Kashyap wrote:
> > Storage encryption has two IOCTLs for creating, importing
> > and preparing keys for encryption. For wrapped keys, these
> > IOCTLs need to interface with the secure environment, which
> > require these SCM calls.
> >
> > generate_key: This is used to generate and return a longterm
> > wrapped key. Trustzone achieves this by generating
> > a key and then wrapping it using hwkm, returning
> > a wrapped keyblob.
> > import_key: The functionality is similar to generate, but here,
> > a raw key is imported into hwkm and a longterm wrapped
> > keyblob is returned.
> > prepare_key: The longterm wrapped key from import or generate
> > is made further secure by rewrapping it with a per-boot
> > ephemeral wrapped key before installing it to the linux
> > kernel for programming to ICE.
> >
> > Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> > ---
> > drivers/firmware/qcom_scm.c | 222 +++++++++++++++++++++++++
> > drivers/firmware/qcom_scm.h | 3 +
> > include/linux/firmware/qcom/qcom_scm.h | 10 ++
> > 3 files changed, 235 insertions(+)
> >
> > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> > index 51062d5c7f7b..44dd1857747b 100644
> > --- a/drivers/firmware/qcom_scm.c
> > +++ b/drivers/firmware/qcom_scm.c
> > @@ -1210,6 +1210,228 @@ int qcom_scm_derive_sw_secret(const u8 *wrapped_key, u32 wrapped_key_size,
> > }
> > EXPORT_SYMBOL(qcom_scm_derive_sw_secret);
> >
> > +/**
> > + * qcom_scm_generate_ice_key() - Generate a wrapped key for encryption.
> > + * @longterm_wrapped_key: the wrapped key returned after key generation
>
> "longterm" was long enough that you didn't feel it made sense in the
> description ;)
>
> Jokes aside, please follow the convention described in:
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#naming
>
> "key" or "wrapped_key" sounds sufficient to me.
The naming I use in my most recent patchset that adds support for
hardware-wrapped inline encryption keys to the block layer and fscrypt
(https://lore.kernel.org/linux-block/20221216203636.81491-1-ebiggers@kernel.org/),
which this patchset is based on, is 'lt_key' for a longterm wrapped key and
'eph_key' for an ephemerally-wrapped key.
> > +int qcom_scm_prepare_ice_key(const u8 *longterm_wrapped_key,
> > + u32 longterm_wrapped_key_size,
> > + u8 *ephemeral_wrapped_key,
> > + u32 ephemeral_wrapped_key_size)
>
> wrapped, wrapped_size, ephemeral, ephemeral_size perhaps?
lt_key, lt_key_size, eph_key, eph_key_size.
- Eric
next prev parent reply other threads:[~2023-07-22 4:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 17:04 [PATCH v2 00/10] Hardware wrapped key support for qcom ice and ufs Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 01/10] ice, ufs, mmc: use blk_crypto_key for program_key Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 02/10] qcom_scm: scm call for deriving a software secret Gaurav Kashyap
2023-07-22 3:50 ` Bjorn Andersson
2023-07-22 4:18 ` Eric Biggers
2023-07-22 17:31 ` Bjorn Andersson
2023-07-19 17:04 ` [PATCH v2 03/10] soc: qcom: ice: add hwkm support in ice Gaurav Kashyap
2023-08-31 8:39 ` Neil Armstrong
2023-07-19 17:04 ` [PATCH v2 04/10] soc: qcom: ice: support for hardware wrapped keys Gaurav Kashyap
2023-08-31 9:10 ` Neil Armstrong
2023-07-19 17:04 ` [PATCH v2 05/10] ufs: core: support wrapped keys in ufs core Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 06/10] ufs: host: wrapped keys support in ufs qcom Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 07/10] qcom_scm: scm call for create, prepare and import keys Gaurav Kashyap
2023-07-19 17:48 ` Trilok Soni
2023-07-22 3:40 ` Bjorn Andersson
2023-07-22 4:11 ` Eric Biggers [this message]
2023-07-22 17:32 ` Bjorn Andersson
2023-07-19 17:04 ` [PATCH v2 08/10] ufs: core: add support for generate, import and prepare keys Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 09/10] soc: qcom: support for generate, import and prepare key Gaurav Kashyap
2023-07-22 3:56 ` Bjorn Andersson
2023-07-19 17:04 ` [PATCH v2 10/10] ufs: host: " Gaurav Kashyap
2023-07-20 2:55 ` [PATCH v2 00/10] Hardware wrapped key support for qcom ice and ufs Eric Biggers
2023-08-01 17:31 ` Gaurav Kashyap (QUIC)
2023-08-10 5:36 ` Eric Biggers
2023-08-11 0:27 ` Gaurav Kashyap (QUIC)
2023-08-11 2:19 ` Bjorn Andersson
2023-08-25 10:19 ` Srinivas Kandagatla
2023-08-25 21:07 ` Eric Biggers
2023-08-29 17:11 ` Srinivas Kandagatla
2023-08-29 18:12 ` Eric Biggers
2023-08-30 10:00 ` Srinivas Kandagatla
2023-08-30 16:12 ` Eric Biggers
2023-08-30 16:44 ` Srinivas Kandagatla
2023-09-12 10:06 ` Srinivas Kandagatla
2023-09-19 23:18 ` Gaurav Kashyap
2023-08-29 21:06 ` Konrad Dybcio
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=20230722041113.GA5660@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=abel.vesa@linaro.org \
--cc=andersson@kernel.org \
--cc=avmenon@quicinc.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=omprsing@qti.qualcomm.com \
--cc=quic_gaurkash@quicinc.com \
--cc=quic_psodagud@quicinc.com \
--cc=quic_spuppala@quicinc.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