Линус Торвальдс: ECC-память должна стать стандартом для всех ПК

567 комментарии
Линус Торвальдс жестко раскритиковал искусственную сегментацию платформ. По его словам, механизм коррекции в микросхемах DDR5 не защищает шину, а 8,2% серверных модулей выдают ошибки в течение первых 12 месяцев

Спор о том, нужна ли ECC-память домашнему компьютеру, идёт не первое десятилетие, и создатель Linux Линус Торвальдс, по его собственным словам, участвует в нём с 1990-х. Полевые замеры Google в собственном парке серверов дали больше 8% модулей с ошибками за год, причём преобладали устойчивые дефекты ячеек, а не разовые сбои от фонового излучения. Осенью 2022 года Торвальдс потерял почти сутки на поиск несуществующей ошибки ядра, пока не выяснилось, что сбоит планка памяти в его собственной машине. Обязательный для всех чипов DDR5 внутренний ECC такую защиту не заменяет, а сентябрьская атака Phoenix обошла и его за 109 секунд.

comss img 2026 09 02 115911

Лишние биты, которые ловят перевёрнутый разряд

ECC расшифровывается как error-correcting code. Модуль с такой защитой несёт дополнительные микросхемы: на каждые 64 бита полезных данных приходится 8 проверочных, и шина расширяется с 64 до 72 бит. Классическая схема SEC-DED исправляет одиночную ошибку на лету и обнаруживает двойную, сообщая об этом операционной системе. Обычный модуль такой проверки не несёт: перевёрнутый разряд уходит дальше как достоверное значение, и ни процессор, ни ядро об этом не узнают.

SEC-DED – схема кодирования, которая исправляет одну ошибочную ячейку в защищаемом слове и обнаруживает две, но не может исправить двойную ошибку.

Механизм не экспериментальный и не новый. Код Хэмминга опубликован в 1950 году, а в серийных машинах SEC-DED применялась ещё в IBM 7030 и в IBM System/360 Model 85, отгрузки которой начались в декабре 1969 года. Формулировка «доступна больше пятидесяти лет», которая кочует по публикациям об ECC, срок скорее занижает: отсчёт идёт от шестидесяти.

Восемь процентов модулей с ошибками за год

Самый цитируемый замер частоты сбоев принадлежит Google: два с половиной года наблюдений за парком серийных серверов, миллионы модуле-суток, несколько поставщиков и несколько поколений DRAM. Итог – от 25 000 до 70 000 ошибок на миллиард устройство-часов в пересчёте на мегабит и более 8% модулей, у которых за год зафиксирована хотя бы одна ошибка. Корректируемую ошибку за год видела примерно треть машин. Полный текст исследования выложен в публикациях Google Research.

Куда важнее для домашнего пользователя другой вывод той же работы. Преобладают не разовые сбои от фонового излучения, а устойчивые дефекты: конкретная ячейка или конкретный чип начинают ошибаться и продолжают ошибаться дальше. Модуль, у которого ошибка уже была, в том же месяце даёт следующую с вероятностью в 13–228 раз выше, чем модуль без истории сбоев. Космические лучи – красивая иллюстрация, но статистику делает износ железа, и отсюда практический вывод: память опаснее всего не в первый месяц, а на третий-четвёртый год, когда владелец давно перестал подозревать в сбоях оборудование.

Сбойный модуль в машине Торвальдса и сутки отладки

Как это выглядит на практике, Торвальдс описал сам , отвечая в рассылке ядра на вопрос о непринятом запросе на слияние. Сборки конфигурации allmodconfig падали с внутренними ошибками компилятора, память портилась в пользовательском пространстве, и первое подозрение легло на свежий код ядра – шло окно слияния, такое случается. Причина оказалась в другом: планка вышла из строя после двух с половиной лет полностью стабильной работы. Диагноз подтвердился загрузкой старого ядра и ночным прогоном memtest86+, а исходное письмо заканчивается признанием, что часть времени ушла на обвинение всего подряд, кроме железа.

Пересказы этой истории обычно опускают приписку в конце письма, а она и есть главная. Машина была рассчитана на ECC. Собиралась она в начале пандемии, когда ECC-модулей по вменяемой цене не было ни у кого, память поставили обычную – и руки заменить её так и не дошли, пока ошибки не пришлось ловить вручную. Человек, годами требовавший ECC для всех, сам просидел два с половиной года без неё из-за дефицита и цен.

