Поясните пожалуйста насчет колец защиты

Я вот совсем недавно решил подогнать под себя какой-нибудь лин, и стал думать, что мне нужно, а что не нужно. Надумал я не совсем то, но возникло несколько вопросов (и не надо кричать, что я ламер, сам знаю).
Во-первых, почему из 4 колец используются ,как правило, только два? Возможно таким образом получается выйгрыш в производительности, но сегодня производительность такой ценой имхо неактуальна.
Вообще я бы в нулевое кольцо запихал микроядро, (менеджер рамы там, планировщик и еще немного), дрова на 1 кольцо, чтоб они не могли ядро уронить, а то меня бсоды достали уже. Пущай работают помедленнее немного, зато надежно, и даже если винт рассыпался, ядро вполне может вывести сообщение, что отказал драйвер харда, а не оставлять юзера непонятно с чем. Юзерские проги можно на 2 кольцо пихнуть.
В процессе родилась еще пара идей: можно запретить процессу доступ ко всему, кроме своего адресного пространства, т.е. вообще никуда не пускать. Например нужно процессу открыть файл, он пихает в СВОЮ область памяти (специальную) запрос и впадает в спячку. Ядро, обнаружив, что этот процесс хочет открыть файл (посылает сообщение), смотрит поля источника и назначения, затем кидает месагу драйверу. Драйвер возвращает результаты работы таким же макаром. В принципе можно посылать сообщения напрямую. Надо подумать еще.
Также я подумал, что в рамках системы можно стандартизировать IOBuffer, но созданием буфера пускай
занимается ядро (менеджер рамы), но процесс НЕ ДОЛЖЕН иметь прав на изменение служебных структур буфера. Конечно 4 кило на служебные данные - это многовато, но зато размер буфера(поле размера) будет всегда верен, и злобная прога не сможет заставить драйвер сетевухи пропахать пару метров рамы после буфера.
Это пока так, мысли.
Что вы думаете по этому поводу?

 

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

В Винде так в принципе и сделано...Процесс имеет доступ только к своему виртуальному адресному пространству...Процесс может общатся с ОСью только через API, которые и являются мостиком между пользовательским режимом и режимом ядра...Там как раз и осуществляется то, что ты описал выше...

 

Опять изобрел велосипед. Д что же это такое.
А можно - ли в лине без особого гемору перебросить дрова на кольцо повыше? Или это уже серьезный шаг?

 

Не знаю как лине, а в винде есть два типа драйверов: драйверы низкого уровня(уровня ядра) - раньше были .386, .vxd, сейчас .sys и драйверы высокого уровня(работают на пользовательском уровне) - раньше были .drv, теперь скорее всего просто .dll или .cpl и т.д. Т.е. нет смысла "поднимать" драйвер на уровень выше...

 

Не совсем так. Просто сегментация в чистом виде сейчас не используется, она используется со страничной организацией памяти, а страничная организация поддерживает только два кольца -- user (1-3) & supervisor (0).

 

_220
Во всех операционках которые на слуху используется 2 кольца защиты, поскольку процессор то имеет их 4, но вот на уровне страниц ты либо user, либо superrevizor, т.о. только 2 "кольца защиты". Потому если ты перебросиш код на уровень выше (допустим на 2й) то процессоро всеравно будет иметь доступ к памяти на уровне superrevizor, а вот на 3м кольце доступ к памяти уже на уровне user.

 

нельзя
точнее можно, но придется писать свой Linux

 

Вот лажа-то , но хотя бы ситуация с кольцами прояснилась.
Спасибо всем.

 

_220.

Отличная идея, отчего ж.

Я сам об этом думал. Допустим: можем в винде выбранный драйвер исполнять не в 0-м кольце, а в первом (user-моде это вроде 3-ий). У нас получается отличная возможность трассировать какой-нить старфак, устанавливать ему индивидуальную I/O Permission map и еще куча приятных возможностей.

Только это сложно, нужно многое перелопатить... Если будешь писать проект, обещаю немного помогать

 

Chingachguk

Старфак "неломается" не от того что его нельзя трассировать (возми эмулятор BOSH), а потому что он имеет свой внутренний язык програм, и есть необходимость в написании своего декомпилятора этого языка, но парни из SF не глупы, и каждый раз необходим новый декомпилятор. А что касаетс I/O Permission map, ну так это не проблема, уже существует множество софта, лучше почитай Криса Касперски.

 

PROFi

