linux-ext4 - Re: [PATCH] e2fsck: check for consistent encryption policies

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: <20190719231843.GH1422@gmail.com>
Date:   Fri, 19 Jul 2019 16:18:44 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     linux-ext4@...r.kernel.org, linux-fscrypt@...r.kernel.org
Subject: Re: [PATCH] e2fsck: check for consistent encryption policies

On Wed, Jul 17, 2019 at 08:12:25PM -0600, Andreas Dilger wrote:
> It would appear from my reading of the patch that every file that is
> encrypted will have the xattr saved until pass2? If the filesystem is very
> large (eg. billions of files), this will consume a large amount of memory.
> 
> Does it make sense to compare compression xattrs during pass1,
> and only track the set of different
> encryption context/type/master key
> sets that exist in the filesystem?  Since these will typically be common
> among large numbers of files, the memory will be largely reduced,
> maybe one or two ints per inode (either an inode+ID pair for sparse
> inodes, or just an ID for dense range of similarly-encrypted inodes with a
> start+count for the whole range. 
> 
> Cheers, Andreas
> 

That's correct.  I wanted to propose something simpler first to see what people
thought, but yes if this is really a concern, what we should do is assign a u32
id to each new encryption policy that is seen, and store just that id per inode.

To do that we need a proper map data structure for the policy => ID mapping,
which as usual is nontrivial to do in C.  lib/ext2fs/rbtree.h could do, though.
There's also lib/ext2fs/hashmap.c, but it doesn't implement resizing.

- Eric