Нарушение защиты памяти между задачами Meltdown.
Я чисто поговорить, о том да о сем. Но все творчество сюда на форум не поместить наверное, поэтому даю содержание, ссылку, эпиграф, отрывки. Будут желающие обсуждать — пожалуйста.
Содержание:
1. Какие проблемы внес производитель x86, что привело к возникновению Meltdown?
а) выполнять бесполезную сериализацию
б) готовый эмулятор стресса системы, встроенный в процессор х86
2. Как исправить обнаруженные проблемы?
3. Виноват ли производитель x86 в возникновении Meltdown и если да то в чем именно?
4. Любая катастрофа это чаще всего сочетание нескольких неблагоприятных факторов, а не единственный промах.
5. Действия программистов пишущих ОС которые прямо ведут к проблемам и ошибкам выполнения, их немного перечислим.
а) вопрос, что в адресном пространстве задачи в проблемных ОС делают привилегированные данные?
б) вопрос, что в адресном пространстве задачи в проблемных ОС делают данные соседних процессов?
в) вопрос, что в проблемных ОС делают страницы?
6. Процессор x86 обладает множеством иных особенностей:
а) в процессоре x86 нет регистров общего назначения
б) модель памяти у процессора x86 особенная
в) еще процессор x86 не поддерживает нити
г) процессор x86 имеет только встроенные в опкоды префиксы сегментов
Источник:
http://grizlyk1.narod.ru/sys_new/msg_01/x86_meltdown_200719.pdf
Эпиграф:
"
аппаратурой авторы оптимизации выполнения нити x86 также не занимаются, но вот опасность генерации непроверенных запросов к памяти в многозадачной системе должна была их насторожить и заставить отвлечься от программной модели процессора
процессор никогда не должен выполнять сбойные в терминах своего контекста обращения, авторы x86 не заметили проблему таких запросов, поскольку вероятно решили так:
— код выполняется в будущем, если в будущем контекст будет правильным, то этот код можно выполнить прямо сейчас;
— если же в будущем контекст будет неправильным, то результат кода выполненного в прошлом можно будет в будущем выбросить, словно код не выполняется сейчас;
Кто на ком стоял? Даже написать эти условные выражения, оперируя одновременно тремя временами, было не просто. И заваленные проблемами авторы x86 перепутали гипотетическое с реальным.
Это примерно также как десятки тысяч фермеров в теории рыночной экономики, которая тоже не отличает реальную экономику от вымышленной, в теории рыночной экономики озабоченно бродят десятки тысяч фермеров, которые все время производят какие то излишки, как чудо-горшочки которые варят кашу, и чтобы полученные излишки не выбрасывать, фермеры упорно их обменивают на рынке с целью продать подешевле. А потом правила такой рыночной теории применяют к реальному миру и тысячелетия бедствий человечества вполне закономерный итог такого применения.
вернувшись к процессору, оперируя формальными правилами и возможностью отменить непосредственный результат выполнения, авторы х86 не сообразили что отменить само сбойное обращение к памяти, после того как оно случилось, будет уже нельзя. Оперируя одновременно тремя временами они два раза выполнили операцию "не". Запутаться легко, если не питать дополнительной неприязни к нарушениям механизмов защиты предлагаемых процессором.
"
Цитата 1:
Также у обращений к памяти с нарушениями прав доступа есть и иная проблема, на связанная с нарушениями программной защиты задач Meltdown.
Эта иная проблема в том, что процессор x86 при упреждающем выполнении может хаотически генерировать произвольные запросы чтения к памяти. Мы увидели эту вторую проблему когда произошла проблема Meltdown.
Обычно на ошибочные запросы к памяти любого происхождения и внимания не обращаешь, потому что у процессора всегда включена защита доступа к памяти для последовательного выполнения, а при спекулятивном выполнении она оказывается отключается и эти запросы вылетают на шину (чем бы она ни была).
Некоторые аппаратные устройства отображаются на память процессора и чтение по случайным адресам теоретически может вызвать аппаратную ошибку на устройствах не готовых к такому развитию событий и не имеющих помехозащищенного протокола для обмена с процессором (особенно для простых устройств, которые реагируют на чтение как на запись).
Цитата 2:
процессор x86 снабжен системой сегментов, но жестко завязан на "плоскую модель памяти С образца 1970-х годов",
это выглядит как единственный сегмент данных, представленный сегментными регистрами DS и SS, при этом
- у DS и SS общая база;
- DS растет вниз и его предел самый первый байт 0, через DS
защищается адрес 0 как NULL
доступен весь физический сегмент данных, кроме адреса 0
доступны данные DATA,BSS, они начинаются снизу от адреса 0 + выравнивание 2 или 4 и растут вверх
доступны данные STACK, они начинаются сверху от адреса 0 - выравнивание 2 или 4 и растут вниз
- SS растет вниз и его предел это адрес посредине сегмента задаваемый с помощью sbrk(), через SS
защищается адрес 0 как NULL
защищаются данные DATA,BSS от автоматического декремента (e)SP при создании фрейма стека
в операциях процессора x86 данные DATA,BSS также недоступны
доступны только данные STACK
через DS весь сегмент данных оптимально доступен для всех обычных опкодов x86 для доступа ко всем данным
через SS только данные STACK оптимально доступны для всех опкодов x86 ориентированных на стек
еще есть регистр CS, который позволяет организовать еще один отдельный от DS/SS сегмент,
это сегмент кода который содержит функции, а эти функции общие на все копии одной задачи
(сегмент данных напротив, отдельный и свой для каждой копии одной задачи), при этом
- CS растет вверх и его предел равен размеру кода задачи, через CS
не защищается адрес 0 как NULL
отметим что "указатель на данные" не совместим с "указателем на код" (адресует разные сегменты при равном значении)
защищается код CODE от записи и даже от чтения
доступен весь сегмент кода CODE
через CS весь сегмент кода оптимально доступен для всех опкодов x86 ориентированных на выполнение команд
такая схема сегментов CS, DS/SS позволяет
иметь "указатель на данные", как требует "плоская модель памяти"
эффективно использовать опкоды x86
эффективно использовать память разделяя один код на несколько копий задачи
такая схема раздельных сегментов используется на 16 битных процессорах x86
на 32 битных процессорах x86 в такой схеме предельный размер сегмента DS/SS уменьшается на размер CS, при этом
- начало DS (предел DS) поднимается вверх на размер CS, уменьшая максимальный размер сегмента DS/SS;
- SS не изменяется;
такая схема раздельных сегментов используется на 32 битных процессорах x86 при включении страниц
это потому, что силами аппаратуры x86 невозможно одновременно разместить в памяти сегменты одной нити,
суммарный размер которых больше 4 Гбайт, их линейные адреса начинают перекрываться
на 32 битных процессорах x86 PAE это "серверная" возможность, которая позволяет запускать много маленьких (по 4 Гбайта) 32 битных задач
на большой памяти, заместо "клиентской" возможности запуска одной большой 32 битной задачи с общей адресуемой памятью более 4 Гбайт
и причина тому 32 битный линейный адрес, сегменты тут не виноваты
PS1: к тексту "Нарушение защиты памяти между задачами Meltdown"
Про "DS/ES это рабочие сегментные регистры х86".
Вот на это замечание в исходном тексте:
>6. Процессор x86 обладает множеством иных особенностей:
>г) процессор x86 имеет только встроенные в опкоды префиксы сегментов
>для модульной архитектуры надо уметь индексировать сегментные регистры,
>а не только статически задавать их префиксы в опкоде
Мы получили пояснение, что:
"DS/ES это рабочие сегментные регистры х86, поэтому индексация сегментов на х86 есть и разработчики х86 хотя и не пишут программы, но программисты все же рассказали им о потребностях модульных программ в индексации сегментов для шаблонов кода времени выполнения".
Мы изучили этот вопрос, что заняло некоторое время. Давайте посмотрим, правда ли что став рабочими сегментные регистры DS/ES обеспечат механизм эквивалентный индексации сегментов в плоском указателе?
2.
Весь текст сюда на форум конечно опять не поместить, даю ссылку, эпиграф, отрывки.
Источник:
http://grizlyk1.narod.ru/sys_new/msg_01/x86_meltdown_090720-ps1.pdf
Эпиграф:
"
"Зачем нужны регистры" это опять из серии "сложно о простом":
— если крысу в опыте вообще не поить и не кормить, то она заболеет и даже может быть умрет;
— ну или лучше жить в плановой интернациональной экономике, чем иметь в РФ в рыночной нациоанальной экономике 15 миллионов нищих, бездомных и безработных "с высокой производительностью труда".
Но вот атеист (т.е. тот кто отрицает десять христианских заповедей как базовые ценности) не подозревает ни о существовании:
— системы базовых ценностей, которая используется при всех рассуждениях как "базовая точка опоры";
— физических и математических моделей применяемых для описания всех рассуждений и всех явлений;
атеист просто ест, спит, ну и т.п., живет как поросенок в стойле. И другие люди рыночный нациоанальный режим лживых воров, в котором каждому надо:
— преступным путем создавать;
— преступным путем удерживать;
— преступное неравновесие для извлечения личной выгоды;
не станут поддерживать. И так происходит тысячелетиями во все странах мира (мы улыбаемся тем, кто улыбается когда политики тысячелетиями говорят то, что они уже когда то слышали).
Вопрос "понимали или не понимали нужды индексации сегментов во времена реального режима сами разработчики архитектуры x86" остается тайной известной только самим разработчикам архитектуры x86.
Отсутствие в защищенном режиме х86 кэша дескрипторов DC (одновременно с появлением TLB кэша в 386) подсказывает нам то, что разработчик х86 фокусировал свое внимание в то время на плоской модели (база DS == база SS), игнорируя светлые идеи сегментации (потребности модульных программ).
"
Цитата 1:
Часть 1
Нам подходит какой нибудь OMF асм для х86 в паре с каким либо OMF линкером:
— напишем пару любых простых функций;
— напишем любой простой пример программы эти функции использующей;
посмотрим на код который получается, слишком ли тяжелы вычисления от перезагрузки DS/ES?
список файлов примера в архиве
вот текст ex01.asm в редакторе far с подсветкой
вот сам образ ex01r.exe в отладчике (тоже с подсветкой)
Цитата 2:
Часть 2
Как только программисту удается сообразить, что в x86 нет регистров и операции с памятью допустимы, он перестает предпринимать попытки бессмысленной оптимизации, настроение программиста улучшается, он успокаивается, а код становится удобным, оптимальным и рациональным.
Вычислим на х86 функцию y=k*x+b из диапазона x от -10.0 до 10.0. Используем 16 бит арифметику с 4 битной фиксированной точкой (shl 4). Два раза вычислим: с помощью регистров и без них.
Глядя на то, как у современного софта печально медленно обрабатываются окна содержащие всего лишь текст и картинки, мы видим, что при хранении всех параметров в регистрах наша программа практически работает в 4 раза быстрее.
В нашем примере с вычислением "y=k*x+b" мы видим и некоторые ограничения на пригодность задач к оптимизации путем использования регистров.
Естественный для архитектуры x86 путь добавления регистрового файла это установка сопроцессора с набором целочисленных регистров и интеграция его обслуживания в систему (флаг TSx в MSW, ...
MMX сделан иначе, это реакция производителя х86 на предыдущий случай невостребованного "ортогонального" защищенного режима в 286.
Цитата 3:
Часть 3
Все же вернемся к нашей теме об индексах сегментов.
Если понять что DS/ES это рабочие сегментные регистры, то становится ясно что в реальном режиме разработчики х86 последовательны в своих намерениях и преследуя свою концепцию "безрегистрового" процессора, ориентированного на хранение всех данных в памяти, а не в явно выделенных программистом кэширующих регистрах, не ограничились такими полумерами как отказ от регистров общего назначения, в х86 нет даже и сегментных регистров, есть только индексы сегментов.
Это неожиданно.
Ну а как предзагружаются сегменты контекста модуля х86 в защищенном режиме, если сегментные регистры это опять индексы?
Индексов сегментов в защищенном режиме х86 нет.
Ограничение линейного адреса в 4Г: давайте мы сами опишем поля базы и предела дескриптора х86 только имеющегося формата исходя из потребностей многосегментных 32 битных программ.
Блин, я что-то не понимаю на этом форуме. Почему первое сообщение от 10.07.20, а ответы на него за 19 год?
Автор отредактировал свое исходное сообщение?
G>Обычно на ошибочные запросы к памяти любого происхождения и внимания не обращаешь, потому что у процессора всегда включена защита доступа к памяти для последовательного выполнения, а при спекулятивном выполнении она оказывается отключается и эти запросы вылетают на шину (чем бы она ни была).
G>Некоторые аппаратные устройства отображаются на память процессора и чтение по случайным адресам теоретически может вызвать аппаратную ошибку на устройствах не готовых к такому развитию событий и не имеющих помехозащищенного протокола для обмена с процессором (особенно для простых устройств, которые реагируют на чтение как на запись).[/q]
Это бред, авторы похоже не в курсе про разницу между виртуальными адресами и физическими. За сим можно просто поставить вердикт "написано пафосными дилетантами", но все же продолжу по тексту.
G>Цитата 2:[code]
G>процессор x86 снабжен системой сегментов, но жестко завязан на "плоскую модель памяти С образца 1970-х годов",
G>это выглядит как единственный сегмент данных, представленный сегментными регистрами DS и SS, при этом
G>- у DS и SS общая база;
G>- DS растет вниз и его предел самый первый байт 0, через DS
G> защищается адрес 0 как NULL
G> доступен весь физический сегмент данных, кроме адреса 0
G> доступны данные DATA,BSS, они начинаются снизу от адреса 0 + выравнивание 2 или 4 и растут вверх
G> доступны данные STACK, они начинаются сверху от адреса 0 — выравнивание 2 или 4 и растут вниз
G>- SS растет вниз и его предел это адрес посредине сегмента задаваемый с помощью sbrk(), через SS
G> защищается адрес 0 как NULL
G> защищаются данные DATA,BSS от автоматического декремента (e)SP при создании фрейма стека
G> в операциях процессора x86 данные DATA,BSS также недоступны
G> доступны только данные STACK
G>...
Это они тут про классическую юниксовую модель памяти распрягли, которая нынче всеръез не воспринимается, так как в АП процесса присутствует 100500 потоков у каждого из которых свой стек и 100500 модулей у каждого из которых свои CODE, DATA и BSS а хипы вообще зачастую содержаться на участках, выделяемых анонимными mmap-ами.
на 32 битных процессорах x86 доступная память нити 4 Гбайт делится на
— данные процесса (хороший доступ через FS)
— данные нити (самый эффективный доступ через DS/SS)
— кода процесса (самый эффективный доступ через CS)
Это вообще русские люди писали? Ну ладно, наверное все-таки нет, а переводчик был пьян, что объясняет корявость терминологии этого фрагмента и всего остального текста в целом. Мысль вобщем-то понятна, но почему в ней все перепутано? FS — это thread local storage, DS — данные.
б) вопрос, что в адресном пространстве задачи в проблемных ОС делают данные соседних процессов?
Похоже о том что такое мельдаун авторы вообще не в курсе.
[UPD]А, оказывается это некропостинг...
