[syslinux] [PATCH] git tree: libfat, chain, mtools/syslinux, menu.txt

[Gene Cumm]

On Wed, Aug 25, 2010 at 16:42, H. Peter Anvin <hpa at zytor.com> wrote:
> On 08/20/2010 04:57 PM, Gene Cumm wrote:
>> -libfat: A check for NULL pointers; A change to allow for a short
>> FAT/too many sectors (depending on perspective); Try trimming the
>> in-memory values to deal with the corruption, if possible.
>
> I'm confused about ca8cade1f86cd22c8dfbdd199bd611df35c1cb92.
>
> The purpose of the checks in libfat_open() is to make sure we throw an
> error rather than end up corrupting a live filesystem.  As far as I can
> read, it looks like the end result of this code is that we functionally
> "defang" the sanity check?
>
> It makes me very nervous, and I really want to get more of an explanation.

(And I thought I hit reply all)

Sure.  I wouldn't think it would end up corrupting a live file system
as it's supposed to only have read access.

It doesn't "defang" all of the sanity check.  it just sees that,
technically, the file system is corrupt.  Specifically, the FAT itself
is too short for the the declared number of sectors in bsSectors or
bsHugeSectors.  It attempts to compute a possibly sane value and
redoes the sanity check with the new value.  If the new value passes
the sanity checks, it's usable.  This serves to essentially ignore the
end of the file system in favor of what can really be allocated in the
FAT.

For a time, Dell was making images that were corrupt in this manner.
Both Linux and mtools seem to ignore this corruption.

The other idea (which is how I found out the exact failure) is to
either barf to unique locations or set errno then go to barf such that
an enduser is informed how the file system failed the checks.

I'm starting to see what you might be thinking about: Syslinux is
pointed at a random jumble of bits that happen to resemble a FAT file
system and only bsSectors or bsHugeSectors is off from passing all
checks for probably being a valid file system.

--
-Gene