Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Нужны ли эти 4 кольца? Есть ли планы на них — что типа в будущем ОС будет использовать все 4 кольца? S>Или же проще управлять доступом на уровне ОС?
Тут вопрос к типу ядра: микроядро vs гибрид vs монолит. Вытеснив драйверы устройств из 0-го кольца мы получаем микроядро, когда драйверы не могут влиять на работу друг друга или супервизора — общей части ядра.
Плюс использования этих колец — большая надежность (нет BSOD, kernel panic и т.д.).
Минус — скорость работы системы из-за относительной дороговизны перехода между кольцами защиты.
Сейчас, выполнение, к примеру открытия файла, сводится к системному вызову — однократному переключению в 0-е кольцо. А уже там, практически бесплатно он передастся между драйверами файловой системы, блочных устройств, фильтрами антивируса в одном адресатном пространстве. Использование дополнительных колец означает, что вместо одного перехода будет их кучка — когда тому или иному драйверу нужно будет выполнить операции доступные супервизору. И следовательно, это выльется в замедление всего ввода-вывода. Причем, в целом для подобной микроядерности достаточно и двух колец — но это ещё сильней увеличивает число переходов между ними. Справедливости ради, нужно отметить, что дороговизна переходов во многом связана не с аппаратными проблемами, а с архитектурой, которая требует выполнения кучки дополнительных операций, т.е. при большом желании можно сделать ОС использующую микроядро, переходу между защитой и с относительно небольшой 5-20% просадкой производительности.
Прожекты 80-х.
S>Пишут, мол, современные ОС используют 2 кольца в оснвовном. А могли бы все 4. S>Вопрос такой. Нужны ли эти 4 кольца? Есть ли планы на них — что типа в будущем ОС будет использовать все 4 кольца?
Современный ARM:
кольцо 0 (в его терминах, Exception Level 0) — user — соответствует 3-му в x86.
Exception Level 1 — supervisor — соответствует 0-му в x86. Аналогов колец 1, 2 из x86 нет.
Exception Level 2 — hypervisor — реализуется средствами виртуализации в x86.
Exception Level 3 — примерно соответствует SMM в x86 (делится ещё и на non-secure и secure).
RISC-V — похожая схема (hypervisor был, временно отменён до выяснения; secure EL3 в штатной спеке нет).
Заметим, что и направление отсчёта (что считается нулём) перевернулось.
Видимо, новые разработки будут иметь те же свойства.
S>Или же проще управлять доступом на уровне ОС?
Оказывается, именно так. По крайней мере пока не будет новых теоретических концепций.
Здравствуйте, m2l, Вы писали:
m2l>Тут вопрос к типу ядра: микроядро vs гибрид vs монолит. Вытеснив драйверы устройств из 0-го кольца мы получаем микроядро, когда драйверы не могут влиять на работу друг друга или супервизора — общей части ядра.
MacOS — микроядерная?
На ARM есть EL0 — user и EL1 — supervisor. (И уровни выше.) Промежуточных между ними нет.
Если есть непривилегированные драйверы, они в такой схеме будут иметь EL0, как и простые пользовательские программы.
m2l>Сейчас, выполнение, к примеру открытия файла, сводится к системному вызову — однократному переключению в 0-е кольцо. А уже там, практически бесплатно он передастся между драйверами файловой системы, блочных устройств, фильтрами антивируса в одном адресатном пространстве.
Я уже спрашивал в соседней теме, повторю: чем "адресатное" пространство отличается от адресного? Есть важные отличия?
m2l>Справедливости ради, нужно отметить, что дороговизна переходов во многом связана не с аппаратными проблемами, а с архитектурой, которая требует выполнения кучки дополнительных операций,
Task switching на x86 сильно медленнее вертикального переключения по syscall.
m2l> т.е. при большом желании можно сделать ОС использующую микроядро, переходу между защитой и с относительно небольшой 5-20% просадкой производительности.
При современной конкуренции это не "небольшая" просадка.
Здравствуйте, netch80, Вы писали:
N>MacOS — микроядерная? N>На ARM есть EL0 — user и EL1 — supervisor. (И уровни выше.) Промежуточных между ними нет. N>Если есть непривилегированные драйверы, они в такой схеме будут иметь EL0, как и простые пользовательские программы.
Как и Windows — гибридная.
m2l>>Сейчас, выполнение, к примеру открытия файла, сводится к системному вызову — однократному переключению в 0-е кольцо. А уже там, практически бесплатно он передастся между драйверами файловой системы, блочных устройств, фильтрами антивируса в одном адресатном пространстве.
N>Я уже спрашивал в соседней теме, повторю: чем "адресатное" пространство отличается от адресного? Есть важные отличия?
Возможно просмотрел. Клавиатура поменялась, пока не привыкну, думаю старую может вернуть.
m2l>>Справедливости ради, нужно отметить, что дороговизна переходов во многом связана не с аппаратными проблемами, а с архитектурой, которая требует выполнения кучки дополнительных операций,
N>Task switching на x86 сильно медленнее вертикального переключения по syscall.
Ну да.
m2l>> т.е. при большом желании можно сделать ОС использующую микроядро, переходу между защитой и с относительно небольшой 5-20% просадкой производительности.
N>При современной конкуренции это не "небольшая" просадка.
Смотря с какой стороны заходить. Гипервизоры в облаках для некоторых видов нагрузки примерно 5-15% perfomance вычитают, но это не мешает крутить на них такую нагрузку. Поэтому, для некоторых кейсов, большая стабильность и безопасность системы могут оправдывать эти проценты. С другой стороны из-за них у нас царствуют гибриды, а MacOS, Windows, Linux часть драйверов вытащили в пользовательский режим.
Здравствуйте, Shmj, Вы писали:
S>Об этом:
S>Image: 255px-Priv_rings.svg.png
S>Пишут, мол, современные ОС используют 2 кольца в оснвовном. А могли бы все 4.
Это IA32 (i386) имеет 4 аппаратных уровня. А есть ещё (были) PowerPC, MIPS и Alpha, ARM... И современные ОС на них тоже работают. Подозреваю, в каких-то процах есть только два уровня
S>Вопрос такой. Нужны ли эти 4 кольца? Есть ли планы на них — что типа в будущем ОС будет использовать все 4 кольца?
Спроси у кого-нибудь, кто ОС пишет. У Торвальдса, например
Здравствуйте, Shmj, Вы писали:
S>Об этом:
S>Image: 255px-Priv_rings.svg.png
S>Пишут, мол, современные ОС используют 2 кольца в оснвовном. А могли бы все 4.
S>Вопрос такой. Нужны ли эти 4 кольца? Есть ли планы на них — что типа в будущем ОС будет использовать все 4 кольца?
S>Или же проще управлять доступом на уровне ОС?
В VAX/VMS использовали все четыре уровня (с порядком могу напутать).
1) Прикладная программа
2) ОС
3) Драйвер
4) Супервизор
VAX/VMS была крута, поэтому Intel заложился на её возможности.
Сейчас обычно используются только два уровня: Прикладной и ОС (Драйверы вшиты в ОС).
Я слышал, что вроде бы виртуальные машины используют ещё один уровень.
Здравствуйте, alpha21264, Вы писали:
A>Сейчас обычно используются только два уровня: Прикладной и ОС (Драйверы вшиты в ОС). A>Я слышал, что вроде бы виртуальные машины используют ещё один уровень.
Виртуальной машине надо, чтобы некоторые совершенно "простые" команды, типа PUSHF/POPF, вызывали исключение, чтобы можно было их перехватить и немного изменить поведение — подставить флаг привелегерованного режима или поймать попытку программы его изменить ("мудрецы" из интела ухитрились засунуть этот флаг туда же, где хранятся "обычные" арифметические флаги, типа переполнения).
Я когда-то читал довольно подробную статью на эту тему. В общем, хитроумно манипулируя кольцами исполнения, этого эффекта можно добиться, с некоторым трудом и проявив некоторую изобретательность. Но деталей, разумеется, не помню.
У более современных процессоров этих хитростей уже не требуется, так называемая поддержка виртуализации именно в том и заключается, что все, что нужно, процессор сам отдает (в виде аппаратных исключений) гипервизору, а всякую возню с флагами эмулирует сам.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, alpha21264, Вы писали:
A>>Сейчас обычно используются только два уровня: Прикладной и ОС (Драйверы вшиты в ОС). A>>Я слышал, что вроде бы виртуальные машины используют ещё один уровень.
Pzz>Виртуальной машине надо, чтобы некоторые совершенно "простые" команды, типа PUSHF/POPF, вызывали исключение, чтобы можно было их перехватить и немного изменить поведение — подставить флаг привелегерованного режима или поймать попытку программы его изменить ("мудрецы" из интела ухитрились засунуть этот флаг туда же, где хранятся "обычные" арифметические флаги, типа переполнения).
Ну да.
Есть два варианта, что требуется для полной виртуализации. Один — классика Popek+Goldberg — чтобы все "sensitive" команды были привилегированными. Тогда перехватчик отработает их по-своему. Но это может быть слишком дорого, как в случае тех же pushf/popf.
Другой — что есть видимая гостю часть состояния и есть где-то в тени реальная часть, которая по-настоящему влияет на состояние и которой управляет хозяин. Это делается, например, ещё в V86 режиме (386 и далее) — sti/cli манипулируют видимым гостю флагом, а реальное управление прерыванием делается через служебные регистры. Это делается в x86, например, для такого: smsw, sldt, sgdt, отдача реального CPL по pushf непривилегированные, и это пытаются сохранять. Но реальные значения контролирует таки хозяин.
Вообще я хочу как-нибудь разобраться, что сделано в S/370...System/Z — там ещё во времена 370-х сделали так, что виртуализация не выше примерно 3 уровней вложенности стоит вообще доли процента(!) Умное управление плюс аппаратное ускорение части действий. Но там реально чёрт ногу сломит в механизме, хотелось бы внятное описание для чайников...
Pzz>Я когда-то читал довольно подробную статью на эту тему. В общем, хитроумно манипулируя кольцами исполнения, этого эффекта можно добиться, с некоторым трудом и проявив некоторую изобретательность. Но деталей, разумеется, не помню.
Я не думаю, что они с этим способны побороться с smsw. То, что я читал, это что без поддержки процессора реально весь исполняемый код перегонялся с анализом и проблемные команды заменялись на спец. вызовы. Подход схожий с тем, как сейчас виртуализируют просто другие архитектуры — где-то есть теневой результат перекомпиляции, который реально и исполняется. Но это сильно дороже.
Pzz>У более современных процессоров этих хитростей уже не требуется, так называемая поддержка виртуализации именно в том и заключается, что все, что нужно, процессор сам отдает (в виде аппаратных исключений) гипервизору, а всякую возню с флагами эмулирует сам.
Здравствуйте, Shmj, Вы писали:
S>Вопрос такой. Нужны ли эти 4 кольца? Есть ли планы на них — что типа в будущем ОС будет использовать все 4 кольца?
Исторический артефакт. Никто так и не смог за эти годы придумать этим 4-м кольцам осмысленного применения, окромя трюкачества, которое используют ранние виртуальные машины, написанные до появления в процессоре прямой поддержки виртуализации.
Очень маловероятно, что эта ситуация изменится в будующем. Насколько я понимаю, более новые процессоры, типа ARM, никаких 4-х колец не реализуют.
Здравствуйте, Pzz, Вы писали:
Pzz>Исторический артефакт. Никто так и не смог за эти годы придумать этим 4-м кольцам осмысленного применения, окромя трюкачества, которое используют ранние виртуальные машины, написанные до появления в процессоре прямой поддержки виртуализации.
Pzz>Очень маловероятно, что эта ситуация изменится в будующем. Насколько я понимаю, более новые процессоры, типа ARM, никаких 4-х колец не реализуют.
(повторюсь для читаемости) ARM — 5 колец, но другие.
Здравствуйте, netch80, Вы писали:
Pzz>>Очень маловероятно, что эта ситуация изменится в будующем. Насколько я понимаю, более новые процессоры, типа ARM, никаких 4-х колец не реализуют.
N>(повторюсь для читаемости) ARM — 5 колец, но другие.
Ужас. Я не знал. Теперь Shmj решит, что за кольцами — будущее.
Здравствуйте, alpha21264, Вы писали:
S>>Или же проще управлять доступом на уровне ОС? A>В VAX/VMS использовали все четыре уровня (с порядком могу напутать). A>1) Прикладная программа A>2) ОС A>3) Драйвер A>4) Супервизор
А в чем суть-то этих колец? Это же просто изоляция адресных пространств, т.е. адресные пространства, доступные
только этом типу программ (например, прикладные). Т.е. как я понимаю, прикладная программа не может
прочитать( и тем более модифицировать) адреса супервизора, но вот супервизор может читать, и, наверное,
менять, как адресное про-во ОС, так и прикладное адресное пространство. Так?
Здравствуйте, Sharov, Вы писали:
S>>>Или же проще управлять доступом на уровне ОС? A>>В VAX/VMS использовали все четыре уровня (с порядком могу напутать). A>>1) Прикладная программа A>>2) ОС A>>3) Драйвер A>>4) Супервизор
S>А в чем суть-то этих колец? Это же просто изоляция адресных пространств, т.е. адресные пространства, доступные S>только этом типу программ (например, прикладные). Т.е. как я понимаю, прикладная программа не может S>прочитать( и тем более модифицировать) адреса супервизора, но вот супервизор может читать, и, наверное, S>менять, как адресное про-во ОС, так и прикладное адресное пространство. Так?
1. Предполагалось, что каждое следующее кольцо обозначает более высокий уровень привилегий, и да, имеет право читать/писать данные низших. И что их нужно в этой схеме больше двух. В принципе, и сейчас это идея неплохая, вопрос в цене переключения.
2. Сейчас часто делают, что супервизору может быть запрещён доступ к пользовательским данным. у Intel это "анклавы" SGX. У RISC-V есть флаг такого запрещения. Смысл — как минимум ограничить вред от нарушений доступа.
Здравствуйте, netch80, Вы писали:
N>Современный ARM: N>кольцо 0 (в его терминах, Exception Level 0) — user — соответствует 3-му в x86. N>Exception Level 1 — supervisor — соответствует 0-му в x86. Аналогов колец 1, 2 из x86 нет. N>Exception Level 2 — hypervisor — реализуется средствами виртуализации в x86. N>Exception Level 3 — примерно соответствует SMM в x86 (делится ещё и на non-secure и secure).
EL3 не делится на secure/non-secure.
EL3 is always in Secure state, regardless of the value of the SCR_EL3.NS bit.
А вот остальные ELx (0,1,2) делятся. Если соотв. NS бит == 1 — то NonSecure.