В ноябре 2025 года новую рабочую станцию ему собрали на камеру: Threadripper 9960X, плата TRX50 AERO, видеокарта Intel Arc B580 и ECC-память, о необходимости которой он отдельно говорил в кадре. Часть изданий, пересказывавших ролик, назвала видеокарту Arc 8580 – такой модели не существует.

Счётчики EDAC: сбой виден до того, как машина упадёт

Главная польза ECC для рабочей машины даже не в самой коррекции, а в отчётности. Исправленная ошибка не пропадает бесследно: контроллер памяти сообщает о ней ядру, а подсистема EDAC выкладывает счётчики в sysfs отдельно по каждому модулю. Документация ядра формулирует смысл этих чисел без обиняков: корректируемые ошибки служат ранним признаком того, что планка начинает выходить из строя, и ненулевое значение счётчика требует внимания задолго до первого неисправимого сбоя.

Посмотреть накопленное на Linux можно одной строкой:

grep -H . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count

На машине без ECC этот каталог либо пуст, либо вовсе не создаётся – сообщать не о чем, потому что перевёрнутый разряд никто не заметил. Именно такой строчки Торвальдсу и не хватило в 2022 году: вместо счётчика с растущим числом у него была ночь прогона теста памяти и сутки подозрений в адрес собственного кода. Для постоянного наблюдения в репозиториях дистрибутивов есть служба rasdaemon и утилита ras-mc-ctl, сводящая те же значения в таблицу с привязкой к слотам, а описание всех полей лежит в документации ядра.

Претензия к Intel: сегментация переехала на чипсеты

Самое резкое высказывание Торвальдса об ECC датируется январём 2021 года и опубликовано не в рассылке ядра, как писали многие, а на форуме Real World Technologies – в ветке о процессорах Ryzen, после реплики собеседника, что ECC не имеет значения. Ответ занял несколько сообщений и сводился к двум тезисам: доступность ECC-модулей на рынке подорвана сегментацией Intel, а рассказы о том, что современная DRAM достаточно надёжна и без коррекции, ничем не подкреплены.

ECC нужна не серверам. ECC нужна всем.

Линус Торвальдс, создатель ядра Linux

Техническая часть претензии проверяема. Поддержка ECC реализуется в контроллере памяти, контроллер в современных системах живёт в процессоре, и решение отключить её в потребительской линейке закрывает возможность для всей цепочки: производителям плат незачем разводить дополнительные линии, производителям памяти незачем выпускать небуферизованные ECC-модули под массовые платформы. AMD поступала мягче: в кристаллах Ryzen поддержка не отключена, но обязательной сертификации плат нет, поэтому работоспособность зависит от конкретной модели, а официальные гарантии дают серверные платы вроде ASRock Rack.

К 2026 году формулировка «ECC только в Xeon» устарела. Чипсет Intel W880 для гнезда LGA 1851 официально поддерживает ECC UDIMM вместе с процессорами Core Ultra 200S – теми же самыми, что продаются в игровых сборках. Запрет не сняли, а перенесли на уровень чипсета: массовые Z890 и B860 остаются без ECC, а плата на W880 стоит как рабочая станция. Формально позиция изменилась, экономическая логика – нет: доплата за коррекцию по-прежнему тянет за собой доплату за класс платы.

Внутренний ECC в DDR5 закрывает другую задачу

Отсюда растёт самое распространённое заблуждение последних лет: раз стандарт DDR5 обязывает встраивать коррекцию в каждый чип, дорогие модули больше не нужны. JEDEC действительно требует on-die ECC – 8 проверочных бит на 128 бит данных внутри кристалла. Но задача у этого механизма другая.

On-die ECC – коррекция одиночных ошибок внутри самой микросхемы DDR5 до выдачи данных наружу. Ошибки не сообщаются операционной системе и не защищают линию между модулем и контроллером.

On-die ECC появился потому, что при уплотнении ячейка удерживает меньше заряда и чаще сбоит на производстве – коррекция позволяет большему проценту кристаллов проходить приёмку по нормам JEDEC. Данные на пути от модуля к процессору она не прикрывает, о накопленных ошибках не докладывает, сбойный модуль по ней не вычислить. Полноценный ECC-модуль устроен иначе: шина шире (у DDR5 RDIMM – 80 бит вместо 72 у прошлых поколений), чипов на плате больше, и контроллер видит каждую исправленную ошибку. Два механизма дополняют друг друга, но не заменяют.

