Что: b0380ab9222db234da5c6bd7d4c30a13796b1dc3
Когда: 2023-11-01 11:48:05+03:00
Темы: hard
Зачем ACPI? https://mjg59.dreamwidth.org/68350.html https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Security_risks https://bugzilla.kernel.org/show_bug.cgi?id=204807 https://www.welivesecurity.com/2022/04/19/when-secure-isnt-secure-uefi-vulnerabilities-lenovo-consumer-laptops/ https://www.csoonline.com/article/575447/gigabyte-firmware-component-can-be-abused-as-a-backdoor.html https://security.stackexchange.com/questions/61785/firmware-backdoor-protection Ещё одно пояснение откуда растут ноги у ACPI. Не забывая, что это один из backdoor-ов в компьютере.
From: kmeaw Date: 2023-11-02 06:25:24Z > это один из backdoor-ов в компьютере А где же там backdoor? По первой ссылке Matthew Garrett достаточно подробно рассказывает, чем жизнь с ACPI лучше жизни без него. Достаточно попытаться запустить систему на нескольких разных ARM-платформах (без UEFI), чтобы увидеть пользу от ACPI. Статья про Gigabyte никак не подтверждает backdoor-ность ACPI - там рассказывается про то, что в Windows есть компонент, который зачем-то вытаскивает исполняемый файл из одной из таблиц и запускает его. Ни для Linux, ни для *BSD мне неизвестно таких реализаций ACPI, которые бы так себя вели. В Open Firmware или UEFI положить backdoor значительно проще, чем в ACPI - там гораздо богаче среда исполнения. Самый "плохой" из известных мне фактов про ACPI - рассуждения Билла Гейтса на тему extensions, позволяющих NT работать лучше остальных ОС: https://web.archive.org/web/20230715100023/http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf
From: Sergey Matveev Date: 2023-11-02 12:40:42Z
From: kmeaw Date: 2023-11-02 14:50:39Z > ACPI требует от ядра запуска (пускай и при загрузке) Не только при загрузке. Ещё при возникновении ACPI-событий - по нажатию на заранее описанные кнопки (на клавиатуре, на корпусе), по таймеру, по прерыванию устройства и при переходе между различными режимами энергосбережения. UEFI, кстати, тоже содержит runtime services, которые не отключаются вызовом ExitBootServices из загрузчика перед запуском ядра ОС - они остаются резидентными и продолжают работать вместе с ядром, предоставляя ему сервисы (управление переменными, консоль, reset, обновление прошивки). > не приемлемо ещё одну очередную Тьюринг-полную штуку иметь А какие есть альтернативы лучше? Device Tree требуют наличия в ОС драйверов для всего, подход legacy BIOS - запускает полноценные привилегированные программы с плохо специфицированным интерфейсом вместо байткода виртуальной машины, у Open Firmware - полноценные программы на Форте. Без этого всего можно обойтись, только если написанием прошивки, операционной системы и полной сборкой всего компьютера занимается одна компания (как, например, Apple или производители игровых приставок), от чего PC очень далеки. Можно ещё пользователя заставить перемычками настраивать ресурсы, но это очень так себе подход - драйвера для всего в ОС всё равно потребуются, а диагностика мисконфигураций усложнится. Соблазна у производителя железа запихнуть что-то сложное во все альтернативные способы автоконфигурирования и управления состоянием железа я видел достаточно. А вот в ACPI DSDT самая сложная процедура, которая мне встречалась, выглядела примерно так - "если нажали на кнопку, то надо получить строку и сравнить с константой; если совпали, то прочитать 16-битное слово, и верхнюю половинку записать в один порт, а нижнюю - в другой, иначе записать в порт константу, затем прочитать оттуда адрес памяти и записать это слово туда, после чего продублировать его в отладчике, если он есть". Чаще это просто возврат константы или запись переданного аргумента в память или порт. У того устройства, которое может влиять на ACPI-таблицы, уже и так есть электрическое соединение с многими важными шинами. Сделать обычный PC безопаснее без всего этого можно только переносом привычных нам внутренних компонентов наружу через USB или Ethernet с последующим жёстким фиксированием и минимизацией системной прошивки. Пока у пользователя есть возможность сильно менять аппаратную конфигурацию, железу, прошивке и ОС надо уметь как-то договариваться и сообща адаптироваться под изменчивые условия.
From: Sergey Matveev Date: 2023-11-02 17:00:47Z
From: kmeaw Date: 2023-11-02 19:24:48Z > до ACPI же IBM PC как-то вполне себе работали с разносторонними компонентами. До ACPI всё было довольно разрозненным и плохо совместимым. Был Plug and Play, придуманный Microsoft, для выделения ресурсов платам расширения. Была процедура ROM scan, которая расширяла системный BIOS новым кодом - VGA-адаптер, например, приносил свою реализацию int10h, а дисковый контроллер - int13h. > "Полноценные привилегированные программы" legacy BIOS это речь про > драйверы, которые загружает ОС? Про расширения BIOS. Карточки имели при себе ROM (или (E)EPROM, или даже flash) микросхему, которая содержала программный код, а обвязка вокруг садилась на системную шину и перехватывала обращения к какому-то сегменту памяти, отдавая содержимое этого ROM. Системный BIOS искал определённую сигнатуру в памяти, проверял контрольную сумму и просто передавал управление этому коду, а тот уже патчил всё подряд - таблицу векторов прерываний, структуры BIOS (в основном (E)BDA), а иногда даже ОС после её загрузки. Такой механизм называется Option ROM. Особенно всё было плохо, когда стали появляться портативные компьютеры, которым было важно работать от батарей дольше, чем конкуренты. Тогда стали появляться всякие странные эвристики, по которым оборудование понимало, что можно частично себя отключить. Потом в 386SL появился режим SMM, который делал прошивку ещё более могущественной, позволяя скрывать свою деятельность от ОС - даже если ОС запрещала обработку прерываний (EFLAGS.IF=0), включая запрет немаскируемых (CMOS.NMI_EN=0), то это не мешало обработчику SMI быть вызванным и получить управление. Не было никаких стандартов на всё это, кроме желания производителей уметь запускать программы от оригинального IBM PC, а значит иметь реализацию примерно тех же программных интерфейсов. Ошибка в SMM-коде могла странным образом взаимодействовать с Option ROM SCSI-контроллера и приводить к сбою тогда, когда пользователь выставил перемычками использование IRQ11. Чтобы в Linux, например, работало переключение видеорежимов на видеокарте, реализующей VBE, нужно запускать куски видеобиоса и просить его переклюать видеорежимы. Конкретно в этом случае есть обходные пути - загрузить специфичный для этой видеокарты драйвер (но который всё равно может полагаться на наличие в памяти каких-то структур, которые приготовил видеобиос), либо запустить видеобиос в виртуальной машине, либо позвать его ровно один раз в загрузчике, раз и навсегда выставив нужный видеорежим. Чтобы узнать, с какого диска BIOS загрузил систему, нужно позвать EDD, предоставляемый дисковым контроллером. Для управления питанием без помощи ACPI нужно позвать APM, предоставляемый системным биосом. Повсюду вызовы чужого несвободного нативного кода. > десять лет назад многие серверы и ПК с отключённым ACPI (в ядре) > загружались и функционировали Они полагались на то, что BIOS ещё до входа в загрузчик каким-то разумныым образом всё оборудование настроил. Но если оборудование потеряет часть своего состояния (например, после выхода из режима энергосбережения), то оно либо не будет работать, либо будет полагаться на чёрную магию из SMM - оба случая плохи тем, что картина мира ОС начинает отличаться от реальности. Кстати, у Intel и AMD в рамках trusted computing есть специальные инструкции, SENTER и SKINIT, задача которых нейтрализовать действие всего, что ранее могло влиять на состояние машины и запустить подписанный производителем чипсета+процессора код, который безопасно запустит подписанную пользовательскую программу. Совсем "победить" SMM даже такими инструментами нельзя, но можно хотя бы измерить его состояние и остановить дальнейшую работу системы, если policy требует так делать при нарушении целостности. Слишком много внутри больших компьютеров стоит маленьких. Хотя большинство из них и пытается обманывать код, работающий на основном процессоре относительно своей природы (как, например, флеш-накопители прикидываются блочными устройствами, а жёсткие диски эмулируют CHS-геометрию), но абстракции протекают (NCQ, TRIM), и приходится как-то договариваться. В идеальном мире ОС брала бы всё под свой контроль и с помощью драйверов бы действительно управляла всем компьютером целиком, как, например, Google Borg управляет кластером, но без помощи программ от производителей железа пока не обойтись. Поскольку операционных систем больше, чем одна, приходится придумывать гибкие абстракции, как ACPI. Можно использовать простые компьютеры, типа Commodore 64, где нет всех этих сложностей, и пользователь действительно имеет контроль. Хотя даже там уже есть второй компьютер в дисководе (примерно на таком же процессоре). Либо забить на всё это и считать железный компьютер вместе со всем несвободным кодом стартовой площадкой для гипервизора, состояние которого уже полностью контролирует пользователь, и где всё "железо" гораздо более предсказуемое и стандартнное.
From: Sergey Matveev Date: 2023-11-02 20:45:46Z
Сгенерирован: SGBlog 0.34.0