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: <20170623171807.GA84943@gmail.com> Date: Fri, 23 Jun 2017 10:18:07 -0700 From: Eric Biggers <ebiggers3@...il.com> To: Theodore Ts'o <tytso@....edu> Cc: Richard Weinberger <richard.weinberger@...il.com>, linux-fscrypt@...r.kernel.org, Eric Biggers <ebiggers@...gle.com>, linux-f2fs-devel@...ts.sourceforge.net, "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>, Jaegeuk Kim <jaegeuk@...nel.org>, linux-ext4@...r.kernel.org Subject: Re: [PATCH 3/4] ubifs: don't bother checking for encryption key in ->mmap() Ted + Richard, On Fri, Jun 23, 2017 at 12:09:07PM -0400, Theodore Ts'o wrote: > On Tue, May 23, 2017 at 04:14:20PM +0200, Richard Weinberger wrote: > > On Tue, May 23, 2017 at 2:39 AM, Eric Biggers <ebiggers3@...il.com> wrote: > > > From: Eric Biggers <ebiggers@...gle.com> > > > > > > Since only an open file can be mmap'ed, and we only allow open()ing an > > > encrypted file when its key is available, there is no need to check for > > > the key again before permitting each mmap(). > > > > > > Signed-off-by: Eric Biggers <ebiggers@...gle.com> > > > > Acked-by: Richard Weinberger <richard@....at> > > There are some patches that were sent to linux-fscrypt (including this > one) that are specific to ubifs that don't appear to be in linux-next > as of this writing. > > I can include them in the fscrypt tree (which I am updating somewhat > belatedly; sorry, crazy travel schedule has made me be late attending > to fscrypt), but it probably makes more sense for the change to go in > via the ubifs tree. The f2fs version of the "don't bother checking > for encryption key" is already in linux-next, via the f2fs tree, for > example. > > So I'm planning on NOT taking the ubifs-specific patches that are in > the linux-fscrypto patch queue; unless Richard, you want to > specifically ask me to do so. > The mmap and truncate patches were basically the same for each filesystem, but yes it's fine for them to go in separately. Richard, can you take for ubifs: ubifs: don't bother checking for encryption key in ->mmap() ubifs: require key for truncate(2) of encrypted file and Ted can you take for ext4: ext4: don't bother checking for encryption key in ->mmap() ext4: require key for truncate(2) of encrypted file - Eric
Powered by blists - more mailing lists