LINUX.ORG.RU

Для ядра Linux представлены патчи, отключающие поддержку спящего режима при загрузке с UEFI Secure Boot

 ,


0

0

Мэтью Гаррет (Matthew Garrett), один из разработчиков ядра Linux, последнее время занимающийся обеспечением загрузки Linux на системах с UEFI, опубликовал в списке рассылки ядра Linux серию патчей, отключающих поддержку спящего режима (Hibernate) и функцию загрузки нового ядра из уже запущенного ядра Linux (kexec), в случае сборки ядра в режиме верификации для UEFI Secure Boot.

Необходимость отключения данных функций при использовании UEFI Secure Boot объясняется невозможностью гарантировать сохранение цепочки доверия при загрузке ядра в процессе возврата из спящего режима или при использовании kexec, чем может воспользоваться атакующий и организовать выполнение варианта ядра в режиме без проверки цифровых подписей. В случае с kexec атакующий может просто запустить произвольный образ ядра, а при активности спящего режима, отключить раздел подкачки и подменить образ восстановления.

В настоящее время полный процесс верификации ядра при загрузке в режиме UEFI Secure Boot используется только в дистрибутиве Fedora Linux, остальные дистрибутивы ограничиваются поддержкой проверки загрузчика, после чего запускают ядро Linux в обычном режиме. Если патчи будут приняты в состав ядра, то пользователи Fedora Linux будут лишены возможности перевода их систем в спящий режим при загрузке системы в режиме UEFI Secure Boot. Без данных патчей и без создания полноценных механизмов проверки для kexec и hibernation, процесс верификации ядра становится бессмысленным, так как его можно обойти. В качестве одного из путей решения проблемы, в случае с kexec, ранее для ядра Linux был предложен прототип системы верификации исполняемых файлов по цифровым подписям. Для hibernation решение пока не предложено.

Кроме патчей для запрета kexec и hibernation при загрузке в режиме UEFI Secure Boot, Мэтью Гаррет опубликовал набор патчей для определения политики доступа в процессе безопасной загрузки (Secure boot policy). Если неизменность хранимого на диске образа ядра гарантируется цифровой подписью, то уже загруженное в память ядро может быть изменено в процессе его работы. В настоящее время существует большое число интерфейсов, позволяющих пользователю с правами root внести модификации в код уже загруженного в память ядра. Представленные патчи реализуют новый тип capabilities — «CAP_COMPROMISE_KERNEL», предназначенный для выборочного предоставления привилегированных действий по модификации ядра только для приложений, которым предоставлены соответствующие полномочия. Новая возможность полезна не только при загрузке в режиме UEFI Secure Boot, но и в других ситуациях, требующих ограничения доступа к ядру.

>>> Подробности

★★★★★

Проверено: tazhate ()

kexec на десктопе мало кому нужен. А по-черепашьи медленный ядерный hibernate не нужен владельцам SSD, которых всё больше.

Lighting ★★★★★ ()

патчи, отключающие поддержку спящего режима

*facepalm* шёл 21 век…

wintrolls ☆☆ ()

Я удивляюсь иногда тому, что творится в LKML.

post-factum ★★★★★ ()

я, конечно, не линуксоид, но бред же сивой кобылы?!

dk- ()
Ответ на: комментарий от Lighting

А по-черепашьи медленный ядерный hibernate не нужен владельцам SSD, которых всё больше.

Правильно, поэтому вместо допиливания хибернейта до приемлемых скоростей давайте выкинем его совсем.

wintrolls ☆☆ ()

В настоящее время полный процесс верификации ядра при загрузке в режиме UEFI Secure Boot используется только в дистрибутиве Fedora Linux

Ничёнепонял.жэпэгэ

Зачем это в линуксе?

Ubuntu1210 ()

Не понял. А что без UEFI Secure Boot такой проблемы не было? С dual-boot'ом?

Самолично угробил систему таким образом: сделал hibernate, потом загрузился под «другим пунктом меню» в grub (просто другое ядро было), чего-то там поделал, потом перегрузился и «вышел из hybernate». Слава Богу, повреждения затронули только корневой раздел (/home на отдельном разделе - хвала тебе), так что для оживления системы просто пересобрал мир.

Надеюсь, данные «патчи» будут отключаемы через menuconfig.

