DebConf 12: разработчики Debian обсудили возможность включения UEFI SecureBoot в версию 7.0 «Wheezy»

Надеюсь что таки нет. Иначе к гемору с ACPI таблицами добавится еще вот это. Начнется старая песня - M$ надавит на производителя и он начнет «забывать» проливать этот ключ, а потом конечно исправится и выпустит патч, для накатывания которого нужно будет выньду лицензионную ставить. Не факт что так будет конечно, но я такую вероятность исключить не могу.

Ему и забывать не надо. Как только утечёт закрытый ключ МС будет требовать от производителей удалить этот ключ из железа и те, скорее всего, послушаются. В противном случае включенный SecureBoot от выключенного отличаться не будет ( малвароклепатели будут просто подписываться открытым ключом). Куда интереснее будет если утечёт закрытый ключ МС особенно после того как по рукам разойдётся тонна железа с этим ключом.

Деньги правят миром и тот сильней у кого их больше(Ц). эммм.............Думаю билли еще поимеют на несколько миллионов американских рублей.Ибо нех..

Билли уже не у дел. Стива уж что-ли поминайте тогда.

Конечно ты всё неправильно понял. UEFI с SecureBoot проверяет подпись на загрузчике и, если она валидная, то передаёт управление загрузчику. А загрузчик уже проверяет ядро и передаёт управление ядру. И так далее.

Ну, это я и имел в виду. На всех этих этапах проверяется только MS ключи. Наличие в материнке других ключей, даже общественных и скомпроментированных (ибо для свободных операционок должна быть открыта и закрытая часть), на работу винды никак не повлияют.

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

Обычно для смены загрузочного устройства достаточно тыкнуть в boot menu, так что тут ты не прав.

Vekt> Что плохого случится с Дебианом, если реализуют поддержку секьюр бута?

Ничего хорошего - точно. На данный момент реализация поддержки SecureBoot - это поддержка самого SecureBoot. Нельзя будет делать свой дистрибутив, нельзя будет копаться в системных внутренностях компьютера и дофига всего нельзя будет сделать. А если появится ОС более подходящая для определённых задач - фигвам. Конкретно линуксу же плохо будет и тем, что будут прецеденты, из-за которых антимонопольный комитет откажет в запрете SecureBoot. Плюс добавится геморрой с установкой и т.д. Но это фигня по сравнению с ультимативными локерами компьютеров, которых антивирусы не смогут забороть и пользователь не вытащит. Похоже, что мир забыл Чернобыль. И вообще я что-то ен понимаю: а почему бздуны молчат в тряпочку? Их система при таком раскладе первым делом отправляется в расход.

ak372771> А что ты узнал обо мне из моей реплики?

То, что ты не станешь поддерживать бойкот, так как считаешь его бесполезным делом. А это на данный момент одно из обязательных действий.

Зря не рассматриваешь ARM всерьёз. Эта архитектура сейчас наиболее перспективна для замены x86 на десктопах. Похоже, мелкософт и намеревается ворваться туда.

Про возможность записи своих ключей у мелкософта я не видел. Отключение же не регламентируется ничем. Может быть, отключение сделают через специальный код производителя. Формально всё есть, но на практике при таком раскладе пользователь нифига не сможет сделать.

invy> На мой взгляд основная фича secure boot - не допустить руткиты в систему.

Основная фича SecureBoot - это как раз таки почти неудаляемые руткиты.

invy> Другими словами, если кто-то решает переписать в шиндошс ntdll, то с secure boot без наличия у авторов вредоносной программы ключика MS это будет невозможно.

Через баги системы - вполне. Через баги UEFI - вообще как нефиг делать. А они будут, как показала история с моторолой и патформами P2K и EZX.

CoreBoot давно допилен.

Кроме этого есть и другие побочные эффекты:

1. Компьютеры имеют свойство ломаться. Надо где-то новые брать.

2. А как же пополнение рядом пользователей линукса? Даже если кто-то сильно захочет - шиш ему, а не линукс.

3. А написание своей ОС?

