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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 7 Jun 2018 06:55:42 +0000
From:   Ladvine D Almeida <Ladvine.DAlmeida@...opsys.com>
To:     Jens Axboe <axboe@...nel.dk>,
        Ladvine D Almeida <Ladvine.DAlmeida@...opsys.com>,
        Christoph Hellwig <hch@...radead.org>
CC:     Hannes Reinecke <hare@...e.com>,
        "ming.lei@...hat.com" <ming.lei@...hat.com>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Manjunath M Bettegowda <Manjunath.MB@...opsys.com>,
        Prabu Thangamuthu <Prabu.T@...opsys.com>,
        Tejas Joglekar <Tejas.Joglekar@...opsys.com>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        "Milan Broz" <gmazyland@...il.com>,
        Alasdair Kergon <agk@...hat.com>,
        Mike Snitzer <snitzer@...hat.com>,
        device-mapper development <dm-devel@...hat.com>,
        "Eric Biggers" <ebiggers3@...il.com>,
        Theodore Ts'o <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org>
Subject: Re: [PATCH] block: Add block level changes for inline encryption

On Thursday 07 June 2018 02:53 AM, Jens Axboe wrote:
> On 6/6/18 1:35 AM, Ladvine D Almeida wrote:
>> On Friday 01 June 2018 09:13 AM, Christoph Hellwig wrote:
>>> On Mon, May 28, 2018 at 02:43:09PM +0100, 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.
>>> This seems to be missing a whole lot of context.  Where is the whole
>>> series showing what you are trying to do?
>>>
>> Christoph,
>>
>> The patches are generated in the below > manner, with a thought of
>> sending separately to the MAINTAINERS responsible for each.
> What both Christoph and I have said is that it's _impossible_ to review
> changes when you don't know what is being built on top of it. The block
> change, by itself, is utterly useless. The use case needs to be seen.
> But apart from that, my comments on why it's doing it completely
> backwards still apply, and I've outlined how you need to fix it. The
> patch, in its current form, isn't going anywhere.
>
Jens,

Since there are implementation level concerns on both device mapper layer and block layer, I will investigate

more and work on those lines. I can send the full patch series to the relevant maintainers after addressing the

issues.

Regards,

Ladvine