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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 6 Jun 2019 10:21:12 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Eric Biggers <ebiggers@...nel.org> Cc: linux-fscrypt@...r.kernel.org, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Linux API <linux-api@...r.kernel.org>, linux-integrity@...r.kernel.org, Jaegeuk Kim <jaegeuk@...nel.org>, "Theodore Y . Ts'o" <tytso@....edu>, Victor Hsieh <victorhsieh@...gle.com>, Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@....de>, "Darrick J . Wong" <darrick.wong@...cle.com> Subject: Re: [PATCH v4 00/16] fs-verity: read-only file-based authenticity protection On Thu, Jun 6, 2019 at 8:54 AM Eric Biggers <ebiggers@...nel.org> wrote: > > This is a redesigned version of the fs-verity patchset, implementing > Ted's suggestion to build the Merkle tree in the kernel > (https://lore.kernel.org/linux-fsdevel/20190207031101.GA7387@mit.edu/). > This greatly simplifies the UAPI, since the verity metadata no longer > needs to be transferred to the kernel. Interfaces look sane to me. My only real concern is whether it would make sense to make the FS_IOC_ENABLE_VERITY ioctl be something that could be done incrementally, since the way it is done now it looks like any random user could create a big file and then do the FS_IOC_ENABLE_VERITY to make the kernel do a _very_ expensive operation. Yes, I see the + if (fatal_signal_pending(current)) + return -EINTR; + cond_resched(); in there, so it's not like it's some entirely unkillable thing, and maybe we don't care as a result. But maybe the ioctl interface could be fundamentally restartable? If that was already considered and people just went "too complex", never mind. Linus
Powered by blists - more mailing lists