Нужен ли UEFI?
Пришло время переустанавливать Linux!
Медитирую на этот UEFI, блин. В бивисе (или как оно теперь называется), включено LEGACY+UEFI, тобишь загружается и так и сяк нормально. Но вот раз уж нам дали этот UEFI, может стоит им пользоваться?
Вообще, стоит ли этот UEFI своих лишних телодвижений по его установке или вообще пофиг? Разницы не замечу?
И стоит ли переходить с MBR (fdisk) на GPT (parted) разметку, если винт всего 64гб? Или опять пофиг, разницы не будет?
И еще. Таблицы разделов никак не влияют на блочные устройства? Если система будет установлена на /dev/sda1 при нынешней властвующей MBR, то потом при переходе на UEFI и GPT разметку я смогу тупо бекапом всего /dev/sda1 утилитой dd перенести ее на GPT разметку без лишних движений?
Нафига? Единственный заметный профит от GPT — можно создать до хрена разделов не заморачиваясь с логическими дисками. Отчасти по этой причине размечал SSD в M$ DOS, ибо кроме системы там держать нечего и куча разделов не нужна. Ну а винт с хомяком таки в GPT, поскольку иногда беру какую-нибудь систему на потыкать.
И стоит ли переходить с MBR (fdisk) на GPT (parted) разметку
Вот. Можно, конечно, сказать, что у ТС винт всего 64Гб и он с этой проблемой вряд ли столкнется (когда я разбивал винт, тоже не думал что столкнусь). Использование гпт, в данном случае, можно считать формой протеста против говна: в эпоху терабайтных винтов ты не можешь создать больше 4 разделов, потому что когда-то сэкономили несколько килобайт в начале. Просто противно пользоваться такой технологией.
не нужен, если у тебя диски ★★★ ( 16.12.14 10:16:40 )
ты не можешь создать больше 4 разделов
стоит ли этот UEFI своих лишних телодвижений
оно позволяет отказаться от загрузчика.
стоит ли переходить с MBR (fdisk) на GPT (parted)
у MBR ограничение в четыре примари раздела, у GPT больше, НО, если нужно UEFI, то нужно GPT, ибо иначе это будут костыли. оффтопик вообще не установится в EFI-режиме на MBR.
примари+екстендед разделов не более четырёх, а на логикал оффтопик не ставится.
а где тут про оффтопик и ставится, тем более на 64ГБ ?
неиспользование гпт можно считать формой протеста против микрософта в твоём линуксе. Хотя конечно этот линукс принадлежит не тебе, а микрософту, который милостиво дозволил пользоваться своим vfat, отключать секуребут или подписывать ядра и управлять ключами.
я предупреждаю возможные проблемы, не более.
Перекатываемся, посоны.
тогда имеет смысл упомянуть и про проблемы uefi — система с ним не будет грузиться с lvm и mdadm.
не будет грузиться с lvm и mdadm
про это я не знал, но запомню.
хотя, зачем оно мне? у меня же btrfs.
А пофиг, он же загрузки ни с чего кроме фат32 не умеет. Загрузочный диск без костылей не продублируешь, при каждом обновлении загрузчика костыли надо повторять. МС знали, что делали, влепили проприоретарную fat32 без альтернатив. Есть еще один момент, про который забывают:
В феврале 2009 года Майкрософт подала в суд на компанию TomTom, производителя автомобильных навигационных систем на основе Linux, обвиняя её в нарушении патентов.
По мнению Джереми Эллисона, цель Майкрософт — поставить различные компании перед выбором: заключить с Майкрософт договор о патентной защите (такой, который с ней заключила Novell в ноябре 2006 года), нарушив тем самым лицензию GNU GPL, и сделав невозможным для себя использование Linux, или не заключать такого договора, и быть обвинённой в нарушении патентов, защита по которым предоставляется при его заключении при условии неразглашения.
uefi поддерживает кучу разделов (mbr может до 13, как минимум, и ехт вроде продлять можно было, не помню, за >20 лет работу максимум 5-7 разделов на этом уровне требовалось), привязана к фат(на mbr-что угодно), лицензионная ловушка (mbr-free), короче, да, uefi-круто,модно,молодежно и как это мы до сих пор без нее жили и дальше живем.
Всё в LVM, кроме EFI-раздела. УМВР. Но сам EFI засунуть нельзя, да — ты это имел в виду?
Да, мне с mdadm актуально для дублирования системных-загрузочных дисков. GPT c резервным бутом на втором диске, как выяснилось, работает не всегда, по крайней мере на том интеле, что мучали в прошлом году.
Единственный заметный профит от GPT
. это две копии таблиц разделов, с контрольными суммами.
и mbr пофиг на порчу.
А еще в GPT тип раздела в невменяемых гуидах.
У MBR 32-битная адресация LBA. Там больше 2ТБ вообще нельзя, так что дело не только в количестве разделов.
оно позволяет отказаться от загрузчика.
Это, с одной стороны, плюс (на самом деле это плюс чисто для перфекционистов), с другой — минус.
Источник
ubuntu + uefi или всё-таки юзать груб легаси?
Дано ноут с uefi + возможность грузиться в обычном legacy режиме
Ось -xubuntu 17.04
Что хочу — быстрейшую загрузку, сейчас винт пустой, gpt разметка
буду ставить с флешки.
Вопрос — можно ли как-то грузить ядро прямо из uefi? можно ли не ставить груб?
Нужно ли юзать груб уефи вместо всего этого?
что есть ещё? systemd-boot?
какие есть фичи у груба? какая разница в скорости загрузки и стоит ли вообще заморачиваться?
в общем сслылки на рабочие маны как лучше организовать загрузку приветствуются
efibootmgr: EFI variables are not supported on this system.
это потому что я через легаси режим загрузился или мне придётся ставить груб?
Что хочу — быстрейшую загрузку, сейчас винт пустой, gpt разметка
Вопрос — можно ли как-то грузить ядро прямо из uefi? можно ли не ставить груб?
Нужно ли юзать груб уефи вместо всего этого?
Либо GRUB (в режиме UEFI), либо не GRUB. Странный вопрос.
Много фич. Скриптовый язык внутри загрузчика.
какая разница в скорости загрузки и стоит ли вообще заморачиваться?
На сам груб уйдёт примерно 0.5-1 с.
в общем сслылки на рабочие маны как лучше организовать загрузку приветствуются
В убунте — так, как сделано по умолчанию. Она не приспособлена к кастомизации под себя. Будешь воевать с системой и после каждого обновления восстанавливать свой конфиг, услужливо перезаписанный дефолтным.
efibootmgr: EFI variables are not supported on this system.
это потому что я через легаси режим загрузился
можно ли как-то грузить ядро прямо из uefi? можно ли не ставить груб?
Нужно ли юзать груб уефи вместо всего этого?
Да, если у тебя рут закриптован.
какие есть фичи у груба? какая разница в скорости загрузки и стоит ли вообще заморачиваться?
Абзацем выше. Загрузчик отнимает от 2ms до ∞, в зависимости от таймера выбора, ожидания ввода пароля и прочего. В среднем это 50-300ms без всего. EFI — это тоже загрузчик, но он простой, потому быстрый.
в общем сслылки на рабочие маны как лучше организовать загрузку приветствуются
У меня в профиле есть. Не для мышевозов, но полезного, надеюсь, почерпнёшь.
Источник
Почему UEFI Secure boot это трудность для Linux
Недавняя публикация на Хабре об ограничениях UEFI вызвала широкое обсуждение, в продолжении темы, хочу поделиться переводом актуального поста из блога Matthew Garrett, одного из разработчиков RedHat.
Я писал о технических деталях поддержки Linux`ом спецификации UEFI Secure boot. Не смотря на то, что я прямо указал, что она игнорирует вопросы лицензирования и распространение ключей, тем не менее опираясь на неё люди утверждают, что поддержка Secure boot может быть добавлена в Linux с минимальными усилиями. В некотором смысле, они правы. Технические детали реализации достаточно просты. Но трудности заключены не в них.
Safe boot требует, что бы весь код, который взаимодействует с железом, был доверенным.
В настоящее время, если вы можете выполнить не доверенный код до загрузки ОС, то можете сделать с ОС всё, что захотите. Secure boot предоставляет механизм, который позволяет быть уверенным, что вы запускаете только доверенный код, что призвано защитить от подобных сценариев. Итак, ваши UEFI драйвера снабжены цифровой подписью, загрузчик так же снабжен цифровой подписью и может загрузить только подписанное ядро. Если для загрузки вами использовался только доверенный код, то вы можете быть уверены, что ваша ОС в безопасности. Но, в отличии от загрузки доверенного кода, Secure boot не даёт вам возможности быть уверенным, что выполняется только доверенный код. Это должно быть обеспечено политиками ОС.
На первый взгляд это не составляет большой проблемы. Но на самом деле является ей. Представьте, что у вас есть подписанный загрузчик Linux и подписанное ядро Linux и эти подписи сделаны с помощью глобального доверенного ключа. Они будут загружаться на любом железе использующем Secure boot. Теперь представьте, что злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI, прерывает выполнение кода ядром и вызывает загрузчик Windows — что-то вроде kexec, но чуть более сложное. Загрузчик Windows уверен, что он выполняется в Secure boot, но на самом деле, всё, что на его взгляд заслуживает доверия, является поддельным кодом UEFI, написанным злоумышленником. Ключ шифрования пользователя записывается, ядро Windows модифицируется таким образом, что бы скрыть код Linux и не смотря на то, что всё выглядит замечательно, данные вашей кредитной карточки уже на пути в Китай. В этом сценарии подписанное ядро Linux просто используется как загрузчик вредоносного ПО. Единственным признаком, что что-то не так, является чуть более долгая загрузка ОС.
Подписанного ядра не достаточно. Подписанное ядро Linux должно предотвращать загрузку любых не подписанных модулей ядра. VirtualBox в Linux? До свидания. Бинарные драйверы Nvidia? До свидания. Всё что выходит за пределы стандартных модулей ядра? Так же до новых встреч. Самостоятельная сборка новых драйверов? В другой раз. Всё это явно не сделает людей счастливее.
(Тоже самое, конечно, касается и Windows. Windows 7 позволяет запретить проверку цифровой подписи драйверов, но Windows 8 не позволит этого сделать, если система использует механизм Secure boot).
Лицензирование
GPLv3 имеет различные требования к доступности ключей используемых для подписи. Согласно новым требованиям Microsoft, система должна поддерживать установку пользовательских ключей, что позволит пользователям использовать их собственные загрузчики ОС, этого вполне может быть достаточно, что бы соблюсти требования лицензии. Но мы попадаем в зависимость от Microsoft — если они уберут это требование, то пользователи теряют свою свободу и мы оказываемся в неловком положении с вопросом о лицензировании. Обсуждения о том, что конкретно мы сможем предпринять в этом случае, еще продолжаются, но на текущей момент эта проблема не решена.
Распространение ключей
Спецификация UEFI не определяет, кто будет являться центральным удостоверяющим центром. Microsoft настаивает, что бы каждый имел свой собственный ключ. Мы, конечно, можем сгенерировать собственные ключи, но не всё так просто с производителями оборудования. Не существует пути, который гарантировал бы, что все производители железа поддержат их. И, очевидно, если мы сгенерируем ключ, мы не сможем просто передать его приватную часть третьим лицам. Это значит, что для людей станет невозможным выпуск собственных дистрибутивов, основанных на других, без получения их личного ключа. Для получения ключа будет требоваться какая-либо процедура проверки идентификации, которая, вероятно, окажется дорогостоящей, и так же вероятно, что может потребоваться легально зарегистрированная организация, для обеспечения проверки идентификационных данных. Думаю, это будут сертификаты Extended Validation, а не Startssl Free. Таким образом, диструбутивы Linux созданные энтузиастами, окажутся в прошлом.
Разве Custom mode не решает эту проблему?
Сертификационные требования Microsoft указывают, что все системы должны поддерживать Custom mode, реализация этой функции должна обеспечить возможность пользователям устанавливать их собственные ключи. Производители Linux смогут поставлять их собственные ключи вместе с дистрибутивом и устанавливать собственные политики. Все счастливы. На самом деле, всё не так хорошо. Людям придётся тратить невероятное количество времени и усилий для того чтобы установить Linux, вместо того, чтобы просто вставить CD в привод. Потребность изменения прошивки и её перенастройка добавляет дополнительный барьер и ограничивает возможность установки Linux лишь более технически грамотными пользователями. А это еще хуже. Вот полное описание требований к Custom mode:
1. Для физически находящегося за устройством пользователя, должна быть возможность использования режима Custom mode, для модифицирования содержимого базы данных сигнатур Secure boot и PK (прим. переводчика: PK — private key).
2. Если пользователь удаляет PK, то при выходе из режима Custom mode, система будет функционировать в режиме Setup Mode c выключенным по-умолчанию Secure Boot.
3. Меню настройки прошивки должно уведомлять о включении Secure boot, а так же о режиме функционирования Standard или Custom mode. Меню настройки так же должно предоставлять возможность возвратиться от Custom к Standard mode, с восстановлением заводских настроек по-умолчанию.
Здесь кое-что упущено, например:
— Какое-либо описание UI. Это делает фактически невозможным документирование процесса установки Linux, когда первый шаг (а) запутан и (б) зависит от производителя. Производители железа стараются выделить себя, предлагая свои собственные уникальные интерфейсы прошивок. Custom mode в них может выглядеть совершенно по-разному.
— Какое-либо описание формата ключа. Простое бинарное представление ключа? Или структура EFI_SIGNATURE_DATA? Ключ в кодировке base64, далее защищенный ROT13? Мы просто не знаем.
— Какой-либо путь для использования режима Custom mode при unattended-варианте установки ОС. Интерфейс прошивки требует физического присутствия пользователя. Желаете установить ОС на несколько тысяч машин по сети? Это не масштабируемый подход.
— … и одна мелочь, на самом деле, нигде нет требований, что бы пользователь мог сам добавлять ключ, производители железа могут воспользоваться этим, разрешив лишь удалять ключи. Это не плохо, пока пользователи могут удалять PK, потому-что затем они вернутся обратно в Setup mode и смогут установить наши ключи из установщика, но на практике это по-прежнему будет вызывать проблемы.
Всё таки Custom mode не решает всех проблем. Custom mode с строго определенным UI и форматом ключа был бы на много лучше, но по-прежнему не решит проблему с автоматическим unattended-вариантом установки ОС.
Источник
