Chrome не запускается при предварительной загрузке системного вызова чтения с использованием LD_PRELOAD

Я работаю над проектом, который требует обертывания системных вызовов libc, в частности вызовов файлового ввода-вывода, таких как открытие, чтение, запись, закрытие и т. д. Я намерен использовать это в качестве службы мониторинга для операций с файлами.

Я успешно обернул все вызовы, и оболочка отлично работает, когда я пытаюсь открыть текстовый файл с помощью gedit. Но проблема в том, что я не могу запустить Google Chrome и несколько других приложений, когда оболочка предварительно загружена. Google Chrome, в частности, переходит в бесконечный цикл наносна. Вы можете увидеть страйк ниже.

После отладки я обнаружил, что проблема связана с системными вызовами чтения и закрытия. Когда я удаляю функции оболочки для чтения и закрытия, все работает нормально. Одна вещь, которую я могу сделать, это отключить оболочку для Google Chrome, но мне любопытно узнать, сталкивался ли кто-нибудь с той же проблемой и нашел какие-либо обходные пути или решения. Я видел другие реализации оболочки и пробовал их, но сталкивался с той же проблемой. Я пропустил что-то очень тривиальное здесь?

set_tid_address(0x7f140cddad50)         = 23827
set_robust_list(0x7f140cddad60, 24)     = 0
rt_sigaction(SIGRTMIN, {0x7f140c867b50, [], SA_RESTORER|SA_SIGINFO, 0x7f140c873390}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7f140c867be0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f140c873390}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
open("/dev/urandom", O_RDONLY)          = 3
futex(0x7f140c8610a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0
nanosleep({0, 2000001}, NULL)           = 0

Вот моя функция-оболочка для read():

ssize_t read(int fd, void *buf, size_t count) {
    ssize_t (*libc_read) (int df, void* buf, size_t count);

    dlerror();

    libc_read = (ssize_t (*) (int df, void* buf, size_t count)) 
    dlsym(RTLD_NEXT, "read");

    // If a dynamic link error occurred
    if (dlerror() || (libc_read == NULL)) {
        return EOF;
    }

    // Call the system function
    size_t bytes_read = libc_read(fd, buf, count);

    return bytes_read;
}

person HARIHARA VARMA INDUKURI    schedule 28.05.2018    source источник
comment
В общем, я считаю, что перехват функций ядра, таких как open и read, не работает. По крайней мере, так говорят разработчики ядра. См. также Запрос о перехвате системного вызова модулями ядра в ядре. -newbies список рассылки и несколько модулей ядра перехватывают один и тот же системный вызов и аварийно завершают работу во время выгрузки при переполнении стека. И см. перехват системного вызова в модуле linux-kernel для людей, которые говорят, что это возможно   -  person jww    schedule 28.05.2018
comment
@jww это не перехват фактического системного вызова, как в любом из этих примеров; просто функция-оболочка для него в libc.   -  person hobbs    schedule 28.05.2018
comment
Не вызывайте dlsym при каждом read; вместо этого напишите функцию, которая выполняет dlsym для каждой функции, и вызовите эту функцию ровно один раз.   -  person Lorinczy Zsigmond    schedule 28.05.2018
comment
спасибо jww за ваш ответ. Но, как сказал @hobbs, я не перехватываю настоящий системный вызов.   -  person HARIHARA VARMA INDUKURI    schedule 28.05.2018
comment
@LorinczyZsigmond да, это может быть проблемой.   -  person hobbs    schedule 28.05.2018
comment
Спасибо @LorinczyZsigmond. Я попробую это.   -  person HARIHARA VARMA INDUKURI    schedule 29.05.2018