Assembly Hall of Shame: рейтинг самых медленных ассемблерных инструкций¶
7.0/10
На GitHub опубликован проект Assembly Hall of Shame — рейтинг необычно медленных или патологических ассемблерных инструкций. Проект задуман как любопытная таблица лидеров и одновременно площадка для обсуждения микроархитектуры CPU, трэпов, эмуляции и низкоуровневого поведения систем. В правилах указано, что для трэпнутых, эмулируемых или виртуализированных инструкций разрешено измерять только время трэпа, а не обработчика. Участники обсуждения отмечают, что некоторые результаты, например запись в порт ACPI IO за 12 мс, вероятно, связаны с переходом в SMM и обработкой там. Проект интересен прежде всего системным инженерам и разработчикам, работающим на уровне инструкций, прерываний и аппаратных взаимодействий.
Контекст¶
Assembly Hall of Shame — это GitHub-репозиторий и таблица лидеров, созданная исследователем безопасности Кристофером Домасом (xoreaxeaxeax), где вместо оптимизации скорости ищут самые медленные одноинструкционные сценарии на x86. Проект инвертирует обычный анализ задержек инструкций: цель состоит в том, чтобы найти абсолютный нижний предел производительности одной инструкции, включая необычные или патологические случаи.
Значение¶
Проект помогает разработчикам лучше понимать крайние случаи производительности и скрытые издержки трэпов, SMM и механизмов виртуализации на уровне отдельных инструкций.
Обсуждение¶
Комментаторы обсуждают связанные проекты, включая использование медленных инструкций для нарушения работы SMI. Также упоминаются потенциально бесконечные шинные циклы, трэпы в таблицах страниц x86 и вопросы интерпретации правил для трэпнутых инструкций.
Проверка фактов¶
Утверждение комментария о связанном проекте `smiiiiiiiiiiiiiiii`, использующем медленные инструкции для влияния на обработку SMI, подтверждается: репозиторий действительно существует и описывает удержание ядра вне SMM с помощью длинной инструкции [tool-2-1, tool-2-3]. Упоминание конкретной платформы Zen 3 Ryzen 7 5800H как примера для медленной `vmovdqu` также подтверждается README проекта. Более широкие утверждения из комментариев о произвольно длинных шинных циклах MC68000 и возможности зацикливания через page-table faults не проверялись независимыми источниками в рамках данного материала.