The trick is putting all important data in the encrypted part. The unencrypted part must be reconstructable in an automated manner. If you are paranoid and you assume that all unplanned reboots are attacks, then you can reconstruct the unencrypted part every time. Tools like Chef make this relatively easy.
The kernel lives on /boot, and could be subverted to lie about its uptime to convince you that there was no unplanned reboot.
This is the same methodology I use, and I think about these attacks a lot. There is no good/cheap way to verify a remote execution environment right now with commodity hardware. :/
That's not possible. Even if you fool the kernel, you still can't mount the encrypted disk. The fact that the encrypted disk is not mounted is proof that there has been an unplanned reboot.
I don't know. Ever since we set up encrypted disks we haven't had an unplanned reboot. I was simply pointing out that this is a possibility that we've considered.