Программирование x86 в защищённом режиме

Привет!



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



http://sergh.pisem.net/protected.html



Читайте и пишите отзывы, буду благодарен.



Что интересно:

— от тех кто уже знает этот самый режим — что я важное пропустил, где я налажал.

— от тех кто ещё не занет — что непонятно, что трудно

— от тех кто знает, как педагогически правильно писать учебники — что я важное пропустил, где я налажал с этой точки зрения.



Что не интересно:

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



P.S. Это дубль темы на RSDN, ваше мнение мне не менее интересно, хотя тут я никого и не знаю. Ссылка на RSDN: http://www.rsdn.ru/Forum/Message.aspx?mid=1481268

 

samples не качаются

 

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

 

выложил правильный samples...

 

качнул спасибо. подскажеш как маскировать порты и на каком эксепшене ловить?

 

Множество описаний одной технологии позваляют ее четче осознавать и лучше применять.

Если затем сделаешь еще описание x64 и IA64 (на русском) будет еще лучше.

 

doctor_Ice

Неа, не подскажу пока Примерно так: надо инициализировать сегмент задачи (Task State Segment, TSS), там есть специальное поле - маска портов, разрешённых для ring 3. Если стоит 1, то можно, если 0, то нельзя (или наоборот, не помню). Подробностей я просто не знаю - не дошёл ещё до этого. А исключение, скорее всего, будет #GP.



NoName

Согласен, что будет лучше Но честно говоря не планирую. Скорее всего, я напишу это дело, по ходу довольно подробно ознакомившись с IA32, а после этого ударными темпами просмотрю интеловские мануалы по x64 и Itanium, просто для общего образования

 

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

 

sergh

В чем проблема инициализации контроллера прерываний у Зубкова? Правилен ли код в аттаче (взято из операционной системы menuetos)?



1250255271__irq.asm

 

halyavin, а в чем то проблема с PIC у тебя? Код то взят, как понимаю из рабочей ОСи? Вектора то на своих "правильных" местах и работают, верно?

А вот это в коде уродство(!): call pic_delay

как и сама pic_delay: ....

автор перестраховался или взял код, что еще от XT было привычным... Задержка между обращеними к портам зачем, если современное железо УЧИТЫВАЕТ СОВРЕМЕННЫЕ шины, скорости, циклы, такты и пр. Тем более, что ВСЕ "это" ISA хозяйство, лишь частичка СОВРЕМЕННОГО ЮЖНОГО МОСТА мамки (см.чипсет!).

А вот если уж надо "подождать", то сегодняшние кодеры харда, пользуются для этого принятыми для этого "портами холостого хода" типа этого (ваш BIOS это имеет...):

OUT 0xEB, AL

или еще встречается

OUT 0xED, AL

значение в AL ЛЮБОЕ!

и никакого JMP... + JMP... + JMP... которые, к тому же

при рассмотрении конвейеризации и тактах(...ГГц) CPU, думаю "вырождаются" в ничто для диаграмм работы шин и портов!!!...

 

halyavin

Официального руководства по i8259A я не нашёл, поэтому верю упоминаемой книжке "Аппаратура персональных компьютеров и её программирование. IBM PS/XT/AT и PS/2".



У Зубкова выставлены в 1 некоторые биты, которые оставлены только для совместимости с 8085, кроме того он инициализирует ПКП в режиме буферизирования. Что такое режим буферизирования нигде не написано, вроде тоже из области 8085. Поэтому код Зубкова работает (я там так и написал), но подход в корне неверен



Твой код не смотрел - сорри, времени нет.

 

1.Не для ring3 разрешённых, а разрешённых на случай уровень привелегий ввода вывода меньше чем у текущего сегмента.

