Плоская модель памяти
Posted: Thu Jan 25, 2007 2:34 pm
Начало темы здесь http://meos.sysbin.com/viewtopic.php?p=8772
Чтобы было понятно о чём идет речь.
В плоской модели памяти базовые адреса всех сегментов равны нулю,пределы 4Гб-1 а защита ядра от программ осуществляется при помощи таблиц страниц. При такой схеме если программа передаёт ядру указатель на свои данные, например буфер для чтения файла, ядру нет необходимости переводить его в своё адресное пространство прибавлением std_application_base_address как это происходит сейчас.
Такая организация памяти очень проста и стала общепринятой. В новой архитектуре AMD64 (Intel® EM64T) базовые адреса сегментов уже установлены в ноль а пределы игнорируются, то есть плоская модель памяти лежит в основе всей архитектуры.
МеОС не было страничной памяти поэтому у каждой программы были свои дескрипторы сегментов где был установлен базовый адрес приложения в памяти, а виртуальный адрес равнялся нулю.
(Для тех кто запутался. В команде mov eax, [0x1234567] 0x1234567 виртуальный адрес. При выполнении комады к нему прибавляется базовый адрес сегмента и образуется линейный адрес. Если работает страничное преобразование то через таблицы страниц этот адрес преобразуется в физический адрес данных в памяти компьютера. Если привыкнуть то ничего сложного ).
Когда Андрей Халявин сделал менеджер памяти у всех приложений стали общие дескрипторы сегментов, а их базовый адрес был установлен в 0х1000000. Так появился std_application_base_address. Каждое приложение получило своё адресное пространство защищённое таблицами страниц а память ядра вместе в LFB составила 16 Мб.
Я изменил это распределение памяти. Сейчас ядро занимает адреса 0-0х5FFFFFFF таблицы страниц 0x60000000-0x603FFFFF, зачение std_application_base_address равно 0х60400000 и приложения оказались сверху ограничены LFB, который отображается непосредственно на адреса видеопамяти. В общем это не самая удачная организация памяти но предполагалось что ядру будет доступна вся имеющаяся видеопамять а приложения смогут обращаться к ней напрямую без селектора gs. Позже оказалость что на старых видеокартах VESA не показывает правильного размера видеопамяти, что приводило к зависаниям, поэтому сейчас размер LFB устанавливается в 8 Мб.
Что предлагается.
Всё адресное пространство будет поделено на две равные части. Базовые адреса всех сегментов будут установлены в 0 а пределы в в 4Гб-1. Программы будут компилироваться с org 0x80000000 и занимать адреса 0х80000000-0хFFFFFFFF, так что макимальный размер программы и данных составит 2Гб.
Ядро и его данные займут адреса 0-0х7FFFFFFF, из них таблицы страниц 0x7FC00000 - 0х7FFFFFFF, LFB 0x7F400000-0x7FBFFFFF. Память ядра будет защищена от программ битами в таблицах страниц так что программы не смогут его переписать.
Часть изменений можно сделать сразу, для приложений они будут совершенно прозрачны. Окончательно всё можно будет закончить через несколько месяцев, а за это время найти и собрать на SVN исходники всех программ.
Чтобы было понятно о чём идет речь.
В плоской модели памяти базовые адреса всех сегментов равны нулю,пределы 4Гб-1 а защита ядра от программ осуществляется при помощи таблиц страниц. При такой схеме если программа передаёт ядру указатель на свои данные, например буфер для чтения файла, ядру нет необходимости переводить его в своё адресное пространство прибавлением std_application_base_address как это происходит сейчас.
Такая организация памяти очень проста и стала общепринятой. В новой архитектуре AMD64 (Intel® EM64T) базовые адреса сегментов уже установлены в ноль а пределы игнорируются, то есть плоская модель памяти лежит в основе всей архитектуры.
МеОС не было страничной памяти поэтому у каждой программы были свои дескрипторы сегментов где был установлен базовый адрес приложения в памяти, а виртуальный адрес равнялся нулю.
(Для тех кто запутался. В команде mov eax, [0x1234567] 0x1234567 виртуальный адрес. При выполнении комады к нему прибавляется базовый адрес сегмента и образуется линейный адрес. Если работает страничное преобразование то через таблицы страниц этот адрес преобразуется в физический адрес данных в памяти компьютера. Если привыкнуть то ничего сложного ).
Когда Андрей Халявин сделал менеджер памяти у всех приложений стали общие дескрипторы сегментов, а их базовый адрес был установлен в 0х1000000. Так появился std_application_base_address. Каждое приложение получило своё адресное пространство защищённое таблицами страниц а память ядра вместе в LFB составила 16 Мб.
Я изменил это распределение памяти. Сейчас ядро занимает адреса 0-0х5FFFFFFF таблицы страниц 0x60000000-0x603FFFFF, зачение std_application_base_address равно 0х60400000 и приложения оказались сверху ограничены LFB, который отображается непосредственно на адреса видеопамяти. В общем это не самая удачная организация памяти но предполагалось что ядру будет доступна вся имеющаяся видеопамять а приложения смогут обращаться к ней напрямую без селектора gs. Позже оказалость что на старых видеокартах VESA не показывает правильного размера видеопамяти, что приводило к зависаниям, поэтому сейчас размер LFB устанавливается в 8 Мб.
Что предлагается.
Всё адресное пространство будет поделено на две равные части. Базовые адреса всех сегментов будут установлены в 0 а пределы в в 4Гб-1. Программы будут компилироваться с org 0x80000000 и занимать адреса 0х80000000-0хFFFFFFFF, так что макимальный размер программы и данных составит 2Гб.
Ядро и его данные займут адреса 0-0х7FFFFFFF, из них таблицы страниц 0x7FC00000 - 0х7FFFFFFF, LFB 0x7F400000-0x7FBFFFFF. Память ядра будет защищена от программ битами в таблицах страниц так что программы не смогут его переписать.
Часть изменений можно сделать сразу, для приложений они будут совершенно прозрачны. Окончательно всё можно будет закончить через несколько месяцев, а за это время найти и собрать на SVN исходники всех программ.