В Си есть функция с мемным названием memmem(). Работает она похоже на strstr(), т.е. ищет подстроку в строке. Только вместо null-terminated строки на вход подается указатель на начало строки и ее размер.

Разработчики ядра применили изменение, в результате которого у меня сломалась работа с Secure Boot:
https://bugzilla.kernel.org/show_bug.cgi?id=216642

Ответ на баг-репорт убил:
In that sense, your use case is exactly what we intended to fix with that patch.

На случай важных переговоров

Маппинг памяти на нулевой адрес в Linux

Вопрос обсуждался на Stack Overflow здесь

Если коротко, то мапить странцы по нулевому адресу можно (если делать это с флагом MAP_FIXED). Правда, это может сделать только root (или процесс с нужными capabilities). Почему это не может сделать процесс обычного пользователя? Чтобы пользователь не мог эксплуатировать уязвимости ядра, связанные с чтением по нулевому указателю. А он это мог бы сделать, поскольку ядро «видит» маппинги памяти пользовательского процесса. И если пользователь замапил нулевую страницу, то она будет доступна и в ядре, тоже по нулевому адресу.

Пример (со Stack Overflow):

#include <sys/mman.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>

int main() {
    void *p = mmap(0, sysconf(_SC_PAGE_SIZE),
        PROT_READ | PROT_WRITE,
        MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS, -1, 0);
    printf("mmap result %p (errno %s)\n", p, strerror(errno));
    return 0;
}

Самый необычный тип в C++ (с расширениями GCC)

Пусть вам дана функция

template <class T>
void foo(const T &) {}

Как вы думаете, какие типы возможно передать в foo()? Любые? Любые, кроме void? А вот и нет!

Если мы воспользуемся variable-length array (в Cтандарте C++ его нет, зато есть в расширениях GCC) и попробуем передать в foo():
int n = 42;
int a[n];
foo(a);

то получим эпичную ошибку:
main.cpp:34:28: note: variable-sized array type ‘int [n]’ is not a valid template argument

А еще variable-length array интересен тем, что sizeof() от него вычисляется в рантайме. Во время компиляции это невозможно, поскольку мы не знаем размер массива.

Всем, кто утверждает, что компилятор Go быстро компилирует, покажите вот этот код:
https://pastebin.com/vzp5ha1y
и попросите дождаться, пока он скомпилируется.

Конечно, это очень вырожденный случай. Компилятору здесь как минимум нужно выписать тип в виде строки (чтобы использовать reflect). При этом для любого типа T верно, что func(a, b T) перепишется в func(a T, b T). Таким образом, количество раз, которое мы выписали T, удвоилось. Вкладывая так func(a, b T) друг в друга много раз, мы получаем, что строка с записью типа растет экспоненциально быстро, и компилятор не осиливает.

Рассказваю, как залипнуть на N часов и не пожалеть об этом:
https://www.decisionproblem.com/paperclips/index2.html

Игра основана на статье шведского философа Ника Бострома про ИИ, который максимизирует число сделанных скрепок (можно еще почитать тут на русском или коротко на английской Вики). (Предупреждаю, статьи могут стать спойлером для самой игры!)

В самой игре вам предстоит играть за такой ИИ и превратить всю Вселенную в скрепки.

С компьютера можно играть прямо из браузера, а с телефона сайт предлагает скачать приложение; лучше смотреть с компьютера.

(Кстати, ссылку на игру я честно подсмотрел в канале у @markysha)

Какая ты сова сегодня?

Интересная статья про то, почему эффект Даннинга-Крюгера может быть ошибочным:
https://www.psychologytoday.com/us/blog/how-do-you-know/202012/dunning-kruger-isnt-real

Оригинальное утверждение заключалось в следующем: менее компетентные люди способны завышать представления о своих способностях, а более компетентные люди — наоборот, занижать.

В статье автор берет оригинальный график из статьи Даннинга и Крюгера, но предлагает иную модель: а именно, что все люди в среднем завышают свои способности (но со случайным разбросом). После чего он моделирует свое предположение с помощью скрипта на R, и результат симуляции оказывается близким к графику из оригинального эксперимента.

— О. Ну что же, в физике никто из нас не разбирается, поэтому поговорить о ней нам, я думаю, не удастся.
— Наоборот, — ответил я. — Поговорить о физике нам не удастся именно потому, что кое-кто из нас в ней разбирается. А обсуждать можно лишь то, о чем никто ничего не знает. Мы можем поговорить о погоде, можем — об общественных проблемах, о психологии, о международных финансах, — не о перемещении золота, тут все-таки нужно хоть что-то понимать, — для любого общего разговора годится лишь та тема, в которой никто ничего не смыслит.
Ричард Фейнман, «Вы, конечно, шутите, мистер Фейнман»

