Проблемы с ремаппингом при запуске AWARD BIOS на виртуалке

Если раньше код по адресу 0xe8000 исполнялся из RAM( распакованный original.tmp по адресам

0xE0000 - 0xFFFFF), то после изменения PAM по адресу 0xe8000(0xE000 : 0x8000) - содержимое
микросхемы BIOS(как Вы писали, там запакованный модуль). По моему изменение PAM
в данном случае недопустимо, тк приводит к бессмысленной передаче управления.

Довольно часто случается что диззасемблирование с неправильного адреса,
диззасемблирование данных как кода, диззасемблирование с неверным начальным
режимом описания сегмента(use16/use32) приводит к на первый взгдяд нормальным
командам. Но как правило рано или поздно попадаем на двоичные данные, которые
не могут быть диззасемблированы как команды или просто бессмысленым операциям.

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

Дизассемблирование здесь ни при чем - человек же в рантайме работает, как я понимаю.
IMHO - косячит QEMU.

Да, ситуация ПРИМЕРНО где-то рядом - по 0xE8000 неожиданно "мусор"/"не то". НО

Оно допустимо. На реальной системе. Ибо это BIOS, на реальной системе класса P2 типа работающий (как минимум теоретически, как я понимаю). Т.е. недопустимых с точки зрения реальной системы вещей в нем быть не может. Так?

Вообще-то я бы порыл те же исходники SeaBios (штатный для QEMU) и, в частности, запрос Гуглу
"SeaBIOS 0xe8000 qemu" (это не рецепт, это "на подумать").

P.S.

На мой первый взгляд - это ненормальные команды. Начиная с первой. Да и автор уже это понял/озвучил (что это не код).

P.P.S. Ну, что за "старый гигабитовский AWARD" - мы без понятия. У QEMU вроде как 440FX чипсетом.

И вообще - задачи такого плана (Legacy AWARD в QEMU) уж лет 5 как кажутся мне просто тренировкой мозга.

To Savely
Я возможно неправильно выразился - под недопустимостью я понимал не
невозможность изменения PAM и последующей передачи управления, а то что
автор писал, что он изменял PAM самостоятельно, что вполне может сломать
нормально работающий код.

То есть код BIOS уже не-оригинальный и может не работать. Изменения PAM нарушили
нормальную(задуманную разработчиками) работу кода BIOS, что и привело к
бессмысленным командам.

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

И вопрос к автору - для чего Вы собственно изменяли PAM?
Для этого вносились временные измененя в код BIOS?

Ну, я лично фразу автора понял как "незадолго до этого оригинальный(!) код BIOS был замечен в изменении PAM".

OK просто фраза автора "были в очередной раз исправлены значения"
у меня вызвала ассоциацию с ручным вмешательством.

Если так, тогда абсолютно согласен,что как Вы писали виноват QEMU, тк не
работать этот код код не может, на своей плате то он работает.

В соответствии со спецификацией чипсета (какого?) под который написан Gigabyte
BIOS(какой платы?), я бы посмотрел правильно ли интерпретирует QEMU значения в
регистрах PAM, может быть просто баг в эмуляторе(или эмулируемый чипсет не
соответствует настоящему, под который код BIOS написан).

