Util-Linux Archive on lore.kernel.org
 help / color / Atom feed
* fdisk not wiping sector 0 before writing new MBR
@ 2019-07-04 21:55 Mike Fleetwood
  2019-07-17 10:16 ` Karel Zak
  0 siblings, 1 reply; 3+ messages in thread
From: Mike Fleetwood @ 2019-07-04 21:55 UTC (permalink / raw)
  To: util-linux

Hi,

This is a bit more of a speculative than my other recent one, but I saw
this quote in aix.c:
    "All fdisk-like programs has to properly wipe the first sector.
    Everything other is a bug."

Using fdisk to create an MBR over the top of a whole disk FAT32 (and
probably FAT16) file system doesn't clear any of the FAT32 boot record
(aka super block).  Blkid and wipefs report this as just an MBR, but
because the boot record is intact, GNU parted reports this still as a
whole disk FAT32 file system.

This is from a GParted issue report where a user had an SD card that
must have originally come with a whole disk FAT32 file system and then
the user partitioned it over the top with fdisk.
   GitLab GParted issue 64 - Add support for Nobbs-partitioned SD cards
    https://gitlab.gnome.org/GNOME/gparted/issues/64

Test case:

Create a whole disk FAT32 file system.
    # dd if=/dev/zero bs=1M of=/dev/sdb
    # mkfs.fat -F32 -I /dev/sdb
    # ./blkid /dev/sdb
    /dev/sdb: UUID="1EF0-1723" TYPE="vfat"
    # ./wipefs /dev/sdb
    DEVICE OFFSET TYPE UUID      LABEL
    sdb    0x52   vfat 1EF0-1723
    sdb    0x0    vfat 1EF0-1723
    sdb    0x1fe  vfat 1EF0-1723

Create a single primary partition covering the whole disk.
    # ./fdisk --version
    lt-fdisk from util-linux 2.34.24-e3bb9
    # ./fdisk /dev/sdb
      n
      p
      [Return]   (defaults to 1)
      [Return]   (defaults to 2048)
      [Return]   (defaults to 16777215)
      w
    # ./fdisk -l /dev/sdb
    Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors
    Disk model: VBOX HARDDISK
    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: 0x00000000

    Device     Boot Start      End  Sectors Size Id Type
    /dev/sdb1        2048 16777215 16775168   8G 83 Linux

util-linux tools now report this as only containing an MBR.
    # ./blkid /dev/sdb
    /dev/sdb: PTTYPE="dos"
    # ./wipefs /dev/sdb
    DEVICE OFFSET TYPE UUID LABEL
    sdb    0x1fe  dos

But GNU parted still sees this as a whole disk FAT32 file system.
    # parted --version
    parted (GNU parted) 3.2
    ...
    # parted /dev/sdb unit s print
    Model: ATA VBOX HARDDISK (scsi)
    Disk /dev/sdb: 16777216s
    Sector size (logical/physical): 512B/512B
    Partition Table: loop
    Disk Flags:

    Number  Start  End
     1      0s

I used hexdump -C to look at sector 0 after writing the FAT32 and after
writing the MBR.  The only bytes which changed were those 16 bytes
storing partition 1 in the MBR.  None of the other bytes in sector 0
changed, hence why parted was able to misidentify this as a FAT32 file
system.

Then just remove that partition and blkid and wipefs again detect it as
a whole disk FAT32 file system.
    # ./fdisk /dev/sdb
      d
      w
    # ./blkid /dev/sdb
    /dev/sdb: UUID="1EF0-1723" TYPE="vfat"
    # ./wipefs /dev/sdb
    DEVICE OFFSET TYPE UUID      LABEL
    sdb    0x52   vfat 1EF0-1723
    sdb    0x0    vfat 1EF0-1723
    sdb    0x1fe  vfat 1EF0-1723

I don't think a user can have any expectation that if a whole disk FAT32
file system "superfloppy" was bootable, that after using fdisk to write
an MBR over the top, that it can still be bootable, without writing new
boot code to the disk.

Thank you for your consideration,
Mike

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: fdisk not wiping sector 0 before writing new MBR
  2019-07-04 21:55 fdisk not wiping sector 0 before writing new MBR Mike Fleetwood
@ 2019-07-17 10:16 ` Karel Zak
  2019-07-17 10:26   ` Karel Zak
  0 siblings, 1 reply; 3+ messages in thread
From: Karel Zak @ 2019-07-17 10:16 UTC (permalink / raw)
  To: Mike Fleetwood; +Cc: util-linux

On Thu, Jul 04, 2019 at 10:55:16PM +0100, Mike Fleetwood wrote:
> Hi,
> 
> This is a bit more of a speculative than my other recent one, but I saw
> this quote in aix.c:
>     "All fdisk-like programs has to properly wipe the first sector.
>     Everything other is a bug."
>
> Using fdisk to create an MBR over the top of a whole disk FAT32 (and
> probably FAT16) file system doesn't clear any of the FAT32 boot record
> (aka super block).  Blkid and wipefs report this as just an MBR, but
> because the boot record is intact, GNU parted reports this still as a
> whole disk FAT32 file system.

This is bug. MBR probing code in fdisk is weak and it does not check for 
false positives like blkid, so FAT32 is interpreted as MBR and the bootbits
are not wiped (fdisk wipes first sector only if it creates a new
partition table).

In another case like

  # dd if=/dev/urandom of=/dev/sdc bs=512 count=1
  # hexdump -C -n 512 /dev/sdc
  # fdisk /dev/sdc                 (...create MBR)

  # hexdump -C -n 512 /dev/sdc
  00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  *
  000001b0  00 00 00 00 00 00 00 00  0b b7 83 76 00 00 00 00  |...........v....|
  000001c0  31 0a 83 03 f2 ff 00 08  00 00 00 18 03 00 00 00  |1...............|
  000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  *
  000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
  00000200



> 
> This is from a GParted issue report where a user had an SD card that
> must have originally come with a whole disk FAT32 file system and then
> the user partitioned it over the top with fdisk.
>    GitLab GParted issue 64 - Add support for Nobbs-partitioned SD cards
>     https://gitlab.gnome.org/GNOME/gparted/issues/64
> 
> Test case:
> 
> Create a whole disk FAT32 file system.
>     # dd if=/dev/zero bs=1M of=/dev/sdb
>     # mkfs.fat -F32 -I /dev/sdb
>     # ./blkid /dev/sdb
>     /dev/sdb: UUID="1EF0-1723" TYPE="vfat"
>     # ./wipefs /dev/sdb
>     DEVICE OFFSET TYPE UUID      LABEL
>     sdb    0x52   vfat 1EF0-1723
>     sdb    0x0    vfat 1EF0-1723
>     sdb    0x1fe  vfat 1EF0-1723
> 
> Create a single primary partition covering the whole disk.
>     # ./fdisk --version
>     lt-fdisk from util-linux 2.34.24-e3bb9
>     # ./fdisk /dev/sdb
>       n
>       p
>       [Return]   (defaults to 1)
>       [Return]   (defaults to 2048)
>       [Return]   (defaults to 16777215)
>       w
>     # ./fdisk -l /dev/sdb
>     Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors
>     Disk model: VBOX HARDDISK
>     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: 0x00000000
> 
>     Device     Boot Start      End  Sectors Size Id Type
>     /dev/sdb1        2048 16777215 16775168   8G 83 Linux
> 
> util-linux tools now report this as only containing an MBR.
>     # ./blkid /dev/sdb
>     /dev/sdb: PTTYPE="dos"
>     # ./wipefs /dev/sdb
>     DEVICE OFFSET TYPE UUID LABEL
>     sdb    0x1fe  dos
> 
> But GNU parted still sees this as a whole disk FAT32 file system.
>     # parted --version
>     parted (GNU parted) 3.2
>     ...
>     # parted /dev/sdb unit s print
>     Model: ATA VBOX HARDDISK (scsi)
>     Disk /dev/sdb: 16777216s
>     Sector size (logical/physical): 512B/512B
>     Partition Table: loop
>     Disk Flags:
> 
>     Number  Start  End
>      1      0s
> 
> I used hexdump -C to look at sector 0 after writing the FAT32 and after
> writing the MBR.  The only bytes which changed were those 16 bytes
> storing partition 1 in the MBR.  None of the other bytes in sector 0
> changed, hence why parted was able to misidentify this as a FAT32 file
> system.
> 
> Then just remove that partition and blkid and wipefs again detect it as
> a whole disk FAT32 file system.
>     # ./fdisk /dev/sdb
>       d
>       w
>     # ./blkid /dev/sdb
>     /dev/sdb: UUID="1EF0-1723" TYPE="vfat"
>     # ./wipefs /dev/sdb
>     DEVICE OFFSET TYPE UUID      LABEL
>     sdb    0x52   vfat 1EF0-1723
>     sdb    0x0    vfat 1EF0-1723
>     sdb    0x1fe  vfat 1EF0-1723
> 
> I don't think a user can have any expectation that if a whole disk FAT32
> file system "superfloppy" was bootable, that after using fdisk to write
> an MBR over the top, that it can still be bootable, without writing new
> boot code to the disk.
> 
> Thank you for your consideration,
> Mike
> 

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: fdisk not wiping sector 0 before writing new MBR
  2019-07-17 10:16 ` Karel Zak
