Почему 64-битный режим (длинный режим) не использует регистры сегментов?
Я начинающий уровень студента :) я изучаю архитектуру intel, и я изучаю управление памятью, такое как сегментация и подкачка. Я читаю руководство Intel, и довольно приятно понимать архитектуры intel.
однако мне все еще интересно кое-что фундаментальное. Почему в 64-битном длинном режиме все регистры сегментов собираются в бит 0? Почему система больше не использует сегментные регистры?
потому что размер системы 64bit (например, GP регистры) достаточно, чтобы содержать эти логические адреса сразу? Правильно ли работает защита в 64-битном режиме?
Я попытался найти 64-битную адресацию, но не смог найти в Google. Возможно, у меня ужасные навыки поиска или мне могут понадобиться некоторые специальные предыдущие знания для поиска в google.
поэтому я хотел бы знать, почему 16bit сегментных регистров не будут использоваться в 64-битном режиме, и как защита может работать правильно в режиме 64bit.
спасибо ты!
2 ответов
в некотором роде, когда вы выполняете адресацию типа массива ("индексированного") с помощью общих регистров, вы делаете то же самое, что и регистры сегмента. В плохие старые времена 8-битного и 16-битного программирования, многие приложения требуют гораздо больше данных (и иногда больше кода), чем 16-битный адрес может достичь.
Так много процессоров решили это, имея большее адресное пространство памяти, чем 16-битные адреса могли достичь, и сделали это области памяти, доступные с помощью "сегментных регистров" или аналогичных. Программа установит адрес в "регистре сегментов" на адрес выше (65536 байт) 16-битного адресного пространства. Затем, когда определенные инструкции выполнялись, они добавляли указанный адрес инструкции в соответствующий (или указанный) "регистр сегментов" для чтения данных (или кода) за пределами диапазона 16-разрядных адресов или 16-разрядных смещений.
однако, ситуация сегодня противоположная!
Как так? Сегодня 64-разрядный процессор может адресовать более (не менее) всего адресуемого пространства памяти. Большинство 64-разрядных процессоров сегодня могут обращаться к чему-то вроде 40-бит к 48-битам физической памяти. Правда, нет ничего, чтобы остановить их от адресации полного 64-битного пространства памяти, но они знают, что никто (кроме АНБ) не может позволить себе столько ОЗУ, и, кроме того, повесив столько ОЗУ на шину процессора, загрузит его емкостью и замедлит доступ к памяти за пределами чипа процессора.
, текущее поколение основных процессоров может обращаться к 40-битам к 48-битам пространства памяти, что составляет более 99,999% рынка, когда-либо представлявшего себе достижение. Обратите внимание, что 32-бит-это 4 гигабайта (которые некоторые люди сегодня превышают в 2, 4, 8, 16 раз), но даже 40-бит могут адресовать 256 * 4GB == 1024GB == 1TB. В то время как 64GB ОЗУ является разумным сегодня, и, возможно, даже 256GB в крайних случаях, 1024GB просто не нужен, за исключением, возможно, 0.001% приложений, и недоступен для сапог.и если вы находитесь в этой категории 0.001%, просто купите один из процессоров, которые адресуют 48 бит физической памяти, и вы говорите 256TB... что в настоящее время непрактично, потому что он загрузит шину памяти с слишком большой емкостью (возможно, даже до того момента, когда шина памяти полностью перестанет работать).
дело вот в чем. Когда ваши обычные режимы адресации с обычными 64-разрядными регистрами уже могут адресовать значительно больше памяти, чем ваш компьютер может содержать, обычная причина добавлять регистры сегмента исчезает.
Это не означает, что люди не могли найти полезные цели для регистров сегментов в 64-разрядных процессорах. Могли бы. Несколько возможностей очевидны. Однако с 64-разрядными общими регистрами и 64-разрядным адресным пространством нет ничего, что общие регистры не могли бы сделать, что могут сегментные регистры. И регистры общего назначения имеют очень много целей, которых сегментные регистры не имеют. Поэтому, если кто-то был планируя добавить больше регистров в современный 64-битный процессор, они добавят регистры общего назначения (которые могут делать "все"), а не добавлять очень ограниченные "сегментные регистры".
и действительно, они есть. Как вы могли заметить, AMD и Intel продолжают добавлять больше регистров общего назначения [sorta] в регистр-файл SIMD, а AMD удвоила количество регистров общего назначения [truly], когда они разработали свои 64-разрядные процессоры x86_64 (которые Intel скопировала).
большинство ответов на вопросы о ненужности сегментных регистров в 32/64 битном мире всегда адресации памяти. Мы все согласны с тем, что основной целью сегментных регистров было обойти ограничение адресного пространства в 16-битном мире DOS. Однако с точки зрения безопасности сегментные регистры обеспечивают 4 кольца изоляции адресного пространства, которая недоступна, если мы делаем 64-битный режим, скажем, для 64-битной ОС. Это не проблема с текущими популярными ОС, такими как Windows и Linux, которые используют только ring 0 и ring 3 с двумя уровнями изоляции. Кольца 1 и 2 иногда являются частью ядра, а иногда частью пользовательского пространства в зависимости от того, как написан код. С появлением аппаратной виртуализации (в отличие от виртуализации ОС) с точки зрения изоляции гипервизоры не совсем вписывались ни в кольцо 0, ни в кольцо 1/2/3. Intel и AMD добавили дополнительные инструкции (например, INTEL VMX) для корневых и некорневых операций виртуальной машины.
Так что смысл сказанного? Если разрабатывается новая безопасная ОС с 4 кольцами изоляции, мы сталкиваемся с проблемами, если сегментация отключена. В качестве примера мы используем по одному кольцу для аппаратного кода mux, кода гипервизора /контейнеров/VM, ядра ОС и пользовательского пространства. Таким образом, мы можем обосновать использование дополнительной безопасности, обеспечиваемой сегментацией, на основе требований, изложенных выше. Однако Intel / AMD по-прежнему позволяют регистрам сегментов F и G иметь ненулевое значение (т. е. сегментация не отключена). К насколько мне известно, никакая ОС не использует этот луч надежды написать более безопасную ОС / гипервизор для аппаратной виртуализации.