dxdt.blog: занимательный интернет-журнал

В марте довольно много писали про новую атаку на SHA-256, “с обнаружением коллизий”. Вообще, тут нужно отделять академические атаки от практики, условно говоря, всяких биткойнов: в исходной работе (“New Records in Collision Attacks on SHA-2”, Li, Liu, Wang) речь идёт про академические атаки на урезанную “функцию сжатия” (см. ниже) из состава SHA-2 (SHA-256 – это разновидность SHA-2), да ещё и со специально подобранным предыдущим состоянием. Это общепринятый подход к исследованию стойкости хеш-функций, результат существенно лучше предыдущих достижений, но нужно учитывать, что он не обязательно приводит к практической атаке на полную хеш-функцию. В статье сказано именно про “практическую атаку”, это верно, однако это разная “практика”.

Возьмём в качестве примера SHA-256 и одну из практических (в академическом смысле) атак, представленных в упомянутой выше работе. Ядром схемы хеш-функции SHA-256 являются преобразования, соответствующие симметричному шифру. Повторно выполняемые раунды преобразований шифра, внутри хеш-функции, и образуют так называемую “функцию сжатия” – это важнейший элемент. Входной текст для преобразования в SHA-256 разбивается на блоки. Блок – это последовательность байтов, соответствующая разрядности функции, здесь – 256 бит или 32 байта. Блоки обрабатываются функцией сжатия, внутри которой выполняется заданное количество раундов – то есть, повторное применение одних и тех же преобразований, в цикле, к обрабатываемому блоку. Далее речь будет идти только про один блок, а не про полный входной текст.

После каждого раунда, блок, в результате применения преобразований, изменяется и потом снова подвергается тем же преобразованиям, которые опять изменяют блок. Эта комбинаторная часть позволяет добиться нужного разрежения для отображения входных блоков в выходные значения. Штатная схема SHA-256 использует 64 раунда в функции сжатия. Атака, о которой идёт речь, работает для 39 раундов (обратите внимание: с подобранным начальным состоянием – это очень важный момент).

Что это означает? Это означает, что исследователи нашли и предъявили кортеж из трёх конкретных значений (чисел или массивов байтов – как хотите), которые, будучи подставленными в урезанную до 39 раундов сжатия версию хеш-функции SHA-256, дают одинаковый результат. Одно из этих значений – это начальное состояние, устанавливаемое перед вызовом функции сжатия внутри урезанной SHA-256. То есть, при штатной реализации SHA-256 – этим состоянием либо был бы предыдущий обработанный блок, либо начальные константы из спецификации SHA-256. Два других упомянутых значения – это различающиеся в некоторых байтах входные блоки. Обработка этих блоков при указанных, весьма строгих, условиях – даёт коллизию. То есть, академическая “практическая” демонстрация, с конкретными числами. Это вполне себе строгий и разумный способ анализа стойкости преобразований. В данной науке это называется SFS-коллизия (от Semi-Free-Start). Но, опять же, очень далеко от демонстрации реальной, практической, “уничтожающей” коллизии SHA-256, то есть, демонстрации двух различных входных текстов, дающих одинаковый результат хеш-функции. (Что, конечно, не отменяет заметного продвижения.)

Сколько раундов для функции сжатия вообще важны? Важны все раунды, указанные в спецификации. Каждый раунд очень важен и блокирует атаки, успешные для урезанных вариантов. Раунды именно для этого и служат. Потому что, если значение хеш-функции изменяется даже только в результате последнего раунда, то на выходе всё равно получаются разные значения и, строго говоря, коллизии нет (но может быть “почти коллизия” и т.д.).

Естественно, обнаружение точек совпадения для уменьшенного количества раундов нередко даёт инструменты для взлома всей хеш-функции целиком. Именно поэтому академические атаки на примитивы с урезанным количеством раундов – важнейший инструмент. Однако, является ли тот факт, что коллизия найдена для более чем половины количества раундов, автоматической гарантией успешного применения того же метода к, предположим, половине оставшейся половины? Нет, совсем не является. Методы тут развиваются, так сказать, полностью “нелинейно”, так что непреодолимое вычислительное препятствие может возникнуть хоть бы и на каждом следующем раунде – потребуется полностью переделать метод атаки. Собственно, это очередное улучшение атак на SHA-2 как раз построено на новых методах, если сравнивать с теми методами, которые использовали для атак на MD5 и пр.

