Hacker News Digest

Платформенный процессор, система управления режимом SMM, C6‑DRAM и микрокод процессора можно «разблокировать», перепрограммируя переводы физических адресов DRAM.
skitter-creek-bath-salts вмешивается в нижние уровни иерархии памяти, переписывая регистры контроллера DRAM, чтобы любой виртуальный адрес *p мог указывать в произвольное место физической памяти. При разрушении адресных преобразований исчезают и защита, построенная на них: SEV, SGX, TDX, TrustZone, pKVM, CoVE, SMRAM и даже скрытые регионы PSP и ME становятся доступными.

Эксперимент проведён на процессорах AMD Family 16h, где документация раскрывает регистры переводов, позволяющие менять маппинг без блокировки. Техника универсальна: схожие схемы переплетения, перемешивания и переключения используют все современные контроллеры памяти — от x86 до ARM и RISC‑V. Таким образом, «разблокировка» DRAM открывает путь к новым атакам и исследованиям, показывая, что даже самые защищённые области DRAM можно обойти, если знать, как «перепутать» их адресацию.

Тред обсуждает потенциальные последствия и ограничения эксплуатации подобных атак. Эксперты расходятся во мнениях: одни считают, что атаки могут обходить традиционные механизмы безопасности, другие — что современные системы уже их предотвращают. По опыту @zahlman, атаки возможны лишь при наличии root-доступа. @creshal утверждает, что они позволяют получить доступ к ранее недоступным областям системы. Эксперты советуют ограничивать доступ к таким возможностям только владельцам систем и действовать с осторожностью, учитывая риски для безопасности.

Основная идея — полностью эмулированная графическая среда, работающая на реальном IBM PC XT с процессором 8088, где каждый запущенный элемент (окно, панель, мини‑приложение) представляет отдельный процесс, имеет собственный док‑тик и независимый буфер памяти. При этом ядро управляет прерывками, планированием и выделением сегментов так, что даже простые программы, как MINES (1,5 КБ) или HELLO, загружаются в собственные 2 КБ и 512‑байтные области без модификации кода.

Особенности, которые запоминаются: одновременная работа до пяти программ, включая «живой» About‑box, отображающий состояние планировщика, и плавный XOR‑трекинг курсора при перемещении окна; минимизация не останавливает фоновые задачи, а лишь скрывает их визуализацию; иконки файлов берутся непосредственно из первого сектора диска, а графические редакторы (Paint, Fractal) используют буферы и кольцевые истории, позволяющие выполнять фоновые операции, пока запущены ресурсоёмкие приложения. Всё это демонстрирует, как ограниченные ресурсы IBM PC XT могут поддерживать современный‑по‑удобству пользовательский интерфейс.

Тред обсуждает реализацию графической ОС Os8088 для IBM XT, 286, 386: участники анализируют код, производительность и опыт использования подобных систем, а также роль ИИ в разработке. Проект признаётся интересным примером графической ОС на старом железе, но некоторые скептически относятся к применению ИИ. Обсуждается уязвимость к перезаписи обработчиков прерываний и таймера — одни считают это значимой проблемой, другие — нет. Предлагаются улучшения: поддержка сети, улучшение интерфейса, портирование приложений вроде WordStar и VisiCalc. Отмечается потенциал ИИ в создании сложных систем, но подчёркивается необходимость человеческого участия в разработке и документировании.

Главная идея — поиск самого медленного одиночного процессорного инструкта, а не ускорения кода. Чем дольше один вызов, тем ниже «потолок» производительности, который можно достичь.

В x86‑версии рекорд держит fxrstor64, который за ≈ 62 секунды (≈ 198 млрд циклов) загружает 512‑байтовый FPU‑/MMX‑/XMM‑контекст из медленной MMIO‑зоны, пока остальные ядра «бьют» соседний регистр 4‑байтовыми чтениями, полностью загружая PCIe‑шину. На AMD Ryzen 7 5800H эта техника дала ≈ 74,5 млрд циклов, а в теоретическом варианте с xrstor64 (8 КБ‑состояние) потенциально ≈ 10¹² циклов.

Кратко: использование специфичных инструкций ввода‑вывода и насыщение шины прерываниями превращает обычный загрузчик состояния в рекордный «замедлитель».

Тред подтверждает, что увеличение абстракции и сложности снижает производительность за счёт дополнительных слоёв обработки и операций. Участники приводят примеры, показывающие влияние инструкций и стратегий на производительность, включая MMIO — использование которого вызывает споры: одни считают это «жульничеством», другие — допустимым подходом. Процессоры с сложными архитектурами страдают от повышенной задержки, а MMIO-инструкции особенно замедляют выполнение из-за дополнительных проверок. Для измерения производительности рекомендуются методы анализа времени выполнения и поведения процессора при выполнении операций.

