OS X 10.8 - Адресное пространство макет пост syscall

Question

Я отключил замену полностью на моей OS X 10.8.2 (который запускает ядро ​​x64 LP64) по экспериментальным причинам, я знаю, что это плохая идея.

Когда я делаю системный вызов из любого приложения, как выглядит расположение адресного пространства? То есть Теперь, когда все адресное пространство подключено (без обмена), я могу детерминистически получить доступ к любому допустимому адресу пользователя из ядра и предположить, что страница, содержащая этот адрес, является резидентной в памяти?

Мое понимание - да, но я немного смущен после прочтения, что независимо от того, является ли пользовательское пространство 64-битным или 32-разрядным ядром OS X, всегда работает в 32-битном режиме, и все пространство адреса процесса отключается, и весь 4G принимается по ядру. Это применимо для 10.8.2? Если это так, то я не смогу получить доступ к допустимому адресу пространства пользователя из пространства ядра, не так ли?

Answer 1

Во-первых, 32-битное ядро ​​/ 64-разрядное расположение пользовательского пространства было до 10.7 (на клиентах) или 10.6 (на серверах). 10.5 и ранее поставлялись только с 32-разрядными ядрами, 10.6 и 10.7, поставляемыми как с 32-разрядными, так и с 64-разрядными ядрами (по умолчанию в зависимости от аппаратного обеспечения), а 10.8 и более поздние - только с 64-разрядными ядрами.

Во-вторых, с 64-разрядными ядрами OSX использует раздельный макет виртуального адреса ядра/пользователя. Вы правы, что 32-разрядные версии заменяют почти 4 ГБ при переключении между пользовательским пространством и ядром.

Что касается разыменования указателей пользовательского пространства напрямую - это плохая идея, даже с отключенным подкачкой, и я никогда не отправлял бы такой код. Если вы только возитесь, вам все равно. (одна из причин, по которой это действительно плохо, - это то, что сопоставления памяти могут быть изменены из другого потока)

Answer 2

Даже в 64-битном режиме, где пространство ядра зарезервировано в верхней части адресного пространства (то есть 0xffffff8000xxxxxx), и даже когда есть без обмена, вы не можете получить доступ к памяти пользовательского пространства, если только вы не находитесь в режиме ядра, действующем от имени этого процесса пользовательского пространства. Причина в том, что все адреса являются виртуальными, и вы полагаетесь на CR3 (регистр управления), чтобы сообщить MMU, какие физические страницы принадлежат к какому процессу. Поэтому, хотя в принципе у вас есть доступ ко всей памяти в режиме ядра, без CR3 вы не сможете определить, какие страницы принадлежат к какому процессу.

Таким образом, внутри системного вызова вы можете перемещать данные из памяти пользовательского режима и из него (для этого есть копия/копия, аналогичная копированию Linux [from/to] _user), а также устраняют ошибки страницы, в листы на самом деле меняются местами, как и в обычном случае. Но это только для активной памяти пользовательского пространства - то есть активного процесса. Конечно, есть хаки для доступа к CR3 другим процессам, но это довольно обескураживает (если вы не создаете вредоносное ПО).