Благодарю за ответы.
Попробую ответить на возникшие вопросы:
В соответствии с тегами в качестве подопытного был выбран Award BIOS от платы Q35M-S2 . Версия F7. Чипсет - Q35 (в официальной ветке QEMU уже года 2-3 в качестве альтернативы 440-му). Собственно решение задачи запуска реального BIOS на QEMU сводится именно к дописыванию в QEMU недостающей функциональности. В частности в QEMU был неполностью реализован механизм PAM. Из-за этого BIOS зависал сильно раньше. После самодельного исправления - появился определенный прогресс. Очередной затык случился на описанном выше месте. Так как никаких изменений в BIOS не вносилось, то не работать сам по себе он не может, но, зато, QEMU может некорректно имитировать реальную систему, что тут, очевидно, и произошло. Также, все значения которые есть в ОЗУ и в регистрах являются следствием работы QEMU и BIOS, вручную никакие области памяти не менялись.
Переходы в 0xe8000 случались и раньше, но конфигурация PAM была другой, обрабатывался код из ОЗУ. Сейчас исполняется код из флешки и есть мысль что тут что-то не так, как надо. Очередная идея - автор BIOS рассчитывал на те инструкции, которые попали в кэш (в самом QEMU кэш как сущность не очень заметен). Но, во-первых: как это проверить, во-вторых: странным выглядит рассчет на то, что некие данные должны быть в кэше (а если их нет, а если было прерывание и т.д....).
Гугление по адресу 0xe8000, как и по ioport 0xA2 ничего не принесло -не удалось найти упоминаний о том, что это какие-либо особенные значения.
QEMU сейчас вполне корректно интерпретирует значения записанные в PAM и перенаправление в PCI вполне законно с точки зрения логики работы PAM регистров. Но есть подозрение что на маппинг может влиять что-то еще. Что именно - пока не знаю. Думал в сторону MTRR регистров проца, но там задается только политика кэширования, конкретно ремаппингом эти регистры не занимаются.

Что-то подобное может-быть возможно было бы сделать используя SMM, на это уже атака
(грязный прием, противоречащий Intel рекомендациям по написанию BIOS), не думаю что в
нормальном коде BIOS будет что-то подобное.
co-c.net/repository-securite-informatique/Papers/smm_cache_fun.pdf

Вы писали что по 0xe8000 ncpucode.bin(запакованный) и соответственно переход заведомо

неверный, анализировать получившиеся "команды" нет смысла.

Вы проанализировали значения PAM регистров, точно соответствует режиму чтения flash?
Если да, то может быть ошибка возникла где-то ранее, что привело к ошибочномуи вызову
процедуры программирования PAM или на упомянутую последовательнось команд,
делающую переход на 0xe8000.

Есть вариант добавить в BIOS отладочный код и исследовать на реальной системе.
Заменяем команду в интересующем месте на near jmp на неиспользуемое место,
(в том же сегменте), где размещаем отладочный код:
ту команду(ы) которые(ми) пришлось заменить вышеупомянутым jmp(то есть
восстанавливаем команды BIOS запорченные jmp) + код выводящий в port 0x80.
Не забываем сохранить и восстановить все регистры использованные кодом вывода
значений в диагностический port!
По окончании отладочного кода jmp обратно. Относительные смещения внутрисегментных
переходов придется рассчитывать. Очень удобно использовать IDA для этого, и легко
убедится, что все адреса переходов рассчитаны верно.

Какую часть кода обходить и продублировать в отладочном коде и что выводить -
зависит от фантазии и конкретной ситуации. Хорошо если POST card имеет дополнительный
индикатор, например для port 0x81, туда можно выводить например дополнительные
значения(Вы отмечали что участок кода с переходм на 0xe8000 исполняется неоднократно).
Можно добавить код чтения PCI PAM reg, по аналогии с основной процедурой, имеющейся
в BIOS и выводить значения в port 0x81).
Можно сделать задержку в отладочном коде, чтобы успеть заметить показания.
Очень полезно иметь POST card, запоминающую историю POST, с целью дальнейшего
анализа. Или можно попробовать снять video и потом в замедленном режиме просматривать.
Можно вообще сделать останов в нужном месте, но после этого придется восстанавливать
BIOS(на Gigabyte Dual-BIOS особо надеяться не стоит).

Я делал подобное при исследовании BIOS платы P3B-F. С современными Award возможны
трудности с внесением изменнений. Здесь немогу подсказать, тк не интересуюсь
современными платформами вообще. Конечно этот способ трудоемок и легко можно
запортить BIOS, но я все же решил написать об этом.

За ссылку спасибо - посмотрю.
Значения в PAM расшифрованы корректно. Ошибочный переход, приеведший к их перезаписи - не уверен, но все бывает, тоже путь для исследования, спасибо.