Re: [PATCH] block: Add block level changes for inline encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 28 May 2018 04:54 PM, Jens Axboe wrote:
> On 5/28/18 7:43 AM, Ladvine D Almeida wrote:
>> This patch introduces new variable under bio structure to
>> facilitate inline encryption. This variable is used to
>> associate I/O requests to crypto information.
> Hard no on this, for two reasons:
>
> 1) Any additions to struct bio are scrutinized heavily and
>    need strong justification.

Thanks for sharing your feedback on the patch.
I am providing reference to an earlier article related to inline encryption support below:
https://lwn.net/Articles/717754/

In the Existing approach, the crypto transformation happens on the I/O requests before
they are actually submitted to the block level drivers for the payload transfer. This is
accomplished using the software algorithms or crypto accelerators invoked by the
device mapper or the file systems.

The inline encryption engine sits inside the controller(unlike the crypto accelerators). The
challenging part now is that we cannot perform encryption outside controller and there
is a need to communicate this crypto information to the block device drivers so they can
use the same for forming the transfer requests to the controller. This is possible
only by associating the bio to the crypto information, because the crypto context is
different for individual I/O requests.

This modification is generic that it can be used by any host controllers with the inline encryption
engine like UFS Host Controller, Mobile Storage Host Controller etc.

>
> 2) Without an actual use case, any change is always denied.
>    This is just a stand-alone patch.

The Use case is supporting the Inline Encryption Engine inside the UFS Host Controller.
UFS Host Controller has multiple key slots available for use. Each key slot can be used when
we setup disks for encryption using different keys with the device mapper.
When the I/O requests happens on each disks configured, there is a need to associate the bio to
crypto context before submitting the bio to the block layer. UFS Host Controller driver will use this
information from the bio to form the UTRD requests with associated Key ID(different ID for different
key slots). The actual encryption happens inside the controller for the I/O requests making use of the
key programmed in the key slot associated to same.

The List of patches related to the Inline Encryption support are shared below:
https://lkml.org/lkml/2018/5/28/1027
https://lkml.org/lkml/2018/5/28/1153
https://lkml.org/lkml/2018/5/28/1196
https://lkml.org/lkml/2018/5/28/1158
https://lkml.org/lkml/2018/5/28/1173
https://lkml.org/lkml/2018/5/28/1178

The implementation has been tested for Full Disk Encryption using the UFS Host Controller
with inline encryption engine on Synopsys HAPS-70 FPGA-based Prototyping System. We seen
a considerable performance improvement over the traditional approach of using crypto
accelerators that much overhead involved in the device mapper layer can now be avoided.

>
> On top of that, you have it inside BLK_CGROUP, which is
> probably not what you want.

Yes. It has to be corrected.

>
Best Regards,

Ladvine





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux