Preventing stack guard-page hopping

Posted Jun 19, 2017 23:26 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Preventing stack guard-page hopping by zblaxell
Parent article: Preventing stack guard-page hopping

> Obviously it would break some existing programs, but it smells like bad practice in general
A fairly common practice is to allocate some data, launch several worker threads to compute its parts and then join all the threads to get the final result. It's not uncommon for it to be allocated or have parts of on-stack data.

Preventing stack guard-page hopping

Posted Jun 20, 2017 1:40 UTC (Tue) by zblaxell (subscriber, #26385) [Link]

> launch several worker threads to compute its parts and then join all the threads to get the final result

That's pretty much how C++11 async functions work, and should be covered by the heuristic exception for "thread A creates thread B".

It wouldn't work if there was a persistent worker thread pool (i.e. the functions are executed by previously existing threads that continue to exist after the result is computed, so there is no creator/created or join relationship). It might be possible to infer data dependencies from mutex locks or higher-level objects (promise/future pairs) but maybe there's too many false positives. Or one could mark worker pool threads differently (e.g. some new pthread_attr) wrt access to other threads' stacks.