public inbox for linux-fscrypt@vger.kernel.org
 help / color / mirror / Atom feed
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: Wed, 30 Aug 2023 09:12:15 -0700	[thread overview]
Message-ID: <20230830161215.GA893@sol.localdomain> (raw)
In-Reply-To: <2230571a-114c-0d03-d02a-fa08c2a8d483@linaro.org>

On Wed, Aug 30, 2023 at 11:00:07AM +0100, Srinivas Kandagatla wrote:
> 
> 3. We are adding these apis/callbacks in common code without doing any
> compatible or SoC checks. Is this going to be a issue if someone tries
> fscrypt?

ufs-qcom only declares support for wrapped keys if it's supported.  See patch 5
of this series:

+	if (qcom_ice_hwkm_supported(host->ice))
+		hba->quirks |= UFSHCD_QUIRK_USES_WRAPPED_CRYPTO_KEYS;

That in turn uses:

+bool qcom_ice_hwkm_supported(struct qcom_ice *ice)
+{
+	return (ice->hwkm_version > 0);
+}
+EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);

Which in turn comes from the ICE version being >= 3.2.  It does seem a bit
suspicious; it probably should check for both the ICE version and the
availability of QCOM_SCM_ES_GENERATE_ICE_KEY, QCOM_SCM_ES_PREPARE_ICE_KEY, and
QCOM_SCM_ES_IMPORT_ICE_KEY.  Regardless, it sounds like you want it to be
determined by something set in the device tree instead?  I don't think it's been
demonstrated that that's necessary.  If we can detect the hardware capabilities
dynamically, we should do that, right?

- Eric

  reply	other threads:[~2023-08-30 18:48 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
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 [this message]
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=20230830161215.GA893@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