Thanks for clarification on this. I read through - I guess - most of the documents of Purism about integrating heads. What got stuck in my head has been until you explained: Tamper detection - bios - firmware - /boot.
Either I didn’t read carefully enough or I had been misleaded to have the expectation of /boot being validated in a more complete way. Partly the reason probably is that I deleted temporary files in boot and had been warned by boot about my own tampering (removing files). This probably helped a lot to lead to the expectation that adding files would be detected also.
Well, don’t know - maybe someone else could give her/his opinion whether this should be more emphasized in the describing documents.
I thought also some more about a possible attack vector that could be a reason to change the behavior of heads and startet thinking along this track without having read into details or even code, yet:
Heads probably is somehow quiet condensend because its binary has to fit into a limited space. For that and any other possible reason the code to access the filesystem is probably not the same as in the kernel driver. Even if it is the same at any point of time the update of those codes for accessing the extX-filesystem is asynchronous and so the code base could drift apart.
If this is true it can be assumed that the checks and available feature for the extX filesystem differ or might differ at some time in future.
If so my actual attack vector would be trying to trick the kernel and heads to have a different view on the same binary data on the boot partition by - e.g. checking on the handling of inodes, sysmlinks, hardlinks, mishandling of unexpected data in the partition.
Don’t know if there is the slightest chance this could work, but - and this is my point - I don’t know neither whether it is impossible. Can somebody tell me without a lot of research that this approach is impossible?
If so: Good :), but I guess it is not that easy. If not: I’d again and still have the expectation that heads tampering detection would protect me against such an attack that is based on altering my unencrypted /boot.