Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I had a prototype boot sector that checked the integrity of the second stage loader using two simple methods: a signature test and 16-bit checksum (all "words" added and casted to an unsigned 16-bit integer). Because of size constraints, I thought I could not have a full CRC-32 check implemented in the boot sector. Everything will be much easier after passing the first stage because then there is enough room for all kind of fancy things.
Nevertheless, I started looking for algorithms that can be implemented even if we had the serious size constraint of a boot sector. Are there recommendations? I am not asking for code but some ideas.
Have you read anything about the Intel HEX format? It has a checksum: two's complement of the modulo 256 sum if I remember correctly. To check you just add the checksum to all of the bytes and you should end up with zero if it went well.
Edit: Found a link: http://www.8052.com/tutintel. From the example given there a check would give 0xe2+0x1e = 0x00 (byte arithmetic) so assuming we have N bytes, the checksum calculation is just series of N "add" instructions and a "neg", and the test for failure is a series of N+1 "add" instructions and a "jnz" instruction . Very minimal but only 1 byte of checksum.
Every universe of discourse has its logical structure --- S. K. Langer.
It is an interesting format but there are problems. It needs more storage space because it is a text file. It is not a big issue. The main problem is that I think it is too easy to edit because it is a text file. If we had a second stage loader stored as a text file in a file system, someone could edit it too easily. However, thank you for bringing this format up. It is very good to know and perhaps I find some other use for it.
The format wasn't really the point, it was the checksum; it's the simplest you can get with regards to space requirements in data and code. I'm suggesting it as something that may meet your specification.
Every universe of discourse has its logical structure --- S. K. Langer.
Your suggestion is correct but it is not something I was looking for. It does not differ much from what I already tried. Of course, it is probably sufficient.
Antti wrote:I thought I could not have a full CRC-32 check implemented in the boot sector.
This is not perfectly true. There is an instruction "CRC32" available if we are using some modern processors that support SSE4.2. Of course, I could not rely on that.
Do you want to make sure the 2nd stage has not been corrupted? (By bad disk access, bad sector, failed download, etc) Or that a user has not changed it?
I want to make sure the second stage loader is not corrupted. It is also good if a user can not change it easily. Of course, it is not cryptographically strong.
For protection from accidental damage, then a simple checksum will be enough
For protection from malicious tampering, you of course need hardware assistance. In these cases, you want a machine with a TPM. The TPM contains a number of "mixing pots" into which you "pour" bytes and out comes a cryptographic hash*. These pots can only be reset by rebooting the machine.
The BIOS will write the MBR into one of these pots before executing it. Your MBR should then write your VBR into one of them, and your VBR should write the next loader into them (and this should continue until you reach a stage which can be verified by other means - e.g. your kernel being required to pass a digital signature check)
On first boot after installation, you should read out the hash that the TPM has produced and save it somewhere that it can be validated.
*This hash is deterministic per TPM but implementation dependent. It is unlikely to be the same across multiple machines.
