[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