[PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Parshuram Thombare]

Hello,

This patch series add inline / real time encryption support to UFS
host controller driver. It include following patches
0001-block-add-bi_crypto_ctx-variable-in-struct-bio.patch
Add 'void *bi_crypto_ctx' variable in 'struct bio' to embded crypto
configuration information, which is used by low level driver when
bio is processed. This field can also be useful to support inline
encryption in other protocols also.
0002-scsi-ufs-add-inline-crypto-support-to-UFS-HCD.patch
This patch depends on patch [0/1] in this series.
Patch include changes regarding UFS controller
crypto support. Inline crypto support is provided by using new
device mapper called 'crypt-ufs'. Inline encryption can be enabled on
UFS device by creating mapping using tool like dmsetup and mapper
'crypt-ufs'. Patch is tested on Cadence UFS controller which currently
support AES-ECB inline encryption.
As part of [PATCH 2/2], MAINTAINERS file is modified to add name as
supporter of ufshcd crypto files.

Regards,
Parshuram Thombare

Parshuram Thombare (2):
  block: add bi_crypto_ctx variable in struct bio
  scsi: ufs: add inline crypto support to UFS HCD

 MAINTAINERS                      |    7 +
 block/Kconfig                    |    5 +
 drivers/scsi/ufs/Kconfig         |   12 +
 drivers/scsi/ufs/Makefile        |    1 +
 drivers/scsi/ufs/ufshcd-crypto.c |  453 ++++++++++++++++++++++++++++++++++++++
 drivers/scsi/ufs/ufshcd-crypto.h |  102 +++++++++
 drivers/scsi/ufs/ufshcd.c        |   27 +++-
 drivers/scsi/ufs/ufshcd.h        |    6 +
 drivers/scsi/ufs/ufshci.h        |    1 +
 include/linux/blk_types.h        |    4 +
 10 files changed, 617 insertions(+), 1 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufshcd-crypto.c
 create mode 100644 drivers/scsi/ufs/ufshcd-crypto.h

[PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Parshuram Thombare]

Hello,

This patch series add inline / real time encryption support to UFS
host controller driver. It include following patches
0001-block-add-bi_crypto_ctx-variable-in-struct-bio.patch
Add 'void *bi_crypto_ctx' variable in 'struct bio' to embded crypto
configuration information, which is used by low level driver when
bio is processed. This field can also be useful to support inline
encryption in other protocols also.
0002-scsi-ufs-add-inline-crypto-support-to-UFS-HCD.patch
This patch depends on patch [0/1] in this series.
Patch include changes regarding UFS controller
crypto support. Inline crypto support is provided by using new
device mapper called 'crypt-ufs'. Inline encryption can be enabled on
UFS device by creating mapping using tool like dmsetup and mapper
'crypt-ufs'. Patch is tested on Cadence UFS controller which currently
support AES-ECB inline encryption.
As part of [PATCH 2/2], MAINTAINERS file is modified to add name as
supporter of ufshcd crypto files.

Regards,
Parshuram Thombare

Parshuram Thombare (2):
  block: add bi_crypto_ctx variable in struct bio
  scsi: ufs: add inline crypto support to UFS HCD

 MAINTAINERS                      |    7 +
 block/Kconfig                    |    5 +
 drivers/scsi/ufs/Kconfig         |   12 +
 drivers/scsi/ufs/Makefile        |    1 +
 drivers/scsi/ufs/ufshcd-crypto.c |  453 ++++++++++++++++++++++++++++++++++++++
 drivers/scsi/ufs/ufshcd-crypto.h |  102 +++++++++
 drivers/scsi/ufs/ufshcd.c        |   27 +++-
 drivers/scsi/ufs/ufshcd.h        |    6 +
 drivers/scsi/ufs/ufshci.h        |    1 +
 include/linux/blk_types.h        |    4 +
 10 files changed, 617 insertions(+), 1 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufshcd-crypto.c
 create mode 100644 drivers/scsi/ufs/ufshcd-crypto.h

Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Christoph Hellwig]

Patch 1 is missing in your series.

But even without looking at it I think your design doesn't make a whole
lot of sense.  If the encryption is implemented in the ufs driver you
should not need device mapper support for it, just ufs driver support
and maybe a little block layer glue.

RE: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Parshuram Raju Thombare]

Hi Christoph,

Thank you for comments.
My comments are inline below.

Regards,
Parshuram Thombare

