On Tue, 10 Sept 2024 at 03:51, Gaurav Kashyap (QUIC)
<quic_gaurk...@quicinc.com> wrote:
>
> 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_gaurk...@quicinc.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.armstr...@linaro.org>
> > > > > Signed-off-by: Gaurav Kashyap <quic_gaurk...@quicinc.com>
> > > > > Signed-off-by: Bartosz Golaszewski
> > > > > <bartosz.golaszew...@linaro.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.
So the init of HWKM should be delayed until the point where the user
tells if HWKM or raw keys should be used.
>
> > >
> > > 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
--
With best wishes
Dmitry
