From nobody Mon Dec 30 22:55:15 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YMWdw4Lw5z5j83T for ; Mon, 30 Dec 2024 22:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YMWdw1Lxpz4Sdv for ; Mon, 30 Dec 2024 22:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1735599316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=OG+FCcpKK7/dA7cR9i+d8d/yOqQSYubteooSliME39s=; b=WQcf/Br1BFFzgitiUlpNJfjqKF/Iikfy1tvBiPaLBXNL9CGUZji7yWqmUliKfKGIxX552n GnvXUYJFwQDKlPG/E3+DWs8IRbBUG1tRYEfKSW98654C2j8HOA6851sg5vitP/4Srs8Wlw iPvBabFIreA82MRO6/Olz+O62OH+GOtxFZjVFQofQQ+InJOJJ8ug/bnMny4nzqmtbOj7EM S4wlD0RciQaRhzEnSJAK3nvATdNg6uLaCYnV+RDqpE6l7254K5Gf9aXl2tjswAW+iWStPp EHmHTw1spXEbilC5uzJCQQdZ5bQmwVG+RQPlvDI016W8zpYoq+n7j4MToPWwqw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1735599316; a=rsa-sha256; cv=none; b=OFosTT1S+HlnLO6Es4fW8NGIzKtp0qr6/D4D+3+L5rr+Q35C56AwWswBydf3EAHAwJPRtB jYCGL/9xjKMrwws74JM1B5cok/D8rxYMMuRYPspjEAv4w+kHwQwrpqdj1IyhE5ufN1sSCi 5qXSSlzt7fZtc6KI9XDdExeUl0ZILi3GztKxNsCznfKaPPGkUJIpbaeDp9BF0aFiDnxuuY 4lb/BUhcTJSmjWY7cWvW6pzdjKZ8R3p1mBmSLqOw8TzHi5zl08rf43rpU6qNWmx7m2Fo13 DyM4PzTedM409Gmx60tYhEWaw3TZhOGFAWDAlr9JXXBCsOjQo9re5/O9NpJGQQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4YMWdw0GjJz1Cr3 for ; Mon, 30 Dec 2024 22:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4BUMtFpD038156 for ; Mon, 30 Dec 2024 22:55:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4BUMtFZx038155 for bugs@FreeBSD.org; Mon, 30 Dec 2024 22:55:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283753] gpart: rejects MBR-formatted disks with partitions that include LBA 4294967295 Date: Mon, 30 Dec 2024 22:55:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283753 Bug ID: 283753 Summary: gpart: rejects MBR-formatted disks with partitions that include LBA 4294967295 Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org PROBLEM =3D=3D=3D=3D=3D=3D=3D On a disk of 2TiB or more (0x100000000 512B sectors), gpart will wrongly re= ject the partition table as corrupt if any partition's final LBA resides on the 0xffffffffth sector (sector 4294967295). gpart will refuse to create any device nodes, and print messages to dmesg like: GEOM_PART: partition 4 has end offset beyond last LBA: 4294967295 > 4294967= 294 GEOM_PART: integrity check failed (md0, MBR) STEPS TO REPRODUCE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On GNU/Linux, do these commands $ truncate -s 2199023255552 2t_file $ /usr/sbin/fdisk almost_2t_file At the interactive prompt, type these subcommands: > o > n > p > 1 >=20 > > p Disk 2t_file: 2 TiB, 2199023255552 bytes, 4294967296 sectors Units: sectors of 1 * 512 =3D 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x30b69544 Device Boot Start End Sectors Size Id Type 2t_file1 2048 4294967295 4294965248 2T 83 Linux Notice the end LBA of the partition is 4294967295. Now, on FreeBSD, try to attach gpart to this file, like this: $ sudo mdconfig -a -t vnode -f 2t_file md0 $ gpart show md0 gpart: No such geom: md0. $ dmesg | tail -n1 GEOM_PART: integrity check failed (md0, MBR) IMPACT =3D=3D=3D=3D=3D=3D GNU/Linux's fdisk tool (tested on Debian 12) will allow creating a partition table with a primary partition that includes LBA 4294967295. Attempting to mount such a disk image on FreeBSD will fail with the above message. This bug is unlikely to effect any physical hard disks, since none were ever manufactured in 2 TiB capacities, and Linux refuses to allow a primary partition that includes LBA 4294967296 or greater. But it effects disk ima= ges of 2 TiB, and disk images of greater than 2 TiB with a partition table that only uses the first 2 TiB. WORKAROUND =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Setting sysctl kern.geom.part.check_integrity=3D0 will workaround the probl= em.=20 However, it will also disable other sanity checks that may be important. ENVIRONMENT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tested on FreeBSD amd64 15.0-CURRENT as of 27-Dec-2024, and FreeBSD amd64 14.1-RELEASE. ANALYSIS =3D=3D=3D=3D=3D=3D=3D=3D An MBR partition entry contains a 32-bit field for each partition's starting LBA and a 32-bit field for each partition's length in sectors. So a partit= ion could theoretically start on LBA 0xffffffff and run for 0xffffffff sectors, meaning that it's last LBA would be 0x1fffffffd. But many (most?) tools re= ject such partitions. GNU/Linux, for example, will refuse to create a partition that ends on a sector higher than 4294967295. The logic in FreeBSD is foun= d in the g_part_check_integrity function, which requires the partition's last LB= A to be less than or equal to the disk's gpt_last value. That gpt_last value is not recorded in the MBR; it's inferred from the disk= 's mediasize. In the function g_part_mbr_create it's set to "MIN(pp->mediasiz= e / pp->sectorsize, UINT32_MAX) - 1". That code was added in SVN r221972 in May 2011 when gpart's MBR support was first added. The older /sbin/fdisk tool = did not attempt such integrity validation. I'm tempted to say that the logic in g_part_mbr_create is wrong, and the correct expression should be "MIN(pp->mediasize / pp->sectorsize - 1, UINT32_MAX)". That would fix this bug. However, I find similar expression= s in the code for other partition table formats: BSD, BSD64, APM, EBR, and even = GPT. But not, however, LDM. So I can't change it with confidence. --=20 You are receiving this mail because: You are the assignee for the bug.=