Почему UEFI Secure boot это трудность для Linux

Original author: Matthew Garrett
  • Translation
Недавняя публикация на Хабре об ограничениях 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-вариантом установки ОС.

Заключение

Мы можем написать код требуемый для поддержки Secure boot в Linux в короткие сроки — фактически большая часть его уже завершена. Но значительные практические проблемы остаются, и до настоящего времени мы не имеем рабочего решения для любых из них.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 105

    +2
    Спасибо, все очень четко описано. В прошлой статье смысл не уловил. В этой доступней. Однако это не только проблема для linux, но и для производителей «железа». Захочу я купить pci wi-fi адаптер и вставить в компьютер. А как? А вдруг ключ не подойдет? Опять же проблемы…

    В итоге хотят как лучше, а получается как всегда…
      +9
      А кто в данном случае хочет как лучше?
        +8
        Майкрософт хочет как лучше! Как ей самой лучше.
          0
          Ну и получается пока как лучше (опять же для M$).
            +1
            Ну так это до первого случая, когда кто-нибудь захочет воткнуть свой крутой SoundBlaster в свой крутой новый комп, в котором уже новые ключи.
              0

              Уже. Что бы драйвер производителя железа заработал на Win 10 1609+ нужно подписывать его через MS Dev Portal. Даже cross signing зарубили для драйверов.


              Правда есть исключения:
              1) если подпись была выполнена ключом выпущенным до какого-то там числа 2015 года — такой драйвер продолжит загружаться
              2) если Win 10 1609+ не был установлен с нуля, а дошёл до этого состояния — то старые подписанные драйвера будут работать, плюс cross-sign (это вообще феерично, если честно: обновлялся, обновлялся — всё работало, вдруг снёс, установил заново — оппа! идите лесом!)
              3) что-то там ещё.


              и это уже при Secure Boot и подписанных драйверах. В Linux же так и не понятно, как подписывать драйвера через DKMS или частично бинарные, подобно nvidia, где основная логика в блобе, а в виде исходников — обёртка. И путь только один: сгенерировать пару ключей, подписать и приватные загрузить в MOK или использовать ключи от shim-signed. Только где здесь безопасность?

      +1
      Вроде как в требованиях к x86 у МС написано, что оно должно отключаться, так понимаю, что полностью. В отличии от ARM.
        –2
        В x86 — по желанию, ARM — обязательно. Вполне разумно, мне кажется.
          0
          И для ARM тоже?? Там же своих загрузчиков хватает. Мда, Wintel все еще пытается диктовать свои правила всему рынку персональных компьютеров
            –5
            Для ARM — в первую очередь. Когда на компе какая-нибудь дрянь убьет или подменит загрузчик — это одно. А вот если на планшете — это будет посприниматься намного хуже. Да и какого черта — 99% людей, купивших планшет на винде вряд ли захотят ставить что-то другое. Точно так же как вряд ли 99% покупателей айпада хотят сменить iOS на что-либо другое. Жертвовать безопасностью 99% пользователей в угоду покупателю-извращенцу не очень то разумно.
              +3
              Так сделайте аппаратный переключатель, как на Chromebook-ах и не будет никаких жертв безопасности. Кроме того, когда у вас в мире миллиард пользователей компьютеров, то 1% — это 10 миллионов. Но находите, что это значимая цифра? И при этом, собственно, безопасность важна именно для этих 10 миллионов, поэтому они Windows и не используют. Остальным плевать, и большинство из них хомячит в ботнетах :)
            +2
            Вполне разумно — отключение защиты. Всё остальное не разумно и попахивает загоном юзера в клетку.
              –5
              Ну опять вы с этим религиозным бредом. Ну если покупает человек планшет, заточенный под винду, с виндой, специально — значит ему винда и нужна! Если не нужна винда — есть планшеты на ведроиде и айпэды — бери не хочу.
                0
                А чего вы про планшеты-то? UEFI — это спецификация биосов для PC-совместимых систем. Это не планшеты. Это ноутбуки, десктопы, серверы и т.д.
                  0
                  А разве UEFI обязывает всех подряд ставить secure boot?
                  Это Microsoft обязывает OEM производителей компов с предустановленной виндой включать secure boot по умолчанию (причем с обязательной возможностью отключения).

                  У меня материнка с UEFI и я не заметил проблем с загрузкой линукса.
                    0
                    Насколько я понимаю, косяк же в том, что Microsoft обязывает OEM, которые хотят получить наклейку Windows 8 Logo, создавать такое вот Secure Boot окружение.

                    И тут вопрос: на какой процент устройств производители захотят её налепить. Кроме того, Secure Boot — это часть стандарта UEFI 2.3.1, в более ранних версиях он не был предусмотрен.
                      +3
                      ВЫ намерено игнорируете это?

                      21. 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. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible.
                        0
                        Оу… Новая редакция? Круто :) Спасибо. Не, ну так стало немного лучше. В более ранней PDF-ке этого не было, а вместо required было написано should allow.
                          0
                          Видимо весь этот крик не зря и Microsoft таки прислушивается к нему. Хотя скорее всего это юристы заранее стелят солому перед антимонопольным комитетом.
                            0
                            Видимо. Тут на самом деле не понятно, почему производители ARM-based железа стелятся под Microsoft. Им-то какая выгода? Или им пообещали, что с обновлением Windows юзеров заставят обновлять и железяку?
                              +1
                              Я склоняюсь к мнению что Microsoft собирается демпинговать цены после выхода Windows 8 ARM и не хотят чтобы их покупали для установки андроида.
                          0
                          А я вот тут download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf

                          вижу на странице 116 вижу следующее:

                          On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enable.
                          21. 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. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure MUST NOT be possible on ARM systems.

                          т.е. ничего не в порядке и на армах они хотят пристегнуть юзера наручниками к батарее.
                            0
                            Как будто сейчас таким не занимается большинство производителей планшетов на Android…
                              0
                              Как будто это хорошо. И армы — это не только планшеты, но и ноутбуки как минимум.
                              0
                              Про АРМы я уже сказал, что будет войнушка за рынок планшетов и Microsoft намерен пристегивать пользователей наручниками в обмен на вкусные цены.

                              А так как сейчас на рынке АРМ Винда никак не представлена (если не считать Windows CE), то и отмазки от антимонопольного комитета можно не вставлять.
                                0
                                Да почему все думают, что арм на планшетах закончился. Даже в формфакторе обычного PC оно может быть. Очень будет круто сидеть за такой штукой прибитой гвоздями к винде.
                          0
                          а у меня нетбук lenovo s205 и я неделю мучился пока туда поставил убунту.
                            0
                            Какое отношение это имеет к secure boot?
                              0
                              это имеет отношение к UEFI. там UEFI и она и подержка в линуксе довольно кривые пока.
                                0
                                Ну так пусть поправят.
                          –1
                          Вы читать то умеете? Сказано же — возможности отключения Secure Boot не будет на ARM-планшетах только, на остальных устройствах рекомендуется включать по умолчанию, но разрешить отрубать.
                            0
                            Там не о планшетах речь идёт. Речь идёт о устройствах на базе процессоров ARM, среди которых будет много ноутбуков в первой же волне, например. nVidia планирует использовать ARM в своих PC-чипах для проекта Denver. Кроме того, в требованиях MS написано: should для non-ARM, а не must, или ought, или required. А should имеет такое значение:

                            употребляется для выражения морального долга или советаи имеет в этом случае значение «должен», «следует», «следовало бы»

                            При чём юридическая трактовка всегда «следовало бы». Про ARM же написано чётко и выделено жирным шрифтом: must not.

                            Так что… Как-то так. Что из этого получится — не понятно. Но веселье всем точно гарантировано.
                              0
                              Я выше привел цитату 21-го пункта требований. Should там и в помине нет, зато есть: is required to implement the ability to disable Secure Boot via firmware setup
                                0
                                Да, да. Я уже поблагодарил Вас :) Даже в карму, за облегчение озабоченности происходящим.
                                  0
                                  Угу, только TIgorA забыл процитировать последнее предложение из абзаца этого документа.
                            0
                            Планшет — это формфактор. UEFI поддерживает ARM-ы и Win8 девайсы (планшеты или нет — не важно) обязаны его иметь.
                              0
                              Сомнительно, что будут девайсы кроме планшетов на ARM под виндой. Вряд ли МС решится так жестко подставить Intel.
                                0
                                А причем тут интел-то? И ничего сомнительного не вижу, уже есть пара ноутбуков с армами. Не думаю, что мс будет тихонько уступать этот рынок.
                                  0
                                  При том, что ноуты на АРМах будут давить интеловские ценой и автономностью. Все, что им для этого нужно — винда. Пока винды на АРМ нет — они не угроза. Соответственно — если МС одобрит широкий выпуск ноутов на АРМах — любовь с интелом закончится.
                                    0
                                    Ну. Видимо, прибивание гвоздями — это некий компромис, достигнутый с Intel-ом. Intel будет пиарить себя, как свободную платформу.
                    +6
                    Насколько я понимаю, попытки установить драйвер (в Windows 8) какого-нибудь китайского устройства, или просто устройства не сертифицированного Microsoft будет невозможно? Тогда это, скорее, наоборот оттолкнет людей от Windows, многие же ведь любят покупать всяческие «гаджеты» на DealExtreme или Aliexpress. Ровно так же могут возникнуть и проблемы со старым (но стабильно работающим) принтером (или другим устройством) более не поддерживаемым производителем.

                    Пишу это исходя из того, что требуется не только публикация драйвера доверенным издателем, но и его тестирование на предмет совместимости. Поправьте меня, если я не прав.
                      –1
                      вы не правы в том, что думаете об отличности китайского устройства от брендового в плане железа. Разница только в качестве. железо как правило одинаковое. Ну или описанное в драйверех Windows. Т.е. я устройств покупал оченб много различных, но драйвера к ним никогда не ставил, подходили родные виндовские.
                        0
                        Не всегда. Я тоже часто покупаю различные китайские устройства, могу разделить на три категории:
                        1) Работает «из коробки» (используются стандартные драйвера, включенные в дистрибутив Windows). К таким устройствам, например, относятся продающиеся всюду «микро bluetooth адаптеры».
                        2) Работает с драйверами брэндового производителя. Опять же могу привести в пример bluetooth адаптеры, которые я покупал года 3 назад. Сейчас таких практически не осталось.
                        3) Работает только с драйверами, идущими в комплекте. Так, мне попадалась привередливая веб-камера. Причем магазин забыл положить диск с драйверами, devid.info не помог, пришлось гуглить сайт производителя, которого (сайта) уже не было, чудом сайт (и драйвера) нашлись в archive.org Кстати, к этой же категории относятся, например, драйвера ADFU, необходимые для перепрошивки S1 плееров.
                          0
                          ну я и написал, что не всегда, а как правило. А то что вы написали в трех пунктах только подтверждает мои слова. В 90% случаев установятся виндовские дрова.
                            0
                            В 90% они ставятся для, так скажем, «стандартных» устройств. Попробуйте обойтись виндовскими дровами (или хотя бы подписанными) при использовании таких устройств, как DVB карта, плата видеозахвата или при прошивке плееров или телефонов.

                            Просто по сути то, наиболее интересные предложения для «домашнего использования» китайцы предлагают именно в этом классе устройств. Мышку или bluetooth можно с таким же успехом (и примерно такой же ценой) купить брэндовую и в локальном магазине.
                              0
                              >>Попробуйте обойтись виндовскими дровами (или хотя бы подписанными) при использовании таких устройств, как DVB карта, плата видеозахвата или при прошивке плееров или телефонов.

                              попробуйте обойтись виндовскими дровами для брэндовых устройств. Результат будет тот же.
                                0
                                Мы вроде с подписей цифровых начали, брендовые устройства обычно имеют подписанные драйвера.

                                Не поймите меня неверно, я ни как не противник noname устройств, я противник создания проблем на ровном месте (это я про Secure boot).
                                  0
                                  нет, я начал с того, что железо китайских устройств по большей части точно такое же как и в брендовых устройствах. Соответственно, для 90% устройств подойдут родные ms-драйвера.

                                  Об остальных 10% разговор особый. Да, для брэндовых скорее всгео будут драйвера подписаны, у китайских не будут. Но это частности.
                      +2
                      Подписанного ядра не достаточно. Подписанное ядро Linux должно предотвращать загрузку любых не подписанных модулей ядра. VirtualBox в Linux? До свидания. Бинарные драйверы Nvidia? До свидания.

                      Стоп, стоп, стоп. UEFI требует подписи себя и загрузчика, но не требует принятия политик в самой ОС. При чем тут ядро и вообще то, что делается после стадии когда загрузчик операционной системы начинает работу?
                        +4
                        В противном случае теряется смысл.
                          +1
                          В смысле что я неправ или то что теряется смысл в поддержке Secure boot, если не подписывать и вышележащий софт? Ну и пусть тогда живут в своей защищенности, мы то тут при чем?

                          Реальная проблема в том, что Microsoft опять пытается консолидировать вокруг себя независимых изготовителей железа. С одной стороны они же свободные, что хотят то и делают. Но с другой это отражается на производителях софта, в данном случае разработчиков ОС. Проблема решается через антимонопольные структуры той или иной страны, огорчает то что это работает не везде и только крупный игрок на рынке пойдет на такое. Вот на чем нужно акцентировать внимание.
                            0
                            Хотите сказать, использование Secure Boot UEFI обязывает ОС использовать только подписанные драйверы? А если нет, то что? Сертификат на саму ОС не выдадут?
                              +2
                              Windows 7 x64 может использовать только подписанный драйверы. Если хочется чтото неподписанное, то нужно запускать ОС в режиме без проверки подписей.
                              0
                              Вы путаете тёплое с мягким, запрет на запуск неподписанных драйверов должен быть включен для обеспечения комплексной защиты (так будет в Windows), но загрузчик об этом знать не обязан — его забота проверить подпись ядра и выполнить его запуск.
                            0
                            злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI, прерывает выполнение кода ядром и вызывает загрузчик Windows

                            Можно подумать загрузчик Windows не будет проверять окружение UEFI на подписанность.
                              +3
                              Сторонний загрузчик передаст вызовы оригинальной UEFI. Как прокси.
                                +2
                                — UEFI это я, загрузчик Windows. Ты меня загрузил с правильным ключем?
                                — Не, я загрузил Linux, но он хороший парень.
                                — А ну ладно, наверное он действительно хороший и будет выполнять только полезный код.
                                  +1
                                  Сарказм засчитан.
                                  Почитайте про тип атак Man in Middle.
                                  Главное чтобы была техническая возможность проложить прокси. Но учитывая имплиментации UEFI поверх BIOS это возможно.
                                    0
                                    Сейчас технических возможностей выше крыши, но эпидемии буткитов не наблюдается. Если не считать всякие активаторы винды.

                                    В любом случае для х86 сертификация обязывает иметь отключаемый режим safeboot, скорее всего в виде перемычки на материнке. Если не хватает ума на такое, то к линуксу лучше не подходить.
                                      +1
                                      Я тоже честно говоря до конца не понимаю. Наверное имеется ввиду лживое ощущение абсолютной защищенности.
                                        +6
                                        Ну с этим как раз понятно:
                                        1. Нагоняем панику
                                        2. Выкатываем магическое лекарство — secure boot
                                        3. Блондинки боятся выключать secure boot
                                        4. В режиме secure boot не работают активаторы
                                        5. ???????
                                        6. PROFIT
                                          +1
                                          1. Secure Boot обязателен только для OEM-ов для установки на компьютер OEM-ной же винды
                                          2. «Активаторы» для OEM-ной винды и так не нужны, а самосбору на коленке вообще по фигу на требования к OEM-ам — могут поддерживать SecureBoot, но оставить его выключенным по дефолту, а могут и не поддерживать вообще
                                          3. ??????
                                          4. ??????
                              +1
                              злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI… ядро Windows модифицируется таким образом, что бы скрыть код Linux… данные вашей кредитной карточки уже на пути в Китай

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

                              GPLv3 имеет различные требования к доступности ключей

                              Аналогичная мешанина понятий. Причем здесь GPL к ключам?

                              Думаю, это будут сертификаты Extended Validation

                              Как и прочее, бессмысленное использование понятий. EV используется не там и не так. И так далее.

                              Не, не убедительно…
                                +3
                                злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI… ядро Windows модифицируется таким образом, что бы скрыть код Linux… данные вашей кредитной карточки уже на пути в Китай
                                Запускается линь c виртуализацией и 3д и подключается к локальному диску, запускается вин, а линь все логгирует, пересылка по сети вопрос ловкости рук и мошенства.
                                  –3
                                  Какая линь, какая виртуализия? Кто ее запустит всю, да еще и с 3Д и с локальными дисками?! Зачем все это надо, если «карточки сливаются» тупо через веб и флэш малвари?
                                    0
                                    Того, что линукс залогирует все что винда пошлет через сеть, будет недостаточно, чтобы перехватить зашифрованные данные. с таким же успехом можно просто врезаться в кабель, аля Man in the middle.
                                      0
                                      Почему не логировать то что клиент вводит? :)
                                        0
                                        И встроить кейлогер прямо в контроллер клавиатуры.
                                    +1
                                    > Причем здесь GPL к ключам?
                                    «Installation Information» for a User Product means any methods,
                                    procedures, authorization keys, or other information required to install
                                    and execute modified versions of a covered work in that User Product from
                                    a modified version of its Corresponding Source. The information must
                                    suffice to ensure that the continued functioning of the modified object
                                    code is in no case prevented or interfered with solely because
                                    modification has been made.

                                    Хотите запускать подписанный GRUB — распространяйте приватные ключи для того, чтобы было возможно запускать модифицированный GRUB
                                      –1
                                      Это совсем не те keys, не серийные номера или подобное. RSA keys — это данные, а не код, к GPL не относятся. Вы же свои приватные ключи не раздаете потому, что генерили их каким-нибудь openssl или pgp.
                                        +1
                                        Это именно они. Причем требования введены в GPLv3 как раз для «борьбы» с тивоизацией: «The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.»

                                        Другими словами, OEM-ы не могут продавать машины со включенным SecureBoot и GRUB и при этом не предоставлять закрытых ключей для подписи перекомпилированного GRUB-а (иначе код перестанет работать исключительно из-за факта модификации, что напрямую запрещено). Наверное настоящие юристы могут найти способ обойти это (если кто-то вообще захочет с этим связываться), но и говорить, что GPL вообще никак не связана с ключами не совсем верно
                                          0
                                          Это НЕ они. Тивоизация — это из другой оперы. Какой, к хренам, ОЕМам дело для GRUB-ов и GPL-ов вообще? GPL — это внутритусовочная лицензия. Поменял GRUB — отдай другому. Но запускать BIOS-у что-то или не запускать на основании GPL-ности загрузчика? Это сильно :). По-вашему, все в мире обязаны грузить лишь линукс на грубе, ибо он GPL, посему обязателен к загрузке, а бут Винды — проприетарный.
                                          ОЕМ решает, что бутит только подписанные загрузчики. Сам решает или берет Secure boot — неважно. Так вот вопроса GPL в этой связке даже рядом не стоит. Грубо говоря, кого хочет, того и бутит.
                                          Ключи для подписи — это данные. Если вы подписали свой GRUB личным ключом и распространяете GRUB с подписью «42» это совершенно не обязывает вас открывать приватный ключ.
                                            0
                                            Если вы подписали свой GRUB личным ключом и распространяете GRUB с подписью «42» это совершенно не обязывает вас открывать приватный ключ.

                                            Всё так, но вы упускаете один существенный в данном случае нюанс. Если вы по подписали свой GRUB личным ключом и распространяете его, это дает конечному пользователю возможность удостовериться, что софт собран именно вами, и по пути от вас к пользователю никто его не модифицировал. Но ничего не мешает пользователю самостоятельно, из поставляемых вами же исходных кодов, собрать свой GRUB добавить рюшечек и использовать именно его. Так дело обстоит сейчас. Если же будет включен Secure boot, и он будет проверять подпись прежде, чем передать управление GRUB, то вы не сможете воспользоваться своей собственной сборкой GRUB, даже из тех же самых исходных кодов, потому как не сможете подписать его. И фактически получаете закрытый бинарный GRUB, с которым ничего сделать не сможете. Именно об этом приведенная выше ссылка на GPLv3.
                                              0
                                              то вы не сможете воспользоваться своей собственной сборкой GRUB

                                              Не сможете, и чо? Каким образом это должно волновать производителя и тем более, привязывать его к лицензии, по которой распространяется некий неведомый GRUB? Ссылка на GPL тут левая, не к месту совершенно, поймите.

                                              Кому нужен будет свой GRUB — отключит SecureBoot, делов-то. Или купит сертификат. Если сертификаты будут дорогие или найдутся производители с неотключаемым SecureBoot, те 15 человек в мире, которые компилируют свои GRUB-ы, найдут способ мэйнтейнить список неподходящих систем, правда?
                                              +3
                                              Тивоизация — это из оперы «поставил в железку и запретил чего либо менять хотя и открыл все исходники». OEM-ам дело до GRUB-а такое, что надо бы Линукс как то грузить (ну это, конечно, если кто нибудь из OEM-ов все еще хочет связываться с Линуксом).

                                              > Но запускать BIOS-у что-то или не запускать на основании GPL-ности загрузчика? Это сильно :).
                                              Straw-man. Перечитайте еще раз. Проблемы с GPL и GRUB возникнут у любого OEM, который решит выпускать компьютер с предустановленным Линуксом и включенным SecureBoot. Да, этих проблем в «реальном мире» не возникнет, потому что в «реальном мире» OEM-ы просто не будут выпускать компьютеры с предустановленным Линуксом и SecureBoot.

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

                                              > Ключи для подписи — это данные.
                                              Очень глубокое замечание.

                                              > Если вы подписали свой GRUB личным ключом и распространяете GRUB с подписью «42» это совершенно не обязывает вас открывать приватный ключ.
                                              Утверждать чего либо без решения суда не могут даже настоящие юристы, но лично для меня вполне очевидно, что данное требование GRUB-а вполне недвусмысленно требует открытия приватных ключей, чтоб можно было подписать видоизмененный GRUB: именно для борьбы с аппаратными проверками подписей «прошивок» (тивоизацией) это требование и было введено в последнюю редакцию GPL (если его можно обойти какими нибудь хитрыми юридическими ухищрениями — это не значит, что у GPL нет ничего общего с ключами).
                                                0
                                                Тивоизация — это из оперы «поставил в железку и запретил чего либо менять хотя и открыл все исходники». OEM-ам дело до GRUB-а такое, что надо бы Линукс как то грузить (ну это, конечно, если кто нибудь из OEM-ов все еще хочет связываться с Линуксом).

                                                Я в курсе. Если речь идет про железку. Откуда и слово пошло :). У производителей железки нет выхода. Железку и софт так просто не поменяешь. А PC — это открытая платформа. Помимо совершенно очевидных способов отказа от любой GPL системы или отключения SecureBoot для GPL системы, у производителя есть еще масса разных вариантов.

                                                Например, поставлять Линукс систему с дистрибутивом (или даже имиджем) на CD, предварительно сохранив ключ этого GRUB (а то и нескольких, из стандартных дистрибутивов). Вот и все: Линукс установлен, лицензия не нарушена, система закрыта.

                                                И так далее. Вариантов так много, что несколько лень перечислять.

                                                Нельзя распространять условия GPL на потенциальную возможность установить софт GPL. OEM, записавший в свои таблицы ключ GRUB, просто записывает 128 или 256 байт, а не обязывается под лицензией! Да, без этих 256 байт нельзя будет использовать GRUB, но и само использование GRUB не может быть обязательным. В embedded-системе обязательно, а на PC — нет. Утверждать обратное — значит утверждать, что любой запуск GPL-приложения на компьютере автоматически и навсегда привязывает все приложения на всех носителях этого компьютера (а также его BIOS и микрокоды) к GPL.

                                                Надеюсь, Вы понимаете о чем я (подозреваю, что выражаюсь немного путано, но сформулировать понятнее конкретно сейчас нет времени).
                                                  0
                                                  Остальные варианты стоят слишком дорого для массовых систем, если Газпром закажет сто тысяч ноутбуков с Линуксом и включенным secure boot — для них это сделают за отдельную денежку, а обычные потребители за подобные штуки платить не готовы (персонализация стоит дополнительных денег).
                                        +1
                                        Я не знаю, что курил автор этого сценария, но для отправки кредитной карточки в Китай злоумышленнику будет проще отправить к жертве пару амбалов. Какая-то дикая, нереальная мешанина ядер, модулей, уровня приложений и угроз для кредитной карточки.

                                        А Вы про виртуализацию слышали? Ничего в этом дикого нет. UEFI — это программный код, который можно достать бесплатно, в открытых исходниках, например, у Intel, перефигачить его так, как надо, запустить с ним виртуальную машину. Да и без виртуальной машины можно. Загрузчик UEFI видит этот самый UEFI просто через таблицу указателей на функции. Подменили таблицу — всё, приехали. Важные вызовы, например, какая-нибудь проверка аутентичности UEFI можно пропускать к реальному UEFI железяки, а остальное перехватывать и подменять так, как нужно. Стандартный метод взлома подобной защиты.

                                        Это не так уж и сложно и никакие амбалы не нужны. Большинство всяких мощных хакерских тулзов делают это полуавтоматически.

                                        Аналогичная мешанина понятий. Причем здесь GPL к ключам?

                                        В GPLv3 написно: все ключи, требующиеся для установки ПО должны быть опубликованы.
                                          0
                                          А Вы про виртуализацию слышали?

                                          Я и про использование четырех 0day vulnerabilities одновременно слышал, и про взрыв центрифуг на ядерном заводе. И что? Вы слышали про кражу кредитной карты через виртуализацию? Ну бред же!

                                          Подменили таблицу — всё, приехали

                                          Для этого (в смысле, против этого) весь этот Секюрбут и придумывают.

                                          В GPLv3 написно: все ключи, требующиеся для установки ПО должны быть опубликованы

                                          Это чушь, извините. И в любом случае не имеет отношения к BIOS-у (который не GPL) и ключам-подписям (которые не GPL). Я тут в другой ветке подобнее отметил.
                                            –3
                                            Про кредитную карточку — нет. Про учётную запись в Steam — да. При чём украли её у меня :) Откуда я знаю, что украли именно через виртуализацию? А случайно вызвал командочку для проверки содержимого BIOS на соответствее залитому туда образу, и потом пришлось ковырять его на предмет кода, и в итоге оказалось, что вот оно самое. С тех пор не пользуюсь Windows вообще. Если система не может защитить доступ к BIOS, то ей в плане безопасности уже ничего не поможет, там куча багов будет и в механизмах валидации. Такая уж квалификация у программистов MS… Все талантливые люди в независимых стартапах, гугле, интеле или фэйсбуке.

                                            И никакая это не чушь. Там прямым текстом в лицензии написано про Тивоизацию. Кажется, вам уже про это там написали.
                                            0
                                            ЕМНИП в UEFI есть защита от модификации, а обновления осуществляются встроенным механизмом, который сверяет цифровую подпись у них (вместо прямой перезаписи ПЗУ из ОС, как это было с BIOS).
                                          0
                                          Это как с законами. Было когда-то все хорошо и четко… так нет, надо сделать искусственно созданные преграды, чтобы кто-то их потом преодолевал.
                                          Также очень интересно, с чего это майкрософт взялась диктовать всем какие-то там условия. Хотелось бы увидеть, что она будет послана нафиг и соберутся адекватные производители софта и железа, которые сообща разработают более грамотную, понятную и четкую реализацию этой хрени.

                                          А вообще кроме красивого мышкотыкательного биоса я профита не вижу в это костыле.
                                            0
                                            Зачем оно нужно в реалтайме?

                                            Мониторинг ACPI, IPMI, да хотя бы просто объем оставшейся у ноута батарейки по аппаратной клавише в любом месте (ну, это уже было..)? Переключение видеокарт не через такой кривой костыль, как Optimus? Также возможно — какое-то взаимодействие с гипервизором в кластере.
                                            +4
                                            Возможно, эта дрянь поможет развитию нормальных архитектур. Хотя бы того же MIPS.
                                              +1
                                              Подписанного ядра не достаточно. Подписанное ядро Linux должно предотвращать загрузку любых не подписанных модулей ядра. VirtualBox в Linux? До свидания. Бинарные драйверы Nvidia? До свидания. Всё что выходит за пределы стандартных модулей ядра? Так же до новых встреч.

                                              Если ядро Linux будет подписано (предположим у Red Hat нашлись деньги на один ключик), то оно же не обязано грузить только подписанные драйверы? Или подписанные ядра обяжут загружать только подписанные модули?
                                              • UFO just landed and posted this here
                                                  0
                                                  Обязать, конечно, не обяжут, но если у вас будет secure boot, подписанный загрузчик и подписанное ядро, которое будет загружать в том числе и неподписанные модули, то смысл первых трех компонентов этой связки сводится к нулю, а всё вместе как раз и сделает возможным описанную в посте ситуацию с fake UEFI.
                                                  0
                                                  Хм, только что в голову пришло. Я итак понимаю в современных процессорах появился уровень гипервизора(аппаратная виртуализация если по-русски), который вроде как позволяет не воспринимать uefi серьёзно. Или я неправ?
                                                    0
                                                    Это поддержка определенного набора инструкций процессором. Например созданная интелом VT-x, или IOMMU от AMD — позволяют виртуализировать операции I/O и пробрасывать девайсы с PCI в гостевую систему, что дает прирост производительности, сопоставимый с производительностью невиртуализированной среды. Но как это может быть связано UEFI, я слабо представляю.
                                                      +1
                                                      Чтобы начать её использовать, надо сначала загрузить какой-то код в проц. Как ты загрузишь код, если UEFI ему не даст запуститься из-за подписи?
                                                      0
                                                      PK — это не private key, это Platform Key, который, естественно, в железяку прошивается открытый, то есть PKpub
                                                        +2
                                                        А вообще, реально ли просто сделать такое: послать всю эту компашку Microsoft куда подальше, и разработать спецификацию для Linux-устройств? С наклейкой и всё такое прочее. Запустить рекламную компанию: Linux — это круто, потому что он уже реально круче, чем Windows для большинства use-case-ов. Родителям в рекламке сообщить: что под Linux куча образовательных программок, а тупого компьютерно-игрового мочилова нету…

                                                        Потратить на это усилия, а не на борьбу против или там на закупку безумно дорогих ключей. Сможет Linux Foundation такое потянуть? Вполне актуально сейчас.
                                                          0
                                                          P.S. Я б даже на такое денюжку бы задонейтил.
                                                            +1
                                                            > что под Linux куча образовательных программок, а тупого компьютерно-игрового мочилова нету…
                                                            Образовательные программки под линукс ограничиваются тем браузером, из-под которого смотрятся обзоры софта для iOS. Взять хотя бы флагман детского обучения — OLPC XO. Что там предустановлено? Tux paint и среда программирования…
                                                              0
                                                              Ой да ладно, kdeedu хотя бы. Stellarium-ы, Шестерёнки, Механика есть, Черепашка и т.д. Опять же, если в Вашем дистрибутиве этого нет, это не означает, что этого нет вообще. OLPC XO — это не флагман обучения, это компьютер для детей из экономически неразвитых стран. Учат их в школе, традиционными методами.
                                                                0
                                                                Вы, возможно, не так меня поняли — меня интересует именно функционал, приучающий 3-летнего ребенка правильно тыкать клавиши, особенно если этот ребенок уже поиграл в каких-нибудь птичек и теперь воротит лицо от kdeedu к телефону с оными птичками.

                                                                Почему-то под другую_ос писать игрушки, использующие только контролы GDI, прекратили еще в 98-99 годах. Никто не говорит, что в образовательном приложении должен быть крутой_графон, но по крайней мере — досовские игрушки Babytype и TIM были несколько привлекательнее всего упомянутого.

                                                                Stellarium — да, но у него в общем-то другая целевая аудитория. А вот теперь найдите, допустим, что-то с курсом математики для дошколят, более-менее интерактивное и с достойным контентом. Под винду оно есть (правда, соответствует только первому критерию).

                                                                Ну так и что рекламировать, кроме воздуха? Напомню, по зомбоящику уже крутят рекламу MS Office, в которой ребенок верстает презенташку про собаку. Что на это ответит опенсурц? Несобирающимся ebuild'ом dreamchess, разве что? (мля, хотел дать ребенку более-менее визуально_интригующие шахматы, так оно сначала не собралось, а потом падало через раз)
                                                                  0
                                                                  А почему ему ту же самую презенташку не верстать в OpenOffice?

                                                                  Про dreamchess не знаю, всё же зависит от настроек ebuild-а, может Gentoo — это совсем даже и не user-friendly система, и если там в portage есть пакет, это ещё не означает, что он гарантированно соберётся и будет стабильно работать. У них философия такая. Возьмите лучше Arch. У меня из AUR dreamchess собрался, музыка скачалась, всё запустилось. Вроде висит он в бэкграунде, не падает.

                                                                  Про математику под Linux не знал, полез искать, и вот наткнулся на gcompris.net Ну и здесь: educational-freeware.com — тоже богатый выбор, многое есть под Linux

                                                                  По моему, достаточно богатый выбор.
                                                              0
                                                              Запрещать так называемое «тупое игровое мочилово» — идиотизм. Весьма нелюбезно отношусь к людям, которые поносят action-игры. Причем, вы не правы, под Линукс есть замечательный Nexuiz, OpenArena и иже с ними (спасибо Кармаку за это).

                                                              Идея — утопическая. На сколько порядков у M$ больше денег чем у Linux Foundation — догадайтесь сами.
                                                                0
                                                                Никто не запрещает. Просто сказать, а вот это мочилово (какой-нибудь именитый тайтл) у нас просто не работает. И это будет правда. Кстати, OpenArena или Nexuiz достаточно абстрактное мочилово, и не особо кровавое, и быстро надоедающее.
                                                                  0
                                                                  А уж под MS-DOS даже и такого не будет! Вот она, система мечты.
                                                                  По-моему такими действиями вы привлечете не тех людей. Соплежуйство на тему жестокости в играх, тяжелой музыки и тд. ущербно по своей сути (на эту тему хорошо высказывался тот-же Д.Карлин).
                                                                  Линукс — система для программеров, с возможностью гибкой настройки (ну и есть неплохие попытки сделать на ее базе надежную user-friendly систему для мобильных девайсов, см. Android и MeeGo). У нее хватает достоинств, кроме отсутствия определенного софта.
                                                                    0
                                                                    Да при чём тут соплежуйство? Речь просто о рекламных лозунгах, которые могут быть популярны в народе (в американском народе). А они все там печалятся о том, что с одной стороны, без компа никак, а с другой, дети втыкают на этом компе не в книжки и учебники, а в какой-нибудь там Carmageddon (работает под MS-DOS, кстати) где сплошное смертоубийство и кровища.

                                                                    Вот на этом просто можно сыграть. Это бизнес и PR, ничего личного. Ещё можно заказать партию игрушечных Tux-ов, проплатить Simpson-ам серию про Linux :) и всё такое прочее.
                                                                0
                                                                Они сейчас поняли, что надо планшеты захватить. Думаю, туда все силы. Рынок ПК считается проигранным почти полностью. Но я б денюжку тоже дал.
                                                                0
                                                                То есть необходимость оставить возможность легально загружать свой код в это самое EFI никого не волнует, и все хотят открытый линукс на закрытой x86 платформе?

                                                                EFI вообще позволяет инициализацию устройств, у которых на борту есть option rom/его аналог? Про то, чтобы вынести управление такими устройствами в тот самый графический интерфейс или доступный из userspace сервис, по-моему, речи вообще нет?
                                                                  0
                                                                  Так все знают, что UEFI хорош по некоторым параметрам, но Secure boot всё портит. Если будет куча доступных UEFI-систем без Secure Boot — будет щастье.
                                                                  –1
                                                                  С каждым разом удивляюсь наглости некоторых лиц. В голове возникла студенческая аналогия. Прибегает неродивый студент на предмет, который долго прогуливал, а его сверстники уже активно изучили многое. Тут он прибегает, говорит преподу — нет, все, будете все следующие пары мне индивидуально объяснять, как старые темы, так и новые, то что по-мимо меня есть другие студенты, которые хотят изучать этот предмет меня не волнует. А мой пап знаете кто! Так что если не пойдете на это, то быстро вылетите со своего места.

                                                                  Only users with full accounts can post comments. Log in, please.