Syslinux - Aug 2010 - [PATCH] git tree: libfat, chain, mtools/syslinux, menu.txt

git://gnx.ath.cx/syslinux.git

On branch for_hpa, I've got several groups of changes (listed bottom up)
-chain.c32: the beginning of a DRMK loader; I still need to test this
further and document/code what ones can possibly work
-mtools/syslinux.c: Check to be sure fs is not NULL in case
libfat_open() failed, like it can on a bad filesystem.  Try to present
a useful error rather than a seg fault.
-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.
-NEW: mtools/fixfat: Attempts to change the sectors attribute of the
FAT to make it more "livable" (probably needs to move to utils, if
included)
-chain.c32: a little more progress on DRMK
-Last, a fix to doc/menu.txt; MENU RESOLUTION had height and width reversed.

-- 
-Gene

On 10-08-21 01:57, Gene Cumm wrote:
> git://gnx.ath.cx/syslinux.git
>
> On branch for_hpa, I've got several groups of changes (listed bottom
up)
> -chain.c32: the beginning of a DRMK loader; I still need to test this
> further and document/code what ones can possibly work
> -NEW: mtools/fixfat: Attempts to change the sectors attribute of the
> FAT to make it more "livable" (probably needs to move to utils,
if
> included)
> -chain.c32: a little more progress on DRMK
Could you possibly point me to the versions of drmk you're testing with 
(I think you mentioned about testing a few of them) ?

Like I mentioned earlier, the chain.c32 branch I'm working on 
might/should be able to load them in a completely generic way - meaning 
drmk= would only flip a bunch of different options, without any special 
part(s) dedicated to mangling dellbio.

On Fri, Aug 20, 2010 at 19:57, Gene Cumm <gene.cumm at gmail.com>
wrote:
> git://gnx.ath.cx/syslinux.git
>
> On branch for_hpa, I've got several groups of changes (listed bottom
up)
> -chain.c32: the beginning of a DRMK loader; I still need to test this
> further and document/code what ones can possibly work
> -mtools/syslinux.c: Check to be sure fs is not NULL in case
> libfat_open() failed, like it can on a bad filesystem. ?Try to present
> a useful error rather than a seg fault.
> -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.
> -NEW: mtools/fixfat: Attempts to change the sectors attribute of the
> FAT to make it more "livable" (probably needs to move to utils,
if
> included)
> -chain.c32: a little more progress on DRMK
> -Last, a fix to doc/menu.txt; MENU RESOLUTION had height and width
reversed.
And apparently, I forgot HPA had already pulled in the first group of
changes.  Thank you.

-- 
-Gene

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.

	-hpa

On 08/25/2010 03:01 PM, Gene Cumm wrote:
> 
> Sure.  I wouldn't think it would end up corrupting a live file system
> as it's supposed to only have read access.
> 
Sort of... we use the sector maps produced by libfat to write
"blindly"
to the filesystem.
> 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.
Something like that, yes; or it's a filesystem which genuinely is
corrupt, and we don't want to do more harm.

I've been very conservative about this, but ultimately I guess if the
operating systems allow it to be read/written then maybe that's good
enough...

	-hpa