Кольца привилегий , почему так и ни как иначе

x86 не охватывает все платформы, 4-е кольца с i386

на сколько мне извество с i386 вробеды появилось и сегментирования памяти, это же они реализовали (простите если ошибся), а кольца нет. Да и ядро было стока раз переделано до основания что можно было и это зацепить.

Строго говоря, на современных x86 6 колец. Есть ещё -2 и -1. -2 - SMM, -1 - гипервизор.

эти не затрагиваем. они вне ОС. они должны быть под ней.

x86 не охватывает все платформы, 4-е кольца с i386

Что касается IBM PC compatible, то предки 386-го давно ни на что в осях не влияют. Или вы таки знаете версию Линукса для 80286?

и при чем тут 80286? я говорю о 80386 он же i386.
регистры и система команд 386-ого сохранились до сих пор, как они не могут влиять если 99.(9)% аппаратов с линупсом работает на предках

хе, кольца появились еще в 80286, поле уровня доступа cpl двухбитное - отсюда и 4-е кольца : )

hizel

x86 не охватывает все платформы, 4-е кольца с i386

Это можно понять так, что за бортом x86 остались 8086, 8088 и 80286. (Они и остались, но nobody cares.)

А есть ещё ARM, Power, IA64... И на всех Linux работает. На ARM так вобще нет колец защиты, как в x86, зато есть supervisor, system и user mode.

Хорошо, почему не сделали нормальную поддержку всех колец хотя бы там где они есть, на том же x86

Как ты себе это представляешь на кроссплатформенных системах?

эм, видимо надо было точку поставить ^_^

>на сколько мне извество с i386 вробеды появилось и сегментирования памяти

Нет, сегменты были и в 8086, а в 386 появилась возможность менять сегментацию. Но кроме того, в нём появилась страничная адресация (точно не уверен, может что-то появилось уже в 286).

А по сабжу: два кольца есть в большинстве процессоров с защитой, а 4 только в x86. Поэтому для переносимости лучше использовать два кольца.

А зачем? Какое применение они могли бы найти?

видимо мечта о вынесении драйверов в отдельное кольцо

> А по сабжу: два кольца есть в большинстве процессоров с защитой, а 4 только в x86. Поэтому для переносимости лучше использовать два кольца.

да но реализация их все равно на архитектурном уровне кода ядра каждая своя, чтоб не использовать преимущества ?

>да но реализация их все равно на архитектурном уровне кода ядра каждая своя, чтоб не использовать преимущества ?

Смысл везе один и тот же - kernel space и user space.

Ну видимо абстракция колец защиты всё же присутствует и не является частью HAL, т.е. считается платформо-независимой. Примерно так же, как с сегментами: некоторые говорят, что использование сегментов полезно, но опять же они ни в одной из мейнтримовых ОС используются по минимуму (с flat-моделью).

в 386 появилась возможность менять сегментацию. Но кроме того, в нём появилась страничная адресация (точно не уверен, может что-то появилось уже в 286).

Так всё и было, но страничная адресация в 286 немного не такая. Protected такой как в 386 на нём не реализуется.

дык это неправильно

>дык это неправильно

А что правильно? Реализовать поддержку 4 колец, но при этом жёстко привязать систему к x86?

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

И, кстати, иногда работают. Fuse тому пример.

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

А что правильно? Реализовать поддержку 4 колец, но при этом жёстко привязать систему к x86?

почему мыслите в таком уклоне ? а что нельзя сделать разве дефайнами если не x86 то юзаем как можно на этой архитектуре, если x86 то юзаем все возможности. Хотя даже так не обязательно, можно просто сделать отдельным патчем для x86 архитектуры, если она то наложили патч и получили более защищенное ядро.

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

Видимо в банках причем консервных ты больше разбираешься чем в процессорах. Никакой безопасности лишний уровень не добавляет. Драйверы работают не в адресном пространстве пользовательских задач и не имеют с ними общей памяти. Почитай что такое виртуальная память. Весь обмен данными идет через ядро системы которое на привилегированном уровне, там же менеджер памяти.

>почему мыслите в таком уклоне ? а что нельзя сделать разве дефайнами если не x86 то юзаем как можно на этой архитектуре, если x86 то юзаем все возможности. Хотя даже так не обязательно, можно просто сделать отдельным патчем для x86 архитектуры, если она то наложили патч и получили более защищенное ядро.

Сделай патч. А заодно перепиши все драйверы.

Классический подход это именно 2 кольца. Память ядра закрыта от памяти user-space, ядро может работать с портами. Всё просто и достаточно.

