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

From: Steev Klimaszewski <steev@kali.org>
To: Eric Biggers <ebiggers@kernel.org>,
	Thara Gopinath <thara.gopinath@linaro.org>
Cc: 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 15:18:23 -0500	[thread overview]
Message-ID: <150ddaaf-12ec-231e-271a-c65b1d88d30f@kali.org> (raw)
In-Reply-To: <20200507180838.GC236103@gmail.com>

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.