public inbox for linux-fscrypt@vger.kernel.org
 help / color / mirror / Atom feed
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

  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