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: <Y6U3x3Cs8Mzaakkx@mit.edu> Date: Fri, 23 Dec 2022 00:08:23 -0500 From: "Theodore Ts'o" <tytso@....edu> To: "Darrick J. Wong" <djwong@...nel.org> Cc: Jun Nie <jun.nie@...aro.org>, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] ext4: fix underflow in group bitmap calculation On Thu, Dec 22, 2022 at 10:08:59AM -0800, Darrick J. Wong wrote: > > Question -- on a 1k-block filesystem, are the first 1024 bytes of the > device *reserved* by ext4 for whatever bootloader crud goes in there? > Or is that space undefined in the filesystem specification? > > I never did figure that out when I was writing the ondisk specification > that's in the kernel, but maybe you remember? That's an interesting (and philosophical) question. The ext2 file system never had a formal specification, and this part of the file system format was devised by Remy Card before I had gotten involved with ext2. (I first got started writing e2fsprogs; which replaced the previous file system utilities, which were forked from minix's tools, and which were quite inefficient.) In favor of it being undefined, the first 1024 bytes are not part of any block group in an ext2 file system with a 1k block size. (The first block group is composed of physical blocks 1 through 8192 inclusive when the block size is 1k. Whereas if the blocksize is 4k, the first block group is composed of physical blocks 0 through 32767.) In addition, the status of the first 1024 bytes is not controlled by an ext2 block allocation bitmap. One could also argue that to the extent that ext2 was derived the ext file system, which in turn was derived from Minix --- and Minix File System (which does have a specification, explicitly states that "block 0" is reserved for the Bootloader, with "Block 1" being the location of the superblock. But Minix only supports a 1k blocksize, and doesn't have the concept of FFS-style block (cylinder) groups. So I'd come down on the side which states that the first 1024 bytes are "undefined" on a 1k block file system. (One could also aruge that they are "undefined" on a 2k and 4k block file system, but the first 1024 bytes are part of "block 0", and on 2k and 4k block file systems, "block 0" is part of a block group.) > If those first 1024 bytes are defined to be reserved in the ondisk > format, then you could return a mapping for those bytes with the owner > code set to EXT4_FMR_OWN_UNKNOWN. > > If, however, the space is undefined, then going off this statement in > the manpage: > > "For example, if the low key (fsmap_head.fmh_keys[0]) is set to (8:0, > 36864, 0, 0, 0), the filesystem will only return records for extents > starting at or above 36 KiB on disk." > > I think the 'at or above' clause means that ext4 should not pass back > any mapping for the byte range 0-1023 on a 1k-block filesystem. Sure, sounds good to me. - Ted
Powered by blists - more mailing lists