Информация об изменениях

Сообщение Re: Нарушение защиты памяти между задачами Meltdown от 11.07.2020 21:22

Изменено 11.07.2020 21:24 ononim

Re: Нарушение защиты памяти между задачами Meltdown
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]А, оказывается это некропостинг...
Re: Нарушение защиты памяти между задачами Meltdown
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]А, оказывается это некропостинг...