Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support

From: Eric Biggers <ebiggers@kernel.org>
To: Steev Klimaszewski <steev@kali.org>
Cc: Thara Gopinath <thara.gopinath@linaro.org>,
	linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-block@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Andy Gross <agross@kernel.org>, Avri Altman <avri.altman@wdc.com>,
	Barani Muthukumaran <bmuthuku@qti.qualcomm.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Can Guo <cang@codeaurora.org>,
	Elliot Berman <eberman@codeaurora.org>,
	John Stultz <john.stultz@linaro.org>,
	Satya Tangirala <satyat@google.com>
Subject: Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
Date: Fri, 8 May 2020 13:25:13 -0700	[thread overview]
Message-ID: <20200508202513.GA233206@gmail.com> (raw)
In-Reply-To: <150ddaaf-12ec-231e-271a-c65b1d88d30f@kali.org>

On Fri, May 08, 2020 at 03:18:23PM -0500, Steev Klimaszewski wrote:
> 
> On 5/7/20 1:08 PM, Eric Biggers wrote:
> > On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> >> Hi Thara,
> >>
> >> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> >>>
> >>> On 5/1/20 12:51 AM, Eric Biggers wrote:
> >>>> From: Eric Biggers <ebiggers@google.com>
> >>>>
> >>>> Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.
> >>>>
> >>>> The standards-compliant parts, such as querying the crypto capabilities
> >>>> and enabling crypto for individual UFS requests, are already handled by
> >>>> ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
> >>>> However, ICE requires vendor-specific init, enable, and resume logic,
> >>>> and it requires that keys be programmed and evicted by vendor-specific
> >>>> SMC calls.  Make the ufs-qcom driver handle these details.
> >>>>
> >>>> I tested this on Dragonboard 845c, which is a publicly available
> >>>> development board that uses the Snapdragon 845 SoC and runs the upstream
> >>>> Linux kernel.  This is the same SoC used in the Pixel 3 and Pixel 3 XL
> >>>> phones.  This testing included (among other things) verifying that the
> >>>> expected ciphertext was produced, both manually using ext4 encryption
> >>>> and automatically using a block layer self-test I've written.
> >>> Hello Eric,
> >>>
> >>> I am interested in testing out this series on 845, 855 and if possile on 865
> >>> platforms. Can you give me some more details about your testing please.
> >>>
> >> Great!  You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
> >>
> >> A basic manual test would be:
> >>
> >> 1. Build a kernel with:
> >>
> >> 	CONFIG_BLK_INLINE_ENCRYPTION=y
> >> 	CONFIG_FS_ENCRYPTION=y
> >> 	CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> > Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
> >
> > - Eric
> 
> I took a look into this as well - is v12 the latest of the fscrypt
> inline crypto patches?
> 
> I see a EXPORT_SYMBOL_GPL(fscrypt_inode_uses_inline_crypto) but it seems
> like it should be EXPORT_SYMBOL_GPL(__fscrypt_inode_uses_inline_crypto)
> otherwise you end up with
> 
> 
> WARNING: modpost: "fscrypt_inode_uses_inline_crypto" [vmlinux] is a
> static EXPORT_SYMBOL_GPL
> 
> 
> when you have something like CONFIG_F2FS_FS=m
> 
> 
> Apologies but I'm not sure where the original patchset is to send as a
> reply to them.

The original patchset is at
https://lkml.kernel.org/r/20200430115959.238073-1-satyat@google.com/

Yes, v12 is the latest version, and yes that's a bug.  The export needs double
underscores.  Satya will fix it when he sends out v13.

- Eric