Здравствуйте, vasketsov, Вы писали:
V>Мое мнение — гарантировать, что по 0xFxxxxxxx что-то будет определенное (равно как и по 0x6xxxxxxx) — нельзя. Область определения — скажем, все машины, на которых запустится какая-нибудь винда.
В качестве подтверждения , на той же мамке, видео ASUS 3800M 16 мб, Windows 2000 AS + SP3 + fixes.
Можно ссылочку на то, откуда Вы брали состояния shadow регистров и сами их описания? Интересно очень... B непонятно, при чем тут shadow регистры и CS — как они связаны???... Насколько я помню, есть просто 36 битный регистр текущего адреса, он формируется исходя из CS (либо селектора либо смещения) и EIP. Соответственно, после сброса он указывает на 16 байт ниже верхнего предела адресного окна (для 8086 это 0xFFFF0). При первом же дальнем переходе он формируется исходя из значений, указанных в команде данного перехода. Собственно, кешировать сам CS смысла нет — это же просто смещение в таблице селекторов в P режиме...
H_D>PS H_D>Я же тебе говорю: это — чтобы BIOS мог инициализироваться нормально, не пересекаясь с обычной памятью... H_D>например в процессорах 8086 это был бы физический адрес 0xFFFF0, а в 286 — 0xFFFFF0 и т.д. это — просто фича, аналогичная BOOT. вот и все. H_D>А то, что вякие BIOS мапятся на старшие адреса физической памяти — это факт... и то, что нонешние BIOS'ы умеют это разруливать — тоже факт... у меня вот щаз две видюхи..
Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000. А видео — да. Она берет себе подходящую свободную часть адресного пространства при помощи PCI.
PS
Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
Здравствуйте, Andrew S, Вы писали:
AS>Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000.
Вот насчет того, что не мэпятся никогда, я б не стал утверждать. И не все в 128К помещаются. Зачем им это надо, не знаю, но вот кусочек кода из исходников биоса (AWARD, 6.0):
OverlayBios64Kb:
;R136 - start
ifdef ICH
dd 0ffb00000H ;32-bit low address
dd 0 ;32-bit high address
dd 5*1024*1024 ;32-bit length low dword
dd 0 ;32-bit length high dword
dd MEM_RESERVED ;remapped system bios at end of addr.
else; ICH
;R136 - end
dd 0ffff0000H ;32-bit low address
dd 0 ;32-bit high address
dd 64*1024 ;32-bit length low dword
dd 0 ;32-bit length high dword
dd MEM_RESERVED ;remapped system bios at end of addr.
endif; ICH ;R136
Эта хрень лежит в файле ATORGS.ASM. В более старых версиях было только:
OverlayBios64Kb:dd 0ffff0000H ;32-bit low address
dd 0 ;32-bit high address
dd 64*1024 ;32-bit length low dword
dd 0 ;32-bit length high dword
dd MEM_RESERVED ;remapped system bios at end of addr.
Так что, оно похоже даже где-то используется. Где, зачем и почему — не знаю, не интересно мне это было.
AS>PS AS>Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
Да это я почти сразу понял, но с BIOS'ами в наше время тоже все не так просто.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Andrew S, Вы писали:
AS>PS AS>Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
Хм... действительно, чушь я спорол с физическим адресом. Признаю. Он действительно имеет значение fec71. Но сейчас не в этом дело.
Подведу итог всей дискуссии:
1. Выяснили, что под WinNT (права админа) данные по этому адресу можно вытащить средствами \device\PhysicalMemory (см. реализацию Русиновича) или средствами WMI
2. Под Win9x предлагалось писать VxD. По моему мнению это не только сложно, но и неудобно в практическом применении. Ведь данное средство разрабатывается для защиты программы от взлома. А VxD IMHO для этих целей не удобно.
3. По поводу уникальности этого номера — действительно, он не так уж и уникален. (как я понимаю, это относится не для всех версий биоса). Но ведь применяться будет не только защита по номеру материнки — это только одна из частей защиты.
Ваши реальные предложения по пункту 2.
PS/ Прошу сильно не пинать, если что-то пропустил в обсуждении.
SP>2. Под Win9x предлагалось писать VxD. По моему мнению это не только сложно, но и неудобно в практическом применении. Ведь данное средство разрабатывается для защиты программы от взлома. А VxD IMHO для этих целей не удобно.
Под 9х область первого мегабайта мапится в аналогичные виртуальные адреса процесса. Т.е. читая просто по смещению 0x0e0000 вы читаете начало биоса. Никакой VxD не нужен.
Здравствуйте, SPavel, Вы писали:
SP>2. Под Win9x предлагалось писать VxD. По моему мнению это не только сложно, но и неудобно в практическом применении. Ведь данное средство разрабатывается для защиты программы от взлома. А VxD IMHO для этих целей не удобно.
Я уже говорил — посмотри книгу Питрека "Windows 95 System programming SECRETS". Там любопытная програмка PHYS описывается.
SP>3. По поводу уникальности этого номера — действительно, он не так уж и уникален. (как я понимаю, это относится не для всех версий биоса). Но ведь применяться будет не только защита по номеру материнки — это только одна из частей защиты.
IMHO, дурацкая это затея. Прошьет юзер новый биос, и номер этот уже другой станет. Да и модифицировать этот номер прямо в ОЗУ при загрузке винды не намного сложней, чем прочитать, так что такую защиту без особого труда отломать можно. Так что только легальным пользователям геморроя добавишь, а кракерам — пофигу.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Хм. Нда. На нечто похожее я наталкивался, когда получал указатель на область DMI примерно в таком диапазоне. Но. Фишка в том, что даже под NT туда не замапится... Странно все это.
Здравствуйте, Andrew S, Вы писали:
AS>Хм. Нда. На нечто похожее я наталкивался, когда получал указатель на область DMI примерно в таком диапазоне. Но. Фишка в том, что даже под NT туда не замапится... Странно все это.
BIOS вполне может средствами чипсета туда страницу мапить, чисто железячно, безотносительно к виртуальному адресному пространству. Если, конечно, чипсет такое умеет. Например, если просто игнорировать старший бит адреса — получим дублирование нижних 2 Гб на верхние. Доки на чипсет (а второй кусок был для i430TX) у меня дома, так что это не более чем предположение. Но вроде что-то подобное припоминается.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Может, конечно. Ну а какого фига тогда NT туда не позволяет доступаться — она же физическую память позволяет замапить на адресное пространство юзера (\device\PhysicalMemory). Странно все это.
S>BIOS вполне может средствами чипсета туда страницу мапить, чисто железячно, безотносительно к виртуальному адресному пространству. Если, конечно, чипсет такое умеет. Например, если просто игнорировать старший бит адреса — получим дублирование нижних 2 Гб на верхние. Доки на чипсет (а второй кусок был для i430TX) у меня дома, так что это не более чем предположение. Но вроде что-то подобное припоминается.
Здравствуйте, Andrew S, Вы писали:
AS>Может, конечно. Ну а какого фига тогда NT туда не позволяет доступаться — она же физическую память позволяет замапить на адресное пространство юзера (\device\PhysicalMemory). Странно все это.
Ну так RAM-то с "дырками" получится. А сегмент с дырками не сделаешь. Если страницы транслировать, то уже не физическая память получится. Ну а людям из мокрософт зачем-то понадобилось сегмент не на все 4 Гб сделать, а только на имеющеся в системе ОЗУ. IMHO.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Честно говоря, не понял, в чем проблема. Физическая память в NT и так транслируется в адресное пространство процесса при помощи MapViewOfSection. И никаких препятствий сделать это путем простой трансляции страниц я не вижу. Скорее всего, причина в другом. Трансляция на mapped io ports работает же...
S>Ну так RAM-то с "дырками" получится. А сегмент с дырками не сделаешь. Если страницы транслировать, то уже не физическая память получится. Ну а людям из мокрософт зачем-то понадобилось сегмент не на все 4 Гб сделать, а только на имеющеся в системе ОЗУ. IMHO.
Здравствуйте, Andrew S, Вы писали:
AS>Можно ссылочку на то, откуда Вы брали состояния shadow регистров и сами их описания?
В.Л.Григорьев "микропроцессор i486. Архитектура и программирование" в 4 книгах, книга 1. стр. 267-270... ISBN 5-900676-01-3 (c) ТОО "ГРАНАЛ" 1993 г.
Классика... AS>Интересно очень... B непонятно, при чем тут shadow регистры и CS — как они связаны???... AS>Насколько я помню, есть просто 36 битный регистр текущего адреса, он формируется исходя из CS (либо селектора либо смещения) и EIP.
нет... для каждого селектора (CS/ES/SS/DS/FS/GS) есть теневой регистр, который является копией записи в GDT/LDT... AS>Соответственно, после сброса он указывает на 16 байт ниже верхнего предела адресного окна (для 8086 это 0xFFFF0). При первом же дальнем переходе он формируется исходя из значений, указанных в команде данного перехода.
на эту тему я уже все написал в предыдущих постингах...
AS>Собственно, кешировать сам CS смысла нет — это же просто смещение в таблице селекторов в P режиме...
Угу и при выборке каждой очередной команды мы будем:
1. лезть в GDT/LDT (через регистр)
2. проверять, что селектор не за границей GDT/LDT
3. находить через селектор описание сегмента
4. из него считать базовый адрес и
5. потом уже вычислять линейный адрес.
Shadow регистры для всех селекторов созданы для того, чтобы не лазить при каждом обращении в память дополнительно в соотв. таблицы (что просто замедляет комп, т.к. кже на 486 DX2 процессор был в два раза быстрее памяти)...
AS>Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000. А видео — да. Она берет себе подходящую свободную часть адресного пространства при помощи PCI.
Я тебе только что написал, куда они мапятся... AS>PS AS>Товарищ, начавий этот флейм просто накололся, приняв сегмент:смещение за физический адрес, а вы тут все спорите...
А это уже не важно....
Enigma — The Eyes of Truth (The Cross of Changes)
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, Andrew S, Вы писали:
AS>Честно говоря, не понял, в чем проблема. Физическая память в NT и так транслируется в адресное пространство процесса при помощи MapViewOfSection. И никаких препятствий сделать это путем простой трансляции страниц я не вижу. Скорее всего, причина в другом.
Да может и можно было, но обломились.
AS>Трансляция на mapped io ports работает же...
У меня — не работает (с адресами со старшим ненулевым байтом). По крайней мере, утилитка Руссиновича их не показывает.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Hacker_Delphi, Вы писали:
AS>>Не мепятся биосы... Зачем им это. Как и раньше, они живут в 128 килобайтах начиная с 0х0E0000. А видео — да. Она берет себе подходящую свободную часть адресного пространства при помощи PCI. H_D>Я тебе только что написал, куда они мапятся...
Ты уж извини, но написал ты полную фигню. При старте BIOS (если он 128 Кб) сидит по адресам E0000 — FFFFF. И выполнение начинается 0xFFFF0, а не с 0xFFFFF0. На первом пне, по крайней мере. Я уж не говорю про 286. А с RAM он не конфликтует потому, что RAM в этот момент нет вообще (по крайней мере, в конце первого мегабайта), она выключена средствами чипсета. Дальнейшее зависит от биоса, AWARD'овский копирует себя куда-то то ли в 30000h, то ли в 50000h, выключает доступ к ROM, включает R/W доступ к RAM E0000 — FFFFF и копирует себя туда. Потом запрещает W по этим адресам.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Ты уж извини, но написал ты полную фигню. При старте BIOS (если он 128 Кб) сидит по адресам E0000 — FFFFF. И выполнение начинается 0xFFFF0, а не с 0xFFFFF0. На первом пне, по крайней мере. Я уж не говорю про 286. А с RAM он не конфликтует потому, что RAM в этот момент нет вообще (по крайней мере, в конце первого мегабайта), она выключена средствами чипсета. Дальнейшее зависит от биоса, AWARD'овский копирует себя куда-то то ли в 30000h, то ли в 50000h, выключает доступ к ROM, включает R/W доступ к RAM E0000 — FFFFF и копирует себя туда. Потом запрещает W по этим адресам.
нет это ты извини... как уже писалось, адрес с которого начинается выполнение BIOS кажется (и является) адресом CS:IP, но с 286 процессора (как тебе, наверное известно) CS ничего не говорит о физическом размещении памяти...
Я, между прочим, ссылку на книгу дал, в которой это написано... и я писал, что данный адрес (0xFFFFFFF0) — это для 486-го процессора... я даже привел адреса для 8086 и 80268... так что ты не прав в корне...
Enigma — I love You... I'll Kill You (The Cross of Changes)
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
H_D>нет... для каждого селектора (CS/ES/SS/DS/FS/GS) есть теневой регистр, который является копией записи в GDT/LDT...
Правильно. Записи в LDT/GDT. Но он никак не CS или еще там что. Это связка регистров, и она хранит дескриптор ЦЕЛИКОМ, ну или почти целиком. По крайней мере так было для 486-х. Соответственно, для дальнейших поколений x86 процессоров все еще более сложно. И EIP внутри тоже как такового нет — есть некий указатель на текущий физический адрес выборки команд, к тому же 36 битный, да еще и не один — а для каждого конвейра несколько... Так что говорить о значениях "теневых" CS по меньшей мере неразумно, т.к. нет их. Есть кеширование дескрипторов. Более того. Есть еще и кеширвание страничных таблиц. Но это уже другая тема.
Так, про начальный адрес выполнения тебе уже сказали, далее..
H_D>Угу и при выборке каждой очередной команды мы будем: H_D>1. лезть в GDT/LDT (через регистр) H_D>2. проверять, что селектор не за границей GDT/LDT H_D>3. находить через селектор описание сегмента H_D>4. из него считать базовый адрес и H_D>5. потом уже вычислять линейный адрес.
H_D>Shadow регистры для всех селекторов созданы для того, чтобы не лазить при каждом обращении в память дополнительно в соотв. таблицы (что просто замедляет комп, т.к. кже на 486 DX2 процессор был в два раза быстрее памяти)...
Правильно. Только они хранят не значение селектора, а сам дескриптор. CS — просто индекс в таблице дескрипторов. Очевидно, даже хряня "теневой" индекс мы не получим требуемого быстродействия, т.к. будем ползать в таблицу каждый раз для вычисления физ. адреса.
Процессор 486 был не в 2 раза (!!! Откуда такие точные данные Цикл по шине занимал больше одного такта. Даже при пакетной 16-байтовой передаче), а гораздо быстрее памяти. Даже своего кеша первого уровня Именно из-за своей конвейерной архитектуры.
H_D>А это уже не важно....
Это важно Т.к. вопрос был задан неправильно, в связи с чем все полезли в дебри, тогда как все решается простым чтение по физ. адреса 0xF????. Нда.
Здравствуйте, Hacker_Delphi, Вы писали:
S>>Ты уж извини, но написал ты полную фигню. При старте BIOS (если он 128 Кб) сидит по адресам E0000 — FFFFF. И выполнение начинается 0xFFFF0, а не с 0xFFFFF0. На первом пне, по крайней мере. Я уж не говорю про 286. А с RAM он не конфликтует потому, что RAM в этот момент нет вообще (по крайней мере, в конце первого мегабайта), она выключена средствами чипсета. Дальнейшее зависит от биоса, AWARD'овский копирует себя куда-то то ли в 30000h, то ли в 50000h, выключает доступ к ROM, включает R/W доступ к RAM E0000 — FFFFF и копирует себя туда. Потом запрещает W по этим адресам.
H_D>нет это ты извини... как уже писалось, адрес с которого начинается выполнение BIOS кажется (и является) адресом CS:IP, но с 286 процессора (как тебе, наверное известно) CS ничего не говорит о физическом размещении памяти... H_D>Я, между прочим, ссылку на книгу дал, в которой это написано... и я писал, что данный адрес (0xFFFFFFF0) — это для 486-го процессора... я даже привел адреса для 8086 и 80268... так что ты не прав в корне...
Признаю, заглянул в манул на процессор и понял, что прогнал. Первая команда действительно идет на 0xFFFFFFF0. VIA'шный чип VT82C693 область памяти FFFEFFFF-FFFFFFFF мапит на 000Fxxxx. Не понятно только, постоянный это алиас или только на время загрузки, херовые у них даташиты (скорее всего постоянный). Но, насколько я понял, он для RAM тоже действует. И в любом случае AWARD'овский биос ведет себя так, как я написал — это я весьма детально разглядывал когда-то. Для этого тоже средства предусмотрены.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[3]: Чтение данных из физической ячейки памяти
От:
Аноним
Дата:
11.02.03 14:04
Оценка:
SP>Было выяснено, что искомая информация содержится по адресу 0xF000EC71. Вот и всё.....
Это частный случай для AWARD BIOS
В других биосах искосая информация находится по другому адресу
Вот фрагмент из библиотеки читающий номер биоса
Работает под 9Х
void numbios(ParamBlk *parm){
int *address;
int value;
address=(int *)0xFEC71;
value=*address;
_RetInt(value,20);
}
Но к сожалению под NT не пашет.
Александр
Цикл по шине занимал больше одного такта. Даже при пакетной 16-байтовой передаче), а гораздо быстрее памяти. Даже своего кеша первого уровня 
