linux-kernel - Re: [PATCH] ext4: fix underflow in group bitmap calculation

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

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