- комментарий 0:
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
- комментарий 1:
From: Sergey Matveev
Date: 2023-11-02 12:40:42Z
*** kmeaw [2023-11-02 06:23]:
>А где же там backdoor?
(Ещё один) Потенциальный backdoor. ACPI заставляет ядро запускать
Тьюринг-полную (недоверенную) программу. Интерпретатор bytecode-а
должен быть.
В Wikipedia вчера кстати убрали раздел с "security risks".
https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
>В Open Firmware или UEFI положить backdoor значительно проще, чем в ACPI
>- там гораздо богаче среда исполнения.
Это бесспорно.
>По первой ссылке Matthew Garrett достаточно подробно рассказывает, чем
>жизнь с ACPI лучше жизни без него.
Но это не означает что надо и нужно мириться с тем, что ACPI требует от
ядра запуска (пускай и при загрузке) полноценных програм. Так проще, так
гибче, но не приемлемо ещё одну очередную Тьюринг-полную штуку иметь.
- комментарий 2:
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 с
последующим жёстким фиксированием и минимизацией системной прошивки.
Пока у пользователя есть возможность сильно менять аппаратную
конфигурацию, железу, прошивке и ОС надо уметь как-то договариваться и
сообща адаптироваться под изменчивые условия.
- комментарий 3:
From: Sergey Matveev
Date: 2023-11-02 17:00:47Z
*** kmeaw [2023-11-02 14:48]:
>UEFI, кстати, тоже содержит runtime services, которые не отключаются [...]
Да вообще, ужас всё это.
>А какие есть альтернативы лучше?
Я тут вообще не шибко понимаю как всё устроено. Но до ACPI же IBM PC
как-то вполне себе работали с разносторонними компонентами. Собственно,
ведь ещё десять лет назад многие серверы и ПК с отключённым ACPI (в
ядре) загружались и функционировали (ибо с ACPI они не работали).
"Полноценные привилегированные программы" legacy BIOS это речь про
драйверы, которые загружает ОС? Но драйверы же это уже хотя бы что-то,
что сам человек явно подсовывает/собирает/управляет ими, а не нечто
загружаемое из железа прозрачно.
И опять же: если сейчас нет лучше, это не значит что всё хорошо и ok.
Сейчас все популярные "web-сайты" стали загружаемыми программами на
компьютер пользователя -- это же не значит что это приемлемо и
нормально. Но всем этим рулят и диктуют крупные корпорации, типа той же
Microsoft, цели которой чаще всего расходятся с пользовательскими.
- комментарий 4:
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, где нет всех
этих сложностей, и пользователь действительно имеет контроль. Хотя даже
там уже есть второй компьютер в дисководе (примерно на таком же
процессоре).
Либо забить на всё это и считать железный компьютер вместе со всем
несвободным кодом стартовой площадкой для гипервизора, состояние
которого уже полностью контролирует пользователь, и где всё "железо"
гораздо более предсказуемое и стандартнное.
- комментарий 5:
From: Sergey Matveev
Date: 2023-11-02 20:45:46Z
*** kmeaw [2023-11-02 19:23]: [...]
Спасибо за объяснения! Я всё равно, видимо, очень смутно понимаю как
вообще работают с железом. Но когда говорят про ACPI, то всегда приходят
к проблемам энергосбережения/сна. Да, я помню что до ACPI (ну или с ним
отключённым), чтобы кто-то уснул и всё в нём проснулось -- только везение.
Но вот если меня вообще не коробит всё это энергосбережение и сон? У
меня ни один компьютер уже лет 12 не засыпал никогда. А энергосбережение
приходилось явно отключать для той же видеокарты, ибо из-за этого глюки
были. И мне пихают ACPI и необходимость выполнять какой-то код ради
фишек которые мне нафиг не нужны (сон/питание). Но, опять же, не силён
тут совсем, только читал очень поверхностные вещи на тему работы с
железом. Если с джамперами на ISA платах и выставлением руками всяких
DMA я ещё знаком и делал и даже понимаю почему всё так было устроено, то
с PCI шиной вроде бы это же всё ушло и оно само автоконфигурируется,
плюс имеет команды для чтения/записи конфигурации. Драйвера в любом
случае нужны же, для каждого, так сказать, класса устройств.