[syslinux] Verify contents before boot?

Thomas Schmitt scdbackup at gmx.net
Fri Aug 4 15:35:17 PDT 2017


Bret Schuhmacher wrote:
> > I want to write a bootable ISO
> > and include some extra stuff on it... the hash and some customer data.

That would be doable somehow. But there is another problem.
The preboot program and the hash must be trusted. So both may not come
unverified from the ISO or the add-on data. I.e. you need a pre-pre-boot

There is Secure Boot, trusted mainly by Microsoft Inc.
But even that idea is meanwhile pierced by praise-worthy anti-trust
requirements (i love the pun in this).
Microsoft hands out blank checks to Linux distros. The "shims" load
boot loaders trusted by the distros, but ... (cough) ... you have to
understand before you trust. And it must be bug-free.

Shao Miller wrote:
> My memory about multiple "write sessions" (or whatever
> they're called) is poor.
> https://www.pcmag.com/article2/0,2817,25430,00.asp

Multi-session: On sequential optical media mount by default the
first track of the most recent session. Typically this track contains
a complete directory tree with data files which have their content
stored in any of the existing sessions. I.e. each session updated the
previous one.

El Torito prescribes that the boot record from the most recent session
shall be used by firmware to find a boot image. To my own experiments
and user reports, BIOS does not obey. It always follows the boot record
at LBA 17 of the first session.

Multi-session works by hardware support with CD-R, CD-RW, DVD-R,
unformatted DVD-RW, DVD+R, DVD+R DL, unformatted or SRM formatted BD-R.
It does not work with DVD-R DL and fast blanked DVD-RW.

Since about 2003, growisofs extended the principle to non-sequential
media: DVD-RAM, DVD+RW, formatted DVD-RW, POW formatted BD-R, BD-RE,
for the case that each session contains an ISO 9660 filesystem.
This is done by overwriting the ISO 9660 superblock at LBA 0 after
a new session was appended. The new superblock points to the root
directory of the new session.
In principle this works with disk files and general block devices, too.
(But something is wrong in that aspect in growisofs.)

xorriso (actually its dynamic home libisoburn) enhances the growisofs
trick by keeping older sessions accessible and by doing multi-session
on data files and general block devices.
With some extra info from the user it does it into pipes, too.

But Bret wants the add-on data outside the ISO 9660 filesystem.

  xorriso -as mkisofs -o result.iso ...options... ...input.directories...

  cat add_on_info.img >> result.iso

or a xorriso run with -append_partition. 

Since the add-on is not pointed to by a filesystem, one needs other means
to learn add-on start and add-on size from the result.iso.
For the start i propose /sbin/isosize. The size must be recorded by other
means. And if its only an unambiguous End-Of-Archive mark in the byte

Have a nice day :)


More information about the Syslinux mailing list