Дефайны и патчи, ну-ну. Там надо менять архитектуру драйверов. Ну будет использовано 3 кольца, ну наверняка получаем заметное снижение производительности, ну получаем усложнение архитектуры и как возможное следствие больше количество ошибок. Якобы получаем «значительное увеличение бы надежности». Допустим отвалился драйвер жёсткого диска или файловой системы, ну краха ядра нет, а ничего не работает. Аналогично, отвалился драйвер сетёвки у сервера --- зачем нужен сервер с неработающий сетвой подсистемой? И что у нас остаётся из драйверов: видео и звуковушка. Возможно, для этих драйверов бы не помешало отдельное кольцо, но драйвер ведь лезет к портам, может писать туда всякую бяку. Допустим поправил настройки чипсета, сбил тайминги памяти и все благополучно скрошилось из-за аппаратной проблеммы.

Драйверы работают не в адресном пространстве

мож я на так понял тебя. Ты говоришь что вынесение модулей на отдельный от ядра уровень не приводит к повышению безопасности ? Чушь! Поясняю: работая в ядре, модуль теоретически (и на всех версия также практически) может подчинить себе не просто ОС, а все ядро, и тогда не одна защита не поможет.

Сделай патч. А заодно перепиши все драйверы.

Да это весьма серьезный и актуальный вопрос. Конечно без вообще модификации модулей не обойтись, но ее можно свести к минимуму, заменить подключаемые хедеры на свои в которых идет враперы на функции к которым обращается модуль. Давайте пока этот вопрос не будем рассматривать. А да если а да кобы...

Классический подход это именно 2 кольца. Память ядра закрыта от памяти user-space, ядро может работать с портами. Всё просто и достаточно.

классический... или устаревший, вот в чем вопрос. По «классике», жаль не помню точной цитаты, «Ха-ха, зачем обычным людям компьютеры»

Дефайны и патчи, ну-ну. Там надо менять архитектуру драйверов. Ну будет использовано 3 кольца, ну наверняка получаем заметное снижение производительности, ну получаем усложнение архитектуры и как возможное следствие больше количество ошибок. Якобы получаем «значительное увеличение бы надежности». Допустим отвалился драйвер жёсткого диска или файловой системы, ну краха ядра нет, а ничего не работает. Аналогично, отвалился драйвер сетёвки у сервера --- зачем нужен сервер с неработающий сетвой подсистемой? И что у нас остаётся из драйверов: видео и звуковушка. Возможно, для этих драйверов бы не помешало отдельное кольцо, но драйвер ведь лезет к портам, может писать туда всякую бяку. Допустим поправил настройки чипсета, сбил тайминги памяти и все благополучно скрошилось из-за аппаратной проблеммы.

Архитектуры драйверов, зачем ?. Отказоусточивость, справедливо, без драйвера на хард или сеть сервер ну нужен, а нужен серверу драйвер для сетевухи позвояющий досить пентагон ? Я думаю тоже ненужен. А он есть, и он стремиться попасть в ядро, и он попадет и хрен его кто выгонет от тудова. Извините за красноречие, я так про руткиты :)

Так много слов и так мало знаний :) Ты так и не понял о чем я тебе говорил. Вынесение кода драйверов на отдельный уровень - это признак как минимум гибридного ядра, коим linux не является а вот windows NT является. Linux - монолитное ядро, и сделано это для повышения скорости работы. Теперь если взять классическую микроядерную архитектуру которую я имел ввиду, там достаточно двух уровней, применение отдельного уровня для драйверов ничего не дает, кроме усложнения системы.

Написать не падающий драйвер можно, а работающий в первом кольце так же быстро, как и в нулевом - нельзя.

linux перестал быть монолитным когда у него появилась возможность динамический подгрузки драйверов, оно стало модульным. Вынесение на одтельное кольцо модулей некоим образом не сделает его микроядерным. И это тут ваще не причем.

Да, я не отрицаю что вынесение модулей на отдельное кольцо сделает их работу чуть медленнее. Но Линус сам выбрал не путь производительности а путь кросспалтформенности, что вытекает из убогой реализации механизма системных прерываний, за которые он «убивает».

Вы почему то думаете только о производительности, а как же безопасность ?

>linux перестал быть монолитным когда у него появилась возможность динамический подгрузки драйверов, оно стало модульным. Вынесение на одтельное кольцо модулей некоим образом не сделает его микроядерным. И это тут ваще не причем.

Ты несешь какую-то ахинею. Модульность и монолитность это перпендикулярные вещи. Монолит - означает что код драйверов работает в одном адресном пространстве с ядром, в одном контексте, имеют общий стек. После вынесения их на другое кольцо это уже будет не монолит. Модульность всего лишь позволяет динамически подключать и отключать к работающему ядру код. В общем не пудри мозги своими псевдознаниями и изучи предмет обсуждения хотя бы поверхностно.

http://ru.wikipedia.org/wiki/Ядро_операционной_системы

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

