Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753183AbcCLAgb (ORCPT ); Fri, 11 Mar 2016 19:36:31 -0500 Received: from imap.thunk.org ([74.207.234.97]:35346 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbcCLAg1 (ORCPT ); Fri, 11 Mar 2016 19:36:27 -0500 Date: Fri, 11 Mar 2016 19:35:56 -0500 From: "Theodore Ts'o" To: Dave Chinner Cc: Linus Torvalds , Andy Lutomirski , One Thousand Gnomes , Ric Wheeler , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <20160312003556.GF32214@thunk.org> Mail-Followup-To: Theodore Ts'o , Dave Chinner , Linus Torvalds , Andy Lutomirski , One Thousand Gnomes , Ric Wheeler , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen References: <20160309230819.GB3949@thunk.org> <56E18B9B.5070503@gmail.com> <56E24CA5.3030702@redhat.com> <20160311135952.57a44931@lxorguk.ukuu.org.uk>

<20160311223047.GZ30721@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160311223047.GZ30721@dastard> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1515 Lines: 30 On Sat, Mar 12, 2016 at 09:30:47AM +1100, Dave Chinner wrote: > It's all well and good to restrict access to the fallocate() call to > limit who can expose stale data, but it doesn't remove the fact it > is easy for stale data to unintentionally escape the privileged > group once it has been exposed because there is no record of the > fact the file contains uninitialised blocks.... Ultimately, it's up to the trusted process to make sure it never reveals any stale data. For example, if you have the policy that all data is encrypted at rest, and the trusted process is always going to be decrypting any blocks it reads from disk before passing it on its client (for example) then any stale data is going to be obscured by the decryption step before it gets passed on. At the end of the day it's about whether you trust the userspace program or not. I know there's a long and venerated traition of assuming that all application programmers are incompetent, but that leads to file systems doing more work than what is strictly necessary, and that has a performance tax. And if the result is the cluster file system authors decide to create a user space file system, and bypass the kernel file system directly, then we have to trust them to do a competent job anyway. But if you believe that there are still ways in which a in-kernel file system can add value, then it's encumbent on us to to be a bit more flexible and not assume that all userspace programmers are blithering idiots. Cheers, - Ted