Интерактивный эксплорер исходного кода Linux kernel позволяет просматривать дерево файлов и структуры данных, открывать исходники для изучения. Гид начинается с первой главы "Understanding Linux Kernel Before Code": ядро — не процесс, а всегда присутствующая система, мост между аппаратным и ПО; оно обслуживает пользовательские процессы через системные вызовы, прерывания и планировщик; организована в слои — виртуальные, отображенные, изолированные и контролируемые.

Рекомендуемые файлы для изучения: init/main.c, kernel/fork.c, include/linux/sched.h, arch/x86/kernel/entry_64.S. Тест знаний проверяет: разницу kernel и процесса (kernel — не процесс, а сама система), способы обслуживания (оркестрация syscalls, interrupts, scheduling), характеристики слоев (virtual, mapped, isolated, controlled). Гид включает 9 глав — от системных основ до scheduling, I/O и virtualization, с веткой @master.

• Пользователи хвалят интерактивный гид по исходникам Linux kernel как удобную "карту" для новичков, сравнивая с Талмудом и инструментами вроде Elixir Bootlin.
• Отмечены баги: ошибки загрузки файлов (entry_64.S), GitHub API rate limits, проблемы с сертификатом .dev, мобильной версией и позиционированием в файлах.
• Сравнения с Elixir (лучше поиск, теги, мобильность); пожелания AI-объяснений, графов зависимостей, локального деплоя и версий для CPython/Emacs/Vim.
• Критика: отсутствие поиска/редактирования/grep, слабые квизы (возможно AI-generated), ожидания большего от "AI-эры".

FEX-Emu — быстрый эмулятор пользовательского режима x86 и x86-64 для Linux, позволяющий запускать x86-приложения на ARM64-устройствах. Он обеспечивает широкую совместимость с 32- и 64-битными бинарными файлами и может использоваться совместно с Wine/Proton для запуска Windows-игр. Эмулятор поддерживает перенаправление вызовов API в библиотеки хост-системы (OpenGL/Vulkan) для снижения накладных расходов, а также экспериментальный кэш кода для минимизации зависаний в играх.

В основе FEX лежит продвинутый бинарный рекompiler, поддерживающий все современные расширения набора инструкций x86(-64), включая AVX/AVX2. Используемая в нем собственная промежуточная репрезентация (IR) позволяет генерировать более оптимизированный код, чем традиционный splatter JIT. Модульная архитектура включает в себя комплексный слой трансляции системных вызовов, реализующий даже нишевые возможности вроде seccomp, и позволяет использовать FEX как бэкенд WoW64/ARM64EC в Wine.

• FEX позволяет запускать x86-64 игры на ARM64-устройствах, используя Wine/Proton, но сталкивается с проблемами совместимости из-за различий в модели памяти и DRM.
• Valve спонсирует FEX, что может быть частью стратегии по переходу игровой экосистемы на ARM.
• Проблемы с DRM и анти-чит системами, а также с производительностью графических API, таких как DirectX, которые не могут быть напрямую перенаправлены на хост-систему.
• Несмотря на это, FEX демонстрирует высокую производительность и совместимость с большинством игр, включая Cyberpunk 2077.
• Возможность запуска Windows игр на ARM64-устройствах с помощью FEX и Wine/Proton может быть ограничена из-за отсутствия поддержки ARM ноутбуков и отсутствия графических драйверов.

Transmeta стала последним крупным IPO эпохи доткомов, собрав $273 миллионов 7 ноября 2000 года. Несмотря на то, что компания была производителем процессоров, а не интернет-стартапом, ее запуск считается символическим завершением интернет-бума. Аналитики часто называют это IPO последним успешным технологическим размещением до Google в 2004 году. Компания привлекла внимание благодаря найму Линуса Торвальдса, который продолжал разработку ядра Linux, работая в Transmeta.

Transmeta предложила революционный подход к созданию процессоров, используя программную эмуляцию x86-архитектуры вместо аппаратной реализации. Их первый процессор Crusoe работал на 30% менее эффективно, чем аналоги от Intel, и хотя компания выпустила два поколения чипов, она не смогла конкурировать по производительности. Отсутствие собственных производственных мощей и неспособность догнать гигантов отрасли привели к тому, что инновационная технология так и не принесла коммерческого успеха.

• Transmeta поставила на то, что динамическая компиляция сможет обогнать традиционные процессоры, но в итоге не смогла удержать рынок и была вынуждена переключиться на лицензирование IP и стала патентным троллем.
• Компания стала жертвой собственной идеи: она не смогла конкурировать с Intel и AMD, но зато Intel позже использовал её идеи в своих продуктах.
• Команда Transmeta, включая Linus Torvalds, в конце концов оказалась в других компаниях, где их опыт и знания были использованы для создания новых продуктов.
• Проект показал, что динамическая компиляция может быть полезна для энергоэффективности, но не для производительности, и что рынок ноутбуков в начале 2000-х был не готов к такой технологии.
• История Transmeta стала примером того, как иногда даже самые продвинутые технологические идеи могут не прижиться из-за плохого тайминга или рыночных условий.

