Implement a hardened mode

[tiagomacarios]

libc++ has implemented a hardened mode that allows applications to enable security checks in production. Would it be possible to add similar functionality to the MSVC STL?

Background:
https://libcxx.llvm.org/Hardening.html
https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html

I understand that we currently have other avenues to achieve similar results (for example _CONTAINER_DEBUG_LEVEL). Could we get clarity if these can be safely used in production as well?

[CaseyCarter]

_CONTAINER_DEBUG_LEVEL is at least very similar in intent. We put DEBUG in the name to set expectations. The ODR violation when linking TUs that define _CONTAINER_DEBUG_LEVEL == 0 with TUs that define _CONTAINER_DEBUG_LEVEL > 0 means that sometimes the linker throws out your checks; it would be unethical to put anything like SECURE in the name such a feature. The checks themselves are great - _CONTAINER_DEBUG_LEVEL controls only O(1) checks that don't require changes to object representations - but we can't recommend relying on a feature that may silently stop working if you add a new dependency and forget to build it with _CONTAINER_DEBUG_LEVEL defined.

That said, I'd love to design and implement a proper hardened mode for the STL and finally finish what Billy tried to get started with _CONTAINER_DEBUG_LEVEL.

[jovibor]

Duplicate or related to #586.

[frederick-vs-ja]

More detailed explanation can be found in #4586 (comment).

@CaseyCarter Can we add explanation to Wiki now?

[StephanTLavavej]

We talked about this at the weekly maintainer meeting. We'd like to hold off on adding any guidance to the wiki, since the whole issue here is that we need to find the time to sit down and properly redesign CDL, answering policy questions like exactly when it's appropriate to add O(1) checks that don't require representation changes (should we do this for all preconditions, or focus on "scary" ones like bounds checks and optional::operator*, since there are a lot of preconditions and checking all of them could accumulate expense, dragging down the utility of the whole feature - it's not like [[nodiscard]] where the question is purely avoiding false positives, here the correctness of every individual check is indisputable but the performance expense is a judgement call).