Там SecureBoot не будет. Разве что в железе с серверной вендой будет идти.

А без этого UEFI SecureBoot в Debian совсем никак?

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

лезем в биос и отключаем, проблемы нет

Эта архитектура сейчас наиболее перспективна для замены x86 на десктопах.

ога, как раком до китая

далеко не на всех матерях

Убрать, убрать к чертовой бабушке эту поддержку. Это бубунте дуалбутчики нужны, а дебиану - нет.

Тогда Дебиан попросту будет невозможно установить на новых матерях.

[utopia] А если взглянуть на это с другой стороны? Ладно, установят на все НОВЫЕ железки этот secureboot. Восьмёрочники и прочие виндовозы останутся с мелкософтом, линуксоиды\бсдшники останутся на старом железе в знак протеста. Что мы имеем? Профит! Разработчики допилят ПО до похудения так, что оно будет летать на старом железе без secureboot. Новое ПО будет писаться не «на вырост», а на реально работающее железо. [/utopia]

Такие прогнозы на практике никогда не сбываются.

А можно ещё мыслей вслух. А как же громаднейшее количество государственных структур переведеных на Linux (в Западной Европе и Латинской Америке если что...)?

это еще почему?

Если Секюребут будет не отключаемым, то как иначе?

У ms есть _требование_ делать его отключаемым, иначе наклейки на коробке с матерью не будет. Ты думаешь кто-то будет покупать мать на которой работает только винда и нет официальной сертификации под винду?

По OEM --- не будет.

Короче, тихое превращение кампутера в очередной быдлодевайс.

У ms есть _требование_ делать его отключаемым, иначе наклейки на коробке с матерью не будет. Ты думаешь кто-то будет покупать мать на которой работает только винда и нет официальной сертификации под винду?

Пруф?
Я заню другое требование: обязательное наличие самого Секюребут, причём на АРМ обязательно не отключаемое.

Пруф?

http://en.wikipedia.org/wiki/Windows_8#Secure_boot

обязательное наличие самого Секюребут, причём на АРМ обязательно не отключаемое.

Не на ARM, а на ARM-устройствах-поставляемых-с-windowsrt. Это огромная разница, так как windowsrt в розничной продаже не будет и ARM устройства есть и с другими ОСями в комплекте.

По Вашей ссылке так: МС требует чтобы производители предлагали возможность отключения опции Секюребут. Про сертификацию там ничего не сказано, но интуитивно связь прослеживается. Скорее всего Вы правы.

дофига хочет. секьюрбут же можно будет вырубить, а загрузчик также подменить. мне так видится будущее.

Не всë так просто. Во-первых, как сделать подобный загрузчик без исходных кодов? Во-вторых, кроме загрузчика на secure boot могут быть завязаны другие компоненты.

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

Вы бы хоть спецификацию почитали. Для серверов UEFI и SecureBoot опциональны.

Тогда Дебиан попросту будет невозможно установить на новых матерях.

Ещë один паникëр. На новых матерях никакого SecureBoot не будет, спецификация не требует этого для *компонентов* ПК. Это нужно только для OEM компьютеров и ноутов с предустановленной вендой.

В качестве пруфа рекомендую посмотреть на новые материнки от Asus, сертифицированные для Win8.

Если же используется более стойкая к взлому проверка, с использованием криптографических технологий, то почему её использовать не для проверки, включен ли SB, а непосредственно для проверки, входит ли с этим компьютером лицензия на венду? Ну как HASP.

Я так понимаю, что так и будет. Вроде SLIC в BIOS, только покруче. Основания для этого - они не будут отказываться от возможности установить Win8 на компьютеры, где не то, что SecureBoot-а нет, а где даже UEFI не пахнет.

Восьмёрочники и прочие виндовозы останутся с мелкософтом, линуксоиды\бсдшники останутся на старом железе в знак протеста.

То есть возникнет рынок железа, выпущенного до «нововведения». Нечто наподобие рынка винтажной акустики и антикварных предметов?

Это нужно только для OEM компьютеров и ноутов с предустановленной вендой.

