Re: [PATCH v2 0/3] Inline Encryption support for UFS

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Jun 21, 2020 at 11:24:30PM +0530, Alim Akhtar wrote:
> Thanks Avri for CCing me.
> 
> > -----Original Message-----
> > From: Avri Altman <Avri.Altman@wdc.com>
> > Sent: 21 June 2020 18:05
> > To: Martin K. Petersen <martin.petersen@oracle.com>; Satya Tangirala
> > <satyat@google.com>; alim.akhtar@samsung.com; asutoshd@codeaurora.org
> > Cc: linux-scsi@vger.kernel.org; Barani Muthukumaran
> > <bmuthuku@qti.qualcomm.com>; Kuohong Wang
> > <kuohong.wang@mediatek.com>; Kim Boojin <boojin.kim@samsung.com>
> > Subject: RE: [PATCH v2 0/3] Inline Encryption support for UFS
> > 
> > +Alim & Asutosh
> > 
> > Hi Satya,
> > 
> > >
> > > Avri,
> > >
> > > > This patch series adds support for inline encryption to UFS using
> > > > the inline encryption support in the block layer. It follows the
> > > > JEDEC UFSHCI v2.1 specification, which defines inline encryption for
> UFS.
> > >
> > > I'd appreciate it if you could review this series.
> > >
> > > Thanks!
> > >
> > > --
> > > Martin K. Petersen      Oracle Linux Engineering
> > A quick question and a comment:
> > 
> > Does the IE infrastructure that you've added to the block layer invented
> for ufs?
> > Do you see other devices using it in the future?
> > 
> > Today, chipset vendors are using a different scheme for their IE.
> > Need their ack before reviewing your patches.
> > 
> Yes, as of today at least in Samsung HCI, we use additional HW blocks to
> handle all the crypto part.
> (Though I need to check the status on the recent SoCs).
> However given the fact that UFSHCI 2.1 spec does includes Crypto support,
> and going by threads that you shared, looks  like other 
> Vendors does uses IE. I am inclined toward getting this reviewed. 

Note that Boojin Kim, who has been Cc'ed on all these patches, has already been
working on replacing Samsung's legacy inline encryption implementation with one
using the new framework.

Unfortunately, Samsung's UFS inline encryption hardware doesn't follow the UFS
specification, so it needs custom driver code and doesn't take much advantage of
ufshcd-crypto (this patchset).  However, it can still use the blk-crypto
framework.  So only the driver needs to differ, not the rest of the storage
stack.  This differs from the "old world" where every vendor had to customize
the entire storage stack to support their inline encryption hardware.

Anyway, ufshcd-crypto (this patchset) is still needed for all vendors who did
mostly/fully follow the UFS specification, e.g. Mediatek
(https://lkml.kernel.org/linux-scsi/20200304022101.14165-1-stanley.chu@mediatek.com)
and Qualcomm
(https://lkml.kernel.org/linux-scsi/20200621173713.132879-1-ebiggers@kernel.org).

More reviews are always appreciated, though note that this patchset has already
been out for review for over a year.  (This is really v15; Satya started the
numbering over after blk-crypto was merged in v5.8-rc1.)  So I'm not sure we
should count on many more formal reviews.  

- Eric