FORMAT crashes with division by zero on a 2 TiB FAT-32 partition

[boeckmann]

Wilhelm Spiegl reported that FROMAT crashes with a divison by zero error when trying a 2 TiB FAT-32 partition. I could reproduce the problem. The determination of the FAT size and/or its start-end sectors seem to fail. See attached screenshots.

[boeckmann]

I could track down the error to the FreeDOS kernel function 440D,4860. This functions returns a zero in the DWORD logical_sectors_per_fat (see fat_size_high and fat_size_low in screenshot), while setting no error flag. FORMAT therefore accepts the fat size returned by the Kernel and works with the non-valid value, eventually leading to the division by zero.

[boeckmann]

It should be mentioned that the number of logical fat sectors is returned correctly by INT21 function 440d,4860 if the partition is slightly smaller than 2 TiB.

[PerditionC]

kernel bug?

[boeckmann]

Maybe. A candidate for an integer wrap-around is:

• https://github.com/FDOS/kernel/blob/95694f7e349f6a7b433292448bd0890b10657214/kernel/initdisk.c#L485C50-L485C50

There is a DebugPrintf a few lines later. If this spits out fatlen=0 on the 2 TiB partition, we know for sure.

[PerditionC]

I will see about recreating a partition that causes the trouble and fix the kernel if that is the culprit. It may take me a few days, depending on how much free time I have.

[boeckmann]

@PerditionC if you are short on time I can try to figure it out by myself, and provide a patch in case of an error. But it will probably take me a week or so.

[andrewbird]

I thought I'd write a test for dosemu's test suite for this, but I seem to be running into a limitation. I created a sparse file of 3 TiB to use as a pseudo disk, then as a check ran Linux's FDISK on it. However I get this response.

 ajb@calypso:/clients/common/dosemu2.git$ ls -lh /tmp/devbpbi.tst
-rw-r--r-- 1 ajb sphere 3.0T Nov 29 12:26 /tmp/devbpbi.tst

Welcome to fdisk (util-linux 2.37.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognised partition table.
The size of this disk is 3 TiB (3298534883328 bytes). DOS partition table format
cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors.
Use GUID partition table format (GPT).

Created a new DOS disklabel with disk identifier 0xb1182dbe.

Command (m for help): p
Disk /tmp/devbpbi.tst: 3 TiB, 3298534883328 bytes, 6442450944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb1182dbe

Command (m for help): 

So my question is, is the only fix possible that the kernel returns an error if the disk is 2TiB or larger, or else non 512B sectors would need to be supported?

[boeckmann]

So my question is, is the only fix possible that the kernel returns an error if the disk is 2TiB or larger, or else non 512B sectors would need to be supported?

@andrewbird I don't think the kernel has to throw an error on such disks. Creating and using a 2TiB MBR partition even on a 3TiB disk should be perfectly fine. One pitfall is that the 32-bit sector variables may overflow on disks >2TiB. Free FDISK therefore restricts the disk size returned by the BIOS to 2TiB. This is done here: https://github.com/FDOS/fdisk/blob/b3ef4505e38c78978788555a1e8b4da91578aead/source/fdisk/pdiskio.c#L562

There is also another option: implement GPT support in initdisk.c. This should actually be easier than updating the Kernel to support non-512-byte sectors, I think. To my knowledge, Tom Ehlert already did some work on GPT support. But for reasons unknown to me it did not land in the official kernel.

[boeckmann]

But to make use of GPT partition >2TiB the variables storing the sector numbers had to be adjusted to 64-bit.

[PerditionC]

GPT support is being worked on, I have it partially working with Open Watcom but haven't had a chance to figure out the math helpers for GCC for 64bit math. Tom's code was merged with my work, but it is limited to finding DOS partitions and requires they still be within 32 bit limits. I'm working on 64 bit GPT support. As such, only 386+ built kernels will offer GPT support (at least until a 8086 version of math helpers get written)

[diekleineHexe]

64 bit support should be almost trivially easy as it's only adding a 32 it number into a 64 bit number; no need for external helper functions needed:

typedef struct { unsigned long low,high; } __int64;

__int64 partitionStart; // to be initialized correctly.

__int64 actualSector;
unsigned long offset;

actualSector = partitionStart;

actualSector.low += offset;

if (actualSector.low < offset) // carry !!
actualSector.high ++;

LBAreadSector(actualSector.low);

//done

[PerditionC]

For clarification, it's not holding a 64bit value or adding 64bit values that invoke the helper function, its multiplication. Also, these are compiler helper functions, so invisible to the C code more or less - these are internal runtime functions that we have to provide substitutes for since not using the compiler's runtime.