[libc-commits] [libc] [libc] add option for hardened freelist (PR #205382)

Daniel Thornburgh via libc-commits libc-commits at lists.llvm.org
Wed Jul 1 12:04:43 PDT 2026


================
@@ -15,9 +15,86 @@
 #define LLVM_LIBC_SRC___SUPPORT_FREELIST_H
 
 #include "block.h"
+#include "hdr/stdint_proxy.h"
+#include "src/__support/CPP/bit.h"
+#include "src/__support/libc_assert.h"
+#include "src/__support/macros/config.h"
+
+#ifndef LIBC_COPT_HARDEN_FREELIST
+#define LIBC_COPT_HARDEN_FREELIST false
+#endif
+
+#if LIBC_COPT_HARDEN_FREELIST
+#define LIBC_HARDENING_ASSERT(cond)                                            \
+  do {                                                                         \
+    if (LIBC_UNLIKELY(!(cond))) {                                              \
+      __builtin_trap();                                                        \
+    }                                                                          \
+  } while (0)
+#else
+#define LIBC_HARDENING_ASSERT(cond) LIBC_ASSERT(cond)
+#endif
 
 namespace LIBC_NAMESPACE_DECL {
 
+struct FreeListSecrets {
----------------
mysterymath wrote:

Since this introduces the notion of a secret, a value that an attacker cannot obtain, this should also really have a header comment that describes what mechanisms actually prevent the attacker from obtaining the secret, given that it is resident in RAM in the target machine.

Viewed another way, we'd need a threat model for an attacker, such that they intrinsically cannot access the secret (which is what makes it a secret ;) ). This will either provide documentation for these guarantees to keep us from accidentally violating them, or if that threat model isn't realistic, it might point us towards a simpler implementation.  

https://github.com/llvm/llvm-project/pull/205382


More information about the libc-commits mailing list