| 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
| ||
|
Message-ID: <20171105130608.5oww3b2fnnrwe7ok@pali>
Date: Sun, 5 Nov 2017 14:06:08 +0100
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: Re: Linux & FAT32 label
On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > 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).
> >
>
> Hi! I did some testing of FAT32 label with different tools and here are
> results:
Hi! I did more tests with MS-DOS and Windows systems and I'm extending
result tables below:
> dosfslabel 3.0.12 fatlabel 4.1 blkid 2.20.1 mlabel 4.0.12 label.exe Windows XP
> fat32_mkdosfs_label1 'label1 ' 'label1 ' 'label1' 'label1 ' 'label1'
> fat32_mkdosfs_label1_dosfslabel_empty ' ' ' ' none ' ' none
> fat32_mkdosfs_label1_dosfslabel_label2 'label2 ' 'label2 ' 'label2' 'label2 ' 'label2'
> fat32_mkdosfs_label1_dosfslabel_NO_NAME 'NO NAME ' 'NO NAME ' none 'NO NAME ' 'NO NAME'
> fat32_mkdosfs_label1_mlabel_erase 'NO NAME ' 'NO NAME ' none none none
> fat32_mkdosfs_label1_mlabel_NO_NAME 'NO NAME ' 'NO NAME ' none 'NO NAME ' 'NO NAME'
> fat32_mkdosfs_label1_xp_erase 'label1' ' 0xE5'abel1 ' 'label1' none none
> fat32_mkdosfs_label1_xp_label2 'label1' ' 'LABEL2 ' 'LABEL2' 'LABEL2 ' 'LABEL2'
> fat32_mkdosfs_none ' ' ' ' none none none
> fat32_mkdosfs_none_dosfslabel_label1 'label1 ' 'label1 ' 'label1' none none
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2 'label1' ' 'LABEL2 ' 'LABEL2' 'LABEL2 ' 'LABEL2'
> fat32_mkdosfs_none_dosfslabel_NO_NAME 'NO NAME ' 'NO NAME ' none none none
> fat32_mkdosfs_none_xp_label1 ' ' 'LABEL1 ' 'LABEL1' 'LABEL1 ' 'LABEL1'
> fat32_mkdosfs_none_xp_label1_dosfslabel_label2 'label2 ' 'label2 ' 'label2' 'label2 ' 'label2'
> fat32_xp_label1 'NO NAME ' 'LABEL1 ' 'LABEL1' 'LABEL1 ' 'LABEL1'
> fat32_xp_none 'NO NAME ' 'NO NAME ' none none none
> fat32_xp_none_dosfslabel_label1 'label1 ' 'label1 ' 'label1' none none
> fat32_xp_none_mlabel_label1 'LABEL1 ' 'LABEL1 ' 'LABEL1' 'LABEL1 ' 'LABEL1'
label.exe MS-DOS 7.10 label.exe Windows 98 label.exe Windows 10
fat32_mkdosfs_label1 'label1' 'label1' 'label1'
fat32_mkdosfs_label1_dosfslabel_empty '' '' none
fat32_mkdosfs_label1_dosfslabel_label2 'label2' 'label2' 'label2'
fat32_mkdosfs_label1_dosfslabel_NO_NAME 'NO NAME' 'NO NAME' 'NO NAME'
fat32_mkdosfs_label1_mlabel_erase none none none
fat32_mkdosfs_label1_mlabel_NO_NAME 'NO NAME' 'NO NAME' 'NO NAME'
fat32_mkdosfs_label1_xp_erase none none none
fat32_mkdosfs_label1_xp_label2 'LABEL2' 'LABEL2' 'LABEL2'
fat32_mkdosfs_none none none none
fat32_mkdosfs_none_dosfslabel_label1 none none none
fat32_mkdosfs_none_dosfslabel_label1_xp_label2 'LABEL2' 'LABEL2' 'LABEL2'
fat32_mkdosfs_none_dosfslabel_NO_NAME none none none
fat32_mkdosfs_none_xp_label1 'LABEL1' 'LABEL1' 'LABEL1'
fat32_mkdosfs_none_xp_label1_dosfslabel_label2 'label2' 'label2' 'label2'
fat32_xp_label1 'LABEL1' 'LABEL1' 'LABEL1'
fat32_xp_none none none none
fat32_xp_none_dosfslabel_label1 none none none
fat32_xp_none_mlabel_label1 'LABEL1' 'LABEL1' 'LABEL1'
Seems that behavior of reading label from FAT32 volume is consistent
between MS-DOS and different Windows versions. The only exception is
when in label in the root directory is stored as empty string (11
spaces). MS-DOS and Windows 98 treat it as label with empty string, but
Windows XP and Windows 10 as disk without label.
> In the first column is image name (all images are compressed and
> attached) which contains steps of operations, e.g. file name
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2 means:
>
> 1. create filesystem with mkdosfs without specifying label
> 2. change label with dosfslabel (3.0.12) to 'label1'
> 3. change label under Windows XP to 'label2'
>
> From testing it looks like that different tools and different version of
> them have different behavior how they read or write FAT32 label, see
> following table:
>
> read boot write boot read root write root
> dosfslabel 3.0.0 - 3.0.6 YES YES NO NO
> dosfslabel 3.0.7 - 3.0.15 YES YES NO BUGGY (YES - if already exists; NO - otherwise)
> dosfslabel 3.0.16 - 4.1 YES YES YES YES
> label.exe Windows XP NO NO YES YES
> blkid YES NO YES NO
> mlabel NO YES YES YES
label.exe MS-DOS 6.22 NO YES YES YES
label.exe MS-DOS 7.10 NO YES YES YES
label.exe Windows 98 SE NO YES YES YES
label.exe Windows 10 NO NO YES YES
Older MS-DOS 6.22 does not support FAT32 disks, only FAT16. MS-DOS 7.10
has support for FAT32 and also for LFN. But both tested MS-DOS versions
and Windows 98 updates label in both locations: boot sector and root
directory. Also in case when label is changed in Windows 98 via
"My Computer" GUI.
>From above tests it can be seen that both MS-DOS and all Windows
versions ignores label which is stored in boot sector and show to user
only label from root directory.
Also it can be seen that both MS-DOS versions do not have problems when
label contains lower case letters.
> Attached images in compressed form has only 600 kB and I think they can
> be useful for testing either blkid or dosfstools project, so I'm sending
> them here.
--
Pali Rohár
pali.rohar@...il.com
Powered by blists - more mailing lists