Конкретный пример, взятый из исходной работы: для 39 раундов SHA-256, при заданном начальном состоянии, получаются совпадающие значения для разных входных блоков (выдача программы, прилагаемой к работе):

431cadcd ce6893bb d6c9689a 334854e8 3baae1ab 038a195a ccf54a19 1c40606d
431cadcd ce6893bb d6c9689a 334854e8 3baae1ab 038a195a ccf54a19 1c40606d

Можно было бы предположить, что раз точка совпадения найдена, то и дальнейшие раунды дадут одинаковые результаты. Но это далеко не так – состояние хеш-функции шире, чем конкретный результат преобразования блока. Так, если в той же программе указать 42 раунда (всего на три раунда больше), то значения уже заметно разойдутся:

d33c0cff 17c9de13 21f528f0 3362e217 563f1779 521a1b9c df062e86 19fb5973 
105d6c34 43ceb0ad 120ba1a0 3362e217 d6dd86e0 7da567b5 cf1ca736 19fb5973

Это, ещё раз, никак не уменьшает ценности результата для 39 раундов, но показывает, что для полной SHA-256 всё, – пока что, – хорошо.

Криптографические хеш-функции отображают сообщения произвольной длины в блоки фиксированной длины, так что, математически, коллизии там есть по определению. Другое дело, что если хеш-функция хорошо отображает множество входных текстов в, скажем, 2^256 выходных значений, то о коллизиях “на полном переборе” можно не особенно задумываться: мало кто может создать и записать даже 2^128 текстов. Атаки с обнаружением точек совпадения в функции сжатия как раз, потенциально, выявляют дефекты отображения, которые могут позволить найти коллизии без необходимости полного перебора. А возможно, что и позволят найти способы решения гораздо более сложной задачи вычисления прообраза, – то есть, подбора входного текста по значению хеш-функции.

Некоторые избранные записки, опубликованные в марте 2024 года:

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

Варп и квантовые компьютеры – необычная записка о борелевском шамане, который выигрывает у теоретического квантового компьютера с теоретическим алгоритмом Шора потому, что шаман лучше слышит ритм.

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

Спутниковый радар Umbra – пример, – в картинках, – работы системы радаров, находящихся на низкоорбитальных спутниках.

Архитектура микропроцессоров и изоляция уровней исполнения – простой конвейерный “префетчер” команд использовался ещё в микропроцессоре Intel 8086, однако для “уязвимостей” типа Metdown/Spectre требуется ещё два шага: “префетчер” должен получить ветвящуюся логику, управляемую теми же кодами команд, которые “префетчер” обрабатывает, а для процессора в целом должно быть декларировано аппаратное разделение многих исполняемых потоков команд на базе общих для этих потоков элементов аппаратуры.

Воскресное чтение манускриптов. Ну или не столько чтение, сколько рассматривание чертежей. В этот раз – продолжение манускрипта Vat.gr 1164, который уже упоминался в записке про баллисту инженера-конструктора Герона. На скриншоте ниже – фрагмент из труда “Полиоркетика” Аполлодора Дамасского. Да, в одну книгу, формируемую библиотекарями скрипториев, входили разные труды разных авторов (Герона и Аполлодора, например), нередко, в формате, так сказать, хрестоматии. Тут почти целую страницу занимает схема атаки отдельной круглой крепостной башни при помощи некоторой “огневой машины”.

Как объясняется в тексте, предшествующем чертежу, машина использует угольную топку и меха для создания огня, а двойную железную (наверное, стальную) трубу – для доставки этого огня на атакуемую стену, всё с целью “расшатывания” каменной кладки. Насколько подобный метод был реализуем и, в случае успешной реализации, эффективен – судить довольно трудно.

Касательно свежей истории с обнаружением закладки/бэкдора (CVE-2024-3094) в пакете xz (liblzma), которая на системах с systemd/glibc, потенциально, протягивалась в sshd: понятно, что такого может быть ещё много в уже массово используемых библиотеках, но всё равно это весьма неплохая и практическая демонстрация того, что подобное удаётся быстро обнаружить силами сообщества. По этой теме я не так давно писал, что, во-первых, добавление закладок и прочего вредоносного кода – это совсем не какая-то особенность Open Source; во-вторых – доступность исходников связана с возможностями по добавлению и обнаружению вредоносного кода, но вовсе не так прямо, как часто говорят и пишут.

