В документации (datasheet) по архитектуре Intel и даташите по оптимизации исполнения программ возможность проблемы самомодифицирующегося кода, его вызова и исполнения, через инъекцию адреса в кэш конвейера до исполнения инструкции возврата, с бесконтрольным изменением, повышением (эскалацией) привилегий при исполнении потоков инструкций конвейером, описана очень давно (ещё с начала 2007 года, судя по архивам), но не решалась и игнорировалась до сих пор в угоду производительности, из-за значительного снижения скорости исполнения инструкций блоками процессорного конвейера в многопоточном режиме (а также HT) работы ядер при обработке и исполнении инструкций, предсказании переходов/возвратов/ветвлений, обработке и трансляции адресов (TLB), и при этом контроле привилегий и контекста безопасности исполнения инструкций:

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

Остальные мануалы и даташиты можно найти по адресу:
https://software.intel.com/en-us/articles/intel-sdm

branch target injection (new)

Вся соль.

Инъекция адреса на код через предсказатель возврата:

При предсказании адреса возврата (return predictor) и самом возврате сохраняется состояние контекста безопасности (уровня привелегий) при исполнении кода и это фундаментальный изъян текущей архитектуры и работы конвейера со спекулятивным предсказанием переходов - это делает возможным инжекцию указателей адреса возврата из привилегированной памяти на код в непривилегированной памяти (и его исполнение в привилегированном режиме после перехода) через изменение и подстановку адреса в кэш конвейера который не очищается перед инструкцией возврата и возвратом/переходом.

however, the basic hypothesis of this attack variant is that it can also be used to redirect execution of code in the victim context (in other words, to create interference from the attacker to the victim; the other way around).

Leaking or injection through the return predictor:

If the return predictor also doesn't lose its state on a privilege level change, it might be useful for either locating the host kernel from inside a VM (in which case bisection could be used to very quickly discover the full address of the host kernel) or injecting return targets (in particular if the return address is stored in a cache line that can be flushed out by the attacker and isn't reloaded before the return instruction).

Это подрывает основу основ безопасности памяти и исполнения кода.
Возможность атаки не гепотетическая, как описано в документе - проведение атаки реально и воспроизводимо (как минимум на архитектуре Haswell), уязвим сам просесс смены привилегий при исполнении инструкций, в особенности в многопоточном режиме и при использовании режима Hyper-Threading (HT), в котором незагруженные части конвейера (образуя "вирутальные ядра") упреждающе (с предсказанием переходов/возвратов/ветвлений кода) обрабатывают инструкции из других программных потоков.
Большую информацию на данный момент разглашать запрещено (NDA) микропроцессорными производителями (вендорами) до тех пор пока не будет найдено решение для текущих поколений процессоров, выпущены патчи ядра и микрокода, и не будет выпущено следующее поколение процессоров с устранением уязвимости.

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf:

Placing data immediately following an indirect branch can cause a performance problem. If the data consists of all zeros, it looks like a long stream of ADDs to memory destinations and this can cause resource conflicts and slow down branch recovery. Also, data immediately following indirect branches may appear as branches to the branch predication [sic] hardware, which can branch off to execute other data pages. This can lead to subsequent self-modifying code problems.

Software should avoid writing to a code page in the same 1-KByte subpage that is being executed or fetching code in the same 2-KByte subpage of that is being written. In addition, sharing a page containing directly or speculatively executed code with another processor as a data page can trigger an SMC condition that causes the entire pipeline of the machine and the trace cache to be cleared. This is due to the self-modifying code condition.

Единственное что можно сделать на данный момент - применить программные, частичные решения проблемы спекулятивного предсказания переходов (ведущие к потерям производительности из-за контроля/восстановления контекста безопасности при исполнении инструкций и переносе частей памяти ядра полностью в область привилегий ядра, что увеличивает накладные расходы системных вызовов), через апдейт микрокода процессоров и патч ядра KPTI на базе KAISER с переносом всех непривилегированных частей адресного пространства ядра из режима пользовательских привилегий полностью в режим привилегий ядра, плюс применение патча KASLR для рандомизации частей адресного пространства ядра при запуске системы и программных процессов, который усложняет поиск адресов кода и данных относящихся к адресному пространству ядра системы.

1984 actually!

​​With best wishes for the birthday of our project - Technologique!

Сегодня каналу исполняется два года! 🎉🎊🍾🥂🎂🍰

Начиналось всё как раз с обзора будущих аппаратных микропроцессорных архитектур, которые уже сейчас стали текущими и нашей реальностью:
https://t.me/technologique/28
https://t.me/technologique/29

