| Message ID | 20200221115050.238976-7-satyat@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Inline Encryption Support | expand |
On Fri, Feb 21, 2020 at 03:50:47AM -0800, Satya Tangirala wrote: > Wire up ufshcd.c with the UFS Crypto API, the block layer inline > encryption additions and the keyslot manager. > > Also, introduce UFSHCD_QUIRK_BROKEN_CRYPTO that certain UFS drivers > that don't yet support inline encryption need to use - taken from > patches by John Stultz <john.stultz@linaro.org> > (https://android-review.googlesource.com/c/kernel/common/+/1162224/5) > (https://android-review.googlesource.com/c/kernel/common/+/1162225/5) > (https://android-review.googlesource.com/c/kernel/common/+/1164506/1) Between all these quirks, with what upstream SOC does this feature actually work?
On Fri, Feb 21, 2020 at 09:22:44AM -0800, Christoph Hellwig wrote: > On Fri, Feb 21, 2020 at 03:50:47AM -0800, Satya Tangirala wrote: > > Wire up ufshcd.c with the UFS Crypto API, the block layer inline > > encryption additions and the keyslot manager. > > > > Also, introduce UFSHCD_QUIRK_BROKEN_CRYPTO that certain UFS drivers > > that don't yet support inline encryption need to use - taken from > > patches by John Stultz <john.stultz@linaro.org> > > (https://android-review.googlesource.com/c/kernel/common/+/1162224/5) > > (https://android-review.googlesource.com/c/kernel/common/+/1162225/5) > > (https://android-review.googlesource.com/c/kernel/common/+/1164506/1) > > Between all these quirks, with what upstream SOC does this feature > actually work? It will work on DragonBoard 845c, i.e. Qualcomm's Snapdragon 845 SoC, if we apply my patchset https://lkml.kernel.org/linux-block/20200110061634.46742-1-ebiggers@kernel.org/. It's currently based on Satya's v6 patchset, but I'll be rebasing it onto v7 and resending. It uses all the UFS standard crypto code that Satya is adding except for ufshcd_program_key(), which has to be replaced with a vendor-specific operation. It does also add vendor-specific code to ufs-qcom to initialize the crypto hardware, but that's in addition to the standard code, not replacing it. DragonBoard 845c is a commercially available development board that boots the mainline kernel (modulo two arm-smmu IOMMU patches that Linaro is working on), so I think it counts as an "upstream SoC". That's all that we currently have the hardware to verify ourselves, though Mediatek says that Satya's patches are working on their hardware too. And the UFS controller on Mediatek SoCs is supported by the upstream kernel via ufs-mediatek. But I don't know whether it just works exactly as-is or whether they needed to patch ufs-mediatek too. Stanley or Kuohong, can you confirm? We're also hoping that the patches are usable with the UFS controllers from Cadence Design Systems and Synopsys, which have upstream kernel support in drivers/scsi/ufs/cdns-pltfrm.c and drivers/scsi/ufs/ufshcd-dwc.c. But we don't currently have a way to verify this. But in 2018, both companies had tried to get the UFS v2.1 standard crypto support upstream, so presumably they must have implemented it in their hardware. +Cc the people who were working on that. - Eric
Hi, On Fri, 2020-02-21 at 10:11 -0800, Eric Biggers wrote: > On Fri, Feb 21, 2020 at 09:22:44AM -0800, Christoph Hellwig wrote: > > On Fri, Feb 21, 2020 at 03:50:47AM -0800, Satya Tangirala wrote: > > > Wire up ufshcd.c with the UFS Crypto API, the block layer inline > > > encryption additions and the keyslot manager. > > > > > > Also, introduce UFSHCD_QUIRK_BROKEN_CRYPTO that certain UFS drivers > > > that don't yet support inline encryption need to use - taken from > > > patches by John Stultz <john.stultz@linaro.org> > > > (https://android-review.googlesource.com/c/kernel/common/+/1162224/5) > > > (https://android-review.googlesource.com/c/kernel/common/+/1162225/5) > > > (https://android-review.googlesource.com/c/kernel/common/+/1164506/1) > > > > Between all these quirks, with what upstream SOC does this feature > > actually work? > > It will work on DragonBoard 845c, i.e. Qualcomm's Snapdragon 845 SoC, if we > apply my patchset > https://lkml.kernel.org/linux-block/20200110061634.46742-1-ebiggers@kernel.org/. > It's currently based on Satya's v6 patchset, but I'll be rebasing it onto v7 and > resending. It uses all the UFS standard crypto code that Satya is adding except > for ufshcd_program_key(), which has to be replaced with a vendor-specific > operation. It does also add vendor-specific code to ufs-qcom to initialize the > crypto hardware, but that's in addition to the standard code, not replacing it. > > DragonBoard 845c is a commercially available development board that boots the > mainline kernel (modulo two arm-smmu IOMMU patches that Linaro is working on), > so I think it counts as an "upstream SoC". > > That's all that we currently have the hardware to verify ourselves, though > Mediatek says that Satya's patches are working on their hardware too. And the > UFS controller on Mediatek SoCs is supported by the upstream kernel via > ufs-mediatek. But I don't know whether it just works exactly as-is or whether > they needed to patch ufs-mediatek too. Stanley or Kuohong, can you confirm? Yes, MediaTek is keeping work closely with inline encryption patch sets. Currently the v6 version can work well (without UFSHCD_QUIRK_BROKEN_CRYPTO quirk) at least in our MT6779 SoC platform which basic SoC support and some other peripheral drivers are under upstreaming as below link, https://patchwork.kernel.org/project/linux-mediatek/list/?state=% 2A&q=6779&series=&submitter=&delegate=&archive=both The integration with inline encryption patch set needs to patch ufs-mediatek and patches are ready in downstream. We plan to upstream them soon after inline encryption patch sets get merged. > > We're also hoping that the patches are usable with the UFS controllers from > Cadence Design Systems and Synopsys, which have upstream kernel support in > drivers/scsi/ufs/cdns-pltfrm.c and drivers/scsi/ufs/ufshcd-dwc.c. But we don't > currently have a way to verify this. But in 2018, both companies had tried to > get the UFS v2.1 standard crypto support upstream, so presumably they must have > implemented it in their hardware. +Cc the people who were working on that. > > - Eric Thanks, Stanley Chu
On Sun, Feb 23, 2020 at 09:47:36PM +0800, Stanley Chu wrote: > Yes, MediaTek is keeping work closely with inline encryption patch sets. > Currently the v6 version can work well (without > UFSHCD_QUIRK_BROKEN_CRYPTO quirk) at least in our MT6779 SoC platform > which basic SoC support and some other peripheral drivers are under > upstreaming as below link, > > https://patchwork.kernel.org/project/linux-mediatek/list/?state=% > 2A&q=6779&series=&submitter=&delegate=&archive=both > > The integration with inline encryption patch set needs to patch > ufs-mediatek and patches are ready in downstream. We plan to upstream > them soon after inline encryption patch sets get merged. What amount of support do you need in ufs-mediatek? It seems like pretty much every ufs low-level driver needs some kind of specific support now, right? I wonder if we should instead opt into the support instead of all the quirking here.
Hi Christoph, On Mon, 2020-02-24 at 15:37 -0800, Christoph Hellwig wrote: > On Sun, Feb 23, 2020 at 09:47:36PM +0800, Stanley Chu wrote: > > Yes, MediaTek is keeping work closely with inline encryption patch sets. > > Currently the v6 version can work well (without > > UFSHCD_QUIRK_BROKEN_CRYPTO quirk) at least in our MT6779 SoC platform > > which basic SoC support and some other peripheral drivers are under > > upstreaming as below link, > > > > https://patchwork.kernel.org/project/linux-mediatek/list/?state=% > > 2A&q=6779&series=&submitter=&delegate=&archive=both > > > > The integration with inline encryption patch set needs to patch > > ufs-mediatek and patches are ready in downstream. We plan to upstream > > them soon after inline encryption patch sets get merged. > > What amount of support do you need in ufs-mediatek? It seems like > pretty much every ufs low-level driver needs some kind of specific > support now, right? I wonder if we should instead opt into the support > instead of all the quirking here. The patch in ufs-mediatek is aimed to issue vendor-specific SMC calls for host initialization and configuration. This is because MediaTek UFS host has some "secure-protected" registers/features which need to be accessed/switched in secure world. Such protection is not mentioned by UFSHCI specifications thus inline encryption patch set assumes that every registers in UFSHCI can be accessed normally in kernel. This makes sense and surely the patchset can work fine in any "standard" UFS host. However if host has special design then it can work normally only if some vendor-specific treatment is applied. I think one of the reason to apply UFSHCD_QUIRK_BROKEN_CRYPTO quirk in ufs-qcom host is similar to above case. Thanks, Stanley Chu
On Tue, Feb 25, 2020 at 03:21:25PM +0800, Stanley Chu wrote: > Hi Christoph, > > On Mon, 2020-02-24 at 15:37 -0800, Christoph Hellwig wrote: > > On Sun, Feb 23, 2020 at 09:47:36PM +0800, Stanley Chu wrote: > > > Yes, MediaTek is keeping work closely with inline encryption patch sets. > > > Currently the v6 version can work well (without > > > UFSHCD_QUIRK_BROKEN_CRYPTO quirk) at least in our MT6779 SoC platform > > > which basic SoC support and some other peripheral drivers are under > > > upstreaming as below link, > > > > > > https://patchwork.kernel.org/project/linux-mediatek/list/?state=% > > > 2A&q=6779&series=&submitter=&delegate=&archive=both > > > > > > The integration with inline encryption patch set needs to patch > > > ufs-mediatek and patches are ready in downstream. We plan to upstream > > > them soon after inline encryption patch sets get merged. > > > > What amount of support do you need in ufs-mediatek? It seems like > > pretty much every ufs low-level driver needs some kind of specific > > support now, right? I wonder if we should instead opt into the support > > instead of all the quirking here. > > The patch in ufs-mediatek is aimed to issue vendor-specific SMC calls > for host initialization and configuration. This is because MediaTek UFS > host has some "secure-protected" registers/features which need to be > accessed/switched in secure world. > > Such protection is not mentioned by UFSHCI specifications thus inline > encryption patch set assumes that every registers in UFSHCI can be > accessed normally in kernel. This makes sense and surely the patchset > can work fine in any "standard" UFS host. However if host has special > design then it can work normally only if some vendor-specific treatment > is applied. > > I think one of the reason to apply UFSHCD_QUIRK_BROKEN_CRYPTO quirk in > ufs-qcom host is similar to above case. So, I had originally assumed that most kernel developers would prefer to make the UFS crypto support opt-out rather than opt-in, since that matches the normal Linux way of doing things. I.e. normally the kernel's default assumption is that devices implement the relevant standard, and only when a device is known to deviate from the standard does the driver apply quirks. But indeed, as we've investigated more vendors' UFS hardware, it seems that everyone has some quirk that needs to be handled in the platform driver: - ufs-qcom (tested on DragonBoard 845c with upstream kernel) needs vendor-specific crypto initialization logic and SMC calls to set keys - ufs-mediatek needs the quirks that Stanley mentioned above - ufs-hisi (tested on Hikey960 with upstream kernel) needs to write a vendor-specific register to use high keyslots, but even then I still couldn't get the crypto support working correctly. I'm not sure about the UFS controllers from Synopsys, Cadence, or Samsung, all of which apparently have implemented some form of the crypto support too. But I wouldn't get my hopes up that everyone followed the UFS standard precisely. So if there are no objections, IMO we should make the crypto support opt-in. That makes it even more important to upstream the crypto support for specific hardware like ufs-qcom and ufs-mediatek, since otherwise the ufshcd-crypto code would be unusable even theoretically. I'm volunteering to handle ufs-qcom with https://lkml.kernel.org/linux-block/20200110061634.46742-1-ebiggers@kernel.org/. Stanley, could you send out ufs-mediatek support as an RFC so people can see better what it involves? - Eric
Hi Eric, On Tue, 2020-02-25 at 17:12 -0800, Eric Biggers wrote: > On Tue, Feb 25, 2020 at 03:21:25PM +0800, Stanley Chu wrote: > > Hi Christoph, > > > > On Mon, 2020-02-24 at 15:37 -0800, Christoph Hellwig wrote: > > > On Sun, Feb 23, 2020 at 09:47:36PM +0800, Stanley Chu wrote: > > > > Yes, MediaTek is keeping work closely with inline encryption patch sets. > > > > Currently the v6 version can work well (without > > > > UFSHCD_QUIRK_BROKEN_CRYPTO quirk) at least in our MT6779 SoC platform > > > > which basic SoC support and some other peripheral drivers are under > > > > upstreaming as below link, > > > > > > > > https://patchwork.kernel.org/project/linux-mediatek/list/?state=% > > > > 2A&q=6779&series=&submitter=&delegate=&archive=both > > > > > > > > The integration with inline encryption patch set needs to patch > > > > ufs-mediatek and patches are ready in downstream. We plan to upstream > > > > them soon after inline encryption patch sets get merged. > > > > > > What amount of support do you need in ufs-mediatek? It seems like > > > pretty much every ufs low-level driver needs some kind of specific > > > support now, right? I wonder if we should instead opt into the support > > > instead of all the quirking here. > > > > The patch in ufs-mediatek is aimed to issue vendor-specific SMC calls > > for host initialization and configuration. This is because MediaTek UFS > > host has some "secure-protected" registers/features which need to be > > accessed/switched in secure world. > > > > Such protection is not mentioned by UFSHCI specifications thus inline > > encryption patch set assumes that every registers in UFSHCI can be > > accessed normally in kernel. This makes sense and surely the patchset > > can work fine in any "standard" UFS host. However if host has special > > design then it can work normally only if some vendor-specific treatment > > is applied. > > > > I think one of the reason to apply UFSHCD_QUIRK_BROKEN_CRYPTO quirk in > > ufs-qcom host is similar to above case. > > So, I had originally assumed that most kernel developers would prefer to make > the UFS crypto support opt-out rather than opt-in, since that matches the normal > Linux way of doing things. I.e. normally the kernel's default assumption is > that devices implement the relevant standard, and only when a device is known to > deviate from the standard does the driver apply quirks. > > But indeed, as we've investigated more vendors' UFS hardware, it seems that > everyone has some quirk that needs to be handled in the platform driver: > > - ufs-qcom (tested on DragonBoard 845c with upstream kernel) needs > vendor-specific crypto initialization logic and SMC calls to set keys > > - ufs-mediatek needs the quirks that Stanley mentioned above > > - ufs-hisi (tested on Hikey960 with upstream kernel) needs to write a > vendor-specific register to use high keyslots, but even then I still > couldn't get the crypto support working correctly. > > I'm not sure about the UFS controllers from Synopsys, Cadence, or Samsung, all > of which apparently have implemented some form of the crypto support too. But I > wouldn't get my hopes up that everyone followed the UFS standard precisely. > > So if there are no objections, IMO we should make the crypto support opt-in. > > That makes it even more important to upstream the crypto support for specific > hardware like ufs-qcom and ufs-mediatek, since otherwise the ufshcd-crypto code > would be unusable even theoretically. I'm volunteering to handle ufs-qcom with > https://lkml.kernel.org/linux-block/20200110061634.46742-1-ebiggers@kernel.org/. > Stanley, could you send out ufs-mediatek support as an RFC so people can see > better what it involves? Sure, I will send out our RFC patches. Please allow me some time for submission. Thanks, Stanley Chu > - Eric
Hi Eric and all, On Wed, 2020-02-26 at 14:43 +0800, Stanley Chu wrote: > Hi Eric, > > On Tue, 2020-02-25 at 17:12 -0800, Eric Biggers wrote: > > > > I'm not sure about the UFS controllers from Synopsys, Cadence, or Samsung, all > > of which apparently have implemented some form of the crypto support too. But I > > wouldn't get my hopes up that everyone followed the UFS standard precisely. > > > > So if there are no objections, IMO we should make the crypto support opt-in. > > > > That makes it even more important to upstream the crypto support for specific > > hardware like ufs-qcom and ufs-mediatek, since otherwise the ufshcd-crypto code > > would be unusable even theoretically. I'm volunteering to handle ufs-qcom with > > https://lkml.kernel.org/linux-block/20200110061634.46742-1-ebiggers@kernel.org/. > > Stanley, could you send out ufs-mediatek support as an RFC so people can see > > better what it involves? > > Sure, I will send out our RFC patches. Please allow me some time for > submission. The ufs-mediatek RFC patch is uploaded as https://patchwork.kernel.org/patch/11415051/ This patch is rebased to the latest wip-inline-encryption branch in Eric Biggers's git: https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/ Thanks, Stanley Chu
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c index 5d6487350a6c..fa9d4d1c43c9 100644 --- a/drivers/scsi/ufs/ufs-hisi.c +++ b/drivers/scsi/ufs/ufs-hisi.c @@ -475,6 +475,14 @@ static int ufs_hisi_init_common(struct ufs_hba *hba) if (!host) return -ENOMEM; + /* + * Inline crypto is currently broken with ufs-hisi because the keyslots + * overlap with the vendor-specific SYS CTRL registers -- and even if + * software uses only non-overlapping keyslots, the kernel crashes when + * programming a key or a UFS error occurs on the first encrypted I/O. + */ + hba->quirks |= UFSHCD_QUIRK_BROKEN_CRYPTO; + host->hba = hba; ufshcd_set_variant(hba, host); diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c index c69c29a1ceb9..4b2ec3745a16 100644 --- a/drivers/scsi/ufs/ufs-qcom.c +++ b/drivers/scsi/ufs/ufs-qcom.c @@ -1002,6 +1002,13 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba) | UFSHCD_QUIRK_DME_PEER_ACCESS_AUTO_MODE | UFSHCD_QUIRK_BROKEN_PA_RXHSUNTERMCAP); } + + /* + * Inline crypto is currently broken with ufs-qcom at least because the + * device tree doesn't include the crypto registers. There are likely + * to be other issues that will need to be addressed too. + */ + hba->quirks |= UFSHCD_QUIRK_BROKEN_CRYPTO; } static void ufs_qcom_set_caps(struct ufs_hba *hba) diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c index 1b8e14d30c04..cd7ca50a1dd9 100644 --- a/drivers/scsi/ufs/ufshcd-crypto.c +++ b/drivers/scsi/ufs/ufshcd-crypto.c @@ -365,3 +365,29 @@ void ufshcd_crypto_destroy_keyslot_manager(struct ufs_hba *hba) { blk_ksm_destroy(&hba->ksm); } + +int ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba, + struct scsi_cmnd *cmd, + struct ufshcd_lrb *lrbp) +{ + struct rq_crypt_ctx *rc = &cmd->request->rq_crypt_ctx; + struct bio_crypt_ctx *bc = rc->bc; + + lrbp->crypto_enable = false; + + if (WARN_ON(!(hba->caps & UFSHCD_CAP_CRYPTO))) { + /* + * Upper layer asked us to do inline encryption + * but that isn't enabled, so we fail this request. + */ + return -EINVAL; + } + if (!ufshcd_keyslot_valid(hba, rc->keyslot)) + return -EINVAL; + + lrbp->crypto_enable = true; + lrbp->crypto_key_slot = rc->keyslot; + lrbp->data_unit_num = bc->bc_dun[0]; + + return 0; +} diff --git a/drivers/scsi/ufs/ufshcd-crypto.h b/drivers/scsi/ufs/ufshcd-crypto.h index 8270c0c5081a..c76f93ede51c 100644 --- a/drivers/scsi/ufs/ufshcd-crypto.h +++ b/drivers/scsi/ufs/ufshcd-crypto.h @@ -16,6 +16,15 @@ static inline bool ufshcd_hba_is_crypto_supported(struct ufs_hba *hba) return hba->crypto_capabilities.reg_val != 0; } +int ufshcd_prepare_lrbp_crypto(struct ufs_hba *hba, + struct scsi_cmnd *cmd, + struct ufshcd_lrb *lrbp); + +static inline bool ufshcd_lrbp_crypto_enabled(struct ufshcd_lrb *lrbp) +{ + return lrbp->crypto_enable; +} + void ufshcd_crypto_enable(struct ufs_hba *hba); void ufshcd_crypto_disable(struct ufs_hba *hba); @@ -49,6 +58,11 @@ static inline void ufshcd_crypto_setup_rq_keyslot_manager(struct ufs_hba *hba, static inline void ufshcd_crypto_destroy_keyslot_manager(struct ufs_hba *hba) { } +static inline bool ufshcd_lrbp_crypto_enabled(struct ufshcd_lrb *lrbp) +{ + return false; +} + #endif /* CONFIG_SCSI_UFS_CRYPTO */ #endif /* _UFSHCD_CRYPTO_H */ diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 825d9eb34f10..9ecfc10feafb 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -47,6 +47,7 @@ #include "unipro.h" #include "ufs-sysfs.h" #include "ufs_bsg.h" +#include "ufshcd-crypto.h" #define CREATE_TRACE_POINTS #include <trace/events/ufs.h> @@ -816,7 +817,14 @@ static void ufshcd_enable_run_stop_reg(struct ufs_hba *hba) */ static inline void ufshcd_hba_start(struct ufs_hba *hba) { - ufshcd_writel(hba, CONTROLLER_ENABLE, REG_CONTROLLER_ENABLE); + u32 val = CONTROLLER_ENABLE; + + if (ufshcd_hba_is_crypto_supported(hba)) { + ufshcd_crypto_enable(hba); + val |= CRYPTO_GENERAL_ENABLE; + } + + ufshcd_writel(hba, val, REG_CONTROLLER_ENABLE); } /** @@ -2192,9 +2200,23 @@ static void ufshcd_prepare_req_desc_hdr(struct ufshcd_lrb *lrbp, dword_0 |= UTP_REQ_DESC_INT_CMD; /* Transfer request descriptor header fields */ + if (ufshcd_lrbp_crypto_enabled(lrbp)) { +#ifdef CONFIG_SCSI_UFS_CRYPTO + dword_0 |= UTP_REQ_DESC_CRYPTO_ENABLE_CMD; + dword_0 |= lrbp->crypto_key_slot; + req_desc->header.dword_1 = + cpu_to_le32(lower_32_bits(lrbp->data_unit_num)); + req_desc->header.dword_3 = + cpu_to_le32(upper_32_bits(lrbp->data_unit_num)); +#endif /* CONFIG_SCSI_UFS_CRYPTO */ + } else { + /* dword_1 and dword_3 are reserved, hence they are set to 0 */ + req_desc->header.dword_1 = 0; + req_desc->header.dword_3 = 0; + } + req_desc->header.dword_0 = cpu_to_le32(dword_0); - /* dword_1 is reserved, hence it is set to 0 */ - req_desc->header.dword_1 = 0; + /* * assigning invalid value for command status. Controller * updates OCS on command completion, with the command @@ -2202,8 +2224,6 @@ static void ufshcd_prepare_req_desc_hdr(struct ufshcd_lrb *lrbp, */ req_desc->header.dword_2 = cpu_to_le32(OCS_INVALID_COMMAND_STATUS); - /* dword_3 is reserved, hence it is set to 0 */ - req_desc->header.dword_3 = 0; req_desc->prd_table_length = 0; } @@ -2437,6 +2457,20 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) lrbp->task_tag = tag; lrbp->lun = ufshcd_scsi_to_upiu_lun(cmd->device->lun); lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba) ? true : false; + +#ifdef CONFIG_SCSI_UFS_CRYPTO + if (cmd->request->rq_crypt_ctx.keyslot >= 0) { + err = ufshcd_prepare_lrbp_crypto(hba, cmd, lrbp); + if (err) { + lrbp->cmd = NULL; + ufshcd_release(hba); + goto out; + } + } else { + lrbp->crypto_enable = false; + } +#endif + lrbp->req_abort_skip = false; ufshcd_comp_scsi_upiu(hba, lrbp); @@ -2470,6 +2504,9 @@ static int ufshcd_compose_dev_cmd(struct ufs_hba *hba, lrbp->task_tag = tag; lrbp->lun = 0; /* device management cmd is not specific to any LUN */ lrbp->intr_cmd = true; /* No interrupt aggregation */ +#ifdef CONFIG_SCSI_UFS_CRYPTO + lrbp->crypto_enable = false; /* No crypto operations */ +#endif hba->dev_cmd.type = cmd_type; return ufshcd_comp_devman_upiu(hba, lrbp); @@ -4208,6 +4245,8 @@ static inline void ufshcd_hba_stop(struct ufs_hba *hba, bool can_sleep) { int err; + ufshcd_crypto_disable(hba); + ufshcd_writel(hba, CONTROLLER_DISABLE, REG_CONTROLLER_ENABLE); err = ufshcd_wait_for_register(hba, REG_CONTROLLER_ENABLE, CONTROLLER_ENABLE, CONTROLLER_DISABLE, @@ -4624,6 +4663,8 @@ static int ufshcd_slave_configure(struct scsi_device *sdev) if (ufshcd_is_rpm_autosuspend_allowed(hba)) sdev->rpm_autosuspend = 1; + ufshcd_crypto_setup_rq_keyslot_manager(hba, q); + return 0; } @@ -8304,6 +8345,7 @@ EXPORT_SYMBOL_GPL(ufshcd_remove); */ void ufshcd_dealloc_host(struct ufs_hba *hba) { + ufshcd_crypto_destroy_keyslot_manager(hba); scsi_host_put(hba->host); } EXPORT_SYMBOL_GPL(ufshcd_dealloc_host); @@ -8513,6 +8555,13 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq) /* Reset the attached device */ ufshcd_vops_device_reset(hba); + /* Init crypto */ + err = ufshcd_hba_init_crypto(hba); + if (err) { + dev_err(hba->dev, "crypto setup failed\n"); + goto out_remove_scsi_host; + } + /* Host controller enable */ err = ufshcd_hba_enable(hba); if (err) { diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index 7b8a87418f0c..c8f948aa5e3d 100644 --- a/drivers/scsi/ufs/ufshcd.h +++ b/drivers/scsi/ufs/ufshcd.h @@ -168,6 +168,9 @@ struct ufs_pm_lvl_states { * @intr_cmd: Interrupt command (doesn't participate in interrupt aggregation) * @issue_time_stamp: time stamp for debug purposes * @compl_time_stamp: time stamp for statistics + * @crypto_enable: whether or not the request needs inline crypto operations + * @crypto_key_slot: the key slot to use for inline crypto + * @data_unit_num: the data unit number for the first block for inline crypto * @req_abort_skip: skip request abort task flag */ struct ufshcd_lrb { @@ -192,6 +195,11 @@ struct ufshcd_lrb { bool intr_cmd; ktime_t issue_time_stamp; ktime_t compl_time_stamp; +#if IS_ENABLED(CONFIG_SCSI_UFS_CRYPTO) + bool crypto_enable; + u8 crypto_key_slot; + u64 data_unit_num; +#endif /* CONFIG_SCSI_UFS_CRYPTO */ bool req_abort_skip; };
Wire up ufshcd.c with the UFS Crypto API, the block layer inline encryption additions and the keyslot manager. Also, introduce UFSHCD_QUIRK_BROKEN_CRYPTO that certain UFS drivers that don't yet support inline encryption need to use - taken from patches by John Stultz <john.stultz@linaro.org> (https://android-review.googlesource.com/c/kernel/common/+/1162224/5) (https://android-review.googlesource.com/c/kernel/common/+/1162225/5) (https://android-review.googlesource.com/c/kernel/common/+/1164506/1) Signed-off-by: Satya Tangirala <satyat@google.com> --- drivers/scsi/ufs/ufs-hisi.c | 8 +++++ drivers/scsi/ufs/ufs-qcom.c | 7 ++++ drivers/scsi/ufs/ufshcd-crypto.c | 26 ++++++++++++++ drivers/scsi/ufs/ufshcd-crypto.h | 14 ++++++++ drivers/scsi/ufs/ufshcd.c | 59 +++++++++++++++++++++++++++++--- drivers/scsi/ufs/ufshcd.h | 8 +++++ 6 files changed, 117 insertions(+), 5 deletions(-)