On Wed, Jan 27, 2021 at 01:10:33AM +0100, Christoph Biedl wrote:
>
> Yes, and my question here: Is it possible the existence of that bogus
> fscrypt feature flag made e2fsck or the kernel think this is an ext4,
> and things went downhill from there? That's a situation I'd like to
> avoid - since in the (today rare) case the bootloader cannot handle
> ext4, this will result in an unbootable system.
So, it had nothing to do with the fscrypt flag; the kernel message was
because that an inode flag was set on an inode, *not* a feature flag
in the superblock.
Looking at the tune2fs -l output, the issue was the inline_data file
system feature flag:
> Filesystem features: ext_attr resize_inode dir_index filetype
> inline_data sparse_super
That *is* a feature which e2fsck will offer to set, but only if there
is a valid inode which (a) has the inline data flag in the inode, (b)
there is a "system.data" extended attribute which has a non-zero size.
In that case, if the inode has valid inline data, e2fsck will assume
that what had happened feature flag was erroneously cleared, and will
ask permission to set it back:
Pass 1: Checking inodes, blocks, and sizes
Inode 12 has inline data, but superblock is missing INLINE_DATA feature
Fix<y>? yes
If there is an inode that has the INLINE_DATA_FL inode flag set, but
there is not a valid system.data extended attribute, then e2fsck will
assume that it's random garbage written into the inode table that
happened to have the INLINE_DATA_FL bit set in the i_flags field set,
then e2fsck will ask permission to clear the inode and then get rid of
the file:
Pass 1: Checking inodes, blocks, and sizes
Inode 12 has INLINE_DATA_FL flag on filesystem without inline data support.
Clear<y>? yes
Pass 2: Checking directory structure
Entry 'foo' in / (2) has deleted/unused inode 12. Clear<y>? yes
What could have happened on your file system? Well, there are two
scenarios that could explain what had happened:
1) Somehow the inode was corrupted to (a) both set the inline data
flag, and (b) a valid extended attribute that had "system.data" (which
can't be set via the userspace API; it would have had to been
magically, random set). Highly unlikely.
2) There was a random bit flip that enabled the inline_data feature
flag in the superblock. The other fscrypt kernel message would
be explained another random bit flip and/or random garbage written
into an inode table block.
3) An admin accidentally ran "tune2fs -O inline_data /dev/sdXX" to
enable the inline_data feature. The fscrypt message could be
explained as above.
In any case, e2fsck is doing the right thing. It *is* possible for
e2fsck to set the inline_data feature flag, yes..... but it's under
very tightly constrained circumstances, and the alternative would be
to have e2fsck to delete user data that could potentially be quite
valuable. (For example, a cryptographic key which protects a bitcoin
wallet with $220 million dollars worth of bitcoin in it. :-P )
Could this happen when it shouldn't? Well, it would highly unlikely
--- as in one in bazillions odds unlucky. It's actually much more
likely that a random bitflip in the in-memory superblock toggled the
inline_data feature bit set.
- Ted