В продолжение предыдущей записки. Различные “аппаратурные” атаки, типа разновидностей Spectre/Meltdown, которые преодолевают механизмы разграничения доступа современных процессоров, имеют интересную связь с концепцией “диагонализации”: то есть, такие атаки всегда возможны, если только процессор пытается оптимизировать использование вычислительных ресурсов достаточно сложным способом. Под “достаточно сложным” тут подразумевается наличие механизмов вида “предикторов” (упреждающего анализа потока команд), задействованных на уровне над “межпотоковым” взаимодействием.

Вообще, в x86 “префетчинг” (предварительное извлечение) кодов команд появился ещё в микропроцессоре 8086. Но тогда соответствующая схема считалась просто конвейером команд. Это был отдельный компонент, со своими регистрами и системой счётчиков, который асинхронно считывал коды команд с внешней шины, когда та была свободна, что существенно ускоряло работу процессора. Понятно, что в 8086 не было ни каких-то особых механизмов аппаратного разграничения потоков команд и адресного пространства, ни обособленных полноценных ядер, исполняющих код, так что и проблем с побочными эффектами от работы схем конвейера тоже быть ещё не могло. Однако состояние этого конвейера, вмещавшего всего несколько кодов (четыре 8-битных регистра), изменяло состояние процессора вне зависимости от исполняемой основным “протоядром” команды, поскольку конвейер содержал пару указателей, несколько флагов и т.д. Впрочем, технические детали устройства исторического микропроцессора тут не важны – важно, что, во-первых, этот простой конвейер работал только на уровне последовательности кодов команд (не со свойствами самих команд); во-вторых, не было потоков и общих элементов, совместно используемых этими потоками.

Отличие “уязвимых” схем современных процессоров в том, что здесь добавляется новый уровень – те самые “предикторы”, оснащённые логикой, которая учитывает уже не порядок кодов команд, а свойства этих команд и состояние процессора, а кроме того, добавляются общие для нескольких потоков элементы (схемы кэширования и пр.) на работу которых прямо влияют предикторы. И, конечно, возникает аппаратное разграничение доступа, которое и предлагается преодолевать при помощи атак, использующих аппаратные уязвимости.

Базовая логика таких атак – использование “оракулов”, сигналы которых пробивают границы, устанавливаемые (формально) аппаратной архитектурой процессора для фрагментов программного кода. Тут нужно учитывать, что границы эти только декларируются, а в реальности – сигналы через них проходят (иначе тут не было бы предмета), потому что процессору необходимо оптимизировать исполнение кода и доступ к памяти. Эти сигналы обязательно будут возникать именно потому, что в процессоре появился уровень, исполняющий “программу над программой”: упреждающий анализ команд работает по собственной программе (пусть и записанной непосредственно в аппаратуре); эта программа не только использует все потоки и фрагменты кода в качестве входных данных, но и влияет на состояние общих для изолируемых фрагментов кода элементов (кэш и очереди команд). То есть, схема аппаратной оптимизации тут всегда будет сквозной, можно сказать, что неустранимой. Вопрос в том, нужно ли считать такую архитектурную черту уязвимостью. Получается, что общая программа смотрит на команды в разных потоках и переключает состояние общих элементов, чтобы оптимизировать процесс. Изолируемые процессы находят способ измерения времени переключения состояний и – строится очередная уязвимость.

Если попробовать бороться с возникающими по описанным только что принципам сигналами, но попытаться сохранять общие элементы процессора, то каждый новый слой просто будет приводить к появлению более хитрых способов измерения: многими “атакующими” потоками, по накопленной статистике, ещё как-то. Если в архитектуру процессора, предположим, введут некоторое зашумление переключений кеша и предикторов, то носителем сигнала окажется схема, реализующая зашумление. Всякое подобное усложнение, добавление новых уровней, приводит к тому, что появляются и носители новых сигналов (это и есть “диагонализация”). При этом защита от “уязвимостей” программными методами, снижающими общее быстродействие, выглядит несколько странно, потому что предлагается прилагать дополнительные усилия для создания затруднений в работе оптимизирующих схем, которые и в процессоре уже встроены (то есть, потрачена площадь подложки и элементарные логические узлы), и само ПО при этом всё равно работает на общей аппаратуре.

