linux-kernel - Linux & FAT32 label

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

Date:   Wed, 4 Oct 2017 17:33:32 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Andreas Bombe <aeb@...ian.org>, Karel Zak <kzak@...hat.com>,
        util-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     Andrius Štikonas <andrius@...konas.eu>,
        Curtis Gedak <gedakc@...il.com>
Subject: Linux & FAT32 label

Hi! There is a big inconsistency in Linux tools which read or write
FAT32 label in filesystem images. The most common used are tools:
blkid (from util-linux project), fatlabel (previously known as
dosfslabel; from dosfstools project) and mlabel (from mtools project).

FAT32 is itself a big mess from Microsoft hell and even FAT32
implementation in Microsoft Windows systems is not compliant to the
released FAT32 documentation from Microsoft.

In past months I observed that Linux FAT32 tools has its own way how
they interpret FAT32 label (known as volume id) and because every GUI
application uses one of those low-level command line tool, it is a big
mess if one application say that FAT32 label is A and another that it is
B. And then Windows XP say, it is C.

I would like to open discussion if it would be possible to change
behavior how blkid (from util-linux project) and fatlabel (from
dosfstool project) handle FAT32 label. Ideally to report exactly same
output.

Basic information about FAT32 label:

1) It is stored in two locations: boot sector and root directory as
   file name.

2) In both location format is 11 bytes, padded with spaces (not nulls).

3) Empty label in boot sector is stored as "NO NAME    " and not as
   empty string.

4) Empty label in root directory is stored either as name which starts
   with byte 0xE5, or is not stored in root directory at all.

5) If label contains leading byte 0xE5, then in root directory is stored
   as byte 0x05.

6) Label string is stored according to current DOS code page. Therefore
   label string needs to be converted to bytes.

7) Label string cannot contain control characters and characters from
   the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
   are stored as their upper case variant (not only ASCII).

(Please correct me if I'm wrong in some of those points)

Plus Microsoft Windows systems fully ignores label stored in boot
sector. Seems they do not read it nor they do not update it on changes.

Looks like that mlabel (from mtools) applies all above rules and uses
DOS code page 850 by default (can be changed in config file).

blkid and fatlabel process special cases from 1) to 5) differently and
they operates on raw bytes, not strings (in DOS code page).

mlabel reads label from the root directory (missing entry is interpreted
as no label; there is no fallback to boot sector), but "set" operation
modify label in both location boot sector + root directory. Basically it
is near to Windows implementation. And reason why Gparted GUI
application uses mlabel and not fatlabel.

As Linux does not have "current DOS code page" and argv arguments are
not (Unicode) strings, but arbitrary bytes, I understand that for point
6) it is easier to operates not on FAT strings (in current code page),
but rather on bytes. Which also would be same on all machines with any
configuration.

But would it be possible to decide and unify handling of point 2), 3),
4), 5)? Ideally with combination how to handle situation when different
label is stored in boot sector and root directory.

As Windows does not use label in boot sector, it is very common
situation that label in boot sector differs from the root directory.

The best would be see in all cases same label from blkid, fatlabel and
mlabel. Ideally same as Windows machines -- but due to DOS code page,
this is possible only for ASCII subset of the 8bit encoding. IIRC most
(or all?) DOS code page has same characters in printable ASCII range.

It is really bad situation if I open disk in Gparted which show me label
via mlabel and then I open in KDE Partition Manager and I see different
label string (as it reads it from fatlabel).

Also note that older version of fatlabel (when it was named dosfslabel)
operated only the label stored in boot sector (and label stored in root
directory was not read or touched).

-- 
Pali Rohár
pali.rohar@...il.com