>-----Original Message-----
>From: Christoph Hellwig <hch@infradead.org>
>Sent: Tuesday, December 11, 2018 7:37 PM
>To: Parshuram Raju Thombare <pthombar@cadence.com>
>Cc: axboe@kernel.dk; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com;
>martin.petersen@oracle.com; mchehab+samsung@kernel.org;
>gregkh@linuxfoundation.org; davem@davemloft.net; akpm@linux-
>foundation.org; nicolas.ferre@microchip.com; arnd@arndb.de; linux-
>kernel@vger.kernel.org; linux-block@vger.kernel.org; linux-
>scsi@vger.kernel.org; tj@kernel.org; jbacik@fb.com; michaelcallahan@fb.com;
>snitzer@redhat.com; osandov@fb.com; keith.busch@intel.com;
>ming.lei@redhat.com; shli@fb.com; dennisszhou@gmail.com; Alan Douglas
><adouglas@cadence.com>; Janek Kotas <jank@cadence.com>; Rafal Ciepiela
><rafalc@cadence.com>
>Subject: Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD
>
>EXTERNAL MAIL
>
>
>Patch 1 is missing in your series.
>
>But even without looking at it I think your design doesn't make a whole lot of
>sense.  If the encryption is implemented in the ufs driver you should not need
>device mapper support for it, just ufs driver support and maybe a little block layer
>glue.
[PATCH 1/2]  does nothing more than adding variable in 'struct bio'. 
Here is link of it.
https://lkml.org/lkml/2018/12/11/193
One reason of using device mapper here is to use existing tools like 'dmsetup', otherwise 
some user space application is needed and may be some changes in block layer to 
pass the crypto information (crypto algorithm, key etc) till ufs driver.
Another reason is supporting multiple UFS devices. I think, as you said UFS crypto support
can be added by some change in ufs driver and block layer glue. But to support
multiple UFS crypto devices having different crypto configs (crypto algorithms, key size etc),
crypto context need to be saved per crypto device which may need some changes in block layer code.

RE: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Parshuram Raju Thombare]

Hi Christoph,

Thank you for comments.
My comments are inline below.

Regards,
Parshuram Thombare

>-----Original Message-----
>From: Christoph Hellwig <hch@infradead.org>
>Sent: Tuesday, December 11, 2018 7:37 PM
>To: Parshuram Raju Thombare <pthombar@cadence.com>
>Cc: axboe@kernel.dk; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com;
>martin.petersen@oracle.com; mchehab+samsung@kernel.org;
>gregkh@linuxfoundation.org; davem@davemloft.net; akpm@linux-
>foundation.org; nicolas.ferre@microchip.com; arnd@arndb.de; linux-
>kernel@vger.kernel.org; linux-block@vger.kernel.org; linux-
>scsi@vger.kernel.org; tj@kernel.org; jbacik@fb.com; michaelcallahan@fb.com;
>snitzer@redhat.com; osandov@fb.com; keith.busch@intel.com;
>ming.lei@redhat.com; shli@fb.com; dennisszhou@gmail.com; Alan Douglas
><adouglas@cadence.com>; Janek Kotas <jank@cadence.com>; Rafal Ciepiela
><rafalc@cadence.com>
>Subject: Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD
>
>EXTERNAL MAIL
>
>
>Patch 1 is missing in your series.
>
>But even without looking at it I think your design doesn't make a whole lot of
>sense.  If the encryption is implemented in the ufs driver you should not need
>device mapper support for it, just ufs driver support and maybe a little block layer
>glue.
[PATCH 1/2]  does nothing more than adding variable in 'struct bio'. 
Here is link of it.
https://lkml.org/lkml/2018/12/11/193
One reason of using device mapper here is to use existing tools like 'dmsetup', otherwise 
some user space application is needed and may be some changes in block layer to 
pass the crypto information (crypto algorithm, key etc) till ufs driver.
Another reason is supporting multiple UFS devices. I think, as you said UFS crypto support
can be added by some change in ufs driver and block layer glue. But to support
multiple UFS crypto devices having different crypto configs (crypto algorithms, key size etc),
crypto context need to be saved per crypto device which may need some changes in block layer code.

Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Christoph Hellwig]

On Tue, Dec 11, 2018 at 06:22:27PM +0000, Parshuram Raju Thombare wrote:
> One reason of using device mapper here is to use existing tools like
> 'dmsetup', otherwise some user space application is needed and may be
> some changes in block layer to pass the crypto information (crypto
> algorithm, key etc) till ufs driver.

Yes, so what?  We also don't use dmsetup to set up TCG OPAL based
encryption either.

> Another reason is supporting multiple UFS devices. I think, as you said
> UFS crypto support can be added by some change in ufs driver and block
> layer glue. But to support multiple UFS crypto devices having different
> crypto configs (crypto algorithms, key size etc), crypto context need to
> be saved per crypto device which may need some changes in block layer code.

I don't think we need device mapper for that.  We can hav the crypto
state hanging off the ufs host, or request_queue if we decide to
implement it generic in the block layer.

Re: [PATCH 0/2] scsi: ufs: add real time/inline crypto support to UFS HCD

[Christoph Hellwig]

On Tue, Dec 11, 2018 at 06:22:27PM +0000, Parshuram Raju Thombare wrote:
> One reason of using device mapper here is to use existing tools like
> 'dmsetup', otherwise some user space application is needed and may be
> some changes in block layer to pass the crypto information (crypto
> algorithm, key etc) till ufs driver.

Yes, so what?  We also don't use dmsetup to set up TCG OPAL based
encryption either.

> Another reason is supporting multiple UFS devices. I think, as you said
> UFS crypto support can be added by some change in ufs driver and block
> layer glue. But to support multiple UFS crypto devices having different
> crypto configs (crypto algorithms, key size etc), crypto context need to
> be saved per crypto device which may need some changes in block layer code.

I don't think we need device mapper for that.  We can hav the crypto
state hanging off the ufs host, or request_queue if we decide to
implement it generic in the block layer.