Радикальное решение предполагает либо полную и точную аппаратную изоляцию уровней и ядер, когда все компоненты продублированы и работают независимо, либо полную замену системы команд (не стоит списывать со счетов, что в x86 уже и некоторые отдельные команды обладают тьюринг-полной реализацией). Однако это противоречит самой идее аппаратурной оптимизации на границе между логическим представлением команд процессора и машинным микрокодом. Да и приведёт внедрение таких методов только к тому, что очередной “пробой изоляции” между потоками выявят на стороне шин и контроллеров, взаимодействующих с ОЗУ и периферийными устройствами.

Почему-то много где громко пишут, что “обнаружена критическая неустранимая уязвимость процессоров Apple M1, раскрывающая криптографические ключи”, при этом имеется в виду новая “брендированная” атака Gofetch. Вообще, если почитать исходную работу, то речь там об очередном аппаратном “оракуле”, который использует, – опять же, очередной, – оптимизирующий компонент процессора: DMP (Data Memory-dependent Prefetcher), направленный на опережающее извлечение данных из памяти на основе косвенных “указателей” – то есть, значений, которые процессор считает записью адреса данных. Это популярное направление. Очень давно известно, что всякий подобный упреждающий механизм исполнения команд или извлечения данных порождает как минимум два побочных канала утечек (по записи и по чтению).

Подход Gofetch использует измеримые локально отличия в обработке тех “указателей”, которые схемы DMP смогли интерпретировать как “полезные” (то есть, показывающие на подходящие для упреждающего извлечения области адресного пространства), и “указателей”, которые получили статус “недоступных”. Это, конечно, выглядит занятно. Но нужно всё же учитывать и прочие параметры. Так, для успешного вычисления секретных ключей, атака должна проводиться из соседнего процесса и требует прямых вызовов функций атакуемого ПО. То есть программа уже должна работать в той же системе, на том же процессоре, где исполняется и полностью программный атакуемый “криптопровайдер”. Более того, атака требует штатного взаимодействия атакующей программы с этим “криптопровайдером” в течение длительного времени (ну и чтобы никакой другой процесс не помешал). Сложно придумать сценарий, где такая конфигурация будет действительно “неустранимой”.

В свежих версиях веб-сервера Nginx есть полезная (и довольно экзотическая) опция для настройки TLS: ssl_reject_handshake (on | off), о которой, оказывается, мало кто знает. Опция позволяет управлять прерыванием процесса установления TLS-соединения (“хендшейка”) на стороне сервера. С помощью “ssl_reject_handshake on;” можно отклонить TLS-соединение, если в клиентском ClientHello указано имя хоста (поле SNI), которого нет на стороне сервера.

Почему это удобно. Штатная работа веб-сервера по HTTPS подразумевает, что при установлении TLS-соединения клиент передаёт имя хоста, соответствующее DNS-имени веб-узла; например, для https://test.ru/ это будет test.ru. Однако никто не запрещает клиенту обратиться с другим именем хоста в SNI. Более того, на тот же самый IP-адрес, который соответствует веб-узлу под именем test.ru, может быть направлено другое DNS-имя (другой домен). Веб-браузеры, обращающиеся по такому имени, будут указывать его в SNI, а сервер, при прочих равных, не сможет найти не только соответствующий “виртуальный хост” в конфигурации, но и подобрать корректный TLS-сертификат. Однако какой-то TLS-сертификат для установления TLS-соединения серверу нужен и, без дополнительных мер, это приводит к тому, что сервер отвечает с “первым попавшимся” (буквально) серверным TLS-сертификатом из сконфигурированных.

Если на сервере всего один виртуальный хост/веб-узел (или настроены отдельные IP-адреса для отдельных веб-узлов), то ничего нового клиент не узнаёт. Однако если виртуальных хостов много, то ответ с произвольным сертификатом приводит к нежелательным утечкам имён: клиент получит сертификат, в котором будет указано имя другого сервиса, доступного на этом же узле (или несколько имён). Администраторы и даже DevOps об этом постоянно забывают.

Сделать тут что-то корректное на уровне HTTP невозможно в принципе, так как TLS-соединение устанавливается раньше, а для каждого HTTP-ответа (403 и пр.) потребуется подходящий по имени доверенный сертификат. Да, возможны различные “костыли”, вроде использования заведомо несовпадающего сертификата-заглушки, но все они подразумевают некорректный ответ.

Указание “ssl_reject_handshake on;” для default_server (для имени хоста по умолчанию) позволяет побороть только что описанную проблему: Nginx будет прерывать именно TLS-соединение, если клиент обращается с неверным именем хоста в SNI – это, что называется, технически строгий способ. Браузер, в таком случае, выведет сообщение о недоступности узла, а не предупреждение о несовпадении имён, которое пользователи привыкли преодолевать при помощи кнопки “Всё равно продолжить”.