@ 2019-07-17 10:26   ` Karel Zak
  0 siblings, 0 replies; 3+ messages in thread
From: Karel Zak @ 2019-07-17 10:26 UTC (permalink / raw)
  To: Mike Fleetwood; +Cc: util-linux

On Wed, Jul 17, 2019 at 12:16:28PM +0200, Karel Zak wrote:
> On Thu, Jul 04, 2019 at 10:55:16PM +0100, Mike Fleetwood wrote:
> > Hi,
> > 
> > This is a bit more of a speculative than my other recent one, but I saw
> > this quote in aix.c:
> >     "All fdisk-like programs has to properly wipe the first sector.
> >     Everything other is a bug."
> >
> > Using fdisk to create an MBR over the top of a whole disk FAT32 (and
> > probably FAT16) file system doesn't clear any of the FAT32 boot record
> > (aka super block).  Blkid and wipefs report this as just an MBR, but
> > because the boot record is intact, GNU parted reports this still as a
> > whole disk FAT32 file system.
> 
> This is bug. MBR probing code in fdisk is weak and it does not check for 
> false positives like blkid, so FAT32 is interpreted as MBR and the bootbits
> are not wiped (fdisk wipes first sector only if it creates a new
> partition table).

Ah, I've forgot... it's fixed now :-)

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-04 21:55 fdisk not wiping sector 0 before writing new MBR Mike Fleetwood
2019-07-17 10:16 ` Karel Zak
2019-07-17 10:26   ` Karel Zak

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
		util-linux@vger.kernel.org util-linux@archiver.kernel.org
	public-inbox-index util-linux


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.util-linux


AGPL code for this site: git clone https://public-inbox.org/ public-inbox