Hi Eric,
Thanks for your contribution, it's great to see new features like this
being posted upstream for gs101 :)
On Tue, 2 Jul 2024 at 08:28, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
>
> Add support for Flash Memory Protector (FMP), which is the inline
> encryption hardware on Exynos and Exynos-based SoCs.
>
> Specifically, add support for the "traditional FMP mode" that works on
> many Exynos-based SoCs including gs101. This is the mode that uses
> "software keys" and is compatible with the upstream kernel's existing
> inline encryption framework in the block and filesystem layers. I plan
> to add support for the wrapped key support on gs101 at a later time.
>
> Tested on gs101 (specifically Pixel 6) by running the 'encrypt' group of
> xfstests on a filesystem mounted with the 'inlinecrypt' mount option.
>
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
> ---
> drivers/ufs/host/ufs-exynos.c | 228 +++++++++++++++++++++++++++++++++-
> 1 file changed, 222 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c
> index 88d125d1ee3c..dd545ef7c361 100644
> --- a/drivers/ufs/host/ufs-exynos.c
> +++ b/drivers/ufs/host/ufs-exynos.c
> @@ -6,10 +6,13 @@
> * Author: Seungwon Jeon <essuuj@xxxxxxxxx>
> * Author: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>
> *
> */
>
> +#include <asm/unaligned.h>
> +#include <crypto/aes.h>
> +#include <linux/arm-smccc.h>
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> @@ -23,16 +26,18 @@
> #include <ufs/ufshci.h>
> #include <ufs/unipro.h>
>
> #include "ufs-exynos.h"
>
> +#define DATA_UNIT_SIZE 4096
> +#define LOG2_DATA_UNIT_SIZE 12
> +
> /*
> * Exynos's Vendor specific registers for UFSHCI
> */
> #define HCI_TXPRDT_ENTRY_SIZE 0x00
> #define PRDT_PREFECT_EN BIT(31)
> -#define PRDT_SET_SIZE(x) ((x) & 0x1F)
> #define HCI_RXPRDT_ENTRY_SIZE 0x04
> #define HCI_1US_TO_CNT_VAL 0x0C
> #define CNT_VAL_1US_MASK 0x3FF
> #define HCI_UTRL_NEXUS_TYPE 0x40
> #define HCI_UTMRL_NEXUS_TYPE 0x44
> @@ -1041,12 +1046,12 @@ static int exynos_ufs_post_link(struct ufs_hba *hba)
>
> exynos_ufs_establish_connt(ufs);
> exynos_ufs_fit_aggr_timeout(ufs);
>
> hci_writel(ufs, 0xa, HCI_DATA_REORDER);
> - hci_writel(ufs, PRDT_SET_SIZE(12), HCI_TXPRDT_ENTRY_SIZE);
> - hci_writel(ufs, PRDT_SET_SIZE(12), HCI_RXPRDT_ENTRY_SIZE);
> + hci_writel(ufs, LOG2_DATA_UNIT_SIZE, HCI_TXPRDT_ENTRY_SIZE);
> + hci_writel(ufs, LOG2_DATA_UNIT_SIZE, HCI_RXPRDT_ENTRY_SIZE);
> hci_writel(ufs, (1 << hba->nutrs) - 1, HCI_UTRL_NEXUS_TYPE);
> hci_writel(ufs, (1 << hba->nutmrs) - 1, HCI_UTMRL_NEXUS_TYPE);
> hci_writel(ufs, 0xf, HCI_AXIDMA_RWDATA_BURST_LEN);
>
> if (ufs->opts & EXYNOS_UFS_OPT_SKIP_CONNECTION_ESTAB)
> @@ -1149,10 +1154,218 @@ static inline void exynos_ufs_priv_init(struct ufs_hba *hba,
> ufs->rx_sel_idx = 0;
> hba->priv = (void *)ufs;
> hba->quirks = ufs->drv_data->quirks;
> }
>
> +#ifdef CONFIG_SCSI_UFS_CRYPTO
> +
> +/*
> + * Support for Flash Memory Protector (FMP), which is the inline encryption
> + * hardware on Exynos and Exynos-based SoCs. The interface to this hardware is
> + * not compatible with the standard UFS crypto. It requires that encryption be
> + * configured in the PRDT using a nonstandard extension.
> + */
> +
> +enum fmp_crypto_algo_mode {
> + FMP_BYPASS_MODE = 0,
> + FMP_ALGO_MODE_AES_CBC = 1,
> + FMP_ALGO_MODE_AES_XTS = 2,
> +};
> +enum fmp_crypto_key_length {
> + FMP_KEYLEN_256BIT = 1,
> +};
> +
> +/**
> + * struct fmp_sg_entry - nonstandard format of PRDT entries when FMP is enabled
> + *
> + * @base: The standard PRDT entry, but with nonstandard bitfields in the high
> + * bits of the 'size' field, i.e. the last 32-bit word. When these
> + * nonstandard bitfields are zero, the data segment won't be encrypted or
> + * decrypted. Otherwise they specify the algorithm and key length with
> + * which the data segment will be encrypted or decrypted.
> + * @file_iv: The initialization vector (IV) with all bytes reversed
> + * @file_enckey: The first half of the AES-XTS key with all bytes reserved
> + * @file_twkey: The second half of the AES-XTS key with all bytes reserved
> + * @disk_iv: Unused
> + * @reserved: Unused
> + */
> +struct fmp_sg_entry {
> + struct ufshcd_sg_entry base;
> + __be64 file_iv[2];
> + __be64 file_enckey[4];
> + __be64 file_twkey[4];
> + __be64 disk_iv[2];
> + __be64 reserved[2];
> +};
> +
> +#define SMC_CMD_FMP_SECURITY \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_SIP, 0x1810)
> +#define SMC_CMD_SMU \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_SIP, 0x1850)
> +#define SMC_CMD_FMP_SMU_RESUME \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
> + ARM_SMCCC_OWNER_SIP, 0x1860)
> +#define SMU_EMBEDDED 0
> +#define SMU_INIT 0
> +#define CFG_DESCTYPE_3 3
> +
> +static void exynos_ufs_fmp_init(struct ufs_hba *hba)
> +{
> + struct blk_crypto_profile *profile = &hba->crypto_profile;
> + struct arm_smccc_res res;
> + int err;
> +
> + /*
> + * Check for the standard crypto support bit, since it's available even
> + * though the rest of the interface to FMP is nonstandard.
> + *
> + * This check should have the effect of preventing the driver from
> + * trying to use FMP on old Exynos SoCs that don't have FMP.
> + */
> + if (!(ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES) &
> + MASK_CRYPTO_SUPPORT))
> + return;
> +
Do you know how these FMP registers (FMPSECURITY0 etc) relate to the
UFSPR* registers set in the existing exynos_ufs_config_smu()? The
UFS_LINK spec talks about UFSPR(FMP), so I had assumed the FMP support
would be writing these same registers but via SMC call.
I think by the looks of things
#define UFSPRSECURITY 0x010
#define UFSPSBEGIN0 0x200
#define UFSPSEND0 0x204
#define UFSPSLUN0 0x208
#define UFSPSCTRL0 0x20C
relates to the following registers in gs101 spec
FMPSECURITY0 0x0010
FMPSBEGIN0 0x2000
FMPSEND0 0x2004
FMPSLUN0 0x2008
FMPSCTRL0 0x200C
And the SMC calls your calling set those same registers as
exynos_ufs_config_smu() function. Although it is hard to be certain as
I don't have access to the firmware code. Certainly the comment below
about FMPSECURITY0 implies that :)
With that in mind I think exynos_ufs_fmp_init() function in this patch
needs to be better integrated with the EXYNOS_UFS_OPT_UFSPR_SECURE
flag and the existing exynos_ufs_config_smu() function that is
currently just disabling decryption on platforms where it can access
the UFSPR(FMP) regs via mmio.
Thanks,
Peter
p.s. Also whilst reviewing this I noticed a bug where I don't check
EXYNOS_UFS_OPT_UFSPR_SECURE flag in exynos_ufs_resume() before calling
exynos_ufs_config_smu(). I'll send a patch to fix that.
[..]
