Runtime smm polling что это
Данная статья продолжает тему углубленного исследования платформы PC,
архитектуры x86 и связанных с ними современных технологий. Рекомендации по
организации рабочего места, объяснение, почему именно DOS выбрана в качестве
полигона для исследований, комментарии по использованию устройства POST Card при
отладке программ, а также описание целевой аудитории содержатся в ранее
опубликованной статье “64-битный
режим под DOS: исследовательская работа № 1”.
Разделы 1-7 содержат теоретические сведения. Опытный специалист может
начинать чтение с раздела 8, в котором на ассемблерном уровне рассматривается
практический пример – считывание блока из SMRAM и сохранение в виде двоичного
файла.
Расширенные реализации. Диапазоны ASeg, TSeg
В данной статье и приведенных далее примерах, при рассмотрении доступа к
памяти SMRAM, используется диапазон адресов 000A0000h-000BFFFFh, расположенный
ниже 1MB (A-Segment). Вместе с тем, современные платформы также поддерживают
доступ к SMRAM в диапазоне адресов выше 1MB (T-Segment). Его планируется
рассмотреть в последующих публикациях. Подробности в [6], [13] ,[14], [15].
История вопроса
Режим System Management Mode (SMM) как специальное состояние
процессора, используемое для выполнения функций по управлению платформой,
появился в процессорах Intel и AMD в середине 90-х годов прошлого века.
“Улучшенные” модификации процессоров класса 486 уже поддерживали этот режим. Для
использования SMM, часть системного ОЗУ выделяется под System Management RAM
(SMRAM). SMRAM используется для хранения выполняемого кода процедур
поддержки SMM, сохранения и восстановления состояния процессора при переходе в
режим SMM и выходе из него, хранения переменных, связанных с поддержкой SMM, а
также других целей, набор которых определяет разработчик BIOS. Процессор
переходит в режим SMM при получении сигнала запроса на прерывание System
Management Interrupt (SMI), генерируемого специальными схемами системной
платы при наступлении контролируемых событий.
Режим SMM был разработан для управления такими объектами и событиями в
системе, существование которых требовалось “скрыть” от ОС, в рамках концепции
взаимодействия ОС и оборудования, характерной для того этапа развития платформы
PC. Такая постановка задачи определила следующие характерные особенности
архитектуры SMM: для хранения адреса процедуры обработки аппаратного прерывания
SMI не используется ни один из векторов в стандартной таблице векторов, в
отличие от всех остальных прерываний. Вместо этого, адрес хранится в специальных
регистрах процессора. Для сохранения и восстановления состояния процессора при
обработке прерывания SMI, не используется стандартный стек, вместо этого
используется память SMRAM, в которой хранятся все данные, необходимые для
поддержки SMM.
Когда BIOS передает управление на загрузку ОС, он настраивает чипсет (в
частности схемы картирования памяти) таким образом, что память SMRAM недоступна
в адресном пространстве. В большинстве платформ для картируемого доступа к SMRAM
используется 128Кбайтное окно по адресам 000A0000h-000BFFFFh. Когда процессор
находится в обычном режиме (не SMM), данный диапазон отображается на шину
ввода-вывода и используется для чтения и записи памяти видеоадаптера. По сигналу
SMI, процессор переходит в режим SMM, после этого на тот же диапазон адресов
будет включена оперативная память (область SMRAM), доступ к видеопамяти временно
закрывается. При выходе из режима SMM после завершения обработки прерывания SMI,
на выше указанный адресный диапазон снова будет включена видеопамять. Таким
образом, память SMRAM “не видна” для ОС и программ.
Внимательный читатель может задать вопрос: а как быть, если процедуре
обработки SMI, выполняемый код которой находится в диапазоне
000A0000h-000BFFFFh, требуется выполнить запись в видеопамять? Для этого,
программно-управляемая логика картирования обеспечивает дополнительную гибкость,
например, процедура обработки SMI может временно включить режим, при котором
процессорные циклы чтения выполняемого кода в диапазоне 000A0000h-000BFFFFh
направляются на SMRAM, а циклы чтения и записи данных направляются на
видеопамять. Есть и другое решение, которое обусловлено тем, что практически все
современные видеоадаптеры, помимо постраничного доступа к видеопамяти в
диапазоне 000A0000h-000BFFFFh обеспечивают и линейный (плоский) доступ к ней в
диапазоне, находящемся выше 1MB. Адрес и размер этого диапазона устанавливается
механизмами PCI PnP. Использование такого метода не создает рассмотренного выше
конфликта адресов в режиме SMM.
The role of SMM
During platform initialization the PC's firmware (BIOS) has complete control of the system and can perform whatever configuration operations are required to prepare the system for an OS to take over. Once an OS is running it expects that it has complete control of the system. If the firmware developer would like the firmware to continue to have some control over the system, SMM is used.
SMM is intended to be completely transparent to the OS. When the system enters SMM, the firmware preserves the state of the CPU in a region of RAM designated as "SMRAM". During SMM the firmware performs low-level management operations like changing fan speeds, checking thermal zones, adjusting the CPU speed, etc. Before leaving SMM, the firmware restores the state of the CPU from SMRAM. From the perspective of the OS, those low-level management operations are happening atomically and automatically in the background.
What can I do with system management mode?
SMM is designed so that OS developers do not need to be aware of it, other than understanding its relationship with ACPI. Since code executing in SMM cannot be detected by the OS under normal circumstances, SMM is an attractive vector for advanced malware. CPU implementations of SMM and BIOS implementations of SMM firmware that can be detected, abused, or interfered with are significant security issues. TODO - include some links to Invisible Things and some SMM hacking papers.
Электронные документы, доступные на сайте
acpi.info.
19) Advanced Configuration and Power Interface Specification. Hewlett-Packard
Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies
Ltd., Toshiba Corporation. Revision 3.0.
Triggering SMM
SMM is triggered through a System Management Interrupt (SMI), a signal sent from the chipset to the CPU. During platform initialization, the firmware configures the chipset to cause a System Management Interrupt for various events that the firmware developer would like the firmware to be made aware of. The firmware also designates the region of RAM that should be used as SMRAM and specifies where the CPU should jump when an SMI occurs. During operation, the chipset detects the configured events and signals an SMI, triggering the CPU to enter SMM by jumping to the SMM entry point. The OS has no way of knowing when the chipset might signal an SMI and cannot "catch" System Management Interrupts like other interrupts. SMIs are not routed through the IVT/IDT.
An OS can ask the chipset to signal an SMI, although the handling of the SMI will still be transparent. This is performed by writing to a particular port (determined via ACPI). If the OS asks the chipset to signal an SMI and there is no reason for an SMI to be triggered at that particular moment, the firmware will not have much to do and the OS will regain control almost immediately.
Сферы применения режима SMM
Как было сказано выше, режим SMM был разработан для управления такими
объектами и событиями в системе, существование которых требуется “скрыть” от ОС.
Сразу после появления SMM, одной из основных сфер его применения являлся
Power Management, осуществляемый BIOS. При наступлении событий, связанных с
взаимодействием программного обеспечения и оборудования (обращение программ к
заданным портам, генерация прерываний), специальная логика, обычно входящая в
состав чипсета системной платы, генерирует прерывание SMI, процедура обработки
которого, входящая в состав BIOS, собирает статистику использования различных
устройств. На основании результатов этой статистики, устройства, не используемые
в течение заданного интервала времени, отключались. Этим обеспечивалось снижение
общей потребляемой мощности системы. Необходимо отметить, что на сегодня, данная
сфера применения SMM уже не актуальна, так как Power Management в современных
платформах и ОС базируется на спецификации ACPI, которая возлагает на ОС все
обязанности по оптимизации энергопотребления. При этом вместо “спрятанного от
ОС” прерывания SMI, генерируется SCI (System Control Interrupt), которое
использует стандартный контроллер прерываний и таблицу векторов. Подробности в
[19].
Другая сфера применения SMM – эмуляция физически несуществующего
оборудования. Например, есть много DOS программ, которые для ввода с клавиатуры
используют чтение скан-кодов из порта данных контроллера клавиатуры (0060h)
вместо вызова сервисных процедур BIOS. Несмотря на очевидное ухудшение
совместимости, программисты часто использовали такое решение, так как не все
комбинации клавиш можно адекватно распознать, используя сервис BIOS. “Час
расплаты” наступил, когда появились клавиатуры USB, при использовании которых,
скан-код уже не доступен через порт 0060h. Разработчики платформ использовали
SMM для решения возникшей проблемы и обеспечения совместимости USB клавиатур с
DOS средой. При вводе скан-кода по интерфейсу USB, контроллер USB генерирует
SMI. Процедура обработки SMI, входящая в состав BIOS, принимает введенный код и
используя специальную команду контроллера клавиатуры (эмуляция ввода), помещает
его в буфер контроллера. После этого, обработка SMI завершается, а для
программного обеспечения все выглядит так, как при использовании стандартной
клавиатуры: скан-код доступен через порт 0060h и контроллер клавиатуры
генерирует прерывание (IRQ1).
BIOS Setup предоставляет опции для включения эмуляции PS/2 клавиатуры и мыши.
Обычно они называются Keyboard Legacy Support, Mouse Legacy Support.
Как было показано выше, режим SMM и прерывание SMI обеспечивают достаточно
хорошую изоляцию между прерываемой и прерывающей процедурой (не используются
таблица векторов прерываний, стек, обычная оперативная память), поэтому данная
технология может быть применена для написания различных программ мониторинга,
перехвата событий, отладчиков и т.п. Но при этом следует понимать, что
архитектура некоторых системных ресурсов, используемых для поддержки SMM
(например, регистров чипсета) может быть различной в различных платформах.
Поэтому, программа, работающая с SMM, будет совместима только с теми
платформами, поддержку которых предусмотрел разработчик. Еще одна проблема
состоит в том, что регистры процессора и чипсета, управляющие SMM, поддерживают
функцию LOCK, позволяющую запретить изменение состояния указанных регистров,
установив для них статус Read Only, который будет снят только после аппаратного
сброса. Если BIOS, до передачи управления на загрузку ОС, активирует функцию
LOCK (на большинстве платформ, протестированных автором, этого не происходит),
то вмешательство внешней программы в работу SMM, а также чтение и запись SMRAM
внешней программой будут невозможны.
Источники информации
16) Winbond LPC I/O W83627THF.
17) IT8712F Environment Control – Low Pin Count Input/Output (EC-LPC I/O).
18) PCI BIOS Specification. Revision 2.1.
Функции компонентов платформы.
Систематизируем выше сказанное. Итак, поддержка SMM сводится к следующей
функциональности процессора, контроллера памяти, подсистемы ввода-вывода и BIOS.
Примечание 1. Для систем AMD64 (Socket 754/939/940/AM2/AM3), у которых
контроллер памяти находится в составе процессора, описанные в этом пункте
функции, реализованы в составе процессора. Для остальных систем – в составе
“северного моста” чипсета. Подробности в [6], [13], [14], [15].
Книги
20) В.Л. Григорьев. Микропроцессор i486. Архитектура и программирование.
Москва ТОО “ГРАНАЛ” 1993.
21) В.Г. Артюхов, А.А. Будняк. В.Ю. Лапий. С.М. Молявко, А.И. Петренко.
Проектирование микропроцессорной электронно-вычислительной аппаратуры.
Справочник. Киев “Тэхника” 1988.
22) К. Г. Самофалов, О.В. Викторов. Микропроцессоры. Библиотека инженера. Киев
“Тэхника” 1989.
23) 2B ProGroup: В.А. Вегнер, А.Ю. Крутяков, В.В. Серегин, В.А. Сидоров, А.В.
Спесивцев. Аппаратура персональных компьютеров и ее программирование. IBM
PC/XT/AT и PS/2. Москва “Радио и связь” 1995.
Здравствуйте, дорогие жители Сети. Сегодня мы расскажем о поллинге – одной из основных технологий для построения нормальных беспроводных сетей.
Все вы знаете Wi-Fi и многократно с ним сталкивались. Всем хороша технология, и шустрая (до 300 Мбит/с заявляют) и дешевая. А вот почему-то эту замечательную технологию не используют операторы для построения городских сетей. Наверное, что им мешает, чего-то наш любимый Wi-Fi (а точнее группа стандартов IEEE 802.11 a/b/g/n) – не умеет.
Алгоритм общения устройств согласно 802.11 выглядит в общих чертах так:
Перед тем как что-либо передать, абонент Wi-Fi слушает эфир – не занят ли он. Если эфир свободен – абонент начинает передачу. И пока он передает, остальные абоненты ждут. Это называется CSMA/CA (carrier sense multiply access with collision avoidance, множественный доступ с контролем несущей и предотвращением коллизий). Вроде технология прекрасная и никаких коллизий не может случиться. И это так, пока все абоненты одной базы «слышат» друг друга. В внутриофисных и домашних сетях Wi-Fi это именно так. Но как только мы начинаем строить сеть за пределами помещений и наши абоненты расположены не в нескольких метрах, а в километрах от базы – все меняется. Для работы на больших расстояниях мы используем направленные антенны.
А это значит, что абонент понятия не имеет, передает его сосед или нет, он слышит только базу. А свободна ли база или она сейчас принимает данные от другого абонента – он не знает. И механизм избегания коллизий перестает работать. Что же делать?
Единственным нормальным выходом из этой ситуации является жесткий арбитраж со стороны базы. То есть решать, кто из абонентов должен сейчас передавать, должна именно база. Так появился поллинг.
Поллинг, он же неколлизионный доступ, он же – маркерный доступ. Применяется в сетях беспроводного доступа с 1990-х годов. В отличие от Wi-Fi – не стандартизован, то есть каждый производитель придумывает и пишет свой вариант, и железо разных вендоров друг с дружкой в режиме поллинга не работает.
Продолжаем начатый в прошлом посте разговор о безопасности UEFI, об угрозах и имеющихся защитах от них.
В этот раз речь пойдет об SMM, о том, как он устроен и работает, и почему является желанной целью для атаки.
Пропустившим нулевую и первую части сего опуса — рекомендую прочесть сначала их, остальных покорно прошу под кат.
Часть вторая. SMM
Немножечко ликбеза
Аппаратное SMI
Писать про него особенно нечего: подаем напряжение на ногу — имеем прерывание. Сейчас используется редко, т.к. почти на всех системах теперь имеются мультифункциональные GPIO, которые могут генерировать события, не прерывая работу ОС, плюс не нужна дополнительная логика для определения, кто же конкретно сгенерировал аппаратное SMI, ведь устройств много, а нога — одна.
Системные SMI
Программные SMI
Программные SMI генерируются чаще всего либо прошивкой, либо драйверами, но ничего не мешает атакующему с правами администратора в ОС (точнее, необходимы права на исполнение инструкции out) тоже генерировать их.
Программное SMI генерируется при записи в CPU IO-порт APM_CNT (чаще всего это порт 0xB2), в качестве параметра в регистре AL передается его номер. Таким образом, максимальное количество различных обработчиков программных SMI в системе — 256, но реально их от 0-5 на специализированных системах, подготовленных для работы с RTOS, до 15-20 на системах с кучей разного железа, которым надо управлять без вмешательства ОС.
Как реализован SMM
Для кода SMM-диспетчера и обработчиков SMI выделяется 1-3 области физической памяти, которую во всех «обычных» режимах исполнения чипсет помечает как область MMIO с несуществующим устройством, т.е. для всего остального мира эти области — сплошная череда 0xFF, которые невозможно перезаписать. Первая область, называемая обычно ASEG (т.е. «сегмент А»), предназначена для т.н. legacy SMM code, т.е. старых 16-битных обработчиков SMI, которых на современных системах уже нет. Имя сегменту досталось за то, что он находится по фиксированным физическим адресам 0xA0000 — 0xBFFFF. Вторая область с фиксированными адресами — HSEG (т.е. «высокий сегмент»), раньше находилась на 0xFEDA0000 — 0xFEDBFFFF, но на современных системах не используется, т.к. имеется гораздо более удобный сегмент с настраиваемыми адресом и размером — TSEG (т.е. «топовый сегмент»), в котором и находятся сейчас 99% кода, исполняемого в SMM, а в ASEG остается только небольшая заглушка для совместимости.
При переходе в SMM процессор сохраняет практически весь контекст (т.е. содержимое практически всех регистров, какие именно не сохраняются — зависит от конкретной микроархитектуры), причем к сохраненному контексту у обработчиков SMI есть полный доступ, и потому он может общаться с системой через изменение сохраненных значений.
Для ОС вызов SMM кода выглядит как волшебное изменение содержимого регистров и памяти, и хотя отследить длительность нахождения в SMM все же можно по косвенным признакам, а факт перехода в него — по непосредственным, при помощи чтения регистра MSR_SMI_COUNT до и после вызова инициации программного прерывания, но повлиять на длительность обработчика SMI ОС не может, поэтому SMM плохо совместим с hard-RTOS (стоит отметить, что вся архитектура x86 совместима с ними весьма через раз, но это другая история).
При настройках по умолчанию работающий в SMM код имеет полный доступ ко всей физической памяти на чтение и запись, полный доступ ко всем подключенным устройствам, в общем — может практически все, и при этом независим от ОС и недоступен из нее даже на чтение, что сильно затрудняет его анализ и делает код обработчиков SMI весьма привлекательной целью для атаки. Более того, если атакуемой системе доступна из SMM запись на SPI-микросхему (а она доступна во всех случаях, кроме систем с включенной PFAT, которые не найти с огнем, систем с Read-only BIOS'ом, которые встречаются еще реже, и систем с защитой через PR-регистры), то успешная атака может закончиться записью своего кода в BIOS, с последующем воровством, убийством и непотребством с гусями. Именно поэтому защитить SMM от вставки туда вредоносного кода — жизненно необходимо.
Атаки на SMM и защита от них
Забытый D_LOCK
Код в SMRAM не появляется там самостоятельно, сначала саму SMRAM нужно настроить, инициализировать физическую память, настроить TSEG так, чтобы все обработчики туда влезли, скопировать туда код SMM-диспетчера и обработчиков, настроить там таблицы дескрипторов — в общем, навести строгий уставной порядок, после чего обязательно снять бит D_OPEN, чтобы никто больше там ничего не испортил, и установить бит D_LOCK, чтобы D_OPEN нельзя было поставить назад. На некоторых старых системах установить D_LOCK забывали, и там SMM был отрыт всем ветрам, но во времена UEFI этого уже не происходит, так что этот вектор атаки ушел в историю.
SMM cache poisoning
Еще одна историческая атака — отравление кэша SMRAM, которую в 2009 году опубликовали Rafal Wojtczuk и Joanna Rutkowska. Суть атаки коротко — меняем тип памяти для региона SMRAM на Write-Back, организуем запись в регион SMRAM своего кода, запись в память не происходит, но при этом наш код остается в кэше второго уровня, после чего генерируем программное SMI и процессор читает данные не из SMRAM, а из кэша, и выполняет наш вредоносный код. Проблема решилась радикально — производители CPU запретили ставить режим WB на SMRAM, и потому системе с UEFI этой уязвимости не подвержены.
SMM call-out, она же SMM incursion attack
Но достаточно истории, перейдем к «современным» атакам. Начнем, пожалуй, с той самой SMM Incursion Attack, о которой тов. maseal упомянул в комментарии к первой части. Я специально поставил слово «современные» в кавычки, ибо этой атаке — сто лет в обед, впервые о ней сообщали еще в 2008 году как проблему тогдашних BIOS'ов, но в 2015 ее вновь переоткрыли Corey Kallenberg и Xeno Kovah. Атака простая как мычание — если обработчик SMI вызывает какой-либо код, находящийся вне SMRAM, то атакующий с правами на запись в физическую память может подменить вызываемый код на свой, и выполнить его таким образом в режиме SMM. А т.к. разработчики UEFI привыкли к доступности EFI Runtime-сервисов, то эти самые сервисы стабильно вызывались из обработчиков SMI на каждый чих (чаще всего это были вызовы GetVariable, SetVariable и ResetSystem). Уязвимости оказалось подвержено столько систем, что проще сказать, где их не было. По моей грубой оценке, если ваш UEFI старше мая-июня 2015 года по build date, в нем гарантированно имеется пара уязвимых к этой атаке обработчиков SMI. Вычистить систему от таких глючных обработчиков достаточно сложно, и т.к. раньше такое поведение вообще не считалось уязвимостью («какой дурак полезет сервисы хукать то?!») и о том, что так делать нельзя, не было известно простым IBV 'шным кодерам — даже сейчас периодически приходят обновления для runtime-драйверов, подверженные этой проблеме. Все очень грустно, в общем.
Для защиты от вызова внешнего по отношению к SMRAM кода инженеры Intel добавили специальный MSR_SMM_FEATURE_CONTROL, после установки определенного бита в котором вызов такого кода генерирует немаскируемое и невосстановимое MCE , но есть такой MSR только в Haswell и более новых CPU, да и включается эта возможность только на время отладки прошивки, иначе за непонятные зависания на ровном месте пользователи могут к дверям отдела R&D прийти с вилами и дубьем — большинству нужно, чтобы работало и сейчас, а эта ваша безопасность вся — overhyped. Для обладателей более старых систем и систем на базе процессоров AMD инженеры Phoenix нашли по своему гениальное решение — использовать NX-бит, настроив память для SMM-кода таким образом, чтобы вызов кода вне SMRAM заканчивался Page Fault'ом, который затем можно обработать, а не висеть намертво на MCE. Каюсь, я у себя пока еще это решение не внедрил, но когда дойдут руки — обязательно это сделаю.
Простому же пользователю от этой атаки можно защититься только не допуская исполнение непонятного кода от рута, но это, к сожалению, на современных ОС практически нереально — вариантов локального повышения прав как было море, так и остается, сколько таких 0day-эксплоитов на руках и в обороте, сказать невозможно. Остается только процитировать вышеупомянутого Xeno Kovah:
DMA attack
SMM cross-buffer attack
Представленная специалистами из Intel ATR атака на обработчики SMI, которые принимают в качестве параметра указатель и размер буфера, и производят запись в него. Атакующий может передать указатель и размер таким образом, чтобы буфер пересекал границу RAM-SMRAM, а т.к. обработчик SMI имеет доступ к SMRAM, то он перепишет какую-то часть данных вначале SMRAM. При удачном стечении обстоятельств (т.е. приблизительно после 500 часов отладки минимум) обработчик может переписать служебные структуры диспетчера SMM или других обработчиков нужным атакующему образом, и он получит возможность выполнения произвольного SMM-кода. Атака адски сложная и целевая, но вполне возможная, поэтому с начала 2015 года все обработчики SMI, принимающие указатели на буфер, обязаны валидировать его перед использованием. На более старых системах атака будет работать, но вероятность того, что именно вас через нее взломают — невелика.
Заключение
Ну вот, теперь разобрались более или менее и с SMM, в следующей части поговорим об атаках на S3 BootScript.
Спасибо за внимание, безопасных вам прошивок.
P.S.
Не могу не поблагодарить тов. d_olex за его статьи об SMM и атаках на него — раз и два. Для интересующихся темой и умеющих читать по-английски — обе обязательны к прочтению.
SMM (англ. System Management Mode - режим системного управления) - это режим, при котором процессор приостанавливает исполнение любого кода (в том числе и операционной системы) и запускает специальную программу, хранящуюся в SMRAM.
SMRAM (System Management RAM) - часть оперативной памяти компьютера, которая резервируется BIOS при включении компьютера перед передачей управления операционной системе. Она используется для хранения выполняемого кода процедур поддержки SMM, сохранения и восстановления состояния процессора при переходе в режим SMM и выходе из него, хранения переменных, связанных с SMM.
Поддержка SMM процессорами Intel и AMD реализована очень давно (еще в 90-х годах 20 столетия). SMM был разработан для управления некоторыми объектами и событиями, существование которых требовалось "скрыть" от операционной системы. Процессор переводится в режим SMM не программным обеспечением, а после поступления сигнала, генерируемого при наступлении определенных событий специальными схемами материнской платы.
Этот режим применяется для решения некоторых важных задач, таких как:
• обработка ошибок памяти и чипсета материнской платы;
• защита процессора от перегрева путем выключения компьютера;
• перевод компьютера в некоторые режимы глубокого энергосбережения;
• эмуляция физически несуществующего оборудования, в частности, мыши и клавиатуры с интерфейсом PS/2 при фактическом использовании этих устройств с разъемом USB и др.
НАПИСАТЬ АВТОРУ
Технологии и инструкции, используемые в процессорах
Люди обычно оценивают процессор по количеству ядер, тактовой частоте, объему кэша и других показателях, редко обращая внимание на поддерживаемые им технологии.
Отдельные из этих технологий нужны только для решения специфических заданий и в "домашнем" компьютере вряд ли когда-нибудь понадобятся. Наличие же других является непременным условием работы программ, необходимых для повседневного использования.
Так, полюбившийся многим браузер Google Chrome не работает без поддержки процессором SSE2. Инструкции AVX могут в разы ускорить обработку фото- и видеоконтента. А недавно один мой знакомый на достаточно быстром Phenom II (6 ядер) не смог запустить игру Mafia 3, поскольку его процессор не поддерживает инструкции SSE4.2.
Если аббревиатуры SSE, MMX, AVX, SIMD вам ни о чем не говорят и вы хотели бы разобраться в этом вопросе, изложенная здесь информация станет неплохим подспорьем.
Таблица совместимости процессоров и материнских плат AMD
Одной из особенностей компьютеров на базе процессоров AMD, которой они выгодно отличаются от платформ Intel, является высокий уровень совместимости процессоров и материнских плат. У владельцев относительно не старых настольных систем на базе AMD есть высокие шансы безболезненно "прокачать" компьютер путем простой замены процессора на "камень" из более новой линейки или же флагман из предыдущей.
Если вы принадлежите к их числу и задались вопросом "апгрейда", эта небольшая табличка вам в помощь.
Сравнение процессоров
В таблицу можно одновременно добавить до 6 процессоров, выбрав их из списка (кнопка "Добавить процессор"). Всего доступно больше 2,5 тыс. процессоров Intel и AMD.
Пользователю предоставляется возможность в удобной форме сравнивать производительность процессоров в синтетических тестах, количество ядер, частоту, структуру и объем кэша, поддерживаемые типы оперативной памяти, скорость шины, а также другие их характеристики.
Дополнительные рекомендации по использованию таблицы можно найти внизу страницы.
Спецификации процессоров
В этой базе собраны подробные характеристики процессоров Intel и AMD. Она содержит спецификации около 2,7 тысяч десктопных, мобильных и серверных процессоров, начиная с первых Пентиумов и Атлонов и заканчивая последними моделями.
Информация систематизирована в алфавитном порядке и будет полезна всем, кто интересуется компьютерной техникой.
Таблица процессоров
Таблица содержит информацию о почти 2 тыс. процессоров и будет весьма полезной людям, интересующимся компьютерным "железом". Положение каждого процессора в таблице определяется уровнем его быстродействия в синтетических тестах (расположены по убыванию).
Есть фильтр, отбирающий процессоры по производителю, модели, сокету, количеству ядер, наличию встроенного видеоядра и другим параметрам.
Для получения подробной информации о любом процессоре достаточно нажать на его название.
Как проверить стабильность процессора
Проверка стабильности работы центрального процессора требуется не часто. Как правило, такая необходимость возникает при приобретении компьютера, разгоне процессора (оверлокинге), при возникновении сбоев в работе компьютера, а также в некоторых других случаях.
В статье описан порядок проверки процессора при помощи программы Prime95, которая, по мнению многих экспертов и оверлокеров, является лучшим средством для этих целей.
ПОКАЗАТЬ ЕЩЕ
System Management Mode (SMM) is an operating mode on x86 and x86-64 processors, intended for use by Firmware/BIOS to perform low-level system management operations while an OS is running.
SMM and ACPI
SMM predates ACPI. Without ACPI, it makes sense that the firmware would want to stay resident in memory even once an OS is running, because the OS may not have drivers for all of the thermal sensors, fans, and CPU performance settings that are available on that particular motherboard/chipset/CPU combination. With ACPI, however, the firmware stores AML code for the OS to interpret and execute; that AML tells the OS how to handle all those things. Theoretically, this means that SMM is not nearly as critical on a modern system as on a pre-ACPI system. However, at boot time the firmware has no way of knowing whether or not the OS includes a complete ACPI implementation or whether the OS is willing to take responsibility to managing power, thermal properties, and CPU performance. So by default, the firmware will still use SMM to handle all those things itself.
If, however, at some point the OS indicates to firmware that it does have a complete ACPI implementation, the firmware will stop performing those low-level management operations and will expect the OS to perform them instead. Even once the OS takes over, the chipset will still occasionally signal SMIs and the CPU will enter SMM, but the firmware will not have very much to do.
The firmware developer decides on the division of responsibilities between firmware and the OS. The firmware could store AML code that tells the OS exactly how to handle every single thing that might happen with the system, leaving the firmware with nothing to do and no real reason for SMM to be used. On the other hand, the AML code could simply tell the OS to tell the chipset to signal an SMI whenever anything happens, at which point the firmware will directly handle the event itself.
A simple example of SMM and ACPI is the power button. Pressing the power button causes the chipset to signal an SMI, sending the CPU into SMM and jumping to the SMM entry point. The firmware determines that the power button was pressed. By default, before the OS takes over low-level system management responsibilities, the firmware will handle the event by telling the chipset to tell the power switching component of the motherboard to turn off, and the system powers off immediately. If, however, the OS has indicated that it will handle low-level system management responsibilities, the firmware ignores the button press and updates the ACPI structures in memory to note that the event occurred. The OS can detect the event by examining the ACPI structures and perform any clean-up operations (like saving files) before it tells the chipset to tell the power switching component of the motherboard to turn off.
Contents
Замечания по совместимости
Необходимо помнить, что архитектура рассматриваемых ниже регистров
контроллера памяти различается в различных платформах. Поэтому рассмотренные
ниже примеры работоспособны только для указанных чипсетов и процессоров. В
приведенном примере, автор не ставил задачу создания универсальной программы
работы с SMRAM, так как пример получился бы слишком громоздким: потребуется база
данных по всем чипсетам и процессорам. Вместе с тем, заинтересованный читатель
может добавить в приведенный исходный текст поддержку своей платформы. Напомним,
что для систем AMD64 (Socket 754/939/940/AM2/AM3), у которых контроллер памяти
находится в составе процессора, для управления SMRAM нужна поддержка различных
типов процессоров. Для остальных систем – различных типов “северных мостов”
чипсетов. Своеобразным исключением является платформа AMD Socket A (синоним
Socket 462). Контроллер памяти здесь находится в составе “северного моста”
чипсета и трансляцией процессорных обращений на шину памяти и шину ввода-вывода
управляет “северный мост”. Но выбор одной из двух этих шин осуществляется в
соответствии с MTRR (Memory Type Range Registers) атрибутами, которые
формируются на основании содержимого MTRR-регистров процессора и передаются от
процессора к чипсету. Поэтому для управления картированием памяти SMRAM на
данных платформах программировать требуется регистры процессора, несмотря на то,
что контроллер памяти находится в чипсете. Подробности в [6], [13], [14], [15].
Transparency
TODO - write a bit about how SMM implements its transparent behavior, SMRAM, the lock bits in the MMU, etc.
Читайте также: