LINUX.ORG.RU
ФорумTalks

Взять и UEFIть


0

1

Matthew Garrett, один из разработчиков Red Hat, опубликовал заметку о текущем состоянии дел с UEFI.

В числе прочего он пророчит смерть блобам:

Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.

Причем это же касается и ситуации с альтернативной ОС и сторонними драйверами.

★★★★★

Смерть блобам это хорошо. Но не от UEFI.

Deleted
()

Читал это еще на опеннете. Так и не понял. UEFI грузит ядро линукса, а линукс уже сам грузит свои модули по желанию. разве UEFI не до лампочки что там ядро творит после него?

А как же форточки? винду с неподписанной вируснёй тоже нельзя будет загрузить?

null123 ★★
()
Ответ на: комментарий от null123

разве UEFI не до лампочки что там ядро творит после него?

он пишет о разнице между «secure boot» и «trusted boot». чтобы «secure boot» имела смысл, нужно подписывать все - и ядро, и модули. иначе это мартышки труд

registrant ★★★★★
() автор топика
Ответ на: комментарий от registrant

Я таки не понял, он это теоретически рассуждает или пользователями линукса пора примерять зонд, потому что иных вариантов не станет кроме разве что серверных да и то?

praseodim ★★★★★
()

Не взлетит. Винда с её анальными фокусами в данный момент в арм-сегменте - догоняющая, с неясными перспективами. Ведущие разработчики железок не могут не ориентироваться на андроид.

prischeyadro ★★★☆☆
()
Ответ на: комментарий от praseodim

вполне реальная перспектива, по времени скорее всего будет привязана к очередной версии офтопика

registrant ★★★★★
() автор топика

а самое главное почему не заметили??

windows8-hardware-cert-requirements-system.pdf (http://msdn.microsoft.com/en-us/library/windows/hardware/hh748200.aspx) direct link (http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F5...)

MANDATORY: Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

Disabling Secure MUST NOT be possible on ARM systems.

olegsov
()

Секунду... может, я не в курсе чего-то, но зачем подписывать ядра? Достаточно же подписывания граба.

segfault ★★★★★
()

Это потому что FSF положило на coreboot?

O02eg ★★★★★
()
Ответ на: re от dima_best

петиция была - помню. а иск - на каком основании?

registrant ★★★★★
() автор топика

Но зачем ЭТО в Linux?

С Windows всё понятно, там куча вирусни, которая хочет в kernel space. Однако же в Linux таких проблем нет. Кроме защиты от вирусов ничего хорошего Secure boot для пользователя не приносит. Вот когда для Linux появятся нормальные вирусы, стремящиеся в ядро, тогда и надо думать о таких фичах.

P.S.: Я верю, что с засилием Secure Boot добрыми хакерами будет написан эксплойт для UEFI, сносящий всю защиту. И для вирусописателей польза - лучше писать вирусы для офтопика, и пользователям нормальных ОС - можно ставить не мелкософтовские поделия.

KivApple ★★★★★
()
Ответ на: комментарий от segfault

так о том и тема, что подписывать что-то одно, а дальше им грузить неподписанное убивает весь смысл secure boot, поэтому надо либо подписывать все, либо не подписывать ничего, т.е. если граб подписан, то грузить им неподписанное - идиотизм.

maloi ★★★★★
()
Ответ на: комментарий от maloi

Если пользователь/админ при настройке ПК не может редактировать список отрытых ключей, которыми проверяются подписи - secure boot не нужен, и плевать, что его смысл умирает ради того, чтобы заработало то, что действительно нужно.

segfault ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.