From: Eric Biggers <ebiggers@kernel.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.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 00/10] Hardware wrapped key support for qcom ice and ufs
Date: Fri, 25 Aug 2023 14:07:27 -0700 [thread overview]
Message-ID: <20230825210727.GA1366@sol.localdomain> (raw)
In-Reply-To: <f4b5512b-9922-1511-fc22-f14d25e2426a@linaro.org>
Hi Srinivas,
On Fri, Aug 25, 2023 at 11:19:41AM +0100, Srinivas Kandagatla wrote:
>
> On 19/07/2023 18:04, Gaurav Kashyap wrote:
> > These patches add support to Qualcomm ICE (Inline Crypto Enginr) for hardware
> > wrapped keys using Qualcomm Hardware Key Manager (HWKM) and are made on top
> > of a rebased version Eric Bigger's set of changes to support wrapped keys in
> > fscrypt and block below:
> > https://git.kernel.org/pub/scm/fs/fscrypt/linux.git/log/?h=wrapped-keys-v7
> > (The rebased patches are not uploaded here)
> >
> > Ref v1 here:
> > https://lore.kernel.org/linux-scsi/20211206225725.77512-1-quic_gaurkash@quicinc.com/
> >
> > Explanation and use of hardware-wrapped-keys can be found here:
> > Documentation/block/inline-encryption.rst
> >
> > This patch is organized as follows:
> >
> > Patch 1 - Prepares ICE and storage layers (UFS and EMMC) to pass around wrapped keys.
> > Patch 2 - Adds a new SCM api to support deriving software secret when wrapped keys are used
> > Patch 3-4 - Adds support for wrapped keys in the ICE driver. This includes adding HWKM support
> > Patch 5-6 - Adds support for wrapped keys in UFS
> > Patch 7-10 - Supports generate, prepare and import functionality in ICE and UFS
> >
> > NOTE: MMC will have similar changes to UFS and will be uploaded in a different patchset
> > Patch 3, 4, 8, 10 will have MMC equivalents.
> >
> > Testing:
> > Test platform: SM8550 MTP
> > Engineering trustzone image is required to test this feature only
> > for SM8550. For SM8650 onwards, all trustzone changes to support this
> > will be part of the released images.
>
> AFAIU, Prior to these proposed changes in scm, HWKM was done with help of
> TA(Trusted Application) for generate, import, unwrap ... functionality.
>
> 1. What is the reason for moving this from TA to new smc calls?
>
> Is this because of missing smckinvoke support in upstream?
>
> How scalable is this approach? Are we going to add new sec sys calls to
> every interface to TA?
>
> 2. How are the older SoCs going to deal with this, given that you are
> changing drivers that are common across these?
>
> Have you tested these patches on any older platforms?
>
> What happens if someone want to add support to wrapped keys to this
> platforms in upstream, How is that going to be handled?
>
> As I understand with this, we will endup with two possible solutions over
> time in upstream.
It's true that Qualcomm based Android devices already use HW-wrapped keys on
SoCs earlier than SM8650. The problem is that the key generation, import, and
conversion were added to Android's KeyMint HAL, as a quick way to get the
feature out the door when it was needed (so to speak). Unfortunately this
coupled this feature unnecessarily to the Android KeyMint and the corresponding
(closed source) userspace HAL provided by Qualcomm, which it's not actually
related to. I'd guess that Qualcomm's closed source userspace HAL makes SMC
calls into Qualcomm's KeyMint TA, but I have no insight into those details.
The new SMC calls eliminate the dependency on the Android-specific KeyMint.
They're also being documented by Qualcomm. So, as this patchset does, they can
be used by Linux in the implementation of new ioctls which provide a vendor
independent interface to HW-wrapped key generation, import, and conversion.
I think the new approach is the only one that is viable outside the Android
context. As such, I don't think anyone has any plan to upstream support for
HW-wrapped keys for older Qualcomm SoCs that lack the new interface.
- Eric
next prev parent reply other threads:[~2023-08-25 21:08 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
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 [this message]
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=20230825210727.GA1366@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=abel.vesa@linaro.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 \
--cc=srinivas.kandagatla@linaro.org \
/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