lkml.org 
[lkml]   [2014]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fs: FAT: Add support for DOS 1.x formatted volumes
On Sun, 30 Mar 2014 02:56:46 +0900
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote:

> Conrad Meyer <cemeyer@uw.edu> writes:
>
> Hi,
>
> > When possible, infer DOS 2.x BIOS Parameter Block from
> > block device geometry (for floppies and floppy images).
> > Update in-memory only. We only perform this update when
> > the entire BPB region is zeroed, like produced by DOS
> > 1.x-era FORMAT (and other OEM variations on DOS).
> >
> > Fixes kernel.org bug #42617.
> >
> > BPB default values are inferred from media size and a
> > table.[0] Media size is assumed to be static for archaic
> > FAT volumes. See also [1].
> >
> > [0]:
> > https://en.wikipedia.org/wiki/File_Allocation_Table#Exceptions
> > [1]: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
>
> [...]
>
> > +static void fat_update_archaic_boot_sector(struct
> > super_block *sb,
> > + struct fat_boot_sector *b)
> > +{
> > + sector_t bd_sects;
> > +
> > + if (get_unaligned_le16(&b->sector_size) != 0 ||
> > b->sec_per_clus != 0 ||
> > + b->reserved != 0 || b->fats != 0 ||
> > + get_unaligned_le16(&b->dir_entries) != 0
> > ||
> > + get_unaligned_le16(&b->sectors) != 0 ||
> > b->media != 0 ||
> > + b->fat_length != 0 || b->secs_track != 0
> > || b->heads != 0 ||
> > + b->secs_track != 0 || b->heads != 0)
> > + return;
> > +
> > + bd_sects =
> > part_nr_sects_read(sb->s_bdev->bd_part);
> > + switch (bd_sects) {
> > + case 160 * KB_IN_SECTORS:
> > + b->sec_per_clus = 1;
> > + put_unaligned_le16(64, &b->dir_entries);
> > + b->media = 0xFE;
> > + b->fat_length = cpu_to_le16(1);
> > + break;
>
> [...]
>
> Hm, this looks like check the volume size. But if there is
> newer fat format on same volume size, how to detect it? Or,
> it is conflicting?

Newer fat volumes will have some non-zero values in the BPB
-- see the early return at the top of the update function. So
this code will ignore them.

>
> [BTW, we should avoid to mount if it doesn't seem fatfs, to
> prevent mis-mount as fatfs (auto mount is depending on this
> detection).]
>
> Thanks.

Hmm, good point. The checks for zero values in 0x0b through
~0x19 (BPB 2 with some of the BPB 3 fields) should help
prevent conflicts, to some degree. We can also check the
3-byte field "ignored" in struct fat_boot_sector -- it is
commonly "eb xx 90" (x86: JMP [rel8] ; NOP) but can also be
"e9 xx xx xx xx" (x86: JMP [rel32]).

These old floppies were only ever created on 16-bit machines,
so I think we can conditionalize on "eb xx 90". I will fix and
resend.

The first three bytes are on all the images from 1985 I have
are: eb 1c 90.

Here's the full boot sector. Perhaps we can also
conditionalize on the "Not system boot floppy" string?
Probably not, we want to support mounting boot floppies as
well.

0000000: eb1c 9000 0000 0000 0000 0000 0000 0000 ................
0000010: 0000 0000 0000 0000 0000 0000 0000 fa33 ...............3
0000020: c08e d0bc 0006 fb0e e846 00b4 06b0 00b7 .........F......
0000030: 07b9 0000 ba4f 18cd 10b4 02ba 0000 b700 .....O..........
0000040: cd10 beb8 102e 8a04 0ac0 74f9 56b4 0ebb ..........t.V...
0000050: 0700 cd10 5e46 ebed 074e 6f74 2073 7973 ....^F...Not sys
0000060: 7465 6d20 626f 6f74 2066 6c6f 7070 792e tem boot floppy.
0000070: 0058 5bba 8b10 8bca 2bd0 d1fa d1fa d1fa .X[.....+.......
0000080: d1fa 2bda 5351 cb00 0000 0000 0000 0000 ..+.SQ..........

The rest (0x090-0x1ff) is zeroes.

And here's the disassembly of the address signified by "JMP
+0x1c" (0x1e):

0x0000001e fa cli
0x0000001f 33c0 xor %ax,%ax
0x00000021 8ed0 mov %ax,%ss
0x00000023 bc0006 mov $0x600,%sp
0x00000026 fb sti
0x00000027 0e push %cs
0x00000028 e84600 call func_00000071

Not sure how common that is among FAT images; mkfs.fat does not
appear to generate valid code, other than eb 3c 90 at the
beginning of the sector.

Thanks,
Conrad


\
 
 \ /
  Last update: 2014-03-29 20:21    [W:0.062 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site