Обсуждение:Meltdown (уязвимость)
Проект «Информационные технологии» (уровень II, важность для проекта высокая)
Эта статья тематически связана с вики-проектом «Информационные технологии», цель которого — создание и улучшение статей по темам, связанным с информационными технологиями. Вы можете её отредактировать, а также присоединиться к проекту, принять участие в его обсуждении и поработать над требуемыми статьями. |
Термин "спекулятивное выполнение" вводит в заблуждение, разделы "Краткое описание" и "Механизм" не соответствуют друг другу править
Под спекулятивным выполнением обычно понимают предварительное исполнение команд в ветви после условного перехода до получения результата анализа условия перехода.
"Краткое описание ...Например, если инструкция ветвления ожидает получения данных из оперативной памяти для принятия решения, простаивающий процессор может заняться исполнением одного из направлений ветвления (а в некоторых архитектурах — даже обеих ветвей)... ...Из-за особенностей ряда реализаций, во время спекулятивного исполнения доступ к памяти фактически осуществляется независимо от прав доступа исполняемого процесса к этой памяти; это позволяет исполнять команды, не дожидаясь ответа от контроллера памяти. Если впоследствии эта ветка спекулятивного исполнения окажется правильной, то будет сгенерировано исключение ошибочного доступа к памяти. Если же ветку отбросят как ошибочную, то исключение сгенерировано не будет; но переменные, загруженные в кэш в процессе исполнения ветки, останутся в кэше."
Возможно, но в примере атаки в разделе "Механизм" механизм :) немного другой. В этом примере нет ни одного перехода! И исключение обязательно генерируется. "Эта последовательность операций на некоторых архитектурах приводит к ошибке защиты на шаге 2". Это на каких НЕ приводит? На 8086 или в real mode? Но там невозможно говорить об уязвимости за полным отсутствием уязвимого предмета (защиты).
Фактически, речь идет об обычном конвейерном исполнении команд, которое применяется очень давно (уже в БЭСМ-6 было). Странная особенность процессоров Intel и ARM, делающая атаку возможной -- проверка права доступа на финальной стадии конвейера. Непонятно, почему бы не делать это в момент трансляции адреса, биты доступа можно так же хранить в кэше транслятора (TLB)?
82.116.48.105 06:28, 18 января 2018 (UTC)
82.116.48.105 06:35, 18 января 2018 (UTC)
- При атаке может использоваться такая особенность: создаётся булевая переменая, выгружается из кеша. И на её основе выполняется доступ к защищённой памяти. Процессор ждать загрузки переменной из кеша не хочет и выполняет команды из двух веток одновременно. Когда переменная уже оказывается загружена, выясняется, что к защищённой памяти получать доступ вообще «не надо было». В итоге, исключения нет, но кеш в нужном месте заполнен. — Vort (обс.) 06:51, 18 января 2018 (UTC)
- То есть, спекулятивное исполнение при реальной атаке всё же используется. Но и без операций ветвления, скорее всего, будут проблемы — это верно. — Vort (обс.) 07:01, 18 января 2018 (UTC)
- Хотя, судя по en-wiki, всё правильно: «Speculative execution is an optimization technique where a computer system performs some task that may not be needed». Выполнил лишнее? Да. Значит, speculative execution. — Vort (обс.) 07:06, 18 января 2018 (UTC)
- Можно ещё интерпретировать и так, что проверка доступа — это тоже условие, только неявное. — Vort (обс.) 07:17, 18 января 2018 (UTC)
- Гипотеза про "особенность процессоров Intel и ARM": проверку прав доступа откладывают (до in-order стадии retire), чтобы ускорить ту спекуляцию (ветку), что прошла через точку смены привилегий (системный вызов) `a5b (обс.) 15:12, 18 января 2018 (UTC)
про особенности спекулятивного выполнения править
Не знаю как это интереснее вставить в статью, но в ней пропущена важная мысль, из статьи можно подумать что на проблему не повлияла ошибка в работе процессора, что такие действия процессора неизбежны и правильны, а это не совсем так.
Процессор при спекулятивном выполнении обращается к запрещенным в текущем контексте областям памяти, это нельзя признать правильным хотя бы потому, что такое сбойное обращение в последствии не может быть отменено.
Опасность генерации непроверенных запросов к памяти в многозадачной системе должна была насторожить разработчиков и заставить их отвлечься от программной модели процессора. Они не заметили проблему таких запросов, поскольку вероятно решили так:
- код выполняется в будущем, если в будущем контекст будет правильным, то этот код можно выполнить прямо сейчас;
- если же в будущем контекст будет неправильным, то результат кода выполненного в прошлом можно будет в будущем выбросить, словно код не выполняется сейчас;
Кто на ком стоял? Даже написать эти условные выражения, оперируя одновременно тремя временами, было не просто. И заваленные проблемами авторы x86 перепутали гипотетическое с реальным.
Это примерно также как десятки тысяч фермеров в теории рыночной экономики, которая тоже не отличает реальную экономику от вымышленной, в теории рыночной экономики озабоченно бродят десятки тысяч фермеров, которые все время производят какие то излишки, как чудо-горшочки которые варят кашу, и чтобы полученные излишки не выбрасывать, фермеры упорно их обменивают на рынке с целью продать подешевле. А потом правила такой рыночной теории применяют к реальному миру и тысячелетия бедствий человечества вполне закономерный итог такого применения.
Оперируя формальными правилами и возможностью отменить непосредственный результат выполнения запроса разработчики х86 не сообразили что отменить само сбойное обращение к памяти, после того как оно случилось, будет уже нельзя. Оперируя одновременно тремя временами они два раза выполнили операцию "не". Запутаться легко, если не питать дополнительной неприязни к нарушениям механизмов защиты предлагаемых процессором.