Из OpenBSD начинают выпиливать syscall()

В этом в общем-то суть любых техник, препятствующих эксплуатации: сделать взлом либо экономически нецелесообразным (можно найти цель по-проще), либо задержать настолько, чтобы админы успели заметить. Никто не говорит, что всё это даёт какие-то 100% гарантии от взлома, даже Тео.

Если атакующий в результате твоей десятилетней работы потратит на пару часов больше… стоило ли оно того?

само по себе время нет, а ты попробуй его в локальное переводить. Будет перечитывать /etc/localtime на каждом вызове localtime

Кто-то тут про localtime вспоминал кроме тебя? Я не вижу.

само по себе время нет, а ты попробуй его в локальное переводить. Будет перечитывать /etc/localtime на каждом вызове localtime

А зачем мне его в localtime переводить? Одна из причин засунуть в vdso была для таймеров и бенчмарков, которые оперируют монотонным временем.

В этом в общем-то суть любых техник, препятствующих эксплуатации: сделать взлом либо экономически нецелесообразным (можно найти цель по-проще), либо задержать настолько, чтобы админы успели заметить. Никто не говорит, что всё это даёт какие-то 100% гарантии от взлома, даже Тео.

Если атакующий в результате твоей десятилетней работы потратит на пару часов больше… стоило ли оно того?

Каждый атакующий каждую систему. В принципе, да. Плюс, все эти штуки не требуют 10 лет работы, чтобы реализовать.

Каждый атакующий каждую систему. В принципе, да. Плюс, все эти штуки не требуют 10 лет работы, чтобы реализовать.

Много датируется ещё нулевыми,а стало дефолтом в конце десятых. Реально же проще на раст переписать.

Каждый атакующий каждую систему. В принципе, да. Плюс, все эти штуки не требуют 10 лет работы, чтобы реализовать.

Много датируется ещё нулевыми,а стало дефолтом в конце десятых.

Они дрочили много :)

Реально же проще на раст переписать.

Чтобы писать на расте, требуется начать принимать женские гормоны и сделать операцию по смене пола. Многие не готовы к такому.

просто это частый юзкейс, который ломает всю оптимизацию

просто это частый юзкейс, который ломает всю оптимизацию

Нет, не ломает, потому что оптимизация там – как выше заметил спермозлыдень – для другого.

Они дрочили много :)

Это они любят, да.

Чтобы писать на расте, требуется начать принимать женские гормоны и сделать операцию по смене пола. Многие не готовы к такому.

Не, это требуется что писать сам Rust.

Они дрочили много :)

Это они любят, да.

Кто ж не любит-то? Особенно когда тебе за твою работу не платят, как в случае с OpenBSD.

Чтобы писать на расте, требуется начать принимать женские гормоны и сделать операцию по смене пола. Многие не готовы к такому.

Не, это требуется что писать сам Rust.

Не, не только. Среди программистов на Rust трансов дохрена почему-то. Больше только в Common Lisp и среди разработчиков Xorg/Wayland.

Голоса в моей голове подсказывают, что чтение перменной из примапленной страницы памяти, не являются примером перехода из Userspace в Kernelspace и рекомендуют тебе свериться ещё раз со своими.

Голоса в моей голове подсказывают, что чтение перменной из примапленной страницы памяти, не являются примером перехода из Userspace в Kernelspace и рекомендуют тебе свериться ещё раз со своими.

man io_uring

io_uring is a Linux kernel system call interface for storage device asynchronous I/O operations addressing performance issues with similar interfaces provided by functions like read/write or aio_read/aio_write etc. for operations on data accessed by file descriptors. Development is ongoing, worked on primarily by Jens Axboe at Meta.

One of the parts of io_uring that I find the most interesting is the possibility to have the kernel poll for new SQEs instead of the user having to inform the kernel via io_uring_enter() (wrapped by io_uring_submit() in liburing). By using io_uring_queue_init_params to pass in flags to io_uring initialisation and setting the IORING_SETUP_SQPOLL flag, the kernel will keep polling for up to params.sq_thread_idle milliseconds after the last SQE was submitted. Any SQEs you put into the SQE ring will automatically be picked up without any system calls required. After sq_thread_idle milliseconds have passed, the polling kernel thread will stop and you will need to call io_uring_enter() again to start it back up. When using liburing, io_uring_submit() will automagically keep track of whether the kernel thread is still alive and skip the syscall if it is not required.

Вот статья короче: https://wjwh.eu/posts/2021-10-01-no-syscall-server-iouring.html

Это POC, но в итоге мы придем к этому в виде production ready решения.

просто это частый юзкейс, который ломает всю оптимизацию

Прости, на какой планете спрашивать localtime сотни раз в секунду это частый юзкейс?

Во-первых, io_ring, который выше упомянули. Во-вторых, что по-твоему происходит, когда программа запрашивает страницу, убранную в своп?

io_uring это изначально подход сокращения количества прыжков между Kernel/User, как в целом и тот же sendfile, а не альтернатива, со страницей - mmu подтянет её, но я так и не увидел ни одного примера вызова из User в Kernel без использования системных вызовов.

io_uring это изначально подход сокращения количества прыжков между Kernel/User, как в целом и тот жеsendfile, а не альтернатива

Што? По-твоему, пакеты в памяти из атсрала появляются что ли? Или может их туда ядро кладёт?

со страницей - mmu подтянет её

Откуда MMU подтянет её? Ты думаешь, MMU знает, где именно на диске лежит эта страница? MMU про диск и раздел со свопом не знает ровно нихрена. Иди читай как виртуальная память работает и что происходит, когда нужной страницы нет в памяти/таблице трансляции адресов в MMU.

я так и не увидел ни одного примера вызова из User в Kernel без использования системных вызовов.

А ты глаза разуй.

«И тут Остапа понесло…», хватит уже душнить на вещи о которых я вообще не говорил, пакеты из атсрала, mmu спросит ядро, закинув прерывание процу, хз как это вообще относится к изначальному разговору, я спрашивал про механизмы вызовов из Userspace в Kernelspace, т.е. довольно конкретно, ты говоришь что их множество, но внятных примеров так и нет, одна возьня вокруг да около, в целом решений разной степени упоротости хватает, тот же In-kernel web server, но это скорее частности из разряда «а почему бы и нет?»

mmu спросит ядро, закинув прерывание процу, хз как это вообще относится к изначальному разговору,

Это был лёгкий намёк на то, что программе совсем не обязательно вызывать syscall/sysenter/int $0x80, чтобы ядро перехватило управление. Достаточно просто дёрнуть нужную страницу памяти. Но ты о таких вещах явно не в курсе, поэтому я напишу прямо: общение между юзерспейсом и ядром можно без проблем организовать через специально замапленную память, при обращении к которой возникает прерывание.

ты говоришь что их множество, но внятных примеров так и нет, одна возьня вокруг да около

Возня у тебя в штанах, чувак. А прерывания от обращений в память возникают весьма чётенько, ваще без напряга. Либо можно даже без прерываний, как это делает io_uring, про который, напомню, тебе выше расписали. В том числе там ссылка на пример сервера, который шлёт и принимает пакеты вообще без сисколлов или прерываний.

я спрашивал про механизмы вызовов из Userspace в Kernelspace, т.е. довольно конкретно, ты говоришь что их множество

Мапишь себе регион памяти, а дальше как с ядром договоритесь. В io_uring вот поллинг.

Ого, ты вернулся?!

Позавчера, кстати, открыл посмотреть INTERRUPT LIST какого-то далеко не самого первого релиза, от 90-х. Ностальгия.