Я когда-то на старом васме поднимал этот вопрос - ничего лучше, чем заюзать DMA тогда не предложили. Но DMA тоже не решение.

Предлагаю рассмотреть следующий способ. Пусть наш код ринг-0 расположен в от n до n+x страницах адресного пространства. Физический адрес этих страниц мы, понятно, не знаем. Начнем в цикле менять IA32_APIC_BASE MSR, начиная с нуля, с шагом 4Кб. Напомню, что там хранится _физический_ адрес local APIC. При этом мы пытаемся записать и потом прочитать какое-то значение в страницу с адресом n+1 по любым зарезервированным local APIC адресам в пределах этой страницы. Если local APIC спроецирован на какую-то другую страницу, то чтение после записи вернет ожидаемое значение.
Если local APIC спроецирован именно на эту страницу, что чтение дворда по зарезервированному адресу вернет 0xFFFFFFFF (или 0 - уже не помню). Как только это произошло, то мы узнали физический адрес этой страницы (он равен IA32_APIC_BASE). После чего уже можно в ней строить PDE, записать этот адрес в CR3 и таким образом поиметь полный контроль над памятью. Понятно, что здесь немало нюансов - кроме PDE нужны еще PTE (я для простоты сейчас говорю о простой двухуровневой модели страничного преобразования со страницами 4Кб), но это все решается по аналогичной схеме. Единственное, что меня смущает - что произойдет, когда в цикле local APIC спроецируется на страницу, где расположен текущий выполняемый код? Как показали мои опыты с SMM, при проецировании local APIC на SMRAM процессор берет код SMM-хэндлера из SMRAM, а не из регистров APIC, хотя данные читает и пишет все-таки в APIC. Так что с этим вроде бы все в порядке. Есть еще нюанс с кэшированием. Проекция local APIC на кэшируемую память и обращение к ней приводит к machine check error. Поэтому надо дизаблить кэширование в MTRR, что приводит к необходимости синхронизировать все описанные операции с другими ядрами.

| Сообщение посчитали полезным:

spinz

Норм такой вопрос для какого нибудь osdev.ru

> Физический адрес этих страниц мы, понятно, не знаем.

Почему же не знаем, (CS << 4) + offset(Ip). Или в реалмоде какой то иной механизм адресной трансляции

| Сообщение посчитали полезным:

Речь идет про протектед моде

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Не понятно нафиг это надо.
ОС есть? Спроси у неё какой физ.адрес.
На Win есть MmGetPhysicalAddress() в ядре.

| Сообщение посчитали полезным:

cppasm пишет:
Не понятно нафиг это надо.
Кто в курсе, те поймут

Добавлено спустя 3 минуты
Dr0p пишет:
Там тоже проблемы адрес вычислить нет, прямой доступ к таблицам трансляции имеется в км.
правда? а подумать в голову не приходит мысль?

| Сообщение посчитали полезным:

spinz

А что делать с физическими адресами, ну допустим мы их вычислили ?

| Сообщение посчитали полезным:

В cr3 новую табличку страниц

| Сообщение посчитали полезным:

Для чего новую ?

Чем текущая не устраивает, тем более что в новом АП данных не будет. Зачем выделять новую память таким извращённым способом ?

| Сообщение посчитали полезным:

Похоже, что Инде не понимает сути страничной адресации. АП остается тем же, меняется отображение его на физпамять. Если, например, по каким-то причинам при прежней адресации ты не мог достучаться до какой-то физ.страницы (ее тупо нет в PTE), то сейчас ты сможешь рулить самостоятельно.

Добавлено спустя 4 минуты
Dr0p пишет:
Зачем выделять новую память таким извращённым способом ?
Авер теоретически может контролить вызов сервисов ОС. А тут он совсем мимо. И плюс - абсолютно независимо от ОС. Этот способ сработает хоть в лине, хоть в винде

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

spinz

> АП остается тем же, меняется отображение его на физпамять.

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

> какой-то физ.страницы (ее тупо нет в PTE), то сейчас ты сможешь рулить самостоятельно.

