| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <98cc8d71d5d9476297a54774c382030d@quicinc.com>
Date: Tue, 10 Sep 2024 00:51:18 +0000
From: "Gaurav Kashyap (QUIC)" <quic_gaurkash@...cinc.com>
To: "dmitry.baryshkov@...aro.org" <dmitry.baryshkov@...aro.org>,
"Neil
Armstrong" <neil.armstrong@...aro.org>
CC: Bartosz Golaszewski <brgl@...ev.pl>, Jens Axboe <axboe@...nel.dk>,
Jonathan Corbet <corbet@....net>, Alasdair Kergon <agk@...hat.com>,
"Mike
Snitzer" <snitzer@...nel.org>,
Mikulas Patocka <mpatocka@...hat.com>,
"Adrian
Hunter" <adrian.hunter@...el.com>,
Asutosh Das <quic_asutoshd@...cinc.com>,
Ritesh Harjani <ritesh.list@...il.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Avri Altman <avri.altman@....com>,
Bart Van Assche <bvanassche@....org>,
"James E.J. Bottomley"
<James.Bottomley@...senpartnership.com>,
"Martin K. Petersen"
<martin.petersen@...cle.com>,
Eric Biggers <ebiggers@...nel.org>,
"Theodore
Y. Ts'o" <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org>,
Alexander Viro
<viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara
<jack@...e.cz>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio
<konradybcio@...nel.org>,
"manivannan.sadhasivam@...aro.org"
<manivannan.sadhasivam@...aro.org>,
"Gaurav Kashyap (QUIC)"
<quic_gaurkash@...cinc.com>,
"linux-block@...r.kernel.org"
<linux-block@...r.kernel.org>,
"linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"dm-devel@...ts.linux.dev"
<dm-devel@...ts.linux.dev>,
"linux-mmc@...r.kernel.org"
<linux-mmc@...r.kernel.org>,
"linux-scsi@...r.kernel.org"
<linux-scsi@...r.kernel.org>,
"linux-fscrypt@...r.kernel.org"
<linux-fscrypt@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org"
<linux-fsdevel@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org"
<linux-arm-msm@...r.kernel.org>,
bartosz.golaszewski
<bartosz.golaszewski@...aro.org>
Subject: RE: [PATCH v6 09/17] soc: qcom: ice: add HWKM support to the ICE
driver
Hello Dmitry and Neil
On Monday, September 9, 2024 2:44 AM PDT, Dmitry Baryshkov wrote:
> On Mon, Sep 09, 2024 at 10:58:30AM GMT, Neil Armstrong wrote:
> > On 07/09/2024 00:07, Dmitry Baryshkov wrote:
> > > On Fri, Sep 06, 2024 at 08:07:12PM GMT, Bartosz Golaszewski wrote:
> > > > From: Gaurav Kashyap <quic_gaurkash@...cinc.com>
> > > >
> > > > Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> > > > management hardware called Hardware Key Manager (HWKM). Add
> HWKM
> > > > support to the ICE driver if it is available on the platform. HWKM
> > > > primarily provides hardware wrapped key support where the ICE
> > > > (storage) keys are not available in software and instead protected in
> hardware.
> > > >
> > > > When HWKM software support is not fully available (from
> > > > Trustzone), there can be a scenario where the ICE hardware
> > > > supports HWKM, but it cannot be used for wrapped keys. In this
> > > > case, raw keys have to be used without using the HWKM. We query
> > > > the TZ at run-time to find out whether wrapped keys support is
> available.
> > > >
> > > > Tested-by: Neil Armstrong <neil.armstrong@...aro.org>
> > > > Signed-off-by: Gaurav Kashyap <quic_gaurkash@...cinc.com>
> > > > Signed-off-by: Bartosz Golaszewski
> > > > <bartosz.golaszewski@...aro.org>
> > > > ---
> > > > drivers/soc/qcom/ice.c | 152
> +++++++++++++++++++++++++++++++++++++++++++++++--
> > > > include/soc/qcom/ice.h | 1 +
> > > > 2 files changed, 149 insertions(+), 4 deletions(-)
> > > >
> > > > int qcom_ice_enable(struct qcom_ice *ice)
> > > > {
> > > > + int err;
> > > > +
> > > > qcom_ice_low_power_mode_enable(ice);
> > > > qcom_ice_optimization_enable(ice);
> > > > - return qcom_ice_wait_bist_status(ice);
> > > > + if (ice->use_hwkm)
> > > > + qcom_ice_enable_standard_mode(ice);
> > > > +
> > > > + err = qcom_ice_wait_bist_status(ice); if (err)
> > > > + return err;
> > > > +
> > > > + if (ice->use_hwkm)
> > > > + qcom_ice_hwkm_init(ice);
> > > > +
> > > > + return err;
> > > > }
> > > > EXPORT_SYMBOL_GPL(qcom_ice_enable);
> > > > @@ -150,6 +282,10 @@ int qcom_ice_resume(struct qcom_ice *ice)
> > > > return err;
> > > > }
> > > > + if (ice->use_hwkm) {
> > > > + qcom_ice_enable_standard_mode(ice);
> > > > + qcom_ice_hwkm_init(ice); }
> > > > return qcom_ice_wait_bist_status(ice);
> > > > }
> > > > EXPORT_SYMBOL_GPL(qcom_ice_resume);
> > > > @@ -157,6 +293,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
> > > > int qcom_ice_suspend(struct qcom_ice *ice)
> > > > {
> > > > clk_disable_unprepare(ice->core_clk);
> > > > + ice->hwkm_init_complete = false;
> > > > return 0;
> > > > }
> > > > @@ -206,6 +343,12 @@ int qcom_ice_evict_key(struct qcom_ice *ice,
> int slot)
> > > > }
> > > > EXPORT_SYMBOL_GPL(qcom_ice_evict_key);
> > > > +bool qcom_ice_hwkm_supported(struct qcom_ice *ice) { return
> > > > +ice->use_hwkm; }
> EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);
> > > > +
> > > > static struct qcom_ice *qcom_ice_create(struct device *dev,
> > > > void __iomem *base)
> > > > {
> > > > @@ -240,6 +383,7 @@ static struct qcom_ice *qcom_ice_create(struct
> device *dev,
> > > > engine->core_clk = devm_clk_get_enabled(dev, NULL);
> > > > if (IS_ERR(engine->core_clk))
> > > > return ERR_CAST(engine->core_clk);
> > > > + engine->use_hwkm = qcom_scm_has_wrapped_key_support();
> > >
> > > This still makes the decision on whether to use HW-wrapped keys on
> > > behalf of a user. I suppose this is incorrect. The user must be able
> > > to use raw keys even if HW-wrapped keys are available on the
> > > platform. One of the examples for such use-cases is if a user
> > > prefers to be able to recover stored information in case of a device
> > > failure (such recovery will be impossible if SoC is damaged and HW-
> wrapped keys are used).
> >
> > Isn't that already the case ? the BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
> size
> > is here to select HW-wrapped key, otherwise the ol' raw key is passed.
> > Just look the next patch.
> >
> > Or did I miss something ?
>
> That's a good question. If use_hwkm is set, ICE gets programmed to use
> hwkm (see qcom_ice_hwkm_init() call above). I'm not sure if it is expected
> to work properly if after such a call we pass raw key.
>
Once ICE has moved to a HWKM mode, the firmware key programming currently does not support raw keys.
This support is being added for the next Qualcomm chipset in Trustzone to support both at he same time, but that will take another year or two to hit the market.
Until that time, due to TZ (firmware) limitations , the driver can only support one or the other.
We also cannot keep moving ICE modes, due to the HWKM enablement being a one-time configurable value at boot.
> >
> > Neil
> >
> > >
> > > > if (!qcom_ice_check_supported(engine))
> > > > return ERR_PTR(-EOPNOTSUPP); diff --git
> > > > a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h index
> > > > 9dd835dba2a7..1f52e82e3e1c 100644
> > > > --- a/include/soc/qcom/ice.h
> > > > +++ b/include/soc/qcom/ice.h
> > > > @@ -34,5 +34,6 @@ int qcom_ice_program_key(struct qcom_ice *ice,
> > > > const struct blk_crypto_key *bkey,
> > > > u8 data_unit_size, int slot);
> > > > int qcom_ice_evict_key(struct qcom_ice *ice, int slot);
> > > > +bool qcom_ice_hwkm_supported(struct qcom_ice *ice);
> > > > struct qcom_ice *of_qcom_ice_get(struct device *dev);
> > > > #endif /* __QCOM_ICE_H__ */
> > > >
> > > > --
> > > > 2.43.0
> > > >
> > >
> >
>
> --
> With best wishes
> Dmitry
Regards,
Gaurav
Powered by blists - more mailing lists