Нарушение защиты памяти между задачами Meltdown
От: grizlyk1  
Дата: 20.07.19 22:18
Оценка: 1 (1)
Нарушение защиты памяти между задачами 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 битный линейный адрес, сегменты тут не виноваты
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.