Page MenuHomeFreeBSD

Continuation of D9903.
AbandonedPublic

Authored by kib on Mar 28 2017, 9:15 AM.

Details

Summary

Make set_/__throw_constraint_handler_s thread-safe.
Move __throw prototype into libc_private.h.
Minor style editings.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 8357
Build 8627: CI src buildJenkins

Event Timeline

kib created this revision.Mar 28 2017, 9:15 AM
lib/libc/stdlib/set_constraint_handler_s.c
59

A memory leak, need to free old.

kib added inline comments.Mar 28 2017, 2:02 PM
lib/libc/stdlib/set_constraint_handler_s.c
59

Well, I cannot free the memory there, see the updated comment above the definition of '_ch'. If going into this direction, either memory should not be allocated (could you, please, point to the rationale text ?) or lock used instead of lockless algorithm.

I thought that the set interface is used rarely so that the leak is not important.

kib updated this revision to Diff 26761.Mar 29 2017, 10:24 AM

Use lock and free old handler pointer.

Still, I would like to see a reference to the recommendation to malloc() the pointer memory.

lib/libc/stdlib/set_constraint_handler_s.c
59

Instead of atomics, a mutex would work.
Here is the rationale from n1173

Most implementations will probably use a pointer to function in their implementation of the set_constraint_handler_s function to hold the address of the currently
registered handler. Unfortunately, pointers to functions are employed by many security exploits. If an exploit deposits new code into a program, the exploit must find a way to cause that new code to be executed. The most common way is to alter the return address on the stack to point to the new code, but an alternative is to find a pointer to a function, and store the address of the new code in that pointer.
The committee thought that the benefit of a user-settable runtime-constraint handler
justified providing another pointer to function that might be exploited. There are steps that an implementation can take to mitigate the vulnerability of the pointer. Some
possibilities are:
• Dynamically allocate the pointer or otherwise arrange for the address of the
pointer to change every time the program runs
• Write-protect the page containing the pointer, and have
set_constraint_handler_s only write-enable the storage when it is
updating the pointer’s value.
• “Encode” the value of the pointer, so that it is not a pure address.

emaste edited edge metadata.Apr 18 2017, 9:09 PM

Committed in rS316213

ed removed a reviewer: ed.Sep 6 2017, 12:06 PM
stevek removed a reviewer: stevek.Sep 9 2017, 3:21 PM
stevek added a subscriber: stevek.

@kib can you close this?

kib abandoned this revision.Dec 19 2017, 3:00 PM