RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > MemoryControl() -- это немного из другой оперы. Вообще, микроядро не оперирует сегментами -- оно оперирует страницами памяти -- flexpages. MemoryControl() позволяет задавать атрибуты страниц памяти. Для IA32 это: Default, Uncacheable, Write Combining, Write Through, Write Protected, Write Back. -- как я понял, это относится к кешируемости. К атрибутам сегментов это не имеет отношения.
> 
> Тогда я ещё меньше понимаю. Те сегменты, в которых само микроядро находится - они откуда взялись? А если GDT и таблицами трансляции логических адресов на физические ведает не микроядро, то выходит, что в них может ковыряться любой желающий?
>  
> >> Ладно, в любом случае упомянутый тобой сервер находится точно в таком же положении - он тоже понятия не имеет, кто это к порту ломится.
> >> Поясняю мысль: есть некий кусок памяти (линейной), выделенной под исполнение виртуальной OS/2. В самОй хостовой системе есть какие-то компоненты, ответственные за этот кусок. Но гостевая OS/2 для них - чёрный ящик, а это значит, что они ничего не знают о принадлежности каждого отдельно взятого байта рассматриваемого куска памяти к тому или иному компоненту OS/2. Для них вся OS/2 - одно монолитное приложение.
> > 
> > Вообще, как я понимаю, при пре-виртуализации (так называется технология паравиртуализации, которую использует afterburner) при помощи afterburner обрабатывается именно ядро и драйвера. Критические для виртуализации инструкции "разрежаются" инструкциями NOP так что при загрузке ОС это свободное место заменяется монитором виртуальной машины (wedge) на код, который вызывает этот самый wedge. Причем, так обрабатываются только ядро и драйвера. Usermode-программы таким образом не обрабатываются. Поэтому, если во время работы ОС внутри VM кто-то вызовет "virtualization-sensitive" инструкцию, то происходит TRAP. Обработчик этого trap'а находится в wedge. Он "поправляет" результат вызвавшей его инструкции, если инструкция находится в ядре или драйвере (которые уже патченные). Если же инструкция, вызвавшая TRAP, находится в "левом" коде (т.е., не патченном), то обработчик TRAP'а завершается не успешно и "левая" программа, в которой находится эта интсрукция, просто трапается. То есть, разделение между ядром и левым кодом простое: левый код не патченный, а ядро и драйверы -- патченные.
> > 
> >>> Надо придумать, как за саму OS/2 сделать запрос этих портов и прочих ресурсов у сервера-менеджера ресурсов.
> >> 
> >> Проблема, как мне представляется, не в том, как запросить, а в том, как позволить лазить к портам только конкретному драйверу и запретить всем остальным.
> > 
> > Тут имхо, вопрос в том, как отделить доверяемый код от не-доверяемого. Это делается наверное, просто (отделением патченного (доверяемого) от не-патченного (не-доверяемого) кода). А позволить лазать к портам конкретному драйверу -- такого нет и в существующей OS/2 -- разделение определяется просто тем, какому кольцу привелегий принадлежит программа. Если RING0, то ей все позволено -- она может лазить к любым портам.
> 
> Напоминаю: мы обсуждали нашу ситуацию - когда исходников драйверов нет, поэтому они все непатченные. И сидят они в r3 - потому что в r0 только микроядро (так ведь?).
> Ты сказал, что в таком случае проблем нет - право доступа к портам даём тому драйверу, который к этому порту обратится первым, а всех следующих - обламываем. Но ведь виртуализатор, под которым OS/2 запущена, ничего не знает о её внутренностях; в том числе он не знает, где в памяти заканчивается один драйвер и начинается другой. Точно так же он не знает, драйвер ли это вообще или вовсе даже прикладная программа. Поэтому получается, что право доступа к портам нужно давать всему коду, исполняемому в OS/2.
>  
> >> Линукс (в том числе и драйверы) патчится на уровне исходных текстов, поэтому гипервизор имеет информацию о том, какой именно модуль обращается за ресурсом.
> > 
> > Неа, в Линуксе точно так же -- все RING0 модули могут лазить к любым ресурсам, а для RING3 -- в большинстве своем -- облом.
> 
> Только вот в случае виртуализации драйверы линуксные исполняются в r3, что в сочетании с патчением и делает всю эту технологию возможной. А драйверы OS/2 патчить возможности нет.
>  
> >>>>> Пейджер может решить отобразить i/o flexpages в адресное пространство приложения, и тогда доступ к порту появится, и операция in/out будет успешной.
> >>>> 
> >>>> Но пейджер - он вне OS/2, И он не знает, осевой драйвер это к порту лезет или кто другой. Что делать? Разрешать этот доступ всем без исключения?
> >>> 
> >>> Нет, OS/2 сама модифицируется (наверное, Afterburner'ом) так, что она запрашивает ресурсы у этого пейджера.
> >> 
> >> А толку от модификации? Драйверы лазают к портам управляемых ими устройств, ни у кого позволения не спрашивая.
> > 
> > Но за них заранее ресурсы (т.е., порты) должен запросить модуль wedge (монитор виртуальной машины). Если не запросит, то линух трапнется.
> 
> Не увлекайся, мы OS/2 обсуждаем. Осевое ядро, хоть как модифицированное, не сможет запросить у надзирателя нужные драйверу ресурсы.
>

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~