System time

Posted Jul 16, 2025 19:14 UTC (Wed) by tux3 (subscriber, #101245)
Parent article: Linux and Secure Boot certificate expiration

I have (not so) fond memories of old BIOS systems where removing the battery would reset both the settings and clock.

I'm not sure if this is still a thing. Does Secure Boot prevent an attacker from turning the clock back; is there maybe some internal clock that cannot be tampered with? Can one not boot a system the firmware accepts today, reset this firmware clock, and then merrily go on to boot payloads signed with the expired key?

Some embedded systems burn fuses to prevent firmware rollbacks, but that's based on version numbers of a fixed boot chain, instead of certificates that might sign arbitrary payloads. I can't see how this sort of hard anti-rollback would work for secure boot, but I'm not sure how much certificate expiration is worth if you don't have a trusted clock.

System time

Posted Jul 17, 2025 0:02 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> I'm not sure how much certificate expiration is worth if you don't have a trusted clock.

The firmware could have a "build date" baked into the signed part of its firmware and do `max(curtime, fwtime)` upon initialization instead of blindly trusting the hardware clock.

System time

Posted Jul 17, 2025 8:02 UTC (Thu) by taladar (subscriber, #68407) [Link]

That would only work if you issue two firmware updates, one for legitimate users before the old key expires to avoid a window where neither key works and one issued after that uses the trick you describe to prevent setting the clock back to the time when the old key was still valid.

System time

Posted Jul 17, 2025 8:32 UTC (Thu) by aaribaud (subscriber, #87304) [Link] (6 responses)

> I have (not so) fond memories of old BIOS systems where removing the battery would reset
> both the settings and clock.
>
> I'm not sure if this is still a thing.</em>

It is not.

For decades now, the BIOS settings are not stored in volatile memory but in the BIOS Flash chip, where they survive as long as they are not reset through a BIOS menu command -- and if that BIOS has a master password set and you don't know it, then you can't enter the BIOS menu, and the only way out is either physically reprogramming the flash chip with a "blank" BIOS, or buying a new motherboard (ask me how I know. Better yet, don't ask).

Plus, about a decade ago, at least one BIOS provider, AMI, provided support for protecting the master password with the TPM, which--if applied by the BIOS vendor--basically removes the "physically reprogramming the flash chip" option.

System time

Posted Jul 18, 2025 0:35 UTC (Fri) by marcH (subscriber, #57642) [Link] (5 responses)

I recently lost all video outputs after trying some "unusual" BIOS settings (lesson learned...)

I realize it's different from a master password lockdown, but I found in the manual a way to reset settings with a jumper (no jumper actually needed, any small piece of metal worked). It worked!

System time

Posted Jul 18, 2025 21:03 UTC (Fri) by Lwnkhz (guest, #178382) [Link] (4 responses)

Not possible on TPM protected systems

System time

Posted Jul 18, 2025 21:18 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (3 responses)

The TPM has nothing whatsoever to do with firmware settings or whether they can be reset.

System time

Posted Jul 18, 2025 22:06 UTC (Fri) by aaribaud (subscriber, #87304) [Link] (2 responses)

> The TPM has nothing whatsoever to do with firmware settings or whether they can be reset.

This rather depends on the context, notably whether and how the BIOS is TPM-protected.

System time

Posted Jul 18, 2025 22:54 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (1 responses)

No, it doesn't. There's no such thing as a TPM-protected BIOS and even if there were that would have nothing to do with the firmware variables which are inherently mutable.

System time

Posted Jul 19, 2025 4:48 UTC (Sat) by aaribaud (subscriber, #87304) [Link]

> No, it doesn't. There's no such thing as a TPM-protected BIOS and even if there were that would have nothing to do with the firmware variables which are inherently mutable.

There appears to be such thing as a TPM-protected BIOS: https://trustedcomputinggroup.org/american-megatrends-sup...

And if there is such a BIOS, then when the master password is set, many settings become immutable.