> Старфак "неломается" не от того что его нельзя трассировать [...]

То есть вся проблема с ним (я не знаток старфака!) в том, чтобы разобрать его VM? Зачем же он тогда перехватывает int 1 и т.п.?

> что касаетс I/O Permission map, ну так это не проблема, уже
> существует множество софта

Можно ссылки (реально хотелось бы попользовать!) - ?

> лучше почитай Криса Касперски

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

 

Chingachguk

У Криса есть статья по старфорс, в ней же и программы которые осущетсвляют мониторинг обращений к железу в часности к CD. Не ругай его, он пишет как умеет, лучше возми мануалы к платформе х86 и почитай про отладку.

Зачем же он тогда перехватывает int 1 и т.п.?

А кто тебе мешает его перехватить.
Да вот задачка если стоит хук на адресе в IDT отвечающий за int 1, и паралельно запрещено использовать регистры отладки (т.о. будет возникать int 1), как его перехватить? (есть по меньшей мере 2 решения)

 

PROFi,

> У Криса есть статья по старфорс, в ней же и программы которые
> осущетсвляют мониторинг обращений к железу в часности к CD.

Да ну?! Можно ссылку (также прошу еще раз ссылку на "Утилиты для которых не проблема Permisson Map")?

> Не ругай его

А я его еще за проект "OZMA" хочу замочить. Его достоинств я принижать не собираюсь, стараюсь быть объективным.

> А кто тебе мешает его перехватить.

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

> Да вот задачка если стоит хук на адресе в IDT
> отвечающий за int 1,

Что такое "хук на адресе в IDT"? Вектор указывает в код старфака?

> и паралельно запрещено использовать регистры отладки (т.о.
> будет возникать int 1),

CRx как устанавлицаюцца, так и сбрасываюцца.

> как его перехватить? (есть по меньшей мере 2 решения)

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

 

Что за проект, если не секрет?

 

Видел несколько коленочных ОСей с несколькими используемыми уровнями защиты. Так что в плане реализации это возможно.

 

Про "OZMA": видел в его книжке весьма скептический отзыв про этот а также про проект "SETI" (поиск внеземных цивилизаций). Поскольку являюсь сильно интересующимся данным вопросом то мне было больно читать (ИМХО) поверхностные рассуждения на данную тему.

 

В общем можно подытожить, чего мне ,собственно говоря,
хотелось видеть в оси:
1) принципиальная неронябельность ядра (при отсутсвии в нем ошибок),
для того, чтобы ошибок в нем не было, нужно сделать его минимальным
2)Запретить процессу все, что ему не нужно (механизмы могут быть разные),
например в винде управление я могу передать хоть в середину API-функции,
и результат будет другой, так можно получить что-нибудь, что приложение знать не должно,
или вовсе совершить черти что. Таким макаром можно решить проблему локальной безопасности,
если способ вызова функций драйверов будет только один, то AV перекрывает его, и все дела.
3)Не знаю, может стоит вернуться к сегментам, конечно многое теряется, но зато все проще,
в принципе, дескрипторов должно хватить.
4) Модульность (ну это уже детали реализации), можно сделать ось, которая состоит из микроядра,
да пары основных драйверов, а остальное все так - навешано, и обеспечить четкий и понятный
контроль за компонентами. Имхо сдесь надо конкретно подумать, а потом делать.
Кстати никто не знает, от винды можно открутить гую?

 

можно сделать сегментность на уровне задач, т. е не отказываясь от страничного режима, ввести LDT для каждой задачи, причем база каждого сегмента (SS, DS, CS) будет вычисляться ядром в момент загрузки исполняемого файла, а в самой программе диапозон адресов секций (кода, данных и т. д) будут иметь вид [0, SIZEi - 1], где SIZEi - размер i-ой секции
т. к LDT дескриптор также как и TSS дескриптор может быть разделяемым, то проблемы ограниченности количества задач в системе не будет

 

> Кстати никто не знает, от винды можно открутить гую?

Вроде бы есть муляция win32 под Linux?

rei3er,

да-да еще и TSS! Если мои исследования были верные, в 98 всего одна "задача" - ядро, а флаг "NestedTask" вообще никогда я не видел установленным (а ведь для задачи также можно назначать PermissionMap! или стремные драйвера пускать как задачи).

 

Chingachguk
Все верно, по крайней мере один TSS в системе должен быть -- он содержит длинные указатели стека используемые при смене уровней привилегий кода.