Images are a false simplification

Posted Nov 5, 2025 22:17 UTC (Wed) by ebee_matteo (subscriber, #165284)
In reply to: Images are a false simplification by bluca
Parent article: A security model for systemd

> It provides authenticity too, as the point being made was about signed dm-verity images. The signature is verified by the kernel keyring, so both authenticity and integrity are covered.

Yes, authenticity against a digital signature.

But trust has to start somewhere. You need to trust the signing keys, or somebody that transitively approved the key, e.g. as a CA.

In other words, you can prove an image was signed against a key, but if I manage to convince you to trust my public key, I can still run malicious software on your machine.

I still haven't seen the problem of supply-chain attacks being solved (by anybody, regardless of the technology employed).

Images are a false simplification

Posted Nov 5, 2025 22:23 UTC (Wed) by bluca (subscriber, #118303) [Link] (3 responses)

> But trust has to start somewhere.

Yes, and this is a solved problem on x86-64: you trust the vendor who sold you your CPU. You have to anyway, since it's your CPU, and it's silly to pretend otherwise.
That CPU verifies the firmware signature, which verifies the bootloader signature, which verifies the UKI signature, which verifies the dm-verity signature.

Images are a false simplification

Posted Nov 6, 2025 1:32 UTC (Thu) by Nahor (subscriber, #51583) [Link] (2 responses)

> this is a solved problem on x86-64

Not really. It's more like it is an unsolvable problem (or at least impractical to do so) so we choose to stop there.

> you trust the vendor who sold you your CPU

Plenty of people will argue you can't ("blabla manufacturing blabla China blabla" and "blabla NSA blabla backdoor blabla")

Images are a false simplification

Posted Nov 6, 2025 2:46 UTC (Thu) by intelfx (subscriber, #130118) [Link] (1 responses)

> Plenty of people will argue you can't ("blabla manufacturing blabla China blabla" and "blabla NSA blabla backdoor blabla")

That's the point of the GP, which I believe you have missed.

If you don't trust your CPU vendor enough to believe that their root of trust implementation is not subverted by your malicious actor of choice, then why would you trust *anything* that comes out of that CPU against the same malicious actor? The only logical choice of action would be to throw the CPU away immediately.

And if you haven't done that, then it necessarily follows that you *do* trust the CPU vendor, so it's fine if they implement a root of trust too.

Images are a false simplification

Posted Nov 6, 2025 10:29 UTC (Thu) by excors (subscriber, #95769) [Link]

I think there are subtly different definitions of "trust". In normal English it means "I believe this person won't harm me", but in a computer security context it often means "I am allowing this person to harm me". Under the first definition, it's best if you can correctly trust as many people as possible. Under the second, it's best to trust as few as possible.

Ideally the people you trust under the second definition are also trusted under the first definition, but in practice you can rarely have that level of belief in anyone, so you're knowingly opening yourself up to some risk of harm.

You can't prevent your CPU vendor harming you, so you do trust them under the second definition. The best you can do is minimise risk by ensuring they're the only people who can harm you.