Phoenix: root-доступ за 109 секунд на модулях SK hynix

Второй аргумент в пользу ECC – защита от Rowhammer. Он верен наполовину, и сентябрь 2025 года это показал.

Rowhammer – воздействие на DRAM, при котором многократное обращение к одной строке ячеек меняет состояние битов в соседних строках без обращения к ним.

Исследователи группы COMSEC из ETH Zurich совместно с Google опубликовали атаку Phoenix (CVE-2025-6202, оценка CVSS 7.1). Обратной разработкой встроенного механизма Target Row Refresh у SK hynix они нашли интервалы, которые защита не отслеживает, и построили два шаблона длиной 128 и 2608 интервалов обновления. Чтобы такие длинные последовательности не расходились с командами обновления, применён метод самокорректирующейся синхронизации. Уязвимыми оказались все 15 протестированных модулей DDR5 выпуска с января 2021 по декабрь 2024 года, а повышение привилегий до root на обычном ПК с настройками по умолчанию заняло 109 секунд. Встроенная в чипы коррекция этому не помешала.

Временная мера от авторов работы – утроить частоту обновления памяти, доведя интервал примерно до 1,3 мкс; по их замерам в SPEC CPU2017 это стоит 8,4% производительности. Раскрытие шло через швейцарский NCSC с , эмбарго сняли . За три дня до снятия авторов уведомили о выпуске обновления BIOS для клиентских машин AMD, но проверить его достаточность самостоятельно в COMSEC не смогли; описание атаки и код опубликованы. Вывод для читателя: модульный ECC поднимает планку сложности, но фразу «ECC решает проблему Rowhammer» пора считать упрощением.

Во что обходится ECC: частота, проценты и дефицит

Само вычисление кода почти ничего не стоит. При измерениях на Ryzen 9 7900X с включением и отключением коррекции в BIOS разница по большинству нагрузок укладывалась в 1–3%, а часто и вовсе в пределы погрешности. Настоящая потеря в другом: ECC-модули без буферизации для DDR5 обычно рассчитаны на 4800 МТ/с, реже на 5200, тогда как массовые комплекты стартуют от 6000 МТ/с и выше по профилям XMP и EXPO. За надёжность платят частотой, а не процентами накладных расходов.

Второе ограничение – плата. Микро-ATX плата ASRock Rack B650D4U-2L2T/BCM с официальной поддержкой ECC UDIMM для Ryzen продавалась дороже 500 $ при бюджетном чипсете B650: цену задаёт серверная обвязка, а не сама коррекция.

Третье ограничение появилось недавно и перевешивает первые два. С осени 2025 года производители DRAM переводят мощности под HBM для ускорителей ИИ, и цены на обычную память выросли кратно: по оценкам отраслевых аналитиков, 16-гигабитный чип DDR5 за IV квартал 2025 года подорожал с 6,84 $ до 27,20 $, а розничные комплекты в 2026 году местами стоят вчетверо дороже прошлогодних. Надбавка за дополнительную микросхему в ранге – примерно 12,5% по объёму хранения – на таком фоне перестаёт быть главным препятствием. Препятствием становится наличие модулей в продаже.

Заключение

Аргумент «современная DRAM надёжна и без коррекции» полевыми данными не подтверждается: ошибки распределены неравномерно, накапливаются с возрастом модуля и в большинстве случаев вызваны износом, а не редкой частицей. Жёсткий запрет Intel формально снят – ECC работает на Core Ultra 200S, – но привязан к чипсету W880 и платам класса рабочей станции, поэтому в массовой рознице ситуация не изменилась.

Практический смысл ECC выше всего там, где ошибка тихо портит результат: файловое хранилище на ZFS, длительные сборки, расчёты, виртуализация. Перед покупкой стоит проверить поддержку ECC UDIMM одновременно в спецификации процессора и платы – одного пункта недостаточно. Тем, у кого ECC уже работает, стоит завести привычку раз в месяц заглядывать в счётчики EDAC: растущее число исправленных ошибок на одном модуле – повод заменить планку до аварии, а не после. Без ECC остаётся прежний порядок: при повторяющихся падениях сборок или необъяснимых ошибках приложений сначала запускают ночной тест памяти – MemTest86 или memtest86+ – и только потом ищут ошибку в программах. История с потерянными сутками отладки повторяется чаще, чем кажется.

Автор:
Комментарии и отзывы

Нашли ошибку?

Новое на сайте