I'm supportive! Do you want to try to create a pull request?

This creates a small overhead on every method call that uses vtables. It is likely to be okay, but I'd like to know a little more about the attacks vs. the performance impact. Are there samples of the attacks & the performance impacts?

I know about vtable Hijacking attack. This kind of attack is based on memory corruption such as heap overflow to overwrite pointer of a c++objects. These pointers are mostly C++ virtual function address (Class method). Controlling one of these pointers, attackers have full access to the flow of control of an application.

GCC offers option to add verification of vtable pointers at run time (-fvtable-verify) so the performance impacts exist. This performance impact is proportional to the objects complexity of a C++ application : The more class methods, the greater the performance impacts.

Yes, I want to create a pull request on this topic. This is the first time I've done this, I need help. I think I should clone your repository and apply my modification?

Regards,

@Flo4152 You'll have the easiest time if you first fork the ossf/wg-best-practices-os-developer repo to your own Github profile, apply your changes to your local fork, then create a pull request.

You can clone the repository and edit it locally and push your changes to your fork, but Github also supports [editing files online] (https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files).

The performance impact isn't just on startup, but on every C++ virtual call:

"verifies at run time, for every virtual call, that the vtable pointer through which the call is made is valid for the type of the object, and has not been corrupted or overwritten. If an invalid vtable pointer is detected at run time, an error is reported and execution of the program is immediately halted."

Is there a way to characterize the performance impact? Basically, is it so large that this is test-only, or small enough to realistically use in production? I've not used this option, so I don't have experience with it.

Caroline Tice played an important role in integrating the vtable verification (VTV) by submitting the commit of this feature in GCC 4.9: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2077db1be5b18b94a91095a3fb380bbc4a81e61b

She involved on articles that give information about performance penalty.

First, she is describe performance penalty following 3 points in article available on GCC website : https://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=cmtice.pdf#page=38

• Call verification: Performance penalty between 5% and 10%.
• Object permission changes: Between 400% and 700% slowdown for permission changes per object file, while a performance loss of 320 ms is noticeable for permission changes per binary.
• Virtual function hashtable size: Storage of virtual function hashtable imply a big waste of space.

Then, a second article of Caroline Tice about Vtable Verification (VTV) compare Vtable Verification (VTV) in GCC 4.9, Indirect Function Call Checker (IFCC) in LLVM and Indirect Function Call Sanitizer (FSan), in LLVM. This second article give information about performance penalty between these 3 features : https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_tice.pdf#page=14

In this second article give a performance penalty between 1.6% and 8.7% for VTV.

I've never used this feature in a production environment, but according to these two articles, the performance penalty is real.

First, a performance penalty of nearly 10% implied by vtable checking should be taken into consideration by system engineers.
Secondly, a performance impact seems to be during the permission update at runtine. This performance impact depend on the option passed to -fvtable-verify flag (std or pre-init):

• Using pre-init option, object constructor function call permission update routine at the begin and at the end of constructor call to take a care of handling virtual function pointers at the early startup of an application.
• Using std option, the permission update calls are handled differently.

The impact on performance can be assessed using profiling tools such as perf. The trace points of the routines involved in virtual table verification can provide information on the performance threat posed by this feature. In addition, a global profiling of the application built with the-fvtable-verify option with tracepoints on the main routines of a application can provide information on the performance penalty in a production environment.

I'm going to summarize these information on my pull request about this feature.

Regards,

Has this been addressed by the C/C++ Compiler Hardening options guide? @gkunz @thomasnyman @david-a-wheeler