Из всего выше сказанного можно сделать вывод что на тот момент когда создавалось ядро (или приобретало боле менее оформленный вид) основной акцент был на кроссплатформенность (даже не на производительность), а именно на кроссплатформенность, что ущемляло производительность. Далее когда появились сформировавшиеся понятия о кольцах привелегии, этого не стали реализовавыть исходя из следующих соображенией: а зачем ?, а так будет медленнее, а так будет архитектцрнозависимо. В следствии чего появился такой распространенный и наиболее опасный вид вредоносных объектов как руткиты. При этом начальные версии ядра вообще не предпринимали никакой защиты от этого и модуль в ядре мог сделать все что угодно. А теперь это является весьма актуальной проблеммой от которой пытаются избавится (также нагромождением ядра) но это не получится, ибо такая не безопасная архитектура.

Блин, одни только мнения, как и ваши так и мои. Мож есть где все это описанное словами авторов, или обоснованное как то, чтоб на что то опираться ? А то так получается бессмысленный холивар.

Холиваришь как раз только ты тут. Никакой ставки на кроссплатформенность не было в помине, более того Танненбаум бил себя пяткой в грудь и орал что ты очкарик дальше i386 не уедешь, все 4 кольца уже тогда были известны. На практике микроядерный minix дальше i386 не развивается а linux портирован на все более менее развитые архитектуры. Руткиты как нетрудно догадаться из названия актуальны только если запущены с правами суперпользователя, а теперь вспомни что все время вдалбливают новичкам - не работать от пользователя root, так что единственная лазейка - это дырявость прикладного ПО которое позволяет запустить код с правами суперпользователя, заметь не ядра.

ну вот, уже говорим ка краз о том о чем хотелось.

Руткиты как нетрудно догадаться из названия актуальны только если запущены с правами суперпользователя, а теперь вспомни что все время вдалбливают новичкам - не работать от пользователя root, так что единственная лазейка - это дырявость прикладного ПО которое позволяет запустить код с правами суперпользователя, заметь не ядра.

шикарная фраза, щас я ее немного по другому скажу:

так как дырявость софта будет всегда и быть иначе не может, то всегда будет возможность выполнить код от рута и выполнить модуль который поработит ядро.

А теперь представь ситуацию когда модуль не может повлиять ни как на ядро, потому что ему это не позволяет архитектура (DPL), тогда можно реализовать в ядре любого рода защиту и ее невозможно будет сломать, так как до нее не кто не будет иметь доступа.

> тогда можно реализовать в ядре любого рода защиту и ее невозможно будет сломать, так как до нее не кто не будет иметь доступа.

Такая защита есть — виртуализация. Но накладные расходы — ого-ого какие

>шикарная фраза, щас я ее немного по другому скажу:

А не надо по-другому говорить, это то как на самом деле обстоит дело. С таким же успехом можно сказать что нет идеальной защиты потому что «дырявость софта будет всегда и быть иначе не может» относится и к защите. Более того нет ни одного процессора без ошибок.

>Такая защита есть — виртуализация.

У Intel в силу дефективной реализации эта защита не шибко хорошо работает. Подробности на rom.by.

С таким же успехом можно сказать что нет идеальной защиты потому что «дырявость софта будет всегда и быть иначе не может» относится и к защите

Это дело обстоит так ЩАС. Ибо делают защиту на уровне ядра, далее модуо загрудается в ядро и обходит эту защиту из за ее ошибок.

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

>А теперь представь ситуацию когда модуль не может повлиять ни как на ядро, потому что ему это не позволяет архитектура (DPL), тогда можно реализовать в ядре любого рода защиту и ее невозможно будет сломать, так как до нее не кто не будет иметь доступа.

Баги бывают не только в ядре, но и в железе. И кольца защиты - не панацея. Погугли на тему smm rootkit. Вкратце: удалось создать руткит, который достаточно запустить от рута на виртуальной машине, и вот он уже работает ниже уровня гипервизора, в SMM, имея доступ ко всем ресурсам всех, запущенных на данном сервере систем.

Но речь даже не об этом. Как уже было сказано выше, для реализации поддержки более двух колец защиты придётся попрощаться с кроссплатформенностью и в корне переделать архитектуру ядра.

> Погугли на тему smm rootkit

да слыхал про такой. Щас еще раз погуглил и почти сразу нашел, что это пока что вроде как исследовательская работа и о применении в практике речи и быть не может, очень много ограничений. Я не отрицаю что когдато в будущем это всетаки смодет развиться в нечто что то более применимое. Но все же от программных руткитов это полностью избавит !

Как уже было сказано выше, для реализации поддержки более двух колец защиты придётся попрощаться с кроссплатформенностью и в корне переделать архитектуру ядра

ПАТЧ :)

>ПАТЧ :)

Блин, ну мне реально лень переписывать по второму разу то, что уже было написано. Перечитай тред.

Виртуализация может быть и полностью программной (эмуляция)

я наверно не правильно ваши слова понимаю.

для реализации поддержки более двух колец защиты придётся попрощаться с кроссплатформенностью

поэтому и говорю что патч, если например станция на x86 архитектуры тогда наклыдваем патч

и в корне переделать архитектуру ядра

это и есть суть :)

>Виртуализация может быть и полностью программной (эмуляция)

попробуй bochs и оцени скорость полностью программной эмуляции.