I see there's a memtest on the Linux discs I've created... would it be possible to put another program in place (a module, perhaps?) that can calculate a hash using a certain algorithm (i.e. SHA512 or similar) to validate and print out the hash of the boot ISO before booting it? The integrity of the ISO is absolutely critical. Thanks, Bret
On 8/4/2017 12:44, Bret Schuhmacher via Syslinux wrote:> I see there's a memtest on the Linux discs I've created... would it be > possible to put another program in place (a module, perhaps?) that can > calculate a hash using a certain algorithm (i.e. SHA512 or similar) to > validate and print out the hash of the boot ISO before booting it? The > integrity of the ISO is absolutely critical.Do you mean that you'd type the expected hash in, during every boot? I ask because without typing it in manually, there's a chronological challenge in which a hash of the whole disc must then be stored on that same disc. You don't know the hash until the disc is produced, but you can't produce the [automated] disc without knowing the hash. Shao Miller Synthetel Corporation W: https://www.synthetel.com
On 8/4/2017 17:04, Bret Schuhmacher wrote:> This is kind of related to my other question about putting extra data > on the disc after the bootable ISO image... I want to write a bootable > ISO and include some extra stuff on it... the hash and some customer > data. The idea is that when the disc is booted from, this preboot > program calculates the hash of the ISO *only*, compares it to the > stored hash and lets the operator know the hash checked or failed. > This shouldn't be an issue with write once media, but it will go a > LONG way towards acceptance of what I'm doing. It'll make the > operator and the regulatory bodies feel warm and fuzzy that the stuff > on the disc is the ACTUAL stuff that's supposed to be on the disc and > no one has altered it in any way.I don't know how to incorporate additional data beyond the ISO, but perhaps someone else does. My memory about multiple "write sessions" (or whatever they're called) is poor. Google seemed to offer me this, but I'ven't gone through it, yet: https://www.pcmag.com/article2/0,2817,25430,00.asp Shao Miller Synthetel Corporation W: https://www.synthetel.com
Hi, 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 verifier. 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.aspMulti-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. Like: 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 stream. Have a nice day :) Thomas
> > Do you mean that you'd type the expected hash in, during every boot? I > ask because without typing it in manually, there's a chronological > challenge in which a hash of the whole disc must then be stored on that > same disc. You don't know the hash until the disc is produced, but you > can't produce the [automated] disc without knowing the hash. > > Shao MillerAgreed; the ISO9660 image cannot contain a yet-to-be-known hash value that would also pass the test later on. It can only be located "somewhere outside". (Slightly off-topic, BTW, and just FYI, some recovery/data integrity tools, such as dvdisaster, Parchive and the like, use some form of Reed?Solomon codes and can append the recovery info right after the original ISO9660 image. Of course, this is beyond the scope of the Syslinux mailing list.) But... Within the to-be-built ISO image, we can have a checksum file, listing filenames (that are located within the ISO9660 filesystem) and the corresponding hash values. (This is in addition to the checksum of the whole ISO image being published somewhere else.) Some Linux distributions use some kernel option in order to perform a test against such checksum file. In the boot menu, such option is listed as "Integrity check" or similar. (Kind of a shameless plug, but not really:) Better yet, some (Syslinux) developer could improve and clean up "hash.c32": www.syslinux.org/archives/2017-July/025850.html which is faster and better than depending on the kernel's file/options. For more than 5 years now, I've been waiting (and mildly pushing) for "hash.c32" to be improved and then to be included in official Syslinux archives, so my hopes are not high. Regards, Ady.