Когда приложение из пользовательского пространства выполняется, выполняется ли код ядра также параллельно, например, потоки ядра всегда проверяют вещи?
Нет.
Эта защита памяти происходит динамически, или это будет во время компиляции, ошибка, если код пользовательского пространства пытается записать в ограниченную часть памяти?
Ограничения памяти динамически применяются аппаратным обеспечением управления памятьюв сочетании с режимом CPU .
Ядро настраивает эти ограничения, то есть инициализацию MMU, во время загрузки.
Компилятор, как правило, не выполняет принудительное выполнение адресов.Легко генерировать код, который обращается к массиву за его пределами.Точно так же легко генерировать указатели, которые ссылаются на «ограниченную» память.Обратите внимание, что на этапе компиляции обычно не предполагается среда выполнения (например, занимает ли пространство ядра 1 ГБ или 2 ГБ 32-разрядного виртуального адресного пространства?), Поэтому скомпилированные программы более переносимы.
В общем, что мешает программе пользовательского пространства записывать куда угодно в память, если код ядра не выполняется одновременно?
AПользовательская программа просто выполняется с ограниченными привилегиями ЦП, которые запрещают определенные операции.
Кроме того, она выполняется в своем собственном ограниченном пространстве виртуальной памяти, помимо других процессов.
Кстати, ЦП может (по существу) выполнять только одну инструкцию за раз,так что "код ядра ... выполняется одновременно" , и посылка не имеет значения.
есть что-то еще для этого?
ЦП должен иметь привилегированный режим (ы) ;не все процессоры имеют такую возможность.Процессоры Intel ранних ПК, например, 8088 и 80286, этого не сделали.
«Когда приложение из пространства пользователя выполняется» , ЦП находится в режиме пользователя, режиме с наименьшими привилегиями / возможностями.Код ядра выполняется в режиме супервизора / привилегированного режима (он же ядро).
Когда и где реализована защита?
По мере выполнения каждой инструкции ЦП проверяетэта инструкция в соответствии с текущим режимом процессора.Попытка выполнить привилегированную инструкцию в ограниченном режиме вызывает исключение CPU.
Если инструкция также включает ссылку на память, то MMU проверяет этот адрес виртуальной памяти (т. Е. Пользовательское пространство по отношению к пространству ядра) на основе текущего режима CPU (т. е. пользователь или режим ядра).
Для правильной ссылки на память MMU затем подтвердит, что физическая память сопоставлена для этого виртуального адреса, и что страница памяти является резидентной.
ADDENDUM
Похоже, вы связываете ограничения на доступ к виртуальной памяти и физической памяти.
Ваша пользовательская программа может получить доступ только к нижней виртуальной памяти.Граница определяется ядром.Доступ к пространству ядра запрещен аппаратными средствами, в частности MMU в сочетании с режимом CPU.
Ваша (пользовательская) программа может получить доступ только к той области памяти, которую предоставляет для нее ОС.Языки программирования не имеют встроенных конструкций для альтернативного (например, физического, а не виртуального) адресного пространства.Windows защищенного режима (то есть Windows NT и более поздние версии, а не Windows 3.x) не предлагает программам доступ к физической памяти.Операционные системы POSIX предлагают псевдоустройство / dev / mem для отображения памяти любого физического адреса в пользовательское (виртуальное) адресное пространство.
Поскольку процессоры ARM не имеют инструкций ввода-вывода или адресного пространства, поэтому все операции ввода-вывода отображаются в памяти.Следовательно, / dev / mem - это устройство для доступа к периферийным устройствам, подключенным к процессору ARM под управлением Linux.
Доступ к псевдо-устройству / dev / mem контролируется ядром(как и любой другой файл) с использованием разрешений файловой системы.