But if the primary purpose of updating your kernel is security updates (which is the case for some people), shouldn't you be making the effort to do all that flashing? (honest question) I realize the attack surface would be much smaller since you'd be running a lot less services.
back
3 comments
Yes, there should be firmware updates for the kernel in flash. (And we haven't really figured out how to handle that yet.)
But such firmware updates likely have different constraints and a different schedule than your kernel-in-production updates. People will likely have much different requirements for the kernel in flash than for the kernel in production. It may be that for your use case and threat model, they'd be the same - but that's up to you to figure out and decide.
The LinuxBoot kernel is designed to check downstream signed kernel images before loading. So it won’t load anything that isn’t signed.
I suggest watching the original Heads talk to understand the context and goal better.
Maybe. That kernel is only running for a short time before it is replaced by the main OS kernel.
In a lot of scenarios it won't connect to the network and therefore will be difficult to exploit. If it does connect to the network (for network boot) then the security profile is different (how do you authenticate the image it downloads) but it probably won't be running many services of its own that could be exploited.
To exploit it locally it would have to run user supplied commands and binaries and hopefully it would be possible to make it difficult to inject these in an adhoc way.
The kernel that your main OS runs does so for a much longer time and with many more processes and services. The security vulnerabilities are exploitable when these different processes run and interact and when these processes are doing things in different security domains.
The scope of what the main OS is doing is much larger and much less pre-determined and therefore easier to exploit.
The LinuxBoot kernel establishes a hardware root of trust with the TPM and measures the ROM before bringing up any IO devices, so when it connects to the network it is able to perform a remote attestation as to its state. This way the hosting provider or customer can decide to not provision a node that has somehow been modified by a prior tenant.
For a network booting scenario the LinuxBoot server can use GPG to validate the signature on the kernel that it receives over the network. Additionally, secrets can be sealed in the TPM and only unlocked if the received kernel matches the expected one (and if the local firmware is unmodified).