linux-ext4 - Remarks regarding sparse

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-next>] [day] [month] [year] [list]

Message-ID: <5724CE0E.6030407@partition-saving.com>
Date:	Sat, 30 Apr 2016 17:23:58 +0200
From:	Damien Guibouret <damien.guibouret@...tition-saving.com>
To:	linux-ext4@...r.kernel.org
Subject: Remarks regarding sparse_super2 feature

Hello,

I was looking to sparse_super2 feature and there is some points I do not 
understand in the way it is handled on fs initialisation and resize.

In ext2fs_initialize (initialize.c), the backup superblocks field is initialised 
at line 437, but they were used previously when checking for overhead (at line 
407) when the second value is still ~0. Could not this lead to wrong overhead 
computation in some cases?
This is certainly very unlikely because of the 50 margin taken on this overhead. 
As this is some chicken/egg problem, solution is not obvious. A way is perhaps 
to have ext2fs_bg_has_super accepting ~0 as a group always having a backup 
superblock (unless extending the number of groups to 64 bits, if such a number 
of groups is reached, it will obviously be the latest so be the candidate for 
the backup bg).

In case there is some other solution, there is same kind of problem in 
adjust_fs_info of resize2fs.c (line 724 check for backup super block and line 
839 updates the value).

Concerning adjust_fs_info I do not understand the logic of some tests concerning 
update of these values:
at line 844:
			if (old_fs->group_desc_count == 1)
				fs->super->s_backup_bgs[0] = 1;
			if (old_fs->group_desc_count == 1 &&
			    fs->super->s_backup_bgs[0])
				fs->super->s_backup_bgs[0] = last_bg;
			else if (fs->super->s_backup_bgs[1])
				fs->super->s_backup_bgs[1] = last_bg;
couldn't the 2 first "if" be collapsed: if first one is true, it leads to second 
one be true and if first one is false, second is also false. Or perhaps it means 
it is the wrong value that is checked or initialised in second if?

For the other case (shrinking the fs) at line 856:
			if (last_bg > 1 &&
			    old_fs->super->s_backup_bgs[1] == old_last_bg)
				fs->super->s_backup_bgs[1] = last_bg;
what ensures the location where the new super block backup will be set is a free 
block?

Regards,

Damien
--
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