IRC channel logs

<stikonas>kerravon: I don't think you can read cdrom with optical microscope

<stikonas>or at the very least it will be at the very edge of what you can read with it

<stikonas>you basically need to have cdrom reading hardware or something like that

<stikonas>cdrom scale is quite close wavelength of the light (by design)

<stikonas>well, I guess cdrom itself is close infrared

<mihi>and btw kerravon putting lots of ones or zeroes will not result in arbitrary length pits/lands. EFM will ensure that every pit or land is from 2 to 10 units long. <https://en.wikipedia.org/wiki/Eight-to-fourteen_modulation#How_it_works>

<stikonas>ok, so pit is 500 nm wide

<stikonas>ok, so maybe you can see it on the best commercial microscopes

<stikonas>those can do up to 200 nm

<kerravon>any idea how much that costs?

<stikonas>no idea...

<oriansj>kerravon: well a Nikon Ti microscope can do down to 200nm and costs about $35K used.

<oriansj>Buy new appearently requires contacting sales for a quote

<kerravon>crikey

<oriansj>but if what mihi expressed is correct, you would be needing to measure and then decode the length to the byte value

<oriansj>as for your proposed bootsector program; I don't think MD5 will fit

<kerravon>it can be boot sectors, as required

<kerravon>and it wouldn't really be boot sectors

<kerravon>if md5 is required, it would be a sector c program

<oriansj>in that case sha256sum would definitely be a valid option and we have a C version which https://github.com/oriansj/mescc-tools-extra/blob/master/sha256sum.c easily translates to assembly

<kerravon>ok, and i'm more not even expecting that. i'm expecting sector c to compile a better c program in a series of stepping stones. compiling to memory and verifying that the executable code in memory is the same as the pre-compiled version sitting on the cdrom

<muurkha>I think you can get microscopes that reach the optical resolution limit (with oil immersion objectives) pretty cheaply

<muurkha>like under US$1000

<kerravon>yeah, this website:

<kerravon> https://www.labx.com/microscope

<kerravon>says that optical microscopes go up to $5000

<kerravon>not $35k

<kerravon>which is way less than the price of a new car, which most people are happy to spend money on

<kerravon>it depends on your priorities

<kerravon>and as you say, the price may be under $1000

<muurkha>CD-ROM encoding is kind of a pain to verify manually because of all the levels of error correction coding

<muurkha>I think that the difference between a US$5000 optical microscope and a US$1000 microscope isn't the resolution

<muurkha>I think it's things like the perfection of the achromacy, the quality of the mechanical parts, and maybe digital readouts

<muurkha>but I don't really know what I'm talking about

<muurkha>but basically the issue is that the wavelength of light is only like 100 times smaller than things you can see with the naked eye, like a human hair or a paramecium

<muurkha>*visible light

<muurkha>so people have reaching it for a long time

<oriansj>kerravon: I just looked up microscopes with 200nm resolution; picked the first result and then looked up purchasing cost on ebay and direct purchase costs for new

<oriansj>I am in no way an expert on optimal pricing on microscopes nor which would be optimal if one wanted to affordably attempt your CD validation strategy

<oriansj>but I was including the firmware of the CD reader into the problem scope of trusted firmware

<oriansj>in contrast a paper tape reader can be implemented entirely in hardware

<muurkha>can you reach 200nm resolution with visible light?

<muurkha>naively 700 megabytes per 5¼" diameter circle is about 4 square microns per bit

<oriansj>well about 380 to about 750 nanometers is the visible light spectrum; so I am guessing the 200nm resolution microscopes do a good bit more than glass to enable to see that level of resolution

<muurkha>so that seems like about an order of magnitude better (linear) resolution than you need for reading a CD, though that doesn't take ECC into account

<muurkha>oh, apparently it's actually 120mm (4.7 "inches")

<muurkha>so it's 2 square microns per bit, not 4

<oriansj>well the pits are 100nm deep, 500nm wide and 850 nm to 3.5 µm in length according to wikipedia

<muurkha>yes, I was just reading that

