linux-kernel - Re: [GIT PULL] f2fs updates for v4.6

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyh6Kjnb+=M5b-V7zY9nakzGfNyNwJf4VZHeQ5cOQRmKw@mail.gmail.com>
Date:	Sat, 26 Mar 2016 13:48:23 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Theodore Ts'o" <tytso@....edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Eric Biggers <ebiggers3@...il.com>,
	Jaegeuk Kim <jaegeuk@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux FS Dev Mailing List <linux-fsdevel@...r.kernel.org>,
	Linux F2FS Dev Mailing List 
	<linux-f2fs-devel@...ts.sourceforge.net>,
	Michael Halcrow <mhalcrow@...gle.com>
Subject: Re: [GIT PULL] f2fs updates for v4.6

On Sat, Mar 26, 2016 at 1:41 PM, Theodore Ts'o <tytso@....edu> wrote:
>
>> I also wonder if the xts_tweak should perhaps have both the page
>> offset _and_ the inode number in it. Both ext4 and f2fs specify that
>> xts tweak size to be 16 bytes, and right now fill the last 8 bytes
>> with zero. Would it make sense to just put the inode number in there?
>> I didn't look at the actual key stuff - maybe the key is already
>> per-inode and it doesn't make any sense to add the inode info _again_,
>
> Yes, the key is per-file.  The user's key is mixed with a per-inode
> nonce to create a per-inode key.

Ok, so the only thing that makes sense is really the page offset. Sounds fine.

> BTW, as far as switching ext4 to use the shared code in fs/crypto ---
> I'm hoping to get that done for the next merge window.  There are a 2
> or 3 patches to fix some recently discovered bugs that I'll need to
> push into the fs/crypto code, but I'll take care of that for the next
> development cycle.

No worries. Considering this mistake (which happily seems to have an
innocent explanation for it) it would be good to have it verified that
the shared code does actually work for you, so that we don't end up in
the unhappy situation that the code got split up in order to be
shared, but some random detail choice then made it not actually work
for ext4 after all..

So even if I wouldn't want to pull any ext4 updates to use the new
shared location this merge windoe (I'm making ready to close the merge
window asap), it would be good to know that what we will have for 4.6
is going to work for you, and we don't end up with somethign that
diverges between f2fs and ext4 after all..

                Linus