2.Не сама карта (называется это permission bit map - на русском используется термин "двоичная карта разрешения ввода-вывода), а последнее 16и битное слово содержит смещение этой карты. Карта сама может занимать до 8 кб

(64 килобит - адресов портов) но может быть усечена через предел, или вообще через тот же придел "отброшена" (т.е. смещение укажет на выход за предел TSS - процессор считает что карты нет в этом случае)



3. И кодирование наоборот - если 0 - то как раз можно, если 1 - то нельзя.

Точнее #GP(0)

 

Прочитал еще не все (1 глава осталась)

Книга написана очень простым языком (что не может не радовать), но очень сжато (не радует)...

В общем, аффтар пиши дальше... самое интересное впереди...

 

VaStaNi

У меня проблем нет, проблемы есть у некоторых людей с 64-битными процами. Прерывания вызываются не смотря на то, что они все запрещены в контроллере. Может ли BIOS включить APIC или Windows забыть его выключить, и может ли это привести к вызовам прерываний (которые не мешают при обычной работе ОС) даже после их запрета в контроллере?



Правильно ли я понимаю, что задержки не достаточные и их нужно заменить на out? Или их можно наоборот убрать?



Вот такие вот реалии программирования в защищенном режиме...

 

Язык казался мне ясным пока я читал вступление, как только произошёл переход в предметную область, то я (несколько владея предментом) перестал понимать, что написано.



Вот, например, цитата:



Так как все эти регистры (и даже совсем новые, и даже новые команды, про которые я ни слова не сказал) доступны из реального режима, строго говоря, он не может называться «режимом полной совместимости».



«режимом полной совместимости» с чем?

С процессором 8086?

Читая далее



Для 8086 это действительно недопустимый код операции, поэтому с ним всё будет нормально, а вот уже для Intel386 это код вполне корректной инструкции pop fs.



Я впадаю в полную прострацию, потому, что с одной стороны моё предположение подтверждается (в примере фигурирует 8086) с другой стороны, если опкод недопустим для 8086, то почему это названо "нормально", а обратное (предпологаю "ненормально"?) когда опкод допустим?



Что берётся за эталон непонятно, то ли корректное выполнение программ для 8086 на IA32 то ли наоборот.

Обычно под совместимостью понимается что корректно работающие программы под старый процессор X так же корректно работают на процессоре с обратной совместимостью Y. При этом я не разу ещё не слышал обсуждения такого чуда "совместимости" как то что некорректно работающие программы под процессор X так же "совместимо по некорректности" некорректно работали на совместимом новом процессоре Y.

Обратно совместимый процессор Y обычно имеет новые команды, регистры и т.п. и говоря о совметсимости никто не ждёт что программы работающие на новом процессоре Y будут совместимы всегда со старым X.

Если идёт речь о 386+ и 8086\8088 то конечно все новые команды (если говорить только о новом в целочисленных командах) а также все "альтернативные полные размеры" (т.е. наличие префикса 66h) будут возбуждать особый случай 6 на 8086\8088 и не вызывать его на 386+.

Но если речь шла всё-таки о несовместимости (не полной совместимости) между 8086\8088 и реальным режимом 386+ то помимо несовместимости по опкоду присутсвующему только в 386+ (отсутсвующему в 8086) есть ещё туча несоместимостей. Когда именно корректно работающие на старом 8086 программы не будут корректно работать в реальном режиме 386(я подчёркиваю потому что в цитате был пример очень странный когда показывалась некорректно работающая программа в старом 8086 работающая корректно в 386)



Причём скажу больше, есть различия и между 286 по отношению к 386му в этом вопросе, и различия виртуального к реальному внутри 386+ и виртуального к реальному 8086.

Это помимо реального 386 к 8086.



Я думаю, страниц 30 без воды можно посветить этим различиям.



Кроме того, несмотря на то что я интересом начал читать статью (она понравилась мне поначалу и слогом и заявленной структуированностью) мне резко непонравилось как автор спозиционировал себя и читателей в отношении необходимости описываемых знаний. Типа в основном just for fun.



Неудивительно с таким позиционированием что многие заинтересовавшиеся низким уровнем, быстро переходят во всякое кряканье, хаканье и вири, если у них изначально сформировали ущербное собственное восприятие, что им ядер не писать, биосов тоже, уж не говоря об отдельно работающих в защищённом режиме специально созданных контроллеров на базе 386+.

Это заведомо ущербный подход.

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



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

 

The Svin

!

 

The Svin

Во-первых, спасибо, ты похоже действительно читал Теперь по твоему ответу.



Программа на 8086 - она же не просто будет "не работать". Нет такого понятия "не работать вообще". Она вызовет исключение #UD. Её автор мог на это расчитывать. Может он так какую-нибудь свою антиоладочную защиту писал, или ещё что-то - неважно. Важно, что на более новом процессоре он обломится. Это и будет несовместимость. Но к счастью, таких программ немного и проблем это не создаёт.



Вроде бы я в том же самом примечании именно так и написал.



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



Про практическую применимость - вау! Честно, удивлён. Ты первый кто мне говорит, что реально использует. Остальные все больше "никому не нужно, 15 лет назад" и т.п. Но и я не замахивался на реальное использование. Я сейчас немного смягчил то место, где про just for fun, но смысл тот же - 99% программистов (если считать по штукам) никогда его использовать не будут. Я замахивался на то, что изучение защищённого режима даёт понимание того, как работает ОС. Мне больше это интересно. Поэтому да, именно баловаться, играть, экспериментировать. Действительно что-то писать это совсем другая задача. Но лучше сначала поэкспериментировать, и только потом, если захочется - писать.



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

 

The Svin

А ты до конца дочитал, или мой подход тебя настолько неустроил, что остановился посередине?

 

Ага, понял, кажется, эту заковыристую мысль.

Под нормальной работой предпологалось вызов 6го особого случая в 8086, который не будет возбуждён таким опкодом в 386+.

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

И это случай действительно экзотический. И именно он приводится. Причём со словами "единственное что мне приходит в голову". Т.е. автор судит о совместимости о том что "ему пришло в голову", а о том "что в голову не пришло" очевидно судит как не о существующем. Это мне напоминает статью Крыса "Дизассемблирование в уме" где автор явно не владея предметом просто излогает о том какие объяснения "приходят ему в голову" когда он смотрит на опкод.



Приведи мне, пожалуйста, хоть один случай несовместимости реального 386 и 8086 который не касается опкодов отсутвующих в одном процессоре и отсутсвующих в другом (их маленькая тучка, просто интересно владеешь ли ты хоть насколько то предметом)

 

The Svin

Сразу честно признаюсь - нет, не владею Ну могу вспомнить про ПКП, которых в 386 два, а в 8086 один, про A20, которую в 8086 открывать бесполезно.. Команды сдвига, вроде, стали поумнее (точно не помню), но это наверное уже опкоды. Могу глянуть какую-нибудь книжку, поискать там значки ТОЛЬКО_AT или НЕ_XT



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