[syslinux] isolinux.bin checksum

[Thomas Schmitt]

Hi,

Ady wrote:
> Apparently, one of the consequences seems to be that the default 
> checksum included in isolinux.bin doesn't seem to help those 
> users/programs that, for whichever reason (e.g. user lacking 
> knowledge), do not patch the boot info table.

I agree and still riddle about the reason.

> So, my question is whether there is some intentional reason for these 
> changes in isolinux.bin.

I assume that hpa intended to move the functionality of checksumiso.pl
into the "prepcore" helper program which compresses all or parts of the
./core/*.bin files.

> What I'd like to know is what 
> happened with the "default" checksum in isolinux.bin,

To my theory it fell victim to a bug.

> how is/are the checksum(s) calculated now?

To my best knowledge by helper program "prepcore". At least the Debian
build log looks like no other program changes isolinux.bin afterwards.

>  Is it possible that the current calculation is incorrect / a bug

Most likely.

> not taking the adequate range of values as input?

Quite probably it is some other bug. But as long as i can show no good
suspect, everything is possible.


-----------------------------------------------------------------------
Unsuccessful theories so far:

The only potential problem i found in lzo/prepcore.c up to now, is that
the buffer for the compressed isolinux.bin is created by malloc(3), which
does not guarantee to hand out the buffer will all zeros as content.
prepcore nevertheless rounds up the outfile_len to finally yield full blocks
of 2048 bytes size. So up to 2047 bytes of arbitrary discarded memory content
could end up in the compressed isolinux.bin.
But those bytes would also be part of prepcore's checksum computation. So the
checksum should match the one from libisofs.

I further tried to provoke the initial checksum of isolinux.bin by spoiling
the byte order of the 4-byte unsigned integers which get added.
But prepcode's function get_32() in both variants yields on amd64 the same
integer values as libisofs sees. Willfully reverting byte order of the
integers does not yield the initial checksum 0x09e675b8.

Another suspect would be a difference between checksum computation and
effective file writing. But the code looks good in that aspect. Checksumming
and file writing is just 20 lines apart in the same function.
Unless the number of uncompressed bytes at the file start is not divisible
by 4, the checksummed byte range and the written byte range match. (The first
64 bytes get not checksummed but written. That's normal.)
The number "offset" of uncompressed bytes stems from the .raw file that
serves as input for prepcore. I assume it is larger than 400 bytes, because
i saw a comment that the LZO decompressor code has 400+ bytes. It must be
in the uncompressed part.
Regrettably those parameters are not written into isolinux.bin. So i can
only guess.

Next i wondered whether Debian maybe does not treat isolinux.raw by
prepcore. But the build log
  https://buildd.debian.org/status/fetch.php?pkg=syslinux&arch=amd64&ver=3%3A6.03%2Bdfsg1-2&stamp=1508286838&raw=0
shows
  /<<BUILDDIR>>/syslinux-6.03+dfsg1/bios/core/../lzo/prepcore ldlinux.raw ldlinux.bin
and isolinux.bin seems not to be manipulated afterwards.

-----------------------------------------------------------------------


Have a nice day :)

Thomas