Этого более чем достаточно для паники. Ноуты почти все идут с Ш1иьош$.

То есть возникнет рынок железа, выпущенного до «нововведения». Нечто наподобие рынка винтажной акустики и антикварных предметов?

Не исключено, это будет вполне логично...

Ну так сказали же уже, что производитель будет обязан предоставить возможность отключение. Теперь пугают только тем, что при дуалбуте придётся в настройки UEFI каждый раз лазить. Если это действительно так, то это не такая уж и серьёзная проблема, не стоит ради этого покупать ключи и создавать схемы по подписи всего линуксового софта. Причём федоровцы вроде говорили, что при такой схеме не получится использовать имеющиеся проприетарные драйверы для видеокарт. Ну оно нам нужно?

http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F5...

страница 121 пунеты 17 и 18

17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: «Custom» and «Standard». Custom Mode allows for more flexibility as specified in the following:

a. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

b. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.

c. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

18. 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. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.

кроме загрузчика на secure boot могут быть завязаны другие компоненты.

какие ещё компоненты, если название говорит само за себя. secure boot. после того как случился boot уже всё можно. или нет?

факт , что большинство серверов крутится на linux, значит для северного оборудования никакого EFI / SecureBoot не будет ?

_Пока_ не будет. А вот если Windows Server сильно потеснит линукс и *bsd, возможно, и там...

Ну, это я и имел в виду. На всех этих этапах проверяется только MS ключи. Наличие в материнке других ключей, даже общественных и скомпроментированных (ибо для свободных операционок должна быть открыта и закрытая часть), на работу винды никак не повлияют.

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

поступить как Fedora с использованием GRUB2

+Kay Sievers and +Harald Hoyer (оба работают в ред хат) just made their little no-nonsense EFI boot loader public. It's tiny (< 64K), can show a menu, discovers all kernel configurations automatically (no wacky autogeneration of boot loader scripts), and can chain-load another boot loader if necessary.

http://freedesktop.org/wiki/Software/gummiboot

То, что ты не станешь поддерживать бойкот, так как считаешь его бесполезным делом. А это на данный момент одно из обязательных действий.

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

Я не говорил, что не буду поддерживать бойкот.

Я не говорил, что это бесполезное дело.

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

Джампер на материнке - ещё удобнее! Я сразу выведу себе проводки наружу и прикручу к ним тумблер.

Щёлк! Есть секуребут. Щёлк! Нет секуребута! Шика-а-арно!

А вообще, конечно, секуребут не нужен.

Плохой способ. Плохой не по сути, а по реализации. Вот смотри: ты не купил «дурное» железо, я не купил, ещё человек 100 не купило. А остальные 10000 купили. Поскольку остальным пофиг, свобода/не свобода. Им лишь бы очередной MV запустить, да в Дьябло 3 поиграться. Поэтому мы с тобой и ещё 100 человек останутся в пролёте, тогда как остальной мир будет сидеть на новом железе.

Такие дела, увы.

В смысле? Вроде как эта хреновина должна отключаться в биосе, разве нет?

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

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

А кто подскажет? Как к UEFI относятся в лагере BSD? И что планируют предпринять?

Как всегда, жди через 10 лет.

А вот если Windows Server сильно потеснит линукс и *bsd, возможно, и там...

В альтернативной реальности разве что.

В дуалбуте теперь придется каждый раз перетыкать включение/выключение UEFI. Хорошо если это будет делаться через BIOS Setup.

Охлол! Во-первых, не UEFI будет включаться/выключаться, а SecureBoot. Во-вторых, UEFI - это замена BIOS, какой там может быть BIOS Setup? :))

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

какие ещё компоненты

Ну, например, ядро. Оно тоже участвует в процессе загрузки.

после того как случился boot уже всё можно. или нет?

Вообще, насколько я понимаю UEFI (firmware interface), ты можешь в любой момент запросить оттуда любые данные, включая ключи SecureBoot. Даже в процессе загрузки explorer.exe (или как там будет называться оболочка Metro UI?).