RFC: C++ Buffer Hardening

Re:RFC: C++ Buffer Hardening by jeffbee on Thursday October 06, 2022 @12:50AM (#33104501)

I'm not at all clear on how exactly that would work. The entire program would have to be rebuilt from scratch, would it not? Things like std::vector::operator[] are not runtime library calls, they are almost always inlined by the compiler. You could not simply take an existing program, replace its runtime library, and get bounds-checked vector accesses.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by pjmlp on Thursday October 06, 2022 @04:25AM (#33105891)

Depends how the linking took place, and optimization levels.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by planede on Thursday October 06, 2022 @05:12AM (#33106184)

vector is a template, at most vector<some_type>::operator[] will be a weak symbol, and I bet it's inlined from -O1 and above.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by gpderetta on Thursday October 06, 2022 @05:59AM (#33106419)

Even if not inlined at -O0, when instantiated for a custom some_type, the standard library .so won't contain any code for it, everything will be in the application binary.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by pjmlp on Thursday October 06, 2022 @06:02AM (#33106441)

Depends on the implementation of helper functions and if external templates are being used.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by gpderetta on Thursday October 06, 2022 @06:06AM (#33106458)

extern templates won't help for user defined types of course as the standard library couldn't possibly have instantiations for them :).

Some non template helpers might be improved of course.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by pjmlp on Thursday October 06, 2022 @06:32AM (#33106592)

They help for common types like std::string.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by pjmlp on Thursday October 06, 2022 @06:01AM (#33106430)

On Windows it can still live on a dynamic library.

That has been a thing since the Windows 16 bit days, and other OSes with similar linking models like Symbian, OS/2 and AIX.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by jeffbee on Thursday October 06, 2022 @09:59AM (#33108225)

It’s difficult to imagine which applications would find the performance of an outline vector access acceptable. Generally vector::operator[] is represented in built programs by a single x86 mov. A call would wreck the performance. In languages with bounds-checked vectors, they don’t do it with library calls.

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by pjmlp on Thursday October 06, 2022 @02:18PM (#33111947)

I have practically always used bounds checked vectors and strings.

In the old days, all C++ frameworks bundled with compilers tended to have bounds checking enabled by default (Turbo Vision, OWL, VCL, MFC, PowerPlant, CSet++, Qt,...).

Nowadays I always set _ITERATOR_DEBUG_LEVEL to 1 on VC++, unless I am not allowed to.

Mostly the performance problems that were dealt with, had to do with badly chosen algorithms and data structures.

Modern Android ships with FORTIFY enabled.

https://android-developers.googleblog.com/2017/04/fortify-in...

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by gpderetta on Thursday October 06, 2022 @05:56AM (#33106399)

Of course, it is a compiler feature, you will have to recompile and manually (or automatically) apply all suggested changes to the source code.

If you just link against an hardened library, only the implementation of the (non inlined) library calls will be hardened, the user code itself won't see much benefits.

Of course these days we have binary level optimizers, so who knows what it is possible in principle?

[ Parent | on HN ]

Re:RFC: C++ Buffer Hardening by yazzku on Saturday October 08, 2022 @12:29AM (#33129786)

Sorry, I used 'link' very liberally there, but you cleared it up. My point was that (from what I remember, it's been a few days) you'd mostly just need to recompile. As opposed to, you know, Rewrite It In Rust (TM).

[ Parent | on HN ]