linux-ext4 - Re: Exporting ext4-specific information through fsinfo attributes

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:   Wed, 1 Apr 2020 12:28:40 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     David Howells <dhowells@...hat.com>, tytso@....edu,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org
Subject: Re: Exporting ext4-specific information through fsinfo attributes

On Wed, Apr 01, 2020 at 12:05:53PM -0700, Darrick J. Wong wrote:
> On Wed, Apr 01, 2020 at 09:27:44AM -0700, Eric Biggers wrote:
> > On Wed, Apr 01, 2020 at 08:39:07AM +0100, David Howells wrote:
> > > Hi Ted,
> > > 
> > > Whilst we were at Vault, I asked you if there was any live ext4 information
> > > that it could be useful to export through fsinfo().  I've implemented a patch
> > > that exports six superblock timestamps:
> > > 
> > > 	FSINFO_ATTR_EXT4_TIMESTAMPS: 
> > > 		mkfs    : 2016-02-26 00:37:03
> > > 		mount   : 2020-03-31 21:57:30
> > > 		write   : 2020-03-31 21:57:28
> > > 		fsck    : 2018-12-17 23:32:45
> > > 		1st-err : -
> > > 		last-err: -
> > > 
> > > but is there anything else that could be of interest?
> > > 
> > > Thanks,
> > > David
> > > 
> > 
> > FWIW, the filesystem UUID would be useful for testing ext4 and f2fs encryption
> > (since it's now sometimes used in the derivation of encryption keys).  But I see
> > you already included it as FSINFO_ATTR_VOLUME_UUID.
> 
> It is??  What happens if you tune2fs -U if csum_seed isn't enabled?
> 

It's only used for IV_INO_LBLK_64 encryption policies, which include the inode
number in the IVs.  The UUID had to be used to distinguish the same inode number
on multiple filesystems, in case the same key is used on multiple filesystems.

Since this type of encryption policy also requires stable inode numbers, on ext4
it can only be set if user has run 'tune2fs -O stable_inodes' to also prevent
filesystem shrinking.

I didn't know that e2fsprogs had a supported way to change the filesystem UUID.
We maybe should make tune2fs -U refuse to operate on filesystems that have the
stable_inodes feature set.  However, the chance that someone would actually
break their encrypted files by changing their filesystem UUID is pretty low,
since most users use the normal fscrypt policies instead.  IV_INO_LBLK_64 is
only really useful with UFS inline encryption hardware, and systems with this
hardware aren't the type of systems you can just log into and randomly change
your filesystem UUID.  For standard Linux distros we have a tool
https://github.com/google/fscrypt, but it doesn't support IV_INO_LBLK_64 yet.

- Eric