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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> > MemoryControl() -- это немного из другой оперы. Вообще, микроядро не оперирует сегментами -- оно оперирует страницами памяти -- flexpages. MemoryControl() позволяет задавать атрибуты страниц памяти. Для IA32 это: Default, Uncacheable, Write Combining, Write Through, Write Protected, Write Back. -- как я понял, это относится к кешируемости. К атрибутам сегментов это не имеет отношения.
>
> Тогда я ещё меньше понимаю. Те сегменты, в которых само микроядро находится - они откуда взялись?

Микроядро загрузил загрузчик kickstart и все эти сегменты он (kickstart) добавил в GDT и потом запустил само микроядро. Внутри себя микроядро как-то управляет всеми этими сегментами, но наружу показывает только несколько дескрипторов GDT и LDT, которыми можно манипулировать через некий API.

> А если GDT и таблицами трансляции логических адресов на физические ведает не микроядро, то выходит, что в них может ковыряться любой желающий?
>

Управляет всем этим _микроядро_. Но по отдельному запросу оно может добавить GDT/LDT дескриптор (если он проходит проверки на правильность, конечно). Причем для userland зарезервированы всего несколько (3 штуки в Fiasco, если мне память не изменяет) GDT-слотов. То есть, управляет этим всем микроядро, в userland может только в ограниченных пределах влиять.

>
> Напоминаю: мы обсуждали нашу ситуацию - когда исходников драйверов нет, поэтому они все непатченные. И сидят они в r3 - потому что в r0 только микроядро (так ведь?).

Я вообще-то предполагал, что патченные -- например, если добыть .obj-и и их дизассемблировать. Тогда можно к дизассемблированному коду применить "патчилку" -- т.е., afterburner.

> Ты сказал, что в таком случае проблем нет - право доступа к портам даём тому драйверу, который к этому порту обратится первым, а всех следующих - обламываем. Но ведь виртуализатор, под которым OS/2 запущена, ничего не знает о её внутренностях; в том числе он не знает, где в памяти заканчивается один драйвер и начинается другой. Точно так же он не знает, драйвер ли это вообще или вовсе даже прикладная программа. Поэтому получается, что право доступа к портам нужно давать всему коду, исполняемому в OS/2.
>

"Право доступа даем первому обратившемуся, а остальных обламываем..." -- речь здесь шла не о драйверах внутри VM, а о серверах и драйверах в _Хостовой_ системе, которая знает про микроядро и микроядро как раз знает, как отличить адресное пространство одного сервера (драйвера) от адресного пространства другого. То есть, к драйверам внутри VM это наверное, неприменимо.

Вообще, я как раз считал, что драйверы _патченные_ afterburner'ом. Если не патчить, а использовать драйверы в неизменном виде, то мне уже подсказали, что для этого уже существуют некие технологии Intel и Microsoft для запуска windows-драйверов внутри VM -- может быть, их можно адаптировать для нашего случая? По крайней мере, как-то они выкручиваются. То есть, здесь надо использовать несколько другую технологию виртуализации, чем оригинальный afterburner. -- Если мы не сможем ничего патчить, то технология виртуализации имхо, должна быть совершенно другая, чем afterburner.


Mon 25 Jun 2007 06:23 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/2005



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.