[libc++][hardening] Introduce a dylib function to log hardening errors. #148266

var-const · 2025-07-11T17:51:00Z

Unlike verbose_abort, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
observe semantic for Hardening.

Unlike `verbose_abort`, this function merely logs the error but does not terminate execution. It is intended to make it possible to implement the `observe` semantic for Hardening.

llvmbot · 2025-07-11T17:51:42Z

@llvm/pr-subscribers-libcxx

Author: Konstantin Varlamov (var-const)

Changes

Unlike verbose_abort, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
observe semantic for Hardening.

Full diff: https://github.com/llvm/llvm-project/pull/148266.diff

5 Files Affected:

(modified) libcxx/include/CMakeLists.txt (+1)
(modified) libcxx/include/__configuration/availability.h (+5)
(added) libcxx/include/__log_hardening_failure (+45)
(modified) libcxx/src/CMakeLists.txt (+1)
(added) libcxx/src/log_hardening_failure.cpp (+49)

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index c8e6d28584623..2f8be540e73e2 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -535,6 +535,7 @@ set(files
   __locale_dir/time.h
   __locale_dir/wbuffer_convert.h
   __locale_dir/wstring_convert.h
+  __log_hardening_failure
   __math/abs.h
   __math/copysign.h
   __math/error_functions.h
diff --git a/libcxx/include/__configuration/availability.h b/libcxx/include/__configuration/availability.h
index ae58e36b508b4..cb72e927caa9c 100644
--- a/libcxx/include/__configuration/availability.h
+++ b/libcxx/include/__configuration/availability.h
@@ -304,6 +304,11 @@
 #define _LIBCPP_AVAILABILITY_HAS_VERBOSE_ABORT _LIBCPP_INTRODUCED_IN_LLVM_15
 #define _LIBCPP_AVAILABILITY_VERBOSE_ABORT _LIBCPP_INTRODUCED_IN_LLVM_15_ATTRIBUTE
 
+// This controls whether the library provides a function to log hardening failures without terminating the program (for
+// the `observe` assertion semantic).
+#define _LIBCPP_AVAILABILITY_HAS_LOG_HARDENING_FAILURE _LIBCPP_INTRODUCED_IN_LLVM_21
+#define _LIBCPP_AVAILABILITY_LOG_HARDENING_FAILURE _LIBCPP_INTRODUCED_IN_LLVM_21_ATTRIBUTE
+
 // This controls the availability of the C++17 std::pmr library,
 // which is implemented in large part in the built library.
 //
diff --git a/libcxx/include/__log_hardening_failure b/libcxx/include/__log_hardening_failure
new file mode 100644
index 0000000000000..73cff0ac64155
--- /dev/null
+++ b/libcxx/include/__log_hardening_failure
@@ -0,0 +1,45 @@
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___LOG_HARDENING_FAILURE
+#define _LIBCPP___LOG_HARDENING_FAILURE
+
+#include <__config>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+// This function should never be called directly from the code -- it should only be called through the
+// `_LIBCPP_LOG_HARDENING_FAILURE` macro.
+_LIBCPP_AVAILABILITY_LOG_HARDENING_FAILURE _LIBCPP_OVERRIDABLE_FUNC_VIS void
+__libcpp_log_hardening_failure(const char* message) _NOEXCEPT;
+
+// _LIBCPP_LOG_HARDENING_FAILURE(message)
+//
+// This macro is used to log a hardening failure without terminating the program (as is the case if the `observe`
+// assertion semantic is used). Where possible, it logs in a way that indicates a fatal error (which might include
+// capturing the stack trace).
+#if !defined(_LIBCPP_LOG_HARDENING_FAILURE)
+
+#  if !_LIBCPP_AVAILABILITY_HAS_LOG_HARDENING_FAILURE
+// The decltype is there to suppress -Wunused warnings in this configuration.
+void __use(const char*);
+#    define _LIBCPP_LOG_HARDENING_FAILURE(message) (decltype(::std::__use(message))())
+#  else
+#    define _LIBCPP_LOG_HARDENING_FAILURE(message) ::std::__libcpp_log_hardening_failure(message)
+#  endif
+
+#endif // !defined(_LIBCPP_LOG_HARDENING_FAILURE)
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP___LOG_HARDENING_FAILURE
diff --git a/libcxx/src/CMakeLists.txt b/libcxx/src/CMakeLists.txt
index 97fe57a5f24f8..926deb3a1c732 100644
--- a/libcxx/src/CMakeLists.txt
+++ b/libcxx/src/CMakeLists.txt
@@ -30,6 +30,7 @@ set(LIBCXX_SOURCES
   include/ryu/ryu.h
   include/to_chars_floating_point.h
   include/from_chars_floating_point.h
+  log_hardening_failure.cpp
   memory.cpp
   memory_resource.cpp
   new_handler.cpp
diff --git a/libcxx/src/log_hardening_failure.cpp b/libcxx/src/log_hardening_failure.cpp
new file mode 100644
index 0000000000000..7e408a6f010b4
--- /dev/null
+++ b/libcxx/src/log_hardening_failure.cpp
@@ -0,0 +1,49 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include <__config>
+#include <__log_hardening_failure>
+#include <cstdio>
+
+#ifdef __BIONIC__
+#  include <syslog.h>
+extern "C" void android_set_abort_message(const char* msg);
+#endif // __BIONIC__
+
+#if defined(__APPLE__) && __has_include(<os/reason_private.h>)
+#  include <os/reason_private.h>
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+_LIBCPP_WEAK void __libcpp_log_hardening_failure(const char* message) noexcept {
+  // On Apple platforms, use the `os_fault_with_payload` OS function that simulates a crash.
+#if defined(__APPLE__) && __has_include(<os/reason_private.h>)
+  os_fault_with_payload(
+      /*reason_namespace=*/OS_REASON_SECURITY,
+      /*reason_code=*/0,
+      /*payload=*/nullptr,
+      /*payload_size=*/0,
+      /*reason_string=*/message,
+      /*reason_flags=*/0);
+
+#elif defined(__BIONIC__)
+  // Show error in tombstone.
+  android_set_abort_message(message);
+
+  // Show error in logcat.
+  openlog("libc++", 0, 0);
+  syslog(LOG_CRIT, "%s", message);
+  closelog();
+
+#else
+  fprintf(stderr, "%s", message);
+#endif
+}
+
+_LIBCPP_END_NAMESPACE_STD

libcxx/include/__log_hardening_failure

libcxx/src/log_hardening_failure.cpp

libcxx/include/__log_hardening_failure

var-const · 2025-07-12T22:06:12Z

libcxx/src/log_error.cpp

+void __log_error(_LogErrorReason reason, const char* message) noexcept {
+  switch (reason) {
+  case _LogErrorReason::_HardeningFailure:
+  default:


@ldionne We need to make sure the default is reasonable and backward-compatible (IIUC, we will have the situation where the enum is newer than the dylib and the dylib has to handle a value it doesn't understand).

succeed).

philnik777 · 2025-07-13T18:50:28Z

libcxx/include/CMakeLists.txt

@@ -535,6 +535,7 @@ set(files
  __locale_dir/time.h
  __locale_dir/wbuffer_convert.h
  __locale_dir/wstring_convert.h
+  __log_error


Could we move all these functions into a single header like __hardening_utils?

If we keep the current approach where the logging function is more generic and not exclusively for hardening, then IMO it shouldn't be in __hardening_utils; although perhaps something more generic like __error_handling_utils might make sense -- WDYT?

Sounds good to me as well. The main thing I'd like to avoid is having a bunch of tiny headers for very closely related utilities.

FWIW, Costa and I discussed this previously and we were thinking to reorganize the top-level headers like __verbose_abort, __assert & friends in a follow-up patch where we'll have an overall view.

Will do in an immediate follow-up patch.

libcxx/include/__log_error

philnik777 · 2025-07-13T18:54:15Z

libcxx/include/__log_error

+// This function should never be called directly from the code -- it should only be called through the
+// `_LIBCPP_LOG_ERROR` macro.
+_LIBCPP_AVAILABILITY_LOG_ERROR _LIBCPP_EXPORTED_FROM_ABI void
+__log_error(_LogErrorReason __reason, const char* __message) _NOEXCEPT;


Should we pass a string_view instead? Most of the time we probably have a string literal, and passing a string_view would avoid calling strlen all the time.

I'm a bit wary of doing it from a layering perspective. This is a low-level function used by hardening, and having its implementation use hardened classes that might theoretically try to call it again seems a bit off. While we could make sure that we don't use any parts of string_view that are hardened, I'd still prefer the logging function to operate on a level "below" hardening, so to speak.

Fair enough. What do you think about having a small wrapper in the headers that just calls __builtin_strlen and passes the char* and lenght to a dylib function?

This header is going to be included from almost all other headers, like __assert. So we really can't depend on the definition of string_view. We could define our own simple string_view type but I wonder if it's worth it. Is that what you had in mind (I mean, defining our own string_view approximation)?

Also, I think it is quite useful to assume that the message we're logging is null terminated, since we then call APIs that also make that assumption in the implementation of the logging function.

If we take a (possibly non-null-terminated) char const* and a length instead, we'd have to basically copy that string into a null terminated buffer (allocated on the fly?) before we can pass it to e.g. fputs. That seems like a lot of additional work/complexity for relatively little actual benefit. WDYT?

I think it would be enough to have

void __log_hardening_failure(const char*, size_t); void __log_hardening_failure(const char* __str) { __log_hardening_failure(__str, __builtin_strlen(__str)); }

Re. null termination, we could also use fwrite to give size information to the libc. I'm actually a bit confused. __log_hardening_failue shouldn't terminate, right? The platform-specific APIs do look like they're terminating though. Or am I mis-reading this?

__log_hardening_failue shouldn't terminate, right?

Yes, it's a regular, non-terminating, function.

The platform-specific APIs do look like they're terminating though. Or am I mis-reading this?

They do not terminate. On Apple platforms, os_fault_with_payload produces crash data as if a crash occurred but doesn't actually crash the program. On Android, I don't think logging with syslog ever terminates regardless of the severity level, and android_set_abort_message, to the best of my knowledge, merely copies the error message to some global location.

Re. null termination, we could also use fwrite to give size information to the libc.

The most important part of this function is calling a system-specific API(s); all the ones we are currently using expect a null-terminated string, and since these syscalls tend to follow historical C conventions, we can expect any new APIs we might add in the future to also accept C strings, more likely than not. At most, we can prevent one call to strlen that would otherwise happen in fputs, at the cost of complicating the interface and increasing the size of the dylib. We would also end up with a function with a weird interface because normally accepting a (string, len) pair implies that the string is not null-terminated, at least not guaranteed to be so. We can document this quirk but it's still suboptimal.

Moreover, I simply don't think this function needs this level of microoptimization. The call to strlen over the relatively short strings that we're using is unlikely to be significant compared to the several syscalls that this function is making, and taking a step back, I don't see this function as performance-critical. In a well-defined program, it should never be invoked at all; while of course bugs happen (otherwise this function would not be necessary), I think it's reasonable to expect it to only be called rarely, and if it happens to be called in a tight loop (e.g. if there's a repeated OOB access in a loop), the right thing to do is fix the OOB access, not optimize the function (and once again, given all the logging we're doing, I strongly doubt skipping a call to strlen would make any worthwhile difference in this case).

@philnik777 Let's continue this conversation in #149452

libcxx/src/log_error.cpp

ldionne · 2025-07-14T13:59:53Z

libcxx/include/CMakeLists.txt

@@ -535,6 +535,7 @@ set(files
  __locale_dir/time.h
  __locale_dir/wbuffer_convert.h
  __locale_dir/wstring_convert.h
+  __log_error


FWIW, Costa and I discussed this previously and we were thinking to reorganize the top-level headers like __verbose_abort, __assert & friends in a follow-up patch where we'll have an overall view.

libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist

libcxx/utils/libcxx/test/features.py

libcxx/include/__log_error

libcxx/src/log_error.cpp

ldionne

Based on additional discussion with @var-const just now, we are leaning towards going back to the simplest and single-purpose API (which was originally proposed). We are not confident that the current enum-based function would solve future problems, and if that ends up not being the case, we'll be stuck with a weird looking API stuck in the ABI forever. Instead, we'd rather add just a simple function with a specific purpose and which is solving the exact problem we're facing right now.

libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist

ldionne

LGTM w/ green CI

philnik777 · 2025-07-15T06:40:43Z

Can we please wait until after the release branch? I didn't even have time to take another look, and given that the release branch is literally today IMO this is way too hasty.

…ng errors." (#148787) Reverts #148266 I'm reverting this temporarily, since the release branch is today and this is ABI sensitive. Let's wait until after the branch so that we have plenty time to discuss the patch.

Reverts #148268 It looks like this was based on #148266, which I reverted in #148787.

…log hardening errors." (#148787) Reverts llvm/llvm-project#148266 I'm reverting this temporarily, since the release branch is today and this is ABI sensitive. Let's wait until after the branch so that we have plenty time to discuss the patch.

[libc++][hardening] Introduce a dylib function to log hardening errors.

1fcfec3

Unlike `verbose_abort`, this function merely logs the error but does not terminate execution. It is intended to make it possible to implement the `observe` semantic for Hardening.

var-const requested a review from a team as a code owner July 11, 2025 17:51

llvmbot added the libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. label Jul 11, 2025

var-const added hardening Issues related to the hardening effort and removed libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. labels Jul 11, 2025

ldionne added the libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. label Jul 11, 2025

ldionne requested changes Jul 11, 2025

View reviewed changes

libcxx/include/__log_hardening_failure Outdated Show resolved Hide resolved

libcxx/src/log_hardening_failure.cpp Outdated Show resolved Hide resolved

libcxx/include/__log_hardening_failure Show resolved Hide resolved

libcxx/include/__log_hardening_failure Outdated Show resolved Hide resolved

var-const added 2 commits July 12, 2025 01:58

Address feedback

ef34ade

Update the ABI list plus minor tweaks.

01eb85d

var-const commented Jul 12, 2025

View reviewed changes

var-const added 6 commits July 12, 2025 19:31

Regenerate the symbol list for Linux.

cfbf82e

Always log to stderr before making any system calls (which might not

1e38d40

succeed).

More symbol list updates.

78ff152

More symbol list updates.

0da96f3

More symbol list updates.

c930bbf

Even more updates to the symbol list.

03da891

philnik777 reviewed Jul 13, 2025

View reviewed changes

var-const added 2 commits July 13, 2025 14:59

Address feedback

2882400

Don't call os_fault if running on a simulator.

9c29b62

ldionne requested changes Jul 14, 2025

View reviewed changes

ldionne reviewed Jul 14, 2025

View reviewed changes

libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.nonew.abilist Outdated Show resolved Hide resolved

Address feedback

9589441

ldionne approved these changes Jul 14, 2025

View reviewed changes

Fix the CI

a98b05a

var-const merged commit 49d2b5f into llvm:main Jul 15, 2025
77 checks passed

philnik777 mentioned this pull request Jul 15, 2025

Revert "[libc++][hardening] Introduce a dylib function to log hardening errors." #148787

Merged

philnik777 mentioned this pull request Jul 15, 2025

Revert "[libc++][hardening] Introduce assertion semantics" #148822

Merged

philnik777 added a commit that referenced this pull request Jul 15, 2025

Revert "[libc++][hardening] Introduce assertion semantics" (#148822)

339a1f2

Reverts #148268 It looks like this was based on #148266, which I reverted in #148787.

[libc++][hardening] Introduce a dylib function to log hardening errors. #148266

[libc++][hardening] Introduce a dylib function to log hardening errors. #148266

Uh oh!

Conversation

var-const commented Jul 11, 2025

Uh oh!

llvmbot commented Jul 11, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ldionne left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ldionne left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

philnik777 commented Jul 15, 2025

Uh oh!

Uh oh!