P. S. А еще надеюсь никогда не столкнуться с UEFI Secure Boot...

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

Правильно, поэтому вместо допиливания хибернейта до приемлемых скоростей давайте выкинем его совсем.

Сколько лет допиливают, что-то всё никак не допилят.

А TOI до сих пор несовместим с Plymouth и не всегда поспевает за релизами ядра.

Lighting ★★★★★ ()

Пусть этот наркоман делает новые «фичи» отключаемыми.

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

А по-черепашьи медленный ядерный hibernate не нужен владельцам SSD, которых всё больше.

А ценность гибернейта только в скорости загрузки? Те, кто просто не хочет перезапускать все приложения, значит просто не понимают суть гибернейта?

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

Те, кто просто не хочет перезапускать все приложения, значит просто не понимают суть гибернейта?

Быстрее заново загрузить систему и перезапустить приложения. Благо, многие из них имеют поддержку сессий.

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

kexec на десктопе мало кому нужен

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

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

Да пофих, быстрее или нет. Я включил комп и пошел чай делать. Пришел - он уже загрузился, осталось только залогиниться и начать работу с того момента, на котором вчера остановился. А открывать десяток документов и десяток приложений ну вообще не интересно.

another ★★★★ ()

Без явного указания того, что вся эта бессмысленная хрень нужна для соответствия _юридическим_ требованиям UEFI Secure Boot(в противном случае МС может отозвать ключи), новость получается толстовата, IMXO.

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

Пусть этот наркоман делает новые «фичи» отключаемыми.

тогда МС отберёт у тебя ключи от твоего компьютера с Линуксом.
Такова селяви.

Anonymous ★★★★★ ()

Чтобы обеспечить нормальную поддержку спящего режима лучше вырву с потрохами Secure Boot.

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

Я и не говорил «не нужен никому». Я сказал: «мало кому нужен».

Lighting ★★★★★ ()

А говорили кокс кончился...

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

На моих компьютерах нет SecureBoot, а там где есть UEFI есть Force Bios.

bhfq ★★★★★ ()

помимо адской бредовости этой всей затеи.. объясните мне почему бы просто не пользоваться гибернацией? Зачем мусор нести в ядро? Ну на крайняк отключить её просто в конфиге acpid. Не, ну я понимаю что можно какой-нить /sys/power/state заюзать, но это уже не проблема ядра.

Вообще мне вся эта затея с secureboot не нравится. Имхо кроме граблей для линуксоидов создатели других целей и не преследовали.

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

цц Мэт работает над правильной а не маркетинговой реализацией SecureBoot. и правильно всё говорит, текущий гибернэйт не подходит для секьюрбута, хотя можно конечно сделать вариант когда ты просто будешь предупреждён, о том что гибернейт могли похакать, но это доппроверки при загрузке убивающие всю скорость гиберната.

в любом случае для Secure Hibernate логику придётся переработать.

Thero ★★★★★ ()

мда заголовок конечно вывернут наизнанку... но пускай эти лоровские невежды будут в страхе и панике, Мэт всёравно няшка -_-

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

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

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

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

сейчас беспредел можно творить и без этого

Thero ★★★★★ ()

Это все объясняется тем, что разработчики остались без Кокса...

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

там где есть неотключаемый секурбут прилагается талончик на возврат от покупателя по причине аппаратного дефекта. и остаётся простой и милый UEFI BIOS

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

ты точно понял что сделал Мэт и почему? там помоему три абзаца не в лучшем виде но таки рассказывают хотябы про то что сделал Мэт.

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

нене этим какраз таки объясняется куда ушёл весь кокс...

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

На моих компьютерах нет SecureBoot, а там где есть UEFI есть Force Bios.

через 5 лет купить компьютер с отключаемым SecureBoot станет проблематично, через 10 - незаконно.
А существование FOSS в ситуации, когда необходимо отправлять свежескомпилированное ядро на подпись в МС труднопредставимо.

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

ты точно понял что сделал Мэт и почему?

я, возможно, не понимаю смысла во всей этой затее вообще. Пока пользователь/админ организации не может сам решать что можно ставить а что нет это всё выглядит глупо. Тем более что сейчас, на сколько я понял, есть (или пытаются пробить, я так понял мелкомягкие упираются) подписанный мелкомягкими загрузчик который может грузить всё. В чём тогда смысл защиты?

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

