Выполнение rm -rf / может привести к неработоспособности UEFI-прошивки ноутбука
Один из любознательных пользователей Arch Linux столкнулся с непредвиденной проблемой, пытаясь провести эксперимент по выполнению "rm -rf --no-preserve-root /" на ноутбуке MSI GP60. Перед плановой переразбивкой диска пользователь решил понаблюдать как поведёт себя система в случае выполнения "rm -rf /", после чего ноутбук пришёл в неработоспособное состояние и перестал подавать признаки жизни, даже не пытаясь вывести что-то на экран при включении.
Проблема оказалась в монтировании в режиме записи псевдо-ФС efivarfs, предоставляющей доступ к переменным UEFI. Таким образом, при выполнении "rm -rf /" удалялось и содержимое директории /sys/firmware/efi/efivars, что приводило к очистке и повреждению конфигурации UEFI.
На запрос перейти к монтированию /sys/firmware/efi/efivars в режиме только на чтение разработчики systemd ответили, что не видят в этом проблемы, так как изменение efivars возможно только под пользователем root, который в случае неадекватных действий может с тем же успехом повредить содержимое /dev/sda или перемонтировать efivars на запись.
Стирание директории /sys под пользователем root нельзя отнести к типичным практикам, а запись в efivars необходима некоторым системным утилитам. Более того, очистка конфигурации UEFI-прошивки не должна приводить к блокированию работы устройства - в случае повреждения, конфигурация UEFI должна восстанавливаться в состояние по умолчанию. Поэтому причиной проблемы является UEFI-прошивка, а не конфигурация systemd. При желании пользователи и разработчики дистрибутивов могут самостоятельно перейти к работе efivars в режиме только на чтение, без изменения кода systemd, достаточно для efivars указать в /etc/fstab флаг "ro".
Дополнение 1: Мэттью Гаррет, известный разработчик ядра Linux, получивший от Фонда СПО премию за достижения в области обеспечения загрузки Linux на системах с UEFI Secure Boot, считает, что проблему нужно решать на уровне ядра Linux. В качестве примера подобного решения Гаррет опубликовал прототип патча.
Дополнение 2: Николай Шлей (CodeRush), автор утилиты UEFITool и исследователь безопасности UEFI, пояснил суть проблемы:
Сама проблема звучит так: "удаление некоторых переменных NVRAM приводит к остановке выполнения фазы DXE на некоторых ноутбуках MSI". Это действительно проблема, причина - в недостатке тестирования этого сценария (вполне, кстати, легитимного, и выполняемого в 20 строк на С в любой UEFI-совместимой ОС), а недостаток этот - он от сокращения времени разработки прошивки и прочих "оптимизаций Time-To-Market".
На самом деле проблема эта не специфична для MSI, и страдают ей подавляющее большинство реализаций от практически всех IBV, плюс сам производитель железа может добавить свои драйверы, которые зависают от того, что нужных им переменных не оказалось, и не протестировать этот момент.
Решение: конкретный баг у MSI - найти и исправить, тест на этот случай - добавить в следующие версии FWTS, BITS и LUV, довести до производителей его необходимость через UEFI Forum. Пока реализации все еще сломаны - пользоваться воркэраундом Гаррета.
Арчеводы - самые любознательные! Интересная новость, а самое интересное - непонятно кто виноват. Хотя я все же склоняюсь к производителю железа: нехорошо, что прошивку платы может изменить прикладная программа (в данном случае ОС). А вы как думаете? Пишите в комментариях.