За 2017 год изменилось многое, но базовые ценности и принципы ведения канала остались незыблемы.

Был выполнен лёгкий ребрендинг с технологической смысловой нагрузкой в стиле Daft Punk. К слову, благодаря смыслу композиции "Technologique" и из любви автора к электронной музыке и родилось название канала.

Изначально и по сей день канал ориентирован на лонгриды и авторский контент - публикацию обзоров и создание аналитических статей. Такой формат авторского блога даётся с большим трудом и не так популярен в Telegram.

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

Рекламу в публикациях не использую (и не буду) из принципа "строго по теме - о технологиях".

В начале 2017 года в канале было всего лишь только сто близких друзей и знакомых. За 2017 год канал вырос до более чем тысячи читающих и думающих людей!

Благодарю читателей за потрясающую энергетику, добрые замечания, предложения и ценные советы, что читаете, даже внимательнее, чем я пишу! =)
Благодарю моих друзей, которые помогают мне, за поддержку, помощь и советы - даже небольшая помощь это уже вклад!
Без всех вас не было бы той искры, проект этого канала не был бы таким интересным и не развивался бы так динамично и с такой энергетикой, а в коридорах нашей "гвардейской редакторской" не кипела бы работа, а только гулял ветер. =)
Спасибо вам за вдохновение продолжать вести канал и публиковать интересные посты и статьи!

Впереди ещё очень много интересных материалов о технологиях, программировании и железе. 🤓

Не переключайте канал! 😉

Links:
https://t.me/technologique/1
https://t.me/technologique/683

​​The king is dead - long live the king!

Что будет дальше, если сейчас суперскалярная архитектура Intel, которую компания продвигала с зарождения всей своей линии процессоров, потерпела такое фиаско?

Вспомнилась одна, едва заметная новость, промелькнувшая в феврале прошлого года в отчёте Intel для инвесторов.

https://t.me/technologique/785

И теперь, перечитывая эту новость, в связи со всей сложившейся сейчас ситуацией вокруг Intel, понятны причины покупки российско-индийского стартапа Soft Machines в сентябре 2016 года.
Финансовый отчёт о приобретении стратапа был представлен в феврале 2017 года на презентации для инвесторов.
Время попадания уязвимостей конвейерного механизма в базу MITRE - 20170201, т.е. материал был подготовлен в январе и добавлен в базу первого февраля 2017 года, до презентации для инвесторов.
Из поста выше - отчёт по уязвимости конвейерного механизма исполнения инструкций был сдан в Intel ещё в июне 2016 года (https://t.me/technologique/1225), Soft Machines был куплен в сентябре 2016 года.

Перечитайте, какими разработками занимется Soft Machines, это интересно:

 Machines занимаются проектрованием новой архитектуры процессоров - VISC (virtual instruction set computing). Это технология программно-аппаратной виртуализации, позволяющая виртуализировать конвейер на уровне микрокода процессора и таким образом лучше распараллеливать поток исполнения инструкций в однопоточных приложениях, и виртуализировать блок команд, сделав многоцелевой процессор, способный исполнять как x86-64/IA-64, так и ARMv8-64 наборы инструкций

В основе ядер VISC архитектуры лежит конвейер исполняющий ограниченный набор RISC инструкций, в свою очередь виртуальный конвейер исполняет виртуальный набор инструкций (практически любой - x86-64, ARM, MIPS) с их преобразованием через уровень трансляции в RISC инструкции.

Отличный обзор архитектуры VISC от Soft Machines писал портал Anandtech:
https://www.anandtech.com/show/10025/examining-soft-machines-architecture-visc-ipc

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

Как гласит великая древняя (математическая) мудрость:
Нет такой проблемы, которую нельзя было бы решить введя дополнительный уровень абстракций, кроме проблемы слишком большого количества уровней абстракций.

Intel уже не впервые кардинально меняет архитектуру процессорных ядер - в истории были архитектуры P6, NetBurst (HT), которая вновь стала использоваться для оптимизации загрузки конвейера в линейках процессоров новых архитектур (начиная с Nehalem), архитектура Core и современные микро-архитектуры на базе Nehalem.

Не исключено, что будущая архитектура Tinsley (процессор Sapphire Rapids), который предположительно выйдет на рынок после 2020 года - это разработка Soft Machines.

https://www.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/platform-codenames.html#search-0=tinsley

Но не стоит забывать и другую ситуацию со средой Intel ME (Intel ME/vPro/AMT/TXT), в которой как оказалось исполняется изменённая ОС Minix, исполняется скрытно, на сопроцессоре, с самым высоким уровнем привилегий, в кольце с условным обозначением -3 (по наименованию исследователей из Invisible Things Lab) - исполнение кода AMT поисходит в специальном сопроцессоре независимо от основного процессора, но с полным привелегированным доступом ко всей памяти.

Какие абстракции и что ещё может быть скрыто в процессорах Intel и при этом не описано ни в одном даташите - вопрос открытый.

Истина как всегда где то рядом.

Презентация Soft Machines на конференции Linley Processor Conference 2014 года:

http://www.softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf

Видео с презентации Soft Machines на конференции Linley Processor Conference 2014 года:

https://youtu.be/lXE0LTsvYQg

Видео с презентации Soft Machines на конференции Linley Processor Conference 2015 года:

https://youtu.be/Y9205sU51jA

Vulnerability impact mitigation.

Неделю назад среди разработчиков компиляторов и инструметов статического анализа была распространена информация, от Google и производителей процессоров, о технике "retpoline", для предотвращения упреждающего исполнения кода с изменённым контекстом безопасности в спекулятивно предсказанных ветвлениях кода, контроле контекста безопасности и содержимого кэша при возврате из ветвлений.
В предоставленной информации был произведён подробный разбор, как должен быть скомпилирован код и как произвести статический анализ существующего ассемблерного кода (либо другой мнемоники/псевдокода) до фазы его оптимизации (циклов, переходов, возвратов), чтобы в коде не было сохранения состояния контекста безопасности (блока контрольных регистров) при смене привилегий, которое не контролируется процессором во время упреждающего конвейерного исполнения инструкций с предсказанием ветвлений и при восстановлении контекста (состояния контрольных регистров безопасности) вызова подпрограмм при возврате в основной поток исполнения из предсказанного ветвления, другого исполяемого потока кода на уровне конвейера.

Было понятно, что решение по предотвращению уязвимостей будет не только на уровне патчей ядра и микрокода, но и на уровне компиляторов.
Многие критические системные приложения, тем более для Linux (и source-based дистрибутивов типа Gentoo) достаточно будет перекомпилировать обновлённым компилятором или его специальной сборкой.

Устранение возможности проведения атаки "leaking through the return predictor", одного из исходов уязвимости Spectre ("branch target injection" CVE-2017-5715 и "bounds check bypass" CVE-2017-5753).

При этом возможность проведения атаки "injection through the return predictor", второго возможного исхода уязвимости Spectre, пока не устранена и данные по уязвимости не преданы огласке.

Устранение производится через рекомпиляцию критического софта (ядро, модули, драйверы, система инициализации и другие части системы, исполняемые процессором в привилегированном режиме) с помощью специальной сборки компилятора LLVM (CLang) или GCC, которая внедряет при компиляции кода последовательность инструкций, названную "retpoline" (от "return" и "trampoline"), для предотвращения спекулятивного предсказания ветвлений кода и упреждающего исполнения инструкций в ветвлениях кода, изоляции контекста безопасности при исполнении инструкций в ветвлениях кода и возврате из пресказанных ветвлений.

The name “retpoline” is a portmanteau of “return” and “trampoline.”  It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will “bounce” endlessly.  

https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

https://support.google.com/faqs/answer/7622138

https://support.google.com/faqs/answer/7625886

https://reviews.llvm.org/D41723

http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219


Ссылки на предыдущие материалы:
https://t.me/technologique/1235
https://t.me/technologique/1230
https://t.me/technologique/1227
https://t.me/technologique/1228
https://t.me/technologique/1225

We like to... move it!

Статья от марта прошлого года с анализом миграции разработчиков между языками программирования и их экосистемами.
Анализ переходов с одного языка на другой выполнен согласно поисковым данным в выдаче статей и постов в Google, с определением вектора/направления и количества переходов и предсказанием тенденции согласно статистическому анализу в каком направлении будут совершаться переходы в будущем.

В статье есть также оценка текущей и будущей миграции разработчиков между JavaScript фреймворками для создания клиентских приложений и между различными движками СУБД, применяемыми в проектах.

https://erikbern.com/2017/03/15/the-eigenvector-of-why-we-moved-from-language-x-to-language-y.html

Исследование just for fun конечно же, но спустя почти год видно, что тенденции сохраняются и переходы просматриваются довольно прозрачно и предсказуемо, особенно при знании концепций языков, их систем типов и возможностей языковых сред компиляции и исполнения кода.

Go вновь в топе всех языков, но с Go на Rust переток довольно сильный.

Интересно было бы взглянуть на результаты спустя год, т.к. Kotlin начал набирать мировую популярность с мая прошлого года, после Google IO 2017.

Кстати, по диаграмме видно, что с Kotlin и Scala на Java возвращаются чаще, чем переходят на эти языки с Java. Такая же тенденция со Swift - чаще возвращаются на Objective-C, чем переходят на Swift.
Видимо многие уже вдоволь наигрались с языками, которые по сути не groundbreaking и предлагают лишь синтаксический сахар - рост популярности старого доброго Си (как и в индексе TIOBE и по данным оценки уровня контрибуции в открытые проекты на GitHub от сервиса Krihelimeter) тому подтверждение.

Ссылки на материалы по теме:
https://t.me/technologique/1215

https://www.tiobe.com/tiobe-index/

По следам OOM Killer'a.

Последнее время читатели и друзья задают один и тот же вопрос про OOM Killer механизм ядра Linux и как сделать систему отзывчивой при превышении лимита памяти так, чтобы не использовать страничную подкачку очень часто.
Поэтому я решил написать заметку с обзором проблемы и её решения.

Преамбула: Памяти никогда не бывает много!

В недавней альфа версии десктоп клиента Telegram для Linux была проблема при совершении звонков.
Во время звонка одно ядро процессора было загружено до 100%, после пары минут работы начиналась неконтролируемая утечка памяти в процессе плиента и если страничная подкачка в ядре отключена (тестировалось на Linux ядре с отключенной подкачкой - переносимая система Debian запускалась с флэш диска с параметром ядра vm.spappiness=0, но ведь многие до сих пор так делают и полностью отключают подкачку на своих рабочих машинах чтобы не вредить SSD дискам), ещё через пару минут, когда свободная память заканчивалась, система зависала намертво с шикарными эффектами заиканий в выводе Pulse Audio.

В ядрах старше версии 3.5 vm.swappiness=0 отключает дамп в swap полностью и в итоге система зависает при исчерпании памяти или испытывает очень сильное замедление (freeze) - лучше никогда не делать так на серверах с SSD, крайнее значение vm.swappiness=1, ранее это означало, что ядро будет сбрасывать страницы в область страничной подкачки (swap раздел) при остатке в 1% свободной памяти в системе.
Но сейчас (в ядрах старше версии 3.5) если vm.swappiness=1 ядро будет "свопить" в страничную подкачку только когда памяти остаётся меньше, чем установлено параметром vm.min_free_kbytes - точно так же, как и было на более ранних ядрах при отключении подкачки установкой параметра vm.swappiness=0.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/vm.txt

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

https://www.kernel.org/doc/Documentation/sysctl/kernel.txt

Сделав дамп памяти программы клиента через gdb, отправил отчёт об ошибке - следующая альфа версия клиента Telegram Desktop уже не имела проблем со звонками, баг пофиксили.

Но ведь утечки памяти из-за программных ошибок и слишком большой расход памяти возникают очень часто! Как с этим бороться? Читайте далее...

Почему при исчерпании памяти не срабатывает OOM Killer!?

Потому что по умолчанию параметр ядра vm.oom_kill_allocating_task=0 и вкупе с другими относящимися к нему параметрами в конфигурации по умолчанию он не срабатывает. Вернее срабатывает, но можно прождать целый час (или даже больше) когда дело наконец дойдёт до SIGKILL процесса с утечкой памяти. Всё это время сервер будет в состоянии глубокого фриза и не в состоянии отвечать ни на что кроме hard reset (т.е. физического рубильника). Для систем высокой доступности с высоким аптаймом такое не подходит - уничтожение процесса (чаще контейнера) или перезагрузка сервера должна происходить сразу, с автоматической маршрутизацией трафика, балансировкой и подхватом нагрузки резервными нодами кластера.

oom_kill_allocating_task

This enables or disables killing the OOM-triggering task in
out-of-memory situations.

If this is set to zero, the OOM killer will scan through the entire
tasklist and select a task based on heuristics to kill.  This normally
selects a rogue memory-hogging task that frees up a large amount of
memory when killed.

If this is set to non-zero, the OOM killer simply kills the task that
triggered the out-of-memory condition.  This avoids the expensive
tasklist scan.

If panic_on_oom is selected, it takes precedence over whatever value
is used in oom_kill_allocating_task.

The default value is 0.

Описание всех параметров и их возможные значения можно найти в документации:

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

https://www.kernel.org/doc/Documentation/sysctl/kernel.txt

По умолчанию в ванильных и кастомных сборках ядер (mainline, stable и longterm) для дистрибутивов Debian, Gentoo, Arch (остальные давно не использовал) параметры ядра установлены по умолчанию следующим образом:

vm.oom_kill_allocating_task=0
vm.oom_dump_tasks=1

vm.panic_on_oom=0
kernel.panic=0

vm.overcommit_kbytes=0
vm.overcommit_memory=0
vm.overcommit_ratio=50

Таким образом Out Of Memory (OOM) Killer по умолчанию настроен не оптимально и не срабатывает ожидаемо и гарантировано в нужный критический для системы момент. Также на механизм его работы было много жалоб на форумах Linux, после чего с версии 4.6 ядра он был несколько переработан.

https://github.com/torvalds/linux/blob/master/mm/oom_kill.c

https://www.kernel.org/doc/gorman/html/understand/understand016.html

Дело в том, что oom_kill() вызывается ядром в самую последнюю очередь, в самой крайней и самой критической ситуации нехватки системной памяти, когда не остаётся пространства для манёвра и ничего другого предпринять уже невозможно.

Для более раннего вызова OOM Killer в user space даже был создан внешний по отношению к ядру инструмент, резидентный демон (что конечно же не является абсолютным решением проблемы):
https://github.com/rfjakob/earlyoom

Системный вызов oom_kill() вызывается при частых запросах программы на выделение памяти при вызове функции malloc() стандартной библиотеки Си.

При vm.oom_kill_allocating_task=0 происходит постоянное сканирование списка процессов при системном вызове oom_kill(), что крайне неэффективно и дорого по накладным расходам.

Сработать успешно oom_kill() может только если ещё осталась свободная память, но вызывается в самый последний критический момент, когда память уже закончилась, в результате чего вызов oom_kill() при исчерпании свободной памяти, пытаясь выполнить сканирование процессов с перерасходом памяти для их завершения, зависает вместе с ядром и всей системой, происходит тотальный системный фриз, работа вызова продолжается крайне медленно, фактически в однозадачном режиме исполняется только oom_kill() и сопутствующие вызовы, с активным дисковым вводом-выводом в swap, начинается меденный дамп страниц в область подкачки (если она есть) и/или пометка страниц памяти на удаление из ОЗУ и вычищение страниц из swap раздела страничной подкачки памяти, очистка всех буферов ядра и только после, спустя достаточно длительное время, происходит вызов сигнала SIGKILL и уничтожение процесса израсходовавшего всю память.

Значение параметра vm.oom_kill_allocating_task=1 нормально работает если vm.overcommit_memory=2 и если подобрать экспериментально vm.overcommit_ratio (или vm.overcommit_kbytes) в зависимости от объёма доступной памяти и среднего размера memory footprint резидентных процессов в системе, т.к. значения этих параметров (порог использования памяти) складываются из суммы использованной процессом ОЗУ и памяти SWAP раздела (страничной подкачки), при учёте порога начала дампа в SWAP (если vm.swappiness установлен >=1).

На серверах дата-центра для развёртывания инфраструктуры сервисов и рабочих станциях коллег разработчиков была опробована следующая конфигурация параметров ядра:

sudo tee -a /etc/sysctl.d/10-failover.conf <<CONF
vm.swappiness=1

vm.oom_kill_allocating_task=1
vm.oom_dump_tasks=1

vm.overcommit_memory=2
vm.overcommit_ratio=90
CONF

Т.е. при превышении одним из процессов системы 90% (можно установить и 100%) занимаемой памяти (RAM и/или swap) он будет гарантировано принудительно завершён, о чём останется запись в системном журнале.

Пример проверки значений параметров ядра:

cat /proc/sys/vm/oom_kill_allocating_task
cat /proc/sys/kernel/panic

или

sysctl vm.oom_kill_allocating_task
sysctl kernel.panic

Пример временной установки (на время рабочей сессии до перезагрузки) значений параметров ядра:

echo 1 > /proc/sys/vm/oom_kill_allocating_task

или

sysctl -w vm.oom_kill_allocating_task=1

Для перезагрузки серверов, а также получения отладочной информации ядра о приложении при возникновении ситуации out of memory failure возможно использование параметра vm.panic_on_oom со значениями 1, 2 и 2+kdump.

Данная конфигурация обеспечила высокий uptime (>180 суток) для СХД (data warehouse), высокую отзывчивость и низкий отклик нод кластера в сервисной инфраструктуре (SOA), базирующейся на среде управления контейнерами - запуском сетевых распределённых приложений в контейнерах и управления их жизненным циклом работы.