Как расширить размер стека

Иногда в олимпиадных задачах не хватает стека, и надо бы увеличить его размер. Есть много разных способов. Например, для MSVC действует такой:

#pragma comment(linker, "/STACK:16777216")

Можно еще вручную выделить массив и переместить на него стек, используя ассемблер. Код ниже работает на GCC для amd64 (тестировался на GNU/Linux, хотя скорее всего будет работать и под Windows):

extern "C" {
void main2();
// размер стека — 16 МБ. Если нужно больше, можно
// поменять размер массива(но alignas не трогать!)
alignas(16) char stack[16777216];
}

void main2() {
// здесь основной код
}

int main() {
asm(
// сохраняем старые rsp и rbp
"pushq %rbp\n"
"movq %rsp, %rbp\n"
// перемещаем rsp на конец созданного
// нами массива; теперь он будет стеком
"leaq stack(%rip), %rsp\n"
"addq $16777216, %rsp\n"
// зовем main2() с основным кодом
"callq main2\n"
// возвращаем все на место
"movq %rbp, %rsp\n"
"popq %rbp"
);
return 0;
}

One flew east, one flew west,
One flew over cheetah's nest.

О том, почему формулировать задания сто́ит предельно четко. Или о том, как не надо работать с заказчиком. Или о том, почему не стоит доверять работу троллям. В общем:
https://27bslash6.com/missy.html

Худшая файловая система в мире

Познакомьтесь. Это EvilFS, который работает через FUSE:
https://pastebin.com/B9KSe0Z0

Инструкция по применению:
- желательно запускать на GNU/Linux
- установите libfuse2 из системного пакетного менеджера и pyfuse через pip
- запустите скрипт
- после запуска скрипта создастся папка рядом со скриптом. Зайдите в нее из командной строки и попробуйте прочитать файлы в ней
- не получилось? Поздравляю, вы застряли :D
- хотите убить процесс, читающий файл, с помощью SIGKILL? Поздравляю, его убить нельзя :D

К счастью, выпутаться из неприятной ситуации возможно: достаточно просто убить сам процесс EvilFS, тогда у использующих ее процессов произойдет разрыв соединения, и их можно будет завершить.

Как это работает?
Все просто. EvilFS реализуется через FUSE — это возможность создавать файловые системы полностью в userspace. Процесс EvilFS как раз создает такую файловую систему и монтирует ее, а в ходе работы обрабатывает все запросы в нее.

Так вот: на запрос open() (т.е. открыть файл) EvilFS просто начинает висеть, подвешивая и того, кто пытается файл открыть. Т.е. мы не можем прочитать файл, потому что его открытие зависает.

Но почему процесс нельзя убить, пока он пытается открыть плохой файл? Здесь вступает в дело понятие uninterruptible sleep (a.k.a. непробудный сон). Он происходит тогда, когда процесс завис в системном вызове, который нельзя прервать (т.к. не все системные вызовы умеют возвращать EINTR). Например, open() прервать нельзя. Во время непробудного сна процесс не принимает никакие сигналы (даже SIGKILL!), то есть, его нельзя убить. Понятно, что зависнуть в open()'е в естественных условиях — дело редкое, но возможное в случае сетевых ФС или медленного диска. А вот в случае с FUSE такое зависание нетрудно воспроизводится в домашних условиях.

Продолжение следует...

Еще более злая файловая система 😈📁

Думали, что хуже EvilFS ничего нет? Есть, конечно! Знакомьтесь, EvilFSv2:
https://pastebin.com/y3PrJvyu

Инструкция по применению аналогичная. Но, в отличие от своего менее коварного предшественника, EvilFSv2 содержит три файла: a.txt, b.txt и c.txt. При этом, если открыть c.txt, то сама EvilFSv2 попытается сделать open('evil_fs/a.txt'), что приведет к попаданию процесса EvilFSv2 в состояние uninterruptible sleep. Это означает, что любые попытки завершить EvilFSv2 тщетны и напрасны. Вот такой вот Уроборос.

Более того, EvilFSv2 не ждет, пока пользователь прочитает c.txt и повесит ФС на самой себе, а действует проактивно: форкается и в форке пытается этот самый c.txt прочесть.

Как же убить EvilFSv2? Выхода нет?

Оказывается, есть. Достаточно лишь сделать

for FILE in /sys/fs/fuse/connections/*/abort; do
echo 1 >$FILE
done

Правда, при этом отмонтируются все остальные основанные на FUSE файловые системы, но тем не менее с задачей завершить EvilFSv2 мы справились :)

И еще один аналогичный мем