Что делает физический адрес 0 в X86 Linux Linux?
$ echo 'Bourbon,Glazed,Turkey,' | sed 's/\([a-z]\),\([A-Z]\)/\1 \2/g'
Bourbon Glazed Turkey,
$
Итак, в vi это то же самое:
:%s/\([a-z]\),\([A-Z]\)/\1 \2/g
То, что оставила ваша прошивка.
В идеальной современной системе процессор вообще никогда не переходит в реальный режим, как я объяснял в этом SU Q&A под названием:В каком режиме современные 64 -битные ПК с чипом Intel запускают загрузочный сектор? , первый КиБ физической памяти не имеет значения, как показал Йохан Мирен в другом ответе здесь. Но многие современные прошивки (до сих пор )имеют поддержку совместимости , а это означает, что
- они могут вернуться (да, обратно , учитывая, что они перешли непосредственно из нереального режима в защищенный режим )из защищенного режима в реальный режим, чтобы запускать системное программное обеспечение, написанное для реальный режим, такой как старые программы загрузки ПК/АТ в MBR и VBR; и
- Они предоставляют старые API прошивки реального режима и настраивают все структуры данных для этих API, на которые опирается вышеупомянутое системное программное обеспечение.
Одной из таких структур данных является IVT реального режима. Старые API прошивки реального режима основаны на инструкциях int, а IVT реального режима заполняется прошивкой как часть ее инициализации указателями на различные подпрограммы обработки прошивки для этих инструкций.
Системному программному обеспечению защищенного режима не нужны старые API прошивки реального режима, и они никогда не запускают процессор в реальном режиме, поэтому IVT реального режима в первом 1 КБ физической памяти не используется. Защищенный режим (v8086 не адресует физический адрес 00000000 и выше, помните. Он обращается к логическим адресам 00000000 и выше, которые транслируются таблицами страниц. )В современных системах EFI микропрограмма передает карту памяти физической памяти загрузчику операционной системы, сообщая ей, какие части зарезервированы для микропрограммы для собственных целей API защищенного режима, а какие части операционная система может использовать бесплатно. просто продолжайте и используйте для его пула физической памяти.Теоретически первая страница физической памяти может относиться ко второй категории.
На практике, во-первых, микропрограммы часто помечают первую страницу физической памяти как «код загрузочных служб», что означает, что операционная система может потребовать ее и просто использовать как часть своей физической памяти. пул памяти, , но только после того, как службы времени загрузки -микропрограммы EFI были отключены операционной системой, и микропрограмма сократилась до предоставления только своих служб времени -времени работы. Пример этого можно увидеть в журнале ядра Linux (с параметром add_efi_memmap), показанным Финнбарром П. Мерфи :
[ 0.000000] efi: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000001000) (0MB), который xe декодирует с помощью другой программы в более удобочитаемой форме -как :
[#00] Type: EfiBootServicesCode Attr: 0xF
Phys: 0000000000000000-0000000000001000
Virt: 0000000000000000-0000000000001000На практике, во-вторых, Linux явно игнорирует этот диапазон физической памяти , даже если прошивка говорит, что можно продолжать и использовать его. Вы обнаружите, что как на EFI, так и на не -прошивках EFI, как только Linux получает карту физической памяти, он исправляет ее(в функции с именем trim_bios_range), что приводит к сообщениям журнала ядра, таким как:
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
Это не столько для того, чтобы справиться с современными прошивками EFI, где реальный режим IVT не является частью API прошивки, сколько для того, чтобы справиться со старыми прошивками PC98, где он является частью API прошивки, но отчет прошивки это (через тот же -тот же API ), что и физическая память, доступная для беспечной перезаписи операционной системой.
Итак, хотя теоретически этот диапазон физической памяти может содержать произвольный код или данные, в зависимости от сиюминутных потребностей распределителей памяти ядра и требования -выгружаемой виртуальной памяти; на практике Linux просто оставляет его нетронутым, поскольку прошивка изначально настроила его.
В вашей системе микропрограмма заполнила ее записями реального режима IVT. Записей IVT в реальном режиме всего 16 :16 дальних указателей, конечно,и если вы посмотрите на свою память с помощью шестнадцатеричного дампа размером 2 -байта, вы увидите это довольно ясно. Некоторые примеры:
- Большинство ваших записей IVT указывают на F000 :FF53, адрес в области ПЗУ микропрограммы реального режима. Вероятно, это фиктивная подпрограмма, которая не делает ничего, кроме
iret. - Запись IVT 1E указывает на F000 :6AA4, таблицу в той же области ПЗУ.
- Запись IVT 1F указывает на C000 :8930, таблицу в области встроенного ПО видеоПЗУ реального режима.
- Запись IVT 43 указывает на C000 :6730, другую таблицу в области встроенного программного обеспечения видеоПЗУ реального режима.
Дополнительная литература
- Финнбарр П. Мерфи (2012 -08 -18 ).Память UEFI V Память E820. fpmurphy.com.
- В каком режиме современные 64 -битные ПК с процессором Intel запускают загрузочный сектор?
Сброс памяти
Вот альтернативный способ сброса содержимого памяти внутри системы вместо того, чтобы делать это извне:
$ head /dev/mem | hexdump -C
00000000 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...S...S...S...|
00000010 53 ff 00 f0 53 ff 00 f0 cc e9 00 f0 53 ff 00 f0 |S...S.......S...|
00000020 a5 fe 00 f0 87 e9 00 f0 53 ff 00 f0 46 e7 00 f0 |........S...F...|
00000030 46 e7 00 f0 46 e7 00 f0 57 ef 00 f0 53 ff 00 f0 |F...F...W...S...|
00000040 22 00 00 c0 4d f8 00 f0 41 f8 00 f0 fe e3 00 f0 |"...M...A.......|
00000050 39 e7 00 f0 59 f8 00 f0 2e e8 00 f0 d4 ef 00 f0 |9...Y...........|
00000060 a4 f0 00 f0 f2 e6 00 f0 6e fe 00 f0 53 ff 00 f0 |........n...S...|
00000070 ed ef 00 f0 53 ff 00 f0 c7 ef 00 f0 ed 57 00 c0 |....S........W..|
00000080 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 53 ff 00 f0 |S...S...S...S...|
...
...
000afea0 00 00 00 00 00 00 00 00 aa aa aa 00 aa aa aa 00 |................|
000afeb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000b0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000c0000 55 aa 40 e9 62 0a 00 00 00 00 00 00 00 00 00 00 |U.@.b...........|
000c0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 49 42 |..............IB|
Анализ
Верхняя часть над 000c0000 может быть связана с загрузчиком. Почему я должен это подозревать? Код 55aah в расположении 000c0000обычно может быть меткой в памяти для таких вещей, как триггер BIOS для запуска вторичного загрузчика.
Однако, учитывая, что этот 55aah находится в диапазоне c0000h -effffh, более вероятно, что эта часть является заголовком расширения PNP :
. Ссылка:Спецификация загрузки BIOS3.3 Devices with PnP Expansion Headers
All IPL devices with option ROMs must contain a valid option ROM header that resides between system memory addresses C0000h and EFFFFh on a 2k boundary and begins with 55AAh. A Device’s booting can only be controlled if it has a PnP Expansion Header. The Expansion Header, whose address resides within the standard option ROM header at offset +1Ah, contains important information used to configure the device. It also contains pointers to code in the device’s option ROM (BCV or BEV) that the BIOS will call to boot from the device. See Appendix A for the structure of the PnP Expansion Header. There are two ways an IPL device with a PnP Expansion Header can be booted. It must contain a BCV or a BEV.
53ff...
Что касается данных 53ffh, которые находятся в начале. Мне непонятно, что это на самом деле. Дальнейшее изучение этого, вероятно, что-то, что ядро Linux написало там после того, как загрузка BIOS MBR была передана ядру Linux для загрузки.
Usually, the bootloader will load the kernel into memory, and then jump to the kernel. The kernel will then be able to reclaim the memory used by the bootloader (because it has already performed its job). However it is possible to include OS code within the boot sector and keep it resident after the OS begins
Продолжая копать, я смог найти этот абзац в исследовательской статье под названием:Внедрение вредоносного кода через /dev/mem:
1 The mem Device
/dev/mem is the driver interface to physically addressable memory. The original intent of both mem and kmem was for assisting in debugging the kernel. We can use the device like a regular character device, using lseek() to select an address offset. The kmem device is similar but provides an image of kernel memory in the context of virtual addressing. The Xorg server makes use of the mem device to access VESA video memory as well as the BIOS ROM Interrupt Vector Table (IVT) located at physical address 0x00000000 to manipulate video modes in VM86 mode. DOSEMU also uses this to access the BIOS IVT to be able to make BIOS Interrupts for various tasks (disk reads, printing to the console, etc).
Ссылки
- Как сделать дамп образа памяти из системы Linux?
- Как сделать дамп физической памяти в Linux?
- Основная загрузочная запись
- Compaq Computer Corporation Phoenix Technologies Ltd. Intel Corporation Спецификация загрузки BIOS, версия 1.01, 11 января 1996 г.
- Анализ памяти Linux -Криминалистическая вики
- Сборка/загрузчик X86
Первоначальная архитектура процессора 8086 (, реализованная как реальный режим в процессорах 80286+ ), не имеет отношения к Linux, который работает в защищенном режиме. По физическому адресу 0 нет таблицы векторов прерываний, вместо этого используется таблица дескрипторов прерываний, содержащая дескрипторы прерываний. IDT может располагаться в любом месте памяти.
Ядро Linux получает карту физической памяти из микропрограммы (BIOS или EFI ), которая сообщает, какие кадры страниц физической памяти можно использовать, а какие зарезервированы или отсутствуют. Диапазон используемых фреймов страниц не является непрерывным, но обычно содержит огромные пробелы. Традиционно ядро x86 Linux пропускало начало физической памяти, даже если она помечена как пригодная для использования. Таким образом, физический адрес 0 не используется ядром Linux.