<muurkha>and 1.6 μm per track standardly

<muurkha>mihi said "from 2 to 10 units", so I guess a unit is like 400 nm?

<oriansj>so assuming 1 pixel is what is seen at 200nm resolution; 2-3 pixels wide and 4-15pixels long is what you would be looking at

<muurkha>so you need 400 nm resolution

<muurkha>more or less

<oriansj>as a rough ballpark

<muurkha>I mean you can probably get by with 1.6 micron resolution really

<muurkha>well, no. you need to be able to tell different pits apart, so you need 850 nm

<muurkha>but the difference is enormous between an optical microscope with 850 nm resolution and whatever kind of microscope you need to see 400 nm

<oriansj>assuming you can work with single pixels and be able to gauge length well enough to know the different byte values

<muurkha>you have a lot of ECC helping you there

<muurkha> https://en.wikipedia.org/wiki/Oil_immersion says δ, the minimum resolvable distance, is λ/2NA, and that with cedar tree oil you can get NA up to 1.5

<muurkha>and that the best non-oil-immersion objectives have NA ≈ 0.95

<muurkha>with visible yellow light you have λ = 555nm, so you have about 290nm resolution with yellow light and air

<muurkha>if you push it with modern immersion oils that can get NA up to 1.6, and 300nm UV light, you should be able to get down to 95nm resolution

<muurkha>but 850 nm is probably adequate

<muurkha>even with much worse resolution you ought to be able to decode due to the ECC if you're using a computer

<oriansj>muurkha: no, we were discussing manual inspection for manual verification; so no computer

<oriansj>if we were using a computer, we would just use a laser and a proper optical sensor and let the CD drive's firmware handle everything

<muurkha>calculating millions of Reed-Solomon codes by hand is going to be an unreasonable amount of work

<oriansj>muurkha: well the ask was just the boot sector

<muurkha>don't you need to verify the source code you're compiling with that boot sector too? or is the boot sector enough for that?

<kerravon>the intention is that the boot sector is (so far) the only thing executed. as such, it can be a simple hex displayer - displaying sectors on the disk image. before you execute the next sector

<kerravon>so the microscope is no longer needed

<kerravon>that reasoning is sound, isn't it?

<kerravon>either way you need to trust the cdrom firmware

<oriansj>kerravon: if you are already trusting the cdrom firmware, you wouldn't need to manually verify anything as putting something like BootOS in the bootsector is entirely possible

<kerravon>oriansj - i don't trust the system that created the cdrom

<kerravon>so i will be verifying every byte on it

<kerravon>first by microscope, then by hex display

<kerravon>as it boots

<kerravon>and then i will have a trustworthy cdrom

<kerravon>the boot sector is manually inspected via microscope to get the hex

<kerravon>that is a sector display utility

<kerravon>so i can inspect the next bit of hex, which will probably be sector c

<kerravon>plus a c source file on a different sector(s)

<kerravon>then i will execute sector c and have it check that the binary (already on the cd) matches what it just built into memory

<kerravon>then i can execute that - whatever it is

<muurkha>kerravon: yes, I agree that that reasoning is sound

<muurkha>I think it will be hard to verify, though, that the boot sector on the CD-ROM is what got loaded into RAM and is executing

<kerravon>but that's down to firmware. if you don't trust your cdrom firmware, you can never use a cdrom for executables - even if you burn them from a trusted system. even a trusted system that was built with hand-verified paper tape

<kerravon>is that the plan? not be able to use cdroms?

<muurkha>I see, so the CD-ROM firmware is part of the TCB, along with things like the CPU microcode

<muurkha>but the boot sector itself isn't, because it comes from a potentially compromised CD writer

<muurkha>?

<kerravon>exactly

<kerravon>the entire cdrom was built on an untested/untrusted system

<kerravon>but it's just being silly to think there is really something wrong with the system

<kerravon>so you do all your work on a normal linux system or whatever

<kerravon>go and get your cdroms pressed

<kerravon>and then the final check of the cdrom to see if your faith in humanity was justified or not

