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
| ||
|
Message-ID: <20190820051635.GF159846@architecture4> Date: Tue, 20 Aug 2019 13:16:36 +0800 From: Gao Xiang <gaoxiang25@...wei.com> To: Chandan Rajendra <chandan@...ux.ibm.com> CC: <tytso@....edu>, <ebiggers@...nel.org>, <linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>, <linux-f2fs-devel@...ts.sourceforge.net>, <linux-fscrypt@...r.kernel.org>, <chandanrmail@...il.com>, <adilger.kernel@...ger.ca>, <jaegeuk@...nel.org>, <yuchao0@...wei.com>, <hch@...radead.org> Subject: Re: [PATCH V4 5/8] f2fs: Use read_callbacks for decrypting file data On Tue, Aug 20, 2019 at 01:12:36PM +0800, Gao Xiang wrote: > Hi Chandan, > > On Tue, Aug 20, 2019 at 10:35:29AM +0530, Chandan Rajendra wrote: > > On Friday, August 16, 2019 11:48 AM Chandan Rajendra wrote: > > > F2FS has a copy of "post read processing" code using which encrypted > > > file data is decrypted. This commit replaces it to make use of the > > > generic read_callbacks facility. > > > > > > Signed-off-by: Chandan Rajendra <chandan@...ux.ibm.com> > > > > Hi Eric and Ted, > > > > Looks like F2FS requires a lot more flexiblity than what can be offered by > > read callbacks i.e. > > > > 1. F2FS wants to make use of its own workqueue for decryption, verity and > > decompression. > > 2. F2FS' decompression code is not an FS independent entity like fscrypt and > > fsverity. Hence they would need Filesystem specific callback functions to > > be invoked from "read callbacks". > > > > Hence I would suggest that we should drop F2FS changes made in this > > patchset. Please let me know your thoughts on this. > > Add a word, I have some little concern about post read procession order FYI. Just a minor concern about its flexibility, not big though. https://lore.kernel.org/r/20190808042640.GA28630@138/ Thanks, Gao Xiang > a bit as I mentioned before, because I'd like to move common EROFS > decompression code out in the future as well for other fses to use > after we think it's mature enough. > > It seems the current code mainly addresses eliminating duplicated code, > therefore I have no idea about that... > > Thanks, > Gao Xiang > > > > > -- > > chandan > > > > > >
Powered by blists - more mailing lists