Re: [PATCH] f2fs: remove broken support for allocating DIO writes

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Aug 17, 2021 at 02:33:01PM -0700, Jaegeuk Kim wrote:
> On 08/17, Eric Biggers wrote:
> > On Tue, Aug 17, 2021 at 11:57:46AM -0700, Jaegeuk Kim wrote:
> > > On 08/17, Christoph Hellwig wrote:
> > > > On Mon, Aug 16, 2021 at 07:03:21PM -0700, Eric Biggers wrote:
> > > > > Freeing preallocated blocks on error would be better than nothing, although note
> > > > > that the preallocated blocks may have filled an arbitrary sequence of holes --
> > > > > so simply truncating past EOF would *not* be sufficient.
> > > > > 
> > > > > But really filesystems need to be designed to never expose uninitialized data,
> > > > > even if I/O errors or a sudden power failure occurs.  It is unfortunate that
> > > > > f2fs apparently wasn't designed with that goal in mind.
> > > > > 
> > > > > In any case, I don't think we can proceed with any other f2fs direct I/O
> > > > > improvements until this data leakage bug can be solved one way or another.  If
> > > > > my patch to remove support for allocating writes isn't acceptable and the
> > > > > desired solution is going to require some more invasive f2fs surgery, are you or
> > > > > Chao going to work on it?  I'm not sure there's much I can do here.
> > > > 
> > > > Btw, this is generally a problem for buffered I/O as well, although the
> > > > window for exposing uninitialized blocks on a crash tends to be smaller.
> > > 
> > > How about adding a warning message when we meet an error with preallocated
> > > unwritten blocks? In the meantime, can we get the Eric's patches for iomap
> > > support? I feel that we only need to modify the preallocation and error
> > > handling parts?
> > 
> > A warning message would do nothing to prevent uninitialized blocks from being
> > leaked to userspace.
> 
> To give a signal that it's a known issue that we'll fix later.
> 

This bug is concerning mainly because it's a security vulnerability: anyone with
read+write access to just one file on an f2fs filesystem can effectively read
all other files on that filesystem.  A warning message wouldn't change that.

And even in the case of this bug breaking a non-malicious program, hardly anyone
reads kernel log messages anyway.  If something is broken, having a log message
that says "yeah, this is broken, sorry" isn't going to accomplish much...

- Eric