<kerravon>and it almost certainly is

<kerravon>if it isn't, you need to demolish the original linux system, and you've blown all your money on cdrom pressing too

<kerravon>but others can use your cdrom and go through the same process to get a trusted system

<kerravon>in case the cdrom presser was dodgy and inserted 5% bad cdroms

<muurkha>heh

<muurkha>seems reasonable

<kerravon>ok, cool!

<kerravon>and no problem with the idea that you press shift or whatever for the boot sector to start the hex dump facility instead of booting normally?

<kerravon>and actually, even if the cdroms are 5% dodgy, you can test that yourself by using your trusted system to check that the cdroms are identical, before you give them to anyone else. and those people are always free to go through the same near-automated process of verification

<kerravon>so the next question would be - what would the first "sector c" program be? a basic file viewer so that you can inspect the next, more sophisticated, sector c program?

<kerravon>and i don't think we've confirmed a price for the microscope yet

<muurkha>interesting questions

<kerravon>i saw this:

<kerravon> https://superuser.com/questions/870776/being-able-to-see-the-tracks-and-bits-in-a-cd-rom

<kerravon>which says you need a 1000x microscope

<kerravon>and i saw this:

<kerravon> https://www.microscope.com/omano-om139-infinity-corrected-plan-optics.html

<kerravon>which is a 1000x microscope for $699

<kerravon>and it says:

<kerravon>you can observe samples and specimens as small as 0.180mm, or 180 microns, across. Now that’s small!

<kerravon>is 180 microns really small though?

<kerravon>i thought the figures from before were in nano

<kerravon>3.5 um is as big as it gets from previous figures

<kerravon>let me check what a micron is

<kerravon>yep, 1 um

<kerravon>so 180 um is ridiculously large for what i need

<kerravon> https://www.amazon.com/AmScope-M150C-I-40X-1000X-Biological-Microscope/dp/B00AM5XB5O/ref=sr_1_3?keywords=1000x%2Bmicroscope&qid=1687319138&sr=8-3&th=1

<kerravon>and here's one for $84

<kerravon>this picture:

<kerravon> http://www.pmonta.com/compact-disc-microscopy.html

<kerravon>seems to have been taken with a lens that costs around 300 euro:

<kerravon> https://www.photomacrography.net/forum/viewtopic.php?t=42156

<kerravon>and it looks to me like this is for a camera, not a microscope

<oriansj>kerravon: the reason why i said there is no point manually inspecting the CD directly if you trust the CD firmware is you can load a reader program from an alternate source (such as hand toggling in the program or a trusted ROM, etc) and use that to validate everything on the disc. Only if you didn't trust the reader would you want to inspect the CD to determine if the altered data was from the burning system or from the firmware

<oriansj>reading the disc

<muurkha>oriansj: that makes sense; I guess you're suggesting that hand-building a trusted 512-byte ROM is easier than manually validating 512 bytes from the CD? That seems likely to be correct

<muurkha>kerravon: you can observe things that are 180μm across with your naked eye; you don't need a 1000× microscope for that

<muurkha>I think 600× is probably good enough

<mihi>Speaking of booting an x86 machine from custom ROM, the easiest way is probably get a 3COM network interface card that has an EEPROM socket for an option ROM (e.g. 3c905b), an EEPROM that fits in there, Ben Eater's breadboard based EEPROM programmer/verifier, and a mainboard that can boot from external option ROMs (everything that predates UEFI, comes with an AWARD/AMI BIOS and does not have an

<mihi>onboard NIC should be probably working)

<mihi>for an example how an option ROM has to look like, look at gPXE, iPXE, etc., which can be compiled to Option ROM.

<muurkha>mihi: hmm, I forget if the 3C905B is ISA or PCI

<muurkha>but presumably not PCIe

<mihi>I know it as a PCI card, I'm unsure whether an ISA version may also be available.

<muurkha>I think maybe it's the PCI version of the 3C509|

<muurkha>?

IRC channel logs

2023-06-21.log