Объяснение, что “кубит находится одновременно в двух состояниях” – не слишком хорошее. Гораздо лучше говорить, что состояние кубита, взятое “в нулях и единицах”, не определено до момента измерения. Изменение распределения этой неопределённости при помощи преобразований конфигурации системы, с учётом будущих и потенциально возможных измерений, как раз и составляет теоретическую полезность квантовых вычислений. То есть, нет “нулей”, нет “единиц” – есть взаимодействующие неопределённости и теоретические алгоритмы, сужающие конфигурацию пространств вариантов, доступных на границах, по которым происходит взаимодействие (квантовое преобразование Фурье, предположим).

Воскресное чтение манускриптов. Известно, что в Древней Греции не только знали, что Земля круглая (это более или менее очевидно), но и сумели определить радиус Земли (что уже требует астрономических познаний). Вообще, предположение, будто древние были уверены, что Земля плоская, встречается сейчас гораздо реже неверного мнения о физических представлениях Аристотеля и падении тел, но встречается всё равно. Между тем, построение на основе наблюдений окружающей действительности “минимально непротиворечивой” модели, в которой Земля, тем не менее, плоская, заметно сложнее, чем вариант с шаром или сферой, который более или менее напрашивается, если некоторое время следить за движением небесных явлений и светил.

Ниже приведён скриншот манускрипта конца 13 века (Adv.MS.18.7.15, древнегреческий) из коллекции Национальной библиотеки Шотландии (в коей библиотеке электронные архивы, как и дистанционный доступ к ним, пока что сохраняются). Фрагмент, на минуточку, относится к переписанной грамматиком Планудом (скорее всего) работе философа Клеомеда, в которой пересказан метод определения периметра большого круга Земли (длины меридиана), использованный древним греком Эратосфеном. Плануд переписал труд Клеомеда в 13 веке (результат – на скриншоте), а исходный труд Клеомеда, как предполагается, относится к периоду с первого по четвёртый век н. э., а вот сам Эратосфен выполнял описанные геометрические расчёты на рубеже третьего и второго веков до н.э. То есть, тут, примерно, полторы тысячи лет, в ходе которых Земля описывается как круглая (круглая Земля, заметьте, тоже может перевозиться большой черепахой, но это другая история).

Занятно, что на этой странице манускрипта дан чертёж, иллюстрирующий метод Эратосфена. Метод этот, как видно из чертежа и описания, состоял в измерении длины тени гномона и углов падения солнечных лучей в двух точках одного меридиана – в городах Сиене и Александрии, – в период летнего солнцестояния. Так как город Сиена находится на Северном тропике, то здесь в полдень, при летнем солнцестоянии, правильно установленный гномон не отбрасывает тени (потому что Солнце в зените), а в Александрии – тень у гномона есть. Предположив, что солнечные лучи параллельны, взяв расстояние между двумя городами и длину тени александрийского гномона, можно вычислить периметр окружности Земли с помощью планиметрии, как и продемонстрировано на чертеже (Земля на чертеже внизу).

Исходя из расстояния от Сиены до Александрии (по большому кругу) в 5000 стадиев, Эратосфен определил общую длину меридиана в 250 000 стадиев – соответствующая строка манускрипта выделена зелёными метками (середина скриншота): “ὁ ἄρα σύμπας κύκλος γίνεται μυριάδων εἴκοσι πέντε” – так будет в современной типографике, но в манускрипте записано с кучей скорописных сокращений (и прочих “смайликов”), поэтому на современные начертания букв не очень-то похоже. Само число, кстати, указано как двадцать пять мириад (μυριάδων, двадцать – εἴκοσι, пять – πέντε). Двадцать пять мириад стадиев, – то есть, примерно, от 44 до 52 тыс. км, – неплохо соответствует современным оценкам в сорок тысяч километров.

“Коммерческий поставщик спутникового наблюдения” Umbra недавно сообщил, что там начали вводить в строй систему бистатической радиолокации с синтезированием апертуры на базе нескольких низкоорбитальных спутников. По ссылке есть пример снимка, этот же пример – рассматривается ниже. Вообще, речь про специализированный радар сантиметрового диапазона, а синтезирование апертуры и согласованная вычислительная обработка данных позволяют сильно улучшить показатели: разрешающую способность, обнаружение движущихся целей и пр. Сейчас спутников в этом проекте, как пишут, запущено всего восемь, два самых новых как раз и обеспечивают базу для бистатической радиолокации. Поддержку оказывает DARPA.

