Не баньте только, вспомнилось  cd:19 (int 21) прерывание

В HEX

Подскажите один момент: для доступа к памяти процесса, во время vm-exit, я решил решил попробовать заменить cr3 с хостового на гостевой для расшифровки виртуального адреса вручную.  При этом оказалось, что доступ к стеку, коду и к всему, находящемуся относительно RIP, остался без каких либо проблем. Я сначала подумал, что это возможно как - то благодаря сегментным дескрипторам, но все они были либо настроены на flat модель, либо указывали на какие - то данные ОС. Та и плюс расчет адреса с ними ведется виртуального, а потом уже в дело вступает paging. Так увот, как такой прикол реализовывается ? А то я даже примерно не представляю, в какую сторону гуглить надо.

P.S.
Гипервизор настроен на виртуализацию уже запущенной ОС

Это ему ответ ?

Нет

Ок, да, из ядра торчат в интерфейсе эти три сискола и их комбинации. Так что можно считать что их три.

(на самом деле 8, но порядок тот же)

Я понял, где собака зарыта.

1: kd> !vtop 12531e000 fffff8023c2e9008
Amd64VtoP: Virt fffff8023c2e9008, pagedir 000000012531e000
Amd64VtoP: PML4E 000000012531ef80
Amd64VtoP: PDPE 0000000004409040
Amd64VtoP: PDE 000000000440af08
Amd64VtoP: PTE 0000000189937748
Amd64VtoP: Mapped phys 00000001b215b008
Virtual address fffff8023c2e9008 translates to physical address 1b215b008.
1: kd> !vtop 1ad000 fffff8023c2e9008
Amd64VtoP: Virt fffff8023c2e9008, pagedir 00000000001ad000
Amd64VtoP: PML4E 00000000001adf80
Amd64VtoP: PDPE 0000000004409040
Amd64VtoP: PDE 000000000440af08
Amd64VtoP: PTE 0000000189937748
Amd64VtoP: Mapped phys 00000001b215b008
Virtual address fffff8023c2e9008 translates to physical address 1b215b008.

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

> ядро замаплено на винде в каждый процесс,

ну звучит логично

для кого то "звучит логично", а для кого то это охренеть, какое открытие :D

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

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

Happy new year everyboby✨✨✨✨

чот с первого числа уже боты полезли(

битки илона маска?

Давайте хвастайтесь, кто чего написал за прошлый год.

я ничего не писал, в плане осдева

Я перешел от горы разбросанных коммитов к работающему на минималках ядру, нормально сложенному в девелоп и доступному для любого желающего запустить cargo run.  Ядро конечно пока совсем тупое но некоторые вещи raspberry типа мейлбоксов или видео фреймбуффера + управление ядром через сериал и отладку через JTAG оно умеет. Начал понимать в итоге как я хочу чтобы выглядели мандаты и работающие с ними интерфейсы.

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

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