А откуда мне знать физические адреса^
Тоесть мне данные из диска достать самостоятельно, даже определив по PA для VA.. переписав пол ОС!?

> Этот способ сработает хоть в лине, хоть в винде

А в чём собственно способ" заключается ?
Что то связанное с формированием нового АП(cr3). Но для чего, как и что ?

| Сообщение посчитали полезным:

cppasm пишет:
А тот же код и данные которые были в старых физ.страницах в новых откуда возьмётся?
Ты *? от смены мапинга в физических страницах внезапно все пропадет? Иди маны читать, даже Инде в этом слегка шарит

Добавлено спустя 0 минут
Dr0p пишет:
этим занимается менеджер памяти ОС
ты бы хоть название треда прочел

| Сообщение посчитали полезным:

spinz, курить надо меньше
Процесс оперирует виртуальными адресами.
Допустим код расположен в странице с VA VA_BASE которая замаплена на PA_BASE.
Ты взял и сменил отображение для VA_BASE на другую физ. страницу - и чё?
В старой физ. странице то код останется, только после смены отображения он никому нафиг не нужен.
А в новой физ. странице на которую ты отобразил VA_BASE его нету. Всё рухнет.
Так что маны иди сам кури, знаток.
А с таким подходом удачи, будешь долго ответы ждать...

| Сообщение посчитали полезным:

cppasm

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

Лет 5 назад было несколько подобных идей, реализовано ничего небыло(кроме ядерного монитора - side"). Я помню начальную задачу - планировалось расшарить общую память ядра на процессы и таким образом каждый ав процесс читал бы не общую системную, а локальную память, соответственно не видя патч ядра.

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



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

Я вообще последнее время воспринимаю подобных ядерщиков" как не вполне адекватных людей.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Не понятно ничего про идеи тс
Да никто не сомневался. Если сервисы ОС похуканы, то как ты будешь _независимо_ управлять памятью?
Или код должен быть ОС-независимым.
Понятно, что реализация подобных вещей и квалификация Инде лежат в разных вселенных.

| Сообщение посчитали полезным:

spinz

> Или код должен быть ОС-независимым.

Пример такой приведи.

> Если сервисы ОС похуканы

Какие есчо сервисы" и зачем ?

> что реализация подобных вещей и квалификация Инде лежат в разных вселенных.

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

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Пример такой приведи.
Ну ты пишешь малварь, идро которой должно одинаково работать под линем и виндой например.

Ну или идро отладчика с аналогичной функциональностью.

| Сообщение посчитали полезным:

spinz

> идро которой должно одинаково работать под линем и виндой например.

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

-----
vx

| Сообщение посчитали полезным: BlackCode

Ты просто не понимаеш о чем речь.

| Сообщение посчитали полезным:

да тут, по ходу, уже ни кто не понимает

| Сообщение посчитали полезным:

difexacaw пишет:
Я ведь не просто так спросил пример, это в принципе невозможно, так как разные архитектуры
Если зверюку загрузить до старта винды то уже пофиг трах*й память как хочешь но это невозможно так как сразу спалят

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

difexacaw пишет:
Я ведь не просто так спросил пример, это в принципе невозможно, так как разные архитектуры.
Это вполне возможно. Ядро одно - плагины под архитектуры разные. Ядру отладчика не надо знать рядом с кокой ОС оно вертится. Достаточно реализовать поддержку отладочного фунционала - int1,3, брейки по ио, памяти и бранчам. Ну и независимое управление памятью - для той же трассировки по #PF

| Сообщение посчитали полезным:

spinz

> Ядро одно - плагины под архитектуры разные.

Какие есчо плагины и где одно ядро, заканчивай со скриптами грибами

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
Какие есчо плагины и где одно ядро
Одно ядро для единого управления памятью и брейками в разных ОС, плагины - для реализации функционала в каждой ОС

| Сообщение посчитали полезным:

spinz

https://github.com/changeofpace/VivienneVMM

| Сообщение посчитали полезным: