>The second relies on DBX not being updated, for which the remedy is "don't do that".
Not updating DBX is the default state. Updating it is what requires effort.
How many devices actually have up-to-date DBX? I know I mentioned LVFS in my first comment, but I have to wonder how many Linux devices with SB enabled actually use it. The ones that don't will not have updated their DBX since they were manufactured.
>The idea is that your main data partition is encrypted with a key held in a secure enclave [...]
You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.
If the boot partition isn't encrypted, doesn't this mean an attacker with physical access to the machine can remove the drive, plug it into their own machine, overwrite the boot partition, then restore the drive back in the original machine? In that scenario they don't have access to the unencrypted root filesystem.
You can set up 'measured boot' so the TPM will only 'unseal' the disk encryption password if you're running a certain version of your BIOS, a certain set of Machine Owner Keys, a certain version of shim, a certain kernel, a certain kernel command line and so on.
Very few normal users do this because it's a great deal of effort/risk for very modest security improvements. But the option is present - it's sometimes used by big corporations making TiVo-style products to lock out the owners from messing with the hard disk in the manner you've described.
> Not updating DBX is the default state. Updating it is what requires effort.
Up to a point, but that's true for almost everything in software. Not updating your OS etc. is the default state, and if it's not up to date it will be full of holes. That's life.
> You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.
If they have root on the live system then they don't need to mess around attacking secure boot at all. The point is "evil maid" style attacks where someone messes with the boot partition (and/or firmware) by booting off another device. Again, this is the whole point of Secure Boot; if you don't care about that kind of scenario then why would you ever be using secure boot at all?
Not updating DBX is the default state. Updating it is what requires effort.
How many devices actually have up-to-date DBX? I know I mentioned LVFS in my first comment, but I have to wonder how many Linux devices with SB enabled actually use it. The ones that don't will not have updated their DBX since they were manufactured.
>The idea is that your main data partition is encrypted with a key held in a secure enclave [...]
You're missing the point. An attacker that can write to the ESP is root on the live system right now. It can exfiltrate the contents of `/` right now. Or if it can't exfiltrate right now, it can install an OS service to do that on future boots.