Понятно, что результат радара – это далеко не цветная картинка, полученная телескопом для публикации в Google Earth (см. наложение ниже). Но у радара целый ряд преимуществ, тем более, если речь идёт об орбитальной радиолокации с разнесением передатчика и приёмника. Такой орбитальный радар видит ночную часть земной поверхности, может просвечивать не только сквозь облака, но и через некоторые наземные укрытия; зондирующий радиосигнал с высокой разрешающей способностью позволяет отличать макеты техники от настоящей техники и, в теории, может даже извлекать сведения о подземных коммуникациях (находящихся на небольшой глубине в подходящих почвах) и обнаруживать подвижные субмарины в подводном положении (по спутному следу). Спутники Umbra находятся на высоте около 550 км (450 – 600 км), а низкая орбита тоже приносит свои преимущества, даже по сравнению с самолётами. (Но, например, на радарной картинке не видна надпись, нанесённая на основание плотины с иллюстрации ниже.)

В качестве иллюстрации работы бистатической радиолокации Umbra публикует изображение дамбы большой ГЭС в Пакистане.

Общий вид:

(Cпутниковый радар Umbra.)

Выделен фрагмент, который ниже дан с увеличением до “пиксел в пиксел”:

(Umbra.)

Фрагмент с большим разрешением

(Umbra.)

Примерное наложение на снимок, доступный в Google Earth:

Занятно, что совпадает почти вся техника, выставленная во дворе (Umbra/Google). От Umbra, кстати, есть немало данных в открытом доступе.

Современные компиляторы хорошо умеют оптимизировать машинный код и обычно делают это гораздо лучше разработчика. Но нужно учитывать тот факт, что программа на некотором языке высокого уровня (ЯВУ) – это не алгоритм, а только запись алгоритма. Соответственно, компилятору принципиально доступны лишь структуры, нашедшие отражение непосредственно в записи, но не сам алгоритм. Один и тот же алгоритм вообще можно записать многими способами и на разных языках. Так что компилятор, в процессе перевода с входного ЯВУ на машинный язык, оптимизирует языковые конструкции. Компилятор не видит алгоритм и не может его оптимизировать. Разработчик, в теории, способен оптимизировать именно алгоритм, это следует из того, что разработчик как раз “переводит” (записывает) алгоритм на ЯВУ (но, конечно, лишь в том случае, если код пишется не силами очередного ИИ/LLM/ChatGPT, выстраивающего “токены” в псевдомарковскую цепь). Поэтому иногда нужен ассемблер.

Есть хрестоматийный “обратный” пример, иллюстрирующий ситуацию обработки структур, которые образует запись алгоритма – “схлопывание” циклов: оптимизирующий компилятор обнаруживает, что промежуточный результат шагов циклического выполнения команд, записанного в программе, не используется, поэтому просто выкидывает цикл, схлопнув структуру, вся внутренняя сложность которой оказалась сводимой к прямому подключению ввода к выводу. Тексты программ не несут смысла сами по себе, а в этом случае за записью программы, как выясняется, стояли разные “алгоритмы”. Разработчик хотел измерить производительность некоторой реализации функции, вызывая её много раз в цикле; а компилятор стремился уменьшить время выполнения программы – количество шагов, приводящее к достижению результата: как говорится, если результат тот же, то зачем тратить больше вызовов?

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

С другой стороны, использование ассемблера вовсе не исключает эффект от “фокусов оптимизации” современных “больших” процессоров (amd64 и пр.): видимые снаружи такты, записанные за выполнением конкретной операции, не обязательно соответствуют реальным тактам – тут накладывается не только параллельное исполнение (его ещё и может быть несколько уровней), но и возможное “предварительное” выполнение, предсказание ветвлений и так далее. Однако ассемблер всё же ближе к аппаратуре, поэтому в целом ряде случаев позволяет сильно повысить именно алгоритмическую точность описания, а не языковое удобство, как в ЯВУ. Типичный пример – использование длинных регистров. Но многое зависит от конкретной ситуации – современный компилятор очень часто генерирует код не хуже, чем написал бы на ассемблере опытный разработчик. Особенно, если учитывать необходимый контроль, которым принято обставлять сложный код для повышения его надёжности: контроль обращений к памяти, адресные таблицы и так далее.