Так как счётчик аргументов не проверялся на соответствие фактическому содержимому массива и полагалось, что он всегда больше 1, в случае передачи процессу пустого массива argv, что допускает функция execve в Linux, pkexec воспринимал значение NULL как первый аргумент (имя процесса), а следующую за пределами буфера память, как далее идущее содержимое массива. Проблема в том, что следом за массивом argv в памяти размещается массив envp, содержащий переменные окружения.
Получив значение argv[1], pkexec пытается с учётом файловых путей в PATH определить полный путь к исполняемому файлу и записать указатель на строку с полный путём обратно в argv[1]
Дело оказалось в том, что GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). Компилятор не учитывает фактический размер результирующего кода, а пытается прогнозировать его. Для ассемблерных вставок прогнозирование делается на основе числа переводов строк ("\n") и разделителей (";") в исходном тексте.
it turned out that by carefully handcrafting the fast path, we can achieve highly-competitive IPC latencies [Blackham and Heiser, 2012]. Specifically this means manually re-ordering statements, making use of (verified) invariants that the compiler is unable to determine by static analysisЛюди руками переписывали сишный код в другой сишный код, на основании знаний того, какие машинные команды получатся в итоге и с какой скоростью будут выполняться.
#include <Object.h>
#define Object XtObject
#include <X11/Intrinsic.h>
#include <X11/IntrinsicP.h>
#undef Object