В 2025 году SIMD в Rust продолжает развиваться, предлагая значительный прирост производительности до 64x для операций с u8 на современных процессорах. Основная проблема - фрагментация наборов инструкций: ARM использует обязательный NEON (128 бит), WebAssembly - 128-bit packed SIMD, а x86 имеет сложную иерархию от SSE2 до AVX-512 (512 бит). Для x86 разработчики выбирают между указанием target-cpu (например, x86-64-v3) и использованием function multiversioning для поддержки различных процессоров.

В Rust существует четыре подхода к SIMD: автоматическая векторизация (самый простой), продвинутые итераторы, портируемые абстракции и сырые интринсики. В то время как ARM стандартизировал NEON, а WebAssembly требует компиляции двух бинарных файлов, x86 остается самой сложной платформой из-за множества расширений и необходимости обеспечения обратной совместимости.

• Обсуждение показало, что Rust пока не может предложить стабильный и удобный способ работы с SIMD, в отличие от C# и C++.
• Основная причина — std::simd всё ещё в nightly, а стабильная альтернатива отсутствует.
• Участники также отметили, что даже в ночной ветке API нестабилен и может измениться, что делает его использование в production-окружениях проблематичным.
• Некоторые участники выразили обеспокоенность тем, что отсутствие стабильной SIMD-поддержки может отпугнуть потенциальных пользователей Rust, особенно в областях, где эффективное использование SIMD критично.
• В то же время, другие участники подчеркнули, что Rust всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

AMD совершила стратегический прорыв в 2003 году, выпустив Athlon 64 — первый 64-битный процессор x86, который заставил Intel отказаться от собственного проекта Itanium и последовать за конкурентом. Intel изначально не хотела расширять x86 до 64 бит из-за архитектурного наследия и предпочла бы начать с чистого листа, создав более эффективный Itanium, но он провалился из-за отсутствия обратной совместимости и слабой поддержки софта.

AMD пошла на риск, понимая, что Itanium угрожает её существованию, и предложила рынку плавный переход: пользователи могли работать с 32-битными приложениями на полной скорости, а позже перейти на 64-битные ОС без потери совместимости. Это сработало — Microsoft поддержала архитектуру, а рынок оценил удобство. Athlon 64 не только выжил, но и заставил Intel лицензировать технологию AMD, что изменило расстановку сил в индустрии.

• Intel разработала собственные 64-битные расширения для x86 (Yamhill) ещё до AMD64, но отказалась от их внедрения из-за опасений конкуренции с Itanium (IA-64).
• Ключевым фактором успеха AMD64 стала обратная совместимость с существующим x86-софтом, в отличие от радикально новой и несовместимой архитектуры Itanium.
• Переломным моментом стало доминирование AMD с Athlon 64, однако Intel позже вернула лидерство с архитектурой Core, а затем вновь уступила с приходом AMD Zen.
• Решение Microsoft отказаться от поддержки 16-битного кода в 64-битных Windows было технически обосновано ограничениями AMD64, а не маркетинговым выбором.
• Разработка AMD64 велась с учётом опыта других архитектур (например, DEC Alpha) и включала устранение ряда недостатков x86, таких как малое количество регистров.

Nvidia и Intel объявили о совместной разработке процессоров Intel x86 RTX SOC для ПК с графикой Nvidia, а также о создании пользовательских серверных процессоров x86 от Nvidia. В рамках масштабной сделки Nvidia приобрела акции Intel на сумму $5 млрд.

• Опасения по поводу негативного влияния на конкуренцию: инвестиции Nvidia могут угрожать развитию графического подразделения Intel (Arc), которое сдерживает цены на GPU и важно для Linux-сообщества.
• Стратегический интерес Nvidia: сделка может быть направлена на получение доступа к производственным мощностям Intel (фабрикам) и созданию гибридных решений (CPU + GPU), а не на прямую конкуренцию на рынке видеокарт.
• Политический и экономический контекст: инвестиции могут быть продиктованы желанием правительства США поддержать национального производителя полупроводников и диверсифицировать цепочки поставок.
• Исторические параллели: сравнение со сделкой Microsoft и Apple в 1997 году, которая спасла последнюю, и надежды на аналогичный положительный исход для Intel.
• Влияние на архитектуру и рынок: возможный сдвиг в сторону интеграции графики в SoC (системы на кристалле) и потенциальные риски для x86-64 лицензирования Intel.