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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Mar 2019 11:48:46 -0500 From: "Theodore Y. Ts'o" <tytso@....edu> To: Artem Blagodarenko <artem.blagodarenko@...il.com> CC: <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca> Subject: Re: [PATCH v7 1/4] ext2fs: opening filesystem code refactoring On Tue, Jan 29, 2019 at 08:51:31PM +0300, Artem Blagodarenko wrote: > There are similar opening filesystem code in different utilities. > > The patch moves improved handling from try_open_fs() > into ext2fs_open(). This function make one of the action > based on parameters: > 1) open filesystem with given superblock, superblock size > 2) open filesystem with given superblock, but try to > find right block size This changes the behavior of ext2fs_open() when the superblock and blocksize parameters is zero. Previously we read the primary superblock at the known location, and a blocksize of zero means "don't care" and so we just do the right thing. With your patch, it's going to loop for all possible block sizes, failing with EXT2_ET_UNEXPECTED_BLOCK_SIZE, until we stumble on the correct file system. That's unfortunate, especially if the device is opened with IO_FLAG_DIRECT_IO. So the brute force searching should be done using if an explicit flag is given. Using a new flag to request this new behavior is safer, but it's probably OK if we only do the blocksize search if the superblock parameter is zero --- you'll note that's what the code you were replacing in dumpe2fs and e2fsck was doing. More generally, for this whole patch series, in the "happy case" where the file system is fine, e2fsck and e2image should *not* do any extra work. - Ted
Powered by blists - more mailing lists