через 10 - незаконно

На каком основании будет приниматься такой закон? И да за 5 лет ваш SecureBoot взломают во все поля.

bhfq ★★★★★ ()
Последнее исправление: bhfq (всего исправлений: 1)

Сами себе придумали проблемы и героически с ними справились.

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

я, конечно, не линуксоид, но бред же сивой кобылы?!

если ты считаешь что бред — то не включай режим Secure Boot...

...кто ж виноват что ты такой параноик, но при этом оказывается любишь ещё и комфорт :-)

# P.S.: под словом «ты» я подразумеваю НЕ именно тебя, а вообще любого кто жалуется что отключили Hibernate, в случае не отключённого Secure Boot :-)

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

А говорили кокс кончился...

Так видимо из-за таких извратов Кокс и кончился...

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

Адвокаты МС докажут, что основным назначением компьютеров без SecureBoot является запуск пиратской винды и, следовательно, производство и продажа таких компьютеров - соучастие и попустительство.

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

Мэт работает над правильной а не маркетинговой реализацией SecureBoot

Правильная, это такая, что андроид «порутить» нельзя будет даже через дыру в ПО? Это ж получится отличная тивоизация.

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

Да пофих, быстрее или нет. Я включил комп и пошел чай делать. Пришел - он уже загрузился, осталось только залогиниться и начать работу с того момента, на котором вчера остановился. А открывать десяток документов и десяток приложений ну вообще не интересно.

Два чая этому господину.

wintrolls ☆☆ ()
Ответ на: комментарий от bohm

Сами себе придумали проблемы и героически с ними справились.

Fedora наверно единственный дистрибутив Linux, который ставит цель реализовывать Secure Boot. и я его уважаю за это. потомучто это ЧЕСТНО!

..но кто же тебя заставляет этот SecureBoot-режим включать? вы параноик или садамазахист? если да, то получите то что хотите!

а если некий пользователь Вася Пупкин против своей воли купил компьютер в котором предположим нельзя отключить Secure Boot, то простите но разработчики Fedora тут вовсе не причём. может быть Васю Пупкина обманул Продавец Консультант, может ещё что-то произошло...

....но факт остаётся фактом: Вася Пупкин купил компьютер с ПОВЫШЕННОЙ «безопасностью» и теперь пусть он этой «безопасностью» наслаждается!!! :-)

НЕфига на зеркало пинать если рожа кривая.

хочешь SecureBoot, получи SecureBoot. а если НЕ хочешь SecureBoot значит НЕ включай его!!

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

Сколько лет допиливают, что-то всё никак не допилят.

И кто же им виноват? Пилить патчи для выпиливания хибернейта время есть, а допиливать нет, лол. Прямо квинтэссенция опенсорца.

wintrolls ☆☆ ()

Безумие какое...

А что вообще Хибернейт делал в ядре, и зачем ядру понадобилось ORM?

anonymous ()

Круто. Только нафига мне запускать произвольный образ ядра или отключать подкачку и подменять образ восстановления на целевой (атакуемой/вражеской/исследуемой) машине, если у меня к ней есть физический доступ? Зачем мне запретят запускать произвольный образ ядра, но разрешат модифицировать уже загруженное ядро? Из этих двух вопросов вытекает третий. Т.е. я как владелец PC не смогу заменить на нужное мне ядро, но зато теперь его удалённо модифицировать можно? Кокс говорите? Да нет, грибы в огромных количествах.

xSudo ★★★ ()
Последнее исправление: xSudo (всего исправлений: 2)
Ответ на: комментарий от xSudo

Т.е. я как владелец PC не смогу заменить на нужное мне ядро, но зато теперь его удалённо модифицировать можно? Кокс говорите? Да нет, грибы в огромных количествах.

ну вообще Shim не запрещает загружать любое (самосборное) ядро.

блокирование Hibernate здесь играет роль ЛИШЬ затрудняющую стрельбу себе в ногу.

(при желании — стрельную в ногу Shim всё же разрешит, но при этом более очевидным способом чем через Hibernate :))

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

Вообще мне вся эта затея с secureboot не нравится.

я даже так подозреваю что ты даже и пользоваться Secure Boot не станешь :-)

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

какое это отношение имеет к UEFI, Hibernate, kexec и ko если есть физический доступ к «тушке»?

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