собираются встроить бутлоадер

Non-ARM там подразумевается под архитектурами IA32 и AMD64

там написано «не-arm».

Целиком предложение читай.

а ты включи голову, и посмотри, чем отличается отключение sb от отключения sb с переходом в setup mode

Конечно. Так ведь короче называть IA32 и AMD64. Потому, что венда сейчас есть только в версиях для трёх архитектур - IA32, AMD64 и ARM (IA64 уже успели убрать, да). И приведённые требования были написаны для текущих версий венды.

cvs-255> чем отличается отключение sb от отключения sb с переходом в setup mode

Очевидно, переходом к сервисным функциям для настройки SecureBoot. Но там прямым текстом сказано, что SecureBoot в Setup Mode отключается, когда все ключи удалены (оно и понятно - как проверять, что грузится?).

думом

это будет первый вменяемый компонент, встроенный в это безобразие

Но там прямым текстом сказано, что SecureBoot в Setup Mode отключается, когда все ключи удалены (оно и понятно - как проверять, что грузится?).

не придирайся к словам. имелось ввиду:

а во-вторых, не только отключение, а еще перевод в Setup Mode

Lincor> не придирайся к словам. имелось ввиду:

Интересно. То есть, ты начинаешь сам придираться к словам, а когда тебе формализованно выкладывают аргумент, идёшь на попятную? Двоемыслие - не иначе. А ведь там прямо сказано, что SecureBoot в этом случае отключается.

То есть, ты начинаешь сам придираться к словам

где?

Хватит рыться в кишках. Мысли глобальнее. Ответь мне таки:
Благодаря кому secure boot сейчас в каждой коробке?
Какая от него польза (с примерами из жизни)?

А ссылку можно? Хочу почитать в оригинале, а то, кажется, Леннарт опять изнасиловал ЛОРовцев...

Но это очень-очень качественный наброс :] Браво.

Ссылку уже давал, к сожелению только на немецком: http://www.golem.de/news/gummiboot-systemd-will-bootloader-integrieren-1502-1...

Благодаря кому secure boot сейчас в каждой коробке?

благодаря консорциуму UEFI.

Какая от него польза

надежная защита от части вредоносных программ.

(с примерами из жизни)

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

благодаря консорциуму UEFI.

а не сертификации определённой ОС?

спрашивай у производителей устройств.

ты за что кисо обидел? стыдись!

Думаю, это связано с внедрением EFISTUB. Ядро маскируется под PE-бинарник.

потому что это и есть исполняемый файл DOS/Windows aka Portable Executable.

надежная защита от части вредоносных программ.

это вопрос времени. Система UEFI/Secure Boot технически довольно сложная и в ней достаточно багов, что уже неоднократно доказывали.

Посмотрел, там хромобук и в качестве нагрузки coreboot

баги бывают в реализации, а не в стандарте. и багами реализации UEFI сторонним программам при наличии Secure Boot будет невозможно воспользоваться.

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

А сабж нужен, если будет опциональным, как SELinux. Неплохо было бы ещё запилить дистр GNU/Linux, который можно запихнуть в UEFI, а то они сплошь и рядом несвободные.

в стандарте тоже бывают баги, и время покажет что там есть. А баги в имплементации были и будут. При наличии secure boot дырами уже даже пользовались, прописывая себя в список разрешенных загрузчиков: http://securityaffairs.co/wordpress/25425/hacking/bypass-secure-boot-uefi.html.

Гондосапог? А что, хорошее название.

Тогда M$ конечно не причём.

в стандарте тоже бывают баги

нет. в стандартах - уязвимости.

Kallenberg also presented a new way to bypass Secure Boot efficient on OEMs not using the security mechanism SMI_LOCK in their UEFI implementations.

Ч.Т.Д. несоблюдение стандартов до добра не доводит.

ох лол. какое Microsoft дело до формата бинарников UEFI? никаких преимуществ из-за этого они не получают.

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

А что может означать то, что файл «vmlinuz-3.2.0-4-686-pae» в папке /boot/ определяет линух как «исполняемый файл DOS/Windows»?
Причём такое только недавно (года 2-а).

$ file /boot/vmlinuz-linux
/boot/vmlinuz-linux: Linux kernel x86 boot executable bzImage, version 3.18.2-2-ARCH (builduser@tobias) #1 SMP PREEMPT Fri Jan 9 07:37, RO-rootFS, swap_dev 0x3, Normal VGA

Раньше он был ELF, а сейчас MZh :)

Secure Boot - это хорошо, только каким боком тут Microsoft.

А какие альтернативы поддерживают полностью безопасную загрузку?

gummi - нем. резина/резинка

Надувная лодка, даже немецкого не нужно знать.

Я не понял, каким образом это EFI-приложение они собираются интегрировать в systemd. Получается, что им придется еще сделать свой systemd-initrd.

• systemd умеет запускаться как инит в initramfs (и всегда умел, а почему бы и нет?), но это здесь ни при чём
• прозреваю, что здесь были изнасилованы некоторые журналисты, встраивать там действительно нечего
• самое большое, что могли решить сделать (в репозитории ещё ничего нет) — это слить исходники и написать тулзу-конфигуратор

Сдаётся мне, что персональным компам скоро, такими темпами, придёт полный и неотключаемый secure boot'ец.

FAT12,16/VFAT,NTFS-3g,питер,девочки,nasm,TASM,loadlin,Debian,Gentoo,LiveCD

Ты погоди, ещё сам взвоешь, когда поцтерринг тебе ненужную мясорубку вкрутит в системГ.

Таких уже много. Мне нужны далеко не все фичи systemd. И ничего, не вою. А всё потому что их, сюрприз, можно не использовать...

Это означает, что ядро собрано со включенной опцией CONFIG_EFI_STUB. Что, в свою очередь, приводит к созданию файла ядра, способного грузиться без загрузчика напрямую из EFI (т. е. ядро «маскируется» под EFI-приложение). А формат EFI-приложений у нас базируется на PE (Portable Executable), который, в свою очередь, в целях обратной совместимости включает в себя MZ-заглушку.

По транзитивности получаем, что собранное таким образом ядро одновременно является корректным MZ-файлом. А файловые менеджеры трактуют это как «исполняемый файл DOS/Windows», хотя правильнее было бы «исполняемый файл DOS/Windows/EFI/и-ещё-хрен-знает-что-умеющее-читать-MZ-файлы».

Ну тогда понятно, а я то думал, что там от ядра линухи ничего не осталось... ;)