Hot patching? [LWN.net]

Hot patching?

Posted May 29, 2026 16:10 UTC (Fri) by mfuzzey (subscriber, #57966)
Parent article: A loadable crypto module for FIPS certification

The module, once loaded, lives in the normal kernel memory space right?
So I guess that means it could, in theory, be "hot patched" by other kernel code meaning that the running code is not necessarily that certified?

Is this a problem or not?

Hot patching?

Posted May 29, 2026 17:00 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

Certification does not protect against attacks.
It just testifies that an implementation matches a specification to a certain (defined in the certification process/rules) degree.
It doesn't prevent anybody from changing the implementation.
You just loose the certification and all the rights that it gave you, if you change it.

Hot patching?

Posted Jun 1, 2026 10:20 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

If the goal is to validate that it matches the spec wouldn't it be much easier and faster to have some kind of automated test suite?

Hot patching?

Posted Jun 1, 2026 13:52 UTC (Mon) by acarno (subscriber, #123476) [Link]

Automated test suites are useful and arguably necessary - see the AES test vectors - but they aren't sufficient (by themselves) to prove validation. There are many anecdotes online of early compilers detecting when a particular benchmark (e.g., SPEC) was compiled and inserting hand-optimized assembly to improve the benchmark results. It doesn't take much to imagine someone writing a crypto library that detects and passes the automated test suite but fails to properly encrypt real data at run-time. For a real world example, see the Volkswagen emissions scandal.

Hot patching?

Posted Jun 1, 2026 9:57 UTC (Mon) by neverpanic (subscriber, #99747) [Link]

Typically, the security policy associated with such a certification says you can't use tools that would do that.

For example, the security policy for user space modules often says you can't LD_PRELOAD a process, can't attach a debugger or otherwise ptrace the certified code:

> Instrumentation tools like the `ptrace` system call, `gdb` and `strace`, userspace live patching, as well as other tracing mechanisms offered by the Linux environment such as `ftrace` or `systemtap`, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment.

As pointed out by other commenters, the certification assumes you are willingly complying. There are many ways to break things if you are actively hostile to the requirements.