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
| ||
|
Message-ID: <20200519025355.GC2396055@mit.edu> Date: Mon, 18 May 2020 22:53:55 -0400 From: "Theodore Y. Ts'o" <tytso@....edu> To: Eric Biggers <ebiggers@...nel.org> Cc: linux-fscrypt@...r.kernel.org, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, Jaegeuk Kim <jaegeuk@...nel.org>, Daniel Rosenberg <drosen@...gle.com> Subject: Re: [PATCH 3/4] fscrypt: support test_dummy_encryption=v2 On Tue, May 12, 2020 at 04:32:50PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@...gle.com> > > v1 encryption policies are deprecated in favor of v2, and some new > features (e.g. encryption+casefolding) are only being added for v2. > > Therefore, the "test_dummy_encryption" mount option (which is used for > encryption I/O testing with xfstests) needs to support v2 policies. > > To do this, extend its syntax to be "test_dummy_encryption=v1" or > "test_dummy_encryption=v2". The existing "test_dummy_encryption" (no > argument) also continues to be accepted, to specify the default setting > -- currently v1, but the next patch changes it to v2. > > To cleanly support both v1 and v2 while also making it easy to support > specifying other encryption settings in the future (say, accepting > "$contents_mode:$filenames_mode:v2"), make ext4 and f2fs maintain a > pointer to the dummy fscrypt_context rather than using mount flags. > > To avoid concurrency issues, don't allow test_dummy_encryption to be set > or changed during a remount. (The former restriction is new, but > xfstests doesn't run into it, so no one should notice.) > > Tested with 'gce-xfstests -c {ext4,f2fs}/encrypt -g auto'. On ext4, > there are two regressions, both of which are test bugs: ext4/023 and > ext4/028 fail because they set an xattr and expect it to be stored > inline, but the increase in size of the fscrypt_context from > 24 to 40 bytes causes this xattr to be spilled into an external block. > > Signed-off-by: Eric Biggers <ebiggers@...gle.com> Signed-off-by: Theodore Ts'o <tytso@....edu> Looks good, but could you do me a favor and merge in this? diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index 04bfaf63752c..6c9fc9e21c13 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -293,6 +293,7 @@ EXT4_ATTR_FEATURE(batched_discard); EXT4_ATTR_FEATURE(meta_bg_resize); #ifdef CONFIG_FS_ENCRYPTION EXT4_ATTR_FEATURE(encryption); +EXT4_ATTR_FEATURE(test_dummy_encryption_v2); #endif #ifdef CONFIG_UNICODE EXT4_ATTR_FEATURE(casefold); @@ -308,6 +309,7 @@ static struct attribute *ext4_feat_attrs[] = { ATTR_LIST(meta_bg_resize), #ifdef CONFIG_FS_ENCRYPTION ATTR_LIST(encryption), + ATTR_LIST(test_dummy_encryption_v2), #endif #ifdef CONFIG_UNICODE ATTR_LIST(casefold), This will make it easier to have the gce-xfstests test runner know whether or not test_dummy_encryption=v1 / test_dummy_encryption=v2 will work, and whether test_dummy_encryption tests v1 or v2. Thanks! - Ted
Powered by blists - more mailing lists