Итоги года для Rust Community.

Подведение итогов этого года работы над развитием экосистемы Rust и Rust Community в официальном блоге.

https://blog.rust-lang.org/2017/12/21/rust-in-2017.html

Меня часто читатели спрашивают о списке рекомендуемой литературы для постижения #Rust — в блог-посте перечислены три очень годных вышедших на данный момент книги по языку Rust и его концепциям, первые две из которых я читал и очень рекомендую к прочтению:

https://www.nostarch.com/rust - более практическая книга от Стива Клабника, подобна самоучителю, на основе Rust Book, https://doc.rust-lang.org/book/second-edition/ почти то же самое 😉

http://shop.oreilly.com/product/0636920040385.do

https://www.manning.com/books/rust-in-action

Dynamic analysis for static typing in Python!

Недавно инженеры Instagram открыли исходный код типизатора MonkeyType — инструмента для динамического run-time анализа программ на Python и автоматизации внедрения статических аннотаций типов в исходниках на Python, с использованием gradual typing расширения mypy (PEP-484) для интерпретатора CPython.
Статические аннотации типов и постепенная типизация (gradual typing) в динамических языках повышают надёжность и предсказуемость поведения программы во время исполнения, уменьшают количество run-time ошибок и исключительных ситуаций, необходимых тестов для их покрытия и выявления, а также повышают быстродействие приложений, т.к. во время исполнения (in run-time) программы уже не производится динамический вывод (type inference), проверка (type matching), диспетчеризация (dynamic dispatching) и связывание (type linkng) типов, что не вызывает задержек проверки типов по времени исполнения кода, а только сокращает их и таким образом ощутимо повышает производительность и скорость исполнения кода приложения.

https://engineering.instagram.com/let-your-code-type-hint-itself-introducing-open-source-monkeytype-a855c7284881

https://github.com/Instagram/MonkeyType

#Python

Ссылки на материалы по теме:
О CPython+Mypy, постепенной типизации (gradual typing) и source maping отладке run-time исключений с применением Sentry:
https://t.me/technologique/1124
https://t.me/technologique/1125
https://t.me/technologique/155

https://www.python.org/dev/peps/pep-0484/
https://github.com/python/mypy

Оптимизация критических участков проектов на Python с помощью Rust:
https://t.me/technologique/1123
https://t.me/technologique/1153

​​Популярность языков программирования за 2017 год.

Данные популярности языков программирования за 2017 год по уровню контрибуции/вклада разработчиков на разных языках в кодовую базу репозиториев на хостинг-сервисе открытых проектов GitHub.

Уровень контрибуции (contribution rate) рассчитывается сервисом Krihelimeter на основе данных о частоте и объёме коммитов кода на различных языках программирования в репозитории проектов на хостинге GitHub.

Визуальное графическое представление данных - https://plot.ly/~andrcmdr/5.embed

Полная диаграмма - https://plot.ly/~andrcmdr/5/#plot

Исходные данные:
https://plot.ly/~andrcmdr/5/#data

https://plot.ly/~andrcmdr/4/#data
https://plot.ly/~andrcmdr/4.embed

Предыдущие публикации:
https://t.me/technologique/1122

С наступающим Новым годом друзья! Желаем Вам отлично встретить Новый год в кругу близких и друзей!

Пусть в Новом году технологии помогают Вам в повседневной жизни, облегчают и делают её более комфортной!

#NewYearsEve

Счастливого Нового Года друзья! ☃️🎄🎁🍊🥂🍾🎉🎊

2018 is actually came!

TDLib - официальная библиотека для создания клиентских приложений от Telegram.

Telegram выпустил официально кросс-платформенную библиотеку для создания клиентсикх приложений и взаимодействия с серверной частью мессенджера по протоколу MTProto 2.0 (обеспечивается полная поддержка протокола).

https://github.com/tdlib/td
https://core.telegram.org/tdlib

Документация:
https://core.telegram.org/tdlib/docs/

Библиотека кроссплатформенная и достаточно просто компилируется практически для любой платформы и ОС, и таким образом пригодна для создания клиентов для любых платформ.

Библиотека реализована на C++, но есть интерфейсы для возможности её использования в других языках (Java, интерфейс с JNI/JNA, и С#, через поддержку C++/CLI в .Net).
В Python скриптах функции библиотеки очень просто использовать через ctypes или cffi модули поддержки FFI в языке.
Для совсем не поддерживаемых официально языков есть интерфейс для обмена данными в формате JSON (JSON-RPC).

Для многопоточной неблокирующей (асинхронной) обработки ввода-вывода TDLib использует собственную реализацию библиотеки акторов для работы с тред-пулами (thread-pools) — https://github.com/arseny30/tdactor

Акторная модель многопоточности для многопоточной асинхронной обработки ввода-вывода и нативная компиляция, используемые в реализации бибилотеки, также обеспечивают очень высокое выстродействие при обработке API вызовов — заявляется, что библиотека TDLib уже давно используется в продакшн сервер-сайде Telegram для поддержки BotAPI и обработки ввода-вывода при взаимодествии с ботами, при этом каждый инстанс серверного приложения для поддержки BotAPI, использующий TDLib поддерживает взаиможействие с 18000 ботов одновременно, что говорит о весьма хорошем масштабировании приложений по нагрузке при использовании библиотеки и о грамотных решениях (actor-based concurrency), заложенных в её дизайн.

In the Telegram Bot API, each TDLib instance handles more than 18000 active bots simultaneously.

https://github.com/tdlib/td/tree/master/tdactor
https://github.com/tdlib/td/tree/master/benchmark
https://github.com/tdlib/td/blob/master/benchmark/bench_actor.cpp

Links:
https://t.me/technologique/1197

Meltdown & Spectre.

Опубликована информация по некорректной работе процессоров Intel, приведшей к двум критическим уязвимостям, касающимся особенностей аппаратной реализации в процессоре защиты страниц памяти ядра и приложений (Meltdown), её поддержки ядрами современных ОС (главным образом Linux и Windows), а также работы процессорного конвейера (pipeline) и спекулятивного предсказания инструкций при переходах и ветвлении кода (Spectre).

Уязвимы процессоры выпускавшиеся последние 10 лет, начиная с поколений архитектур Nehalem и Sandy Bridge.

https://www.youtube.com/watch?v=bReA1dvGJ6Y

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

https://lwn.net/Articles/738975/

Атака эксплуатирующая уязвимость Meltdown позволяет в непривелегированном режиме читать данные из адресного пространства ядра, вынесенные в user space memory, а также возможна запись кода в данные области памяти с последующим их исполнением в привелегированном режиме работы ядра.

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

Информация о возможности проведения атак, эксплуатирующих данные уязвимости, впервые появилась и была подтверждена экспериментально в середине декабря прошедшего года.

Однако первая эксплуатация была проведена 1.5 года назад и отчёт по данным уязвимостям был сдан в Intel ещё в июне 2016 года.

Для предотвращения атаки Meltdown в Linux возможно применение двух уже вышедших и включенных в ядро патчей - KAISER и kernel address space layout randomization (KASLR).

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

На данный момент разработчики ядра Linux, патча KAISER и патч-сета GRSecutiry ведут разработку патча Kernel Page Table Isolation (KPTI) на базе патча KAISER.

Описание уязвимости:
https://meltdownattack.com и https://spectreattack.com (доменные псевдонимы одного и того же сайта)

https://meltdownattack.com/meltdown.pdf

https://spectreattack.com/spectre.pdf

http://www.opennet.ru/opennews/art.shtml?num=47849

#security

See also:
https://t.me/technologique/709
https://t.me/technologique/710

https://t.me/technologique/964
https://t.me/technologique/999
https://t.me/technologique/1004

Кто кодил на мнемонике ассемблера 80x386/586/686 знает, что при передаче инструкций и указателей на конвейер в процессорах Intel они никак не проверяются (просто либо исполняются либо возвращается исключение, либо происходит остановка конвейера, операция Halt) — проблема давняя и уходит глубоко корнями в историю.
Сейчас процессорами проверяется только пометка страниц памяти NX битом неисполнения и контекст управляющих контрольных регистров (CR), при восстановлении контекста исполнения кода содержащегося в странице памяти. При этом не все ядра используют весь блок регистров CR и не все кольца привелегий (всего 4, от 0 до 3 в числовом представлении регистра), задаваемые регистром CR0, в т.ч. ядро Linux и ядро Windows, которые используют только два кольца, ring0 для адресного пространства памяти с привелегиями ядра (модулей ядра, драйверов и некоторых резидентных демонов) и ring3 для остальных пользовательских приложений, что во многом обусловлено требованием переносимости ядер на другие аппаратные процессорные архитектуры.
Кольца привелегий были введены впервые программно в ОС Multics, предшественнице Unix, разработанной также в Bell Labs в 1960-x годах. Ядро Multics поддерживало программно 64 кольца (http://www.multicians.org/mgr.html#ring, http://www.multicians.org/protection.html), но аппаратно железо того времени поддерживало только 8 колец.

Для создания более безопасного окружения для исполнения приложений сборка ядра Linux должна быть с поддержкой nx-bit и security модулями (SELinux, AppArmor), и патч-сетом grsecurity (включая патч PaX).
В этом случае для создания безопасного окружения приложений лучше использовать специализированные дистрибутивы, например микро-дистрибутив Alpine Linux (лучше дополнительно в Docker контейнере), сборки ядра которого содержат данные патчи.

Патч ядра Linux GRSecuruty позволяет выполнять в ядре более строгие проверки привелегий и страниц памяти, чтения/записи данных, исполнения кода, но в корне не решает проблему.

В процессорах AMD, при исполнении кода в конвейере, спекулятивном эвристическом предсказании переходов для оптимизации циклов, трансляции адресов памяти через TLB кэш, инструкции и указатели проверяются и исполняются согласно уровню привелегий и контексту безопасности управляющих регистров, поэтому архитектурных проблем в процессорах AMD нет — https://lkml.org/lkml/2017/12/27/2

Удивительно, что до реализации поддержки всех аппаратных возможностей контроля безопасности при исполнении кода, которые предоставляют современные процессоры и аппаратные архитектуры, в реализации ядер ОС дошли только сейчас.

Многие IT издания и СМИ пишут о данных уязвимостях как исключительно аппаратных, ставя в вину Intel и нанося ущерб репутации компании, и при том не разделяя особенности аппаратной реализации и её программную поддержку со стороны ядер ОС и не вникая в суть проблемы, т.е. практически все СМИ пишут только об аппаратной архитектурной проблеме, но никто не акцентирует внимания на программной поддержке средств безопасности, предоставляемых современными процессорными аппаратными архитектурами, уровнях/кольцах привелегий, контексте безопасности при сохранении/восстановлении состояния регистров при исполнении кода, пометке страниц памяти и защите сегментов памяти от записи/изменения кода или исполнения данных в них.
Это вызвало уже ответную реакцию и критику со стороны самой Intel - https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Meltdown и Spectre это лишь названия, две грани одной давней проблемы, огреха в дизайне железа при его проектировании и производстве, за которыми по сути стоит одна и та же проблема контроля привилегий при упреждающей (с предсказанием переходов/возвратов) обработке инструкций в конвейере суперскалярной архитектуры соверменных процессоров (параллелизм выполнения на уровне инструкций).

На данный момент опубликованы лишь уязвимости с возможностями чтения привилегированной памяти ядра из непривилегированного режима исполнения пользовательского кода приложений:
Spectre:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753
https://nvd.nist.gov/vuln/detail/CVE-2017-5715
https://nvd.nist.gov/vuln/detail/CVE-2017-5753
Meltdown (тайминг атака, через анализ кэша данных, https://habrahabr.ru/post/346078/):
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754
https://nvd.nist.gov/vuln/detail/CVE-2017-5754

https://support.f5.com/csp/article/K91229003

Если посмотреть на время попадания (не публикации!) уязвимостей в базу MITRE - 20170201 - становятся вполне оправданной информация, что первая эксплуатация была проведена 1.5 года назад и отчёт по данным уязвимостям был сдан в Intel ещё в июне 2016 года.

Но есть ещё более глубокая проблема в дизайне cуперскалярной архитектуры Intel - injection through the return predictor.

В документации (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 для рандомизации частей адресного пространства ядра при запуске системы и программных процессов, который усложняет поиск адресов кода и данных относящихся к адресному пространству ядра системы.