linux-ext4 - Re: ext4

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]

Date:	Mon, 25 Jun 2012 01:33:35 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Fredrick <fjohnber@...o.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: ext4_fallocate

On 2012-06-25, at 12:42 AM, Fredrick wrote:
> When calling fallocate on ext4 fs, ext4_fallocate does not initialize
> the extents.

The whole point of fallocate() is that the extents are uninitialized
(i.e. not zero-filled with data, but read back as if they were), and
only overwritten with user data as needed.

> The extents are allocated only when they are actually
> written. This is causing a problem for us. Our programs create many
> "write only once" files as large as 1G on ext4 very rapidly at times.
> We thought fallocate would solve the problem. But it didnt.
> If I change the EXT4_GET_BLOCKS_CREATE_UNINIT_EXT to
> just EXT4_GET_BLOCKS_CREATE in the ext4_map_blocks in the ext4_fallocate call, the extents get created in fallocate call itself. This is helping us.

This means that if any user reads the fallocate'd file, they will be able
to read any old data that was previously written to disk and deleted.  This
is a big security hole.  Also, if the writer of such a file is interrupted
for some reason, the file will contain garbage in it.

There was a recent patch series "ext4: add an io-tree to track block
allocation" that may improve the performance for your case of overwrite
of uninitialized files, but it hasn't landed yet.

> Now the write throughtput to the disk was close to 98%. When extents were not
> initialized, our disk throughput were only 70%.
> 
> Can this change be made to ext4_fallocate?

Not if you value data security.  That said, it is possible some users value
performance over security on systems that have limited access, or do not
have any private data on them.  If the "io-tree" doesn't fix the performance
problem, it may make sense to add a mount option to allow users to specify
that uninitialized extents can return old data from disk, but before that
happens, I'd really prefer to make the correct behaviour work efficiently.

Cheers, Andreas

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html