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: <2915109D-9F6F-4D25-A759-3D99716BEF4C@dilger.ca>
Date:   Thu, 28 Jun 2018 16:20:48 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsck: do not allow initialized blocks pass i_size

On Jun 28, 2018, at 4:12 PM, Theodore Y. Ts'o <tytso@....edu> wrote:
> 
> On Thu, Jun 28, 2018 at 01:55:49PM -0600, Andreas Dilger wrote:
>> On Jun 28, 2018, at 7:59 AM, Lukas Czerner <lczerner@...hat.com> wrote:
>>> 
>>> We do not allow initialized blocks to exist past i_size as this could
>>> lead to stale data exposure.
>> 
>> I don't think this is any more dangerous than uninitialized bytes beyond
>> i_size in the same block, or as a hole in the middle of the file exposing
>> stale data.  That is to say, there is some risk, but not any worse.  The
>> converse is true also - extendiy,ng i_size to the end of the allocated blocks
>> will not only expose that data, but in some cases make applications think
>> the file is corrupted because there are now NULs at the end of the file.
> 
> I believe what Lukas is referring to is the fact that historically,
> ext2, ext3, and ext4 in the nodelalloc case used i_size as the
> interlock to make sure we don't end up exposing stale data.  With the
> advent of punch hole functionality, life gets interesting so we have
> one set of mechanisms for interlocking between buffered and direct I/O
> for truncate, and different one for punch hole.
> 
> So the kernel should never create intialized blocks past i_size.  I've
> done some quick checks, and this appears to be correct.

That's true for stock ext4, but as I mentioned in my other email, Lustre
will allocate up to the PAGE_SIZE boundary because the RDMA will overwrite
the whole page regardless of where i_size is, which results in blocks
being allocated beyond i_size for PAGE_SIZE > blocksize.

While that is not a typical configuration (we always format with 4KB
blocksize, and typically run x86 servers), there are a few sites that
have SPARC servers, so this patch is to accommodate them.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