The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot

08.06.2022 10:57

В загрузчике GRUB2 устранено 7 уязвимостей, позволяющих обойти механизм UEFI Secure Boot и добиться запуска неверифицированного кода, например, осуществить внедрение вредоносного ПО, работающего на уровне загрузчика или ядра. Дополнительно отмечается одна уязвимость в прослойке shim, которая также позволяет обойти UEFI Secure Boot. Группа уязвимостей получила кодовое имя Boothole 3, по аналогии с аналогичными проблемами, ранее выявленными в загрузчике.

Для устранения проблем в GRUB2 и shim дистрибутивы смогут использовать механизм SBAT (UEFI Secure Boot Advanced Targeting), поддержка которого реализована для GRUB2, shim и fwupd. SBAT разработан совместно с Microsoft и подразумевает добавление в исполняемые файлы компонентов UEFI дополнительных метаданных, которые включают информацию о производителе, продукте, компоненте и версии. Указанные метаданные заверяются цифровой подписью и могут отдельно включаться в списки разрешённых или запрещённых компонентов для UEFI Secure Boot.

В большинстве Linux-дистрибутивов для верифицированной загрузки в режиме UEFI Secure Boot используется небольшая прослойка shim, заверенная цифровой подписью Microsoft. Данная прослойка верифицирует GRUB2 собственным сертификатом, что позволяет разработчикам дистрибутивов не заверять каждое обновление ядра и GRUB в Microsoft. Уязвимости в GRUB2 позволяют добиться выполнения своего кода на этапе после успешной верификации shim, но до загрузки операционной системы, вклинившись в цепочку доверия при активном режиме Secure Boot и получив полный контроль за дальнейшим процессом загрузки, в том числе для загрузки другой ОС, модификации компонентов операционной системы и обхода защиты Lockdown.

Для устранения проблем в загрузчике дистрибутивам придётся сформировать новые внутренние цифровые подписи и обновлять инсталляторы, загрузчики, пакеты с ядром, fwupd-прошивки и shim-прослойку. До внедрения SBAT, обновление списка отозванных сертификатов (dbx, UEFI Revocation List) было обязательным условием полного блокирования уязвимости, так как атакующий, независимо от используемой операционной системы, мог для компрометации UEFI Secure Boot использовать загрузочный носитель со старой уязвимой версией GRUB2, заверенной цифровой подписью.

Вместо отзыва подписи SBAT позволяет блокировать её использование для отдельных номеров версий компонентов без необходимости отзыва ключей для Secure Boot. Блокирование уязвимостей через SBAT не требует использования списка отозванных сертификатов UEFI (dbx), а производится на уровне замены внутреннего ключа для формирования подписей и обновления GRUB2, shim и других поставляемых дистрибутивами загрузочных артефактов. В настоящее время поддержка SBAT уже добавлена в большинство популярных дистрибутивов Linux.

Выявленные уязвимости:

  • CVE-2021-3696, CVE-2021-3695- переполнения буфера в куче при обработке специально оформленных PNG-изображений, которое теоретически можно использовать для организации выполнения кода атакующего и обхода UEFI Secure Boot. Отмечается, что проблема трудно эксплуатируема, так как для создания рабочего эксплоита требуется учёт большого числа факторов и наличия сведений о раскладке памяти.
  • CVE-2021-3697 - переполнение через нижнюю границу буфера (buffer underflow) в коде обработки JPEG-изображений. Эксплуатация проблемы требует получения сведений о раскладке памяти и находится примерно на том же уровне сложности, что и проблема с PNG (CVSS 7.5).
  • CVE-2022-28733 - целочисленное переполнение в функции grub_net_recv_ip4_packets(), позволяющее влиять на параметр rsm->total_len через отправку специально оформленного IP-пакета. Проблема отмечена как наиболее опасная из представленных уязвимостей (CVSS 8.1). При успешной эксплуатации уязвимость позволяет записать данные за границу буфера через выделение заведомо меньшего размера памяти.
  • CVE-2022-28734 - однобайтовое переполнение буфера при обработке разделённых HTTP-заголовков. Проблема может привести к повреждению метаданных GRUB2 (запись нулевого байта сразу за концом буфера) при разборе специально оформленных HTTP-запросов.
  • CVE-2022-28735 - проблема в верификаторе shim_lock, позволяющая загрузить файлы, не относящиеся к ядру. Уязвимость может быть использована для загрузки в режиме UEFI Secure Boot незаверенных цифровой подписью модулей ядра или непроверенного кода.
  • CVE-2022-28736 - обращение к уже освобождённой области памяти в функции grub_cmd_chainloader() через повторный запуск команды chainloader, используемой для загрузки операционных систем, не поддерживаемых в GRUB2. Эксплуатация может привести к выполнению кода атакующего, если злоумышленник сможет определить особенности распределения памяти в GRUB2
  • CVE-2022-28737 - переполнение буфера в прослойке shim, возникающее в функции handle_image() при загрузке и выполнении специально оформленных образов EFI.


  1. Главная ссылка к новости (https://lists.gnu.org/archive/...)
  2. OpenNews: Релиз загрузочного менеджера GNU GRUB 2.06
  3. OpenNews: Трудноустранимые уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot
  4. OpenNews: Дистрибутивы устранили проблемы с обновлением GRUB2
  5. OpenNews: В обновлении GRUB2 выявлена проблема, приводящая к невозможности загрузки
  6. OpenNews: Критическая уязвимость в загрузчике GRUB2, позволяющая обойти UEFI Secure Boot
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/57316-grub
Ключевые слова: grub, boot
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (196) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:01, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    Никогда такого не было и вот опять
     
     
  • 2.20, _hide_ (ok), 11:57, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Вообще не понятно, почему что-то вообще должно выполняться на уровне загрузчика?
    Как можно лечить проблему (загрузка вредоносного кода на уровне ядра системы) и создать новую проблему -- загрузка вредоносного кода на уровне загрузчика (и, кстати, UEFI, при определённых обстоятельствах)
    Кстати, никто не знает, почему запускаемый код называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает?
     
     
  • 3.26, Аноним (-), 12:05, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает?

    Цифровая бюрократия. Без бумажки, ой, цифровой подписи - ты букашка...

     
     
  • 4.30, Аноним (30), 12:20, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Скоро без оной и птицам нельзя за границу, и рыбам плыть запрещено.
     
  • 3.68, Аноним (68), 14:08, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Если вирус подписать, то проблема исчезает?

    Проблема пользователя - нет.
    А вот проблема microsoft("почему никто не использует наш механизм подписей всего?") - да.

     
  • 3.100, Аноним (100), 19:00, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +15 +/
    > Вообще не понятно, почему что-то вообще должно выполняться на уровне загрузчика?

    Это отличный вопрос к знатокам GRUB2. Примерно за тем же зачем ему поддержка PNG, BMP, TGA и прочего. GRUB2 по своим размерам тянет на небольшую ОС.

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

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

    Изначальная проблема, которую решает Secure Boot - это проблема специфических вирусов, которые портят загрузчик ОС. Их логика целиком построена на социальной инженерии, дескать, обманутый пользователь запустит код в привилегированном режиме и тем самым испортит себе загрузчик. Аналогично это усложняет написание руткитов, потому что теперь всем этим вирусам нужно обзавестись цифровой подписью и пройти через 7 кругов бюрократического ада, доказывая, что ты не верблюд. По итогам этих изменений в Windows стало очень трудно писать такие вирусы и народ переключился на шифровальщики, работающие целиком в пространстве пользователя, но это уже другая история.

    Под Linux таких вирусов нет, потому что там нет пользователя, который попадётся на такие уловки. Нету спроса - нету предложения. Когда ОС пользуется больше 1.3 миллиарда человек, то даже 5% умственно отсталых пользователей (а их больше), жамкающих разрешить себе всё - это, на минуточку, 65 миллионов! Теперь давайте представим себе ботнет таких размеров и поймём почему принимаются те или иные решения.

    Логика цифровых подписей начинается с UEFI Secure Boot (не грузить что попало, если пользователь явно не разрешил), продолжается ядром ОС, которое проверяет цифровые подписи всех своих модулей. Пользовательская подсистема проверяет сертификаты всех исполняемых файлов и жалуется на их отсутствие. Файрвол, который определяет зоны, откуда взялся файл и файловая система проставляет любому файлу блокирующие атрибуты, чтобы нельзя было автоматом после скачивания файла из интернета его запустить без дополнительных проверок (хэширование и сличение с базой известных вирусов, проверка цифровых подписей и прочее). Даже текстовые сценарии должны быть подписаны, а если они пытаются обращаться напрямую к объектам ядра и драйверов, то вне зависимости от наличия сертификатов, такая активность считается вредоносной.

    Это всё потому что пользователи по природе своей не очень разбираются в ИТ и не обязаны это делать, чтобы лайкать котиков в социальных сетях.

    Теперь давайте посмотрим что сделано в Linux. Есть костыль shim, чтобы не подписывать ни ядро, ни драйверы. Подсистема цифровых подписей в ядре, не та новая, которую дописывал MS, портируя свой WHQL, а оригинальная, полагается на хранилища сертификации на файловой в системе, что глупо. И вот если это всё включить,.. но оно выключено по-умолчанию. Про подпись кода и скриптов я вообще ничего не буду говорить, это слишком на стороне DE, а там все озабочены Wayland-танцами уже последние 8 лет. И всё это можно было бы довести до ума, учитывая, что в ядре-то всё есть... Дистрибутивы не пользуются, впрочем подобное много лет назад наблюдалось вокруг cgroups и систем мандатного контроля.

    Причем в каждом сообществе найдутся 10 баранов-меинтейнеров, которые дальше make; make install одного пакетика задачи не видели, которые сбегутся и начнут рассуждать, как же это всё никому не нужно. Если же хотя бы 5 из них начнут переписку до приёма прописанных таблеток, то окажется, что это мало того что не нужно, так еще и вредно, потому что злобный MS замышляет козни против Linux, вводя для СВОИХ пользователей PKI на уровне выполнения кода.

    Техническая сложность в Linux всего одна: монолитность. В Windows обновления драйверов и целой кучи подсистем идёт отдельно от основного ядра, потому что большая часть драйверов, строго говоря в юзерспейсе. У WinNT действительно маленький Ring 0. Динамическая же часть ядра живёт отдельно. Те драйверы, цифровые подписи и проверки выполняются совершенно другой подсистемой, никак не подпадающей под UEFI и вопросы безопасной ЗАГРУЗКИ. В Linux всё монолитно, поэтому каждое минорное обновление потенциально ненужного на конкретном устройстве модуля должно заменить цифровую подпись всея ядра. И вот чтобы было как в Windows они выделили маленький кусочек отдельно и вот он вам shim.

    Ну и вишенка на торте - это поддержка Userspace drivers в Linux: https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html
    Она есть, просто всё принято тащить в ядро сочиняя себе новые API и ломая старое API, которое там было. Ну и поверх нужно сделать 100500 версий одного и того же ядра на уровне дистрибутивов. Но ладно драйверы... вся сетевая подсистема должна обновляться с ядром, включая файрвол и графика.... И соответственно триггерить смену подписей. Жуткая помойка, которая накопилась из нерешенных проблем с размерами монолитной кодовой базы. Молодежь уже даже не понимает, что такие вещи как kmod и dkms это адские костыли, которые прикрывают архитектурные проблемы фиговым листочком.

    > Кстати, никто не знает, почему запускаемый код называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает?

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

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

    P.S. Я вообще не понимаю, почему в GRUB не впилят поддержку MP3, очень не хватает слушать музло во время просмотра любимой картинки во время ожидания загрузки пункта меню. Народу явно больше зайдёт чем нормальная поддержка верификации кода на уровне ОС.

     
     
  • 4.107, microsoft (?), 19:28, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > пользователь явно не разрешил

    Пользователя ни о чем не спрашивают. Его ставят перед фактом, и заставляют жрать че дали. А он и рад хрустеть да чавкать.

     
  • 4.116, Аноним (116), 21:14, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Благодарю, Аноним-100. Почитал лекцию с интересом. Скрывать не буду: что-то во мне дрогнуло.
     
  • 4.128, Аноним (128), 23:33, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что вместо того чтобы заниматься внедрением цифровой подписи кода в Linux истерически применялись попытки обойти это, теми же самыми костылями с shim, лишь бы не внедрять.

    Потому что в том виде как оно сделано в UEFI оно нах не нужно!!! Это не безопасность, а дерьмо какое-то, навязанное доверие Microsoft и еще кому-то. Вместо того, чтобы дать ПРОСТОЙ способ самостоятельно подписать свою систему СВОИМИ ключами. В принципе есть возможность удалить предустановленные ключи в UEFI и прописать свои, но во-первых, не на всех устройствах получится, во вторых, практическая реализация достаточно сложная, чтобы мало, кто стал связываться. Еще и с большим риском окирпичиться.

     
     
  • 5.130, Аноним (100), 01:03, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    PKI это вообще не безопасность, а инфраструктура открытого ключа Задача такой и... большой текст свёрнут, показать
     
     
  • 6.132, penetrator (?), 04:16, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем нам такая ущербная схема?
     
  • 6.140, n00by (ok), 09:45, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > И вопреки самым алармистским параноикам, MS не грохнул никому ничего.

    Не надо категоричных заявлений, они портят общую картину. Вот эта HIPS  http://www.online-solutions.ru/products/osss-security-suite.html находила много всего, включая руткит, который Микрософт пришлось ловить совместно с сэрами мэйорами. В том числе и несанкционированные обновления ОС, от которых ныне стонет пользователь, могла считать подозрительной активностью и блокировать.

     
  • 5.138, n00by (ok), 09:36, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Вместо того, чтобы дать ПРОСТОЙ способ самостоятельно подписать
    > свою систему СВОИМИ ключами.

    Прекратите орать. Почитайте умную книжку. Там пишут, как самостоятельно подписать.

     
     
  • 6.166, Аноним (-), 16:03, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Может там еще пишут как отключить бутгада и сделать СВОЙ root of trust а не майкрософто-интеловский? И даже прошивку ME подписать своим ключом дадут? Без всего этого секурити всей этой схемы около ноля.
     
     
  • 7.173, n00by (ok), 19:02, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это надо детскую сказку "Теремок" почитать. Что бы научиться не так заметно увеличивать запросы.
     
     
  • 8.184, Аноним (-), 23:32, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Система которая служит своему владельцу и делает что обещано а не кучу других не... текст свёрнут, показать
     
     
  • 9.196, n00by (ok), 09:02, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Мой комментарий оставлен по поводу совсем другого желания Подписать ядро можно ... текст свёрнут, показать
     
  • 4.129, tty0 (?), 00:02, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Т.е, чтобы решить проблему имбицилов и им сочувствующим, я должен подписывать все модели ядра после сборки? Сторонними средствами и чужими ключами?
    Бред сумашедшего.
    UEFI - решение чрезвычайно узкоспециализированное и нужно только ИНДИВИДУАЛЬНЫМ пользователям Windows с ROOT правами.
    Для всего остальных - это какое-то извращение.
     
     
  • 5.131, Аноним (100), 01:46, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Или купить оборудование, которое позволяет грузить свои ключи в прошивку Или на... большой текст свёрнут, показать
     
     
  • 6.134, Аноним (134), 07:30, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А чё там у вендоров с "договороспособностью"? Чё они столько лет "ветошью прикидывались", а, в итоге, свалили проблему с себя на других?
     
  • 6.141, _hide_ (ok), 10:00, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Аналог пользователя root в Windows - это Local System

    Т.е. пользователь с правами администратора может поднять права до Local System и изменить код в загрузчике. А зачем столько слов? Чтобы запутать?

     
     
  • 7.151, Аноним (100), 12:35, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что там всё на самом деле запутано Для начала вам нужно быть понять, что... большой текст свёрнут, показать
     
     
  • 8.155, n00by (ok), 14:26, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Начали во здравие, а завернули невесть куда advapi32 dll - это не ядро Это час... большой текст свёрнут, показать
     
     
  • 9.171, Аноним (100), 17:41, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А Win32 это часть подсистемы чего Гриба Яблока Табуретки В Windows ядро не м... большой текст свёрнут, показать
     
     
  • 10.175, n00by (ok), 19:41, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я даже и не знаю, что тут можно сказать Раньше это был такой термин от произ... большой текст свёрнут, показать
     
  • 4.136, bergentroll (ok), 08:41, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Всё вы классно написали. Непонятно только, что хорошего за «доверием» ходить на поклон к «батюшке»-Майкрософту™.
     
     
  • 5.146, Аноним (-), 10:53, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > за «доверием» ходить на поклон к «батюшке»

    Так это основной принцип бюрократии, про который он не написал.

    Чтобы цепочка доверия хоть что-то гарантировала нужно найти "доверенные" концы: начиная от "доверенного" железа, на котором проверяется доверие, до заранее записанных "доверенных" сертификатов.
    Это достигается тупым вендорлок'ом: железо и софт только от "доверенного" поставщика (например, продукция от apple и прочих андроид-телефонов [хотя андроид - это тоже франкештейн с гуглом]).
    В случае с uefi secure boot такой вендорлок не пропустили. Получился франкенштейн, когда поставщик железа прописывает чужие корневые сертификаты. В итоге никто ни за что не отвечает, потому что не может.

     
  • 4.139, Аноним (-), 09:43, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Secure Boot
    > Ну и последнее, PKI - это не безопасность, а номенклатурные отношения доверия.

    Как обычно, подмена понятий.

     
  • 4.143, Аноним (-), 10:16, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Под Linux таких вирусов нет, потому что там нет пользователя

    Андроид - это linux?

     
     
  • 5.167, Аноним (-), 16:05, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дерьмовенький и специфичный, да. А что, под него именно вирусы бывают? Не путать с троянами и иной малварью, вирус должен самораспостряняться, на андроиде с этим неудобно.
     
     
  • 6.169, Аноним (-), 16:20, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, под него именно вирусы бывают?

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

    Мой вопрос был: есть пользователи linux (android - linux?), и как следствие, есть ли "такие вирусы" для linux?

    > вирус должен самораспостряняться

    (Само)распространение кастомных прошивок со взломанными загрузчиками - это вирус?

     
     
  • 7.185, Аноним (-), 23:44, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > (Само)распространение кастомных прошивок со взломанными загрузчиками - это вирус?

    Наверное сойдет за вирус. А оно такое вообще бывает? Там так то довольно много вещей которые могут пойти не так и это сложно сделать незаметно и без действий юзера. Это кто-то вообще делал? Или это чисто теоретически? Если вдруг это у кого получится, положите на гитхабчик, посмотреть на то как оно вообще работает избегая многих веселых факапов системного уровня :)

     
  • 4.163, Аноним (-), 15:34, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > GRUB2 по своим размерам тянет на небольшую ОС.

    UEFI тоже тянет на это. И?

     
     
  • 5.170, Аноним (-), 16:29, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это отличный вопрос к знатокам GRUB2. Примерно за тем же зачем ему поддержка PNG, BMP, TGA и прочего. GRUB2 по своим размерам тянет на небольшую ОС.
    > UEFI тоже тянет на это. И?

    В uefi-прошивке есть "поддержка PNG, BMP, TGA и прочего"?

     
     
  • 6.186, Аноним (-), 23:48, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > В uefi-прошивке есть "поддержка PNG, BMP, TGA и прочего"?

    Зависит от UEFI прошивки. В некоторые даже флешер встроен, не то что PNG. Более того - как GRUB может догружать модули (вон то оформлено модулями) так и EFI может догружать внешние программы. Хуже, оно может runtime-сервисы и дрова железа подпихивать свои. Оставаясь частично in charge даже после того как ядро запустилось. GRUB в этом плане не такой зловредный сам по себе. В режиме эмуляции EFI он даже умеет runtime services по минимуму вывешивать, но то ж опенсорсный код и мало, а не 16-метровый блобина фирмвари мамки где черти что и с боку бантик, но вы можете расколупать эту блоботу и посмотреть что оно там умеет...

     
     
  • 7.197, Аноним (-), 09:52, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, вот, я же говорил во всем опенсорсный grub виноват, а не любимые оффтопщикам доверенные блобы, подписанные доверенными сертификатами, выданные доверенными компаниями.
     
  • 4.182, Аноним (182), 20:44, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Посоветуй систему изоляции для приложений пользовательского пространства для linux?
     
  • 3.125, AlexN (??), 22:32, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И вообще! Это не уязвимость - это фича. Secure Boot - происки мелкософта.
     
  • 2.24, alex (??), 12:02, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не помню новости про уязвимости, к которой не было бы такого комментария. Где ваша креативность, баянисты?
     
     
  • 3.62, Аноним (62), 13:46, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Никогда такого комментария не было, и вот опять!
     
     
  • 4.117, Аноним (116), 21:15, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Никогда такого комментария не было, и вот опять!
     
  • 3.200, Аноним (182), 13:27, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Однажды я написал креативный комментарий, и вот что произошло... большой текст свёрнут, показать
     
  • 2.25, Аноним (25), 12:03, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +12 +/
    > Никогда такого не было и вот опять

    Хз что там не было никогда с GRUB, но возможность обойти Secure Boot, это не баг, это фича.

    Я надеюсь что в аду есть приготовили отдельный котёл для тех, кто эту ерунду с Secure Boot затеял.

     
     
  • 3.89, YetAnotherOnanym (ok), 17:35, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Рядом с котлом для разрабов одного не в меру развесисто-фичастого загрузчика. Нефиг в загрузчик пихать обработку png или jpeg, или разбор заголовков http.
     
  • 3.90, Ooiiii (?), 17:38, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >в аду есть приготовили
     

     ....большая нить свёрнута, показать (44)

  • 1.2, Аноним (2), 11:04, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +37 +/
    ШОК! Имея физический доступ к компьютеру, можно запустить в нем все, что угодно. Уязвимость получила кодовое имя Boothole 3. Для устранения уязвимости принимайте перед сном одну столовую ложку обычного советского... Читать далее >>
     
     
  • 2.3, Жироватт (ok), 11:12, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Найдены фото секретных исходников UEFI! Там видно самого... Читать далее>>
     
     
  • 3.8, Аноним (8), 11:23, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы пропатчить KDE2 под FrreBSD, достаточно каждый втирать... Читать далее>>
     
     
  • 4.11, Аноним (11), 11:36, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Вы не поверите, но все кто использовал Linux умерли... Читать далее>>
     
  • 4.12, InuYasha (??), 11:37, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ползователи в ШОКЕ! Если два раза нажать кнопку "питание" можно удвоить... Смотреть далее >>
     
     
  • 5.119, Аноним (116), 21:20, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ШОК!!! Электрический ток обладает... Читать далее >>
     
     
  • 6.122, Аноним (-), 21:30, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На соревнованиях по плаванию электрик Сидоров замкнул тройку лидеров
    << Вернуться
     
  • 4.22, Аноним (22), 12:00, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Виндовс пользователей разделят на органы ...
    Читать далее>>
     
     
  • 5.91, Ooiiii (?), 17:42, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А вы знали стало с теми кто перешёл обратно на уиндоуз...
    Читать далее>>
     
  • 5.178, Аноним (182), 20:15, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Девушка узнала, что её парень пользуется линуксом и решила... большой текст свёрнут, показать
     
  • 4.112, Дмитрий (??), 20:15, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А ведь наши дедушки и бабушки для этого использовали надёжный советский... Читать далее>>
     
  • 2.10, Аноним (10), 11:33, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > Имея физический доступ ..., можно ... все, что угодно.

    В цивилизованных странах за это посадить (на счетчик) могут.

     
     
  • 3.76, наме (?), 15:21, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В нецивилизованных просто пристреливают.
     
     
  • 4.94, Neon (??), 18:16, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Причем неизвестно что гуманнее.
     
  • 2.15, Бывалый смузихлёб (?), 11:45, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Почему Читать далее не нажимаеццо !??
     
     
  • 3.27, Аноним (-), 12:14, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Потому что нужен платный аккаунт.

    Платный аккаунт увеличивает... Читать далее>>

     
     
  • 4.29, Аноним (30), 12:17, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Erlarge your penis!
     
     
  • 5.66, AleksK (ok), 14:00, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Erlang your penis.
     
     
  • 6.71, Аноним (11), 14:18, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Главное чтобы не eating
     
  • 2.67, АнонимкаРастуимка (?), 14:07, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Почему я жму на "читать далее" и ничего не происходит?! Читать далее >>
     
     
  • 3.85, Читать далее (?), 16:58, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Жмите!
     
  • 3.88, Аноним (88), 17:24, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Как правильно нажимать... ? Читать далее >>
     
     
  • 4.101, Аноним (101), 19:08, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да хватит уже... Читать далее >>
     
     
  • 5.120, Аноним (116), 21:22, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не хватит... Читать далее >>>
     
     
  • 6.181, Аноним (182), 20:25, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Учёные выяснили, чего не хватает людям для комфортного общения... большой текст свёрнут, показать
     
  • 2.145, Аноним (145), 10:40, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > ШОК! Имея физический доступ к компьютеру, можно запустить в нем все, что угодно.

    Разное образование сказывается.

    Их учат, что минимальный уровень безопасности ОС - C1, должен гарантировать неизменность всего исполняемого и невозможность запуска всего стороннего!

    ЗЫ: по теме половины уязвимостей там нет:

    png и прочие входящие данные проходят верификацию по цифровой подписи. Их не подменить.

    Shim - самим своим существованием противоречит фундаментальным принципам Integrity. Сторонние ключи не допускаются.

    Уязвимости по сети надо смотреть.

     
     
  • 3.150, Аноним (10), 12:15, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > должен гарантировать неизменность всего исполняемого и невозможность запуска всего стороннего!

    А что, "безопасники" уже решили "проблему останова"?

     
     
  • 4.156, n00by (ok), 14:36, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Решили, но не для общего случая: BLM заявляют ныне, что "белый список" ущемляет их права.
     
     
  • 5.158, Аноним (-), 14:54, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если "белый список" полный по Тьюрингу?
     
     
  • 6.176, n00by (ok), 19:53, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не полный, а бодипозитивный.
     
     
  • 7.198, Аноним (-), 10:01, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    бодипозитивный - это толстый
    полный - это укомплектованный на 100%
     
     
  • 8.202, n00by (ok), 13:52, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Укомплектованный на все 100 по Тьюрингу инклюзивный чёрно-белый список ... текст свёрнут, показать
     
  • 4.159, Аноним (159), 14:55, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > уже решили "проблему останова"?

    Это что? Выключение компа? Гибернации?

     

     ....большая нить свёрнута, показать (32)

  • 1.4, Аноним (4), 11:16, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Уязвимости в GRUB2, позволяющих обойти ненужно
     
  • 1.5, Аноним (5), 11:17, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Кто-нибудь, пожалуйста, научите уже системных программистов тестировать код:(
     
     
  • 2.31, Rev (?), 12:21, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это невозможно. Для решения систематических ошибок программистов и был разработан новый язык программирования. О нём тут все знают.
     
     
  • 3.39, Аноним (5), 12:45, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    даже там Тестирование, никто не отменяет!
     
     
  • 4.48, Аноним (48), 13:15, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но никто и не выполняет...
     
     
  • 5.53, Аноним (5), 13:24, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если это действительно так, то это весьма печально:(
     
  • 2.77, warlock (??), 15:39, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Пользователи протестируют.
     
     
  • 3.82, Аноним (5), 15:54, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Увы, к сожалению да, - это стратегия большинства, ака тяп-ляп и в продакшн:(
    Про корпарасов я вообще молчу! Например, мелкомягкие, так вообще решили что им не нужны профессиональные тестировщики, и по сути переложили всю работу на так называемых инсайдеров, - и получили соответствующий результат!
     

  • 1.6, beduin747 (ok), 11:18, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Это был не баг! Это была фича!
     
     
  • 2.193, анон_тот самый (?), 00:41, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    я вот тоже такого мнения. было бы круто еслиб груб мог сам заменить уефай и вернуть старый добры биос. а то с этим поделием чую куда то не туда свернули.
     

  • 1.7, Аноним (7), 11:20, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Пора уже закопать этого перегруженного уродца
     
     
  • 2.41, Аноним (41), 12:47, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А на что заменить?
     
     
  • 3.49, НяшМяш (ok), 13:15, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    systemd-boot /s
     
     
  • 4.93, qetuo (?), 18:06, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Зря. Отличный легковесный boot manager.
     
  • 3.78, warlock (??), 15:41, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть ELILO.
     
  • 3.86, Аноним (86), 16:59, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    das u-boot.
     
     
  • 4.108, Аноним (108), 19:39, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Das ist Fantastisch!
     
  • 3.104, Аноним (104), 19:15, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >А на что заменить?

    1. компилируешь ядро как efi-приложение
    2. загружаешь из UEFI efi-приложение (efibootmgr в помощь)
    profit!

    И никакой systemг-bootd не нужен.

     
  • 3.135, Аноним (134), 08:02, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Давно заменил на Арче mkinitcpio на dracut, а GRUB2 на systemd-boot. Хуком для pacman собираю initrd как UEFI-приложение. Брат жив.
     
  • 3.162, Аноним (159), 15:32, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    GNU/GRUB - отличный загрузчик! По его возможностям просто нет альтернатив.

    Возьмем, например, только две с его фич:

    1. Загрузка с шифрованого раздела

    2. Верификация всех подгружаемых модулей, настроек, ядер OS и initrd с помощью публичного ключа.

    Альтернативы какие?

     
  • 2.92, Ooiiii (?), 17:48, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но не обязательно же использовать все лишние компоненты. Можно самому написать grub.cfg из 5 строк, и больше не запускать update-grub.
     
     
  • 3.109, Аноним (108), 19:43, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тем более, что этот update-grub в каких-то случаях не находит образ inird, не вписывает его в grub.cfg. В результате этот пункт меню оказывается неспособным загрузиться.
     
  • 3.187, Аноним (-), 23:52, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Но не обязательно же использовать все лишние компоненты. Можно самому написать grub.cfg
    > из 5 строк, и больше не запускать update-grub.

    Как бы update grub нужен в основном чтобы при установке например нового ядра пакетный менеджер сразу бы дернул хук который пропишет это ядро в меню загрузки.

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

     

  • 1.9, mos87 (ok), 11:26, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >В загрузчике GRUB2 устранено

    UEFI SecureBoot

     
  • 1.13, InuYasha (??), 11:39, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А можно просто загрузить свой ключ и сертификат в UEFI и жить в безSHIMном мире?
     
     
  • 2.16, Аноним (16), 11:49, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Людишки не могут EFISTUB осилить и грузятся через промежуточный загрузчик, ну о чём ты говоришь...
     
     
  • 3.35, n00by (ok), 12:40, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А при чём здесь пользователи? Баш-программисты POCA LINUX XPOM не умеют добавить 10 банальных строк в инсталлятор, а тут ещё и немножко подумать требуется.
     
  • 3.46, Аноним (46), 13:12, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потому что промежуточный загрузчик удобнее EFISTUB и позволяет настраивать загрузку без запуска ОС.

    Когда сделаете в EFISTUB такую же удобную консоль как в grub, тогда и будете рассказывать про людишек.

     
     
  • 4.64, Аноним (16), 13:49, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > позволяет настраивать загрузку без запуска ОС.

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

     
     
  • 5.188, Аноним (-), 23:56, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А сам GRUB ты поставишь не из ОС?

    1) Прописать в boot image оси заранее. Это конечно тоже из ОС будет, но из совсем другой.
    2) Live CD/USB - это конечно тоже из ОС, но - опять же другой.

    > Или тебе нужна именно возможно что либо поправить, когда ты по дури снесёшь себе систему?

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

    > И главный вопрос - ты хоть раз этой консолью воспользовался?

    Я пользовался. Иногда полезно, например для кастомного командлайна ядру.

     
  • 3.95, Аноним (95), 18:25, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Людишки не могут EFISTUB осилить

    А вот может ли этот ваш EFISTUB грузить 64-х битное ядро linux из uefi32? А вот grub может!

    Я как личный владелец планшета на bay trail говорю

     
     
  • 4.115, Попандопала (?), 21:03, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Включите в ядре EFI mixed mode support  и 64 битное ядро  будет робит с 32 битной UEFI.
     
     
  • 5.133, Аноним (133), 07:08, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только этому вашему "EFI mixed mode support" нужен промежуточный загрузчик, типа grub
     
     
  • 6.153, Аноним (153), 13:11, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Минусаторы вот вам пруфы - https://cateee.net/lkddb/web-lkddb/EFI_MIXED.html https://lwn.net/Articles/589193/

    >Note that it is not possible to boot a mixed-mode enabled kernel via the EFI boot stub - a bootloader that supports the EFI handover protocol must be used.

     
     
  • 7.157, n00by (ok), 14:42, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это всё недостаточно авторитетный пруф. Сам директор POCA LINUX заявил, что "нами даже решён вопрос ..., когда 64-разрядный дистрибутив устанавливается на компьютер с 32-разрядным UEFI" и фанаты уверовали, тогда как науке подтверждения не известны.
     
  • 4.168, Аноним (-), 16:09, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В нем еще и эмуляция EFI кажись есть для BIOS систем. И выбирая между EFI от wintel и прочих AWARD_SW - ну вы поняли.
     
  • 3.142, Аноним (134), 10:00, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Шо на необразованных людишек пенять, если преуспевающие мамкины хозяйчики никак не могут нормальный UEFI-загрузчик для своих матюршинных плат напейсать, чтобы просто работало и не окирпичивалось при малейшем дуновении ветра.
     
  • 2.164, Аноним (159), 15:42, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А можно просто загрузить свой ключ и сертификат в UEFI и жить в безSHIMном мире?

    Именно это необходимо делать:

    1. Установить свой ключ Intel boot guard

    2. Удалить все чужие ключи с UEFI Secure Boot. Установить свои ключи UEFI secure boot. Подписать UEFI с своими ключами ключом Intel boot guard.

    3. Установить загрузчик GNU/GRUB с своим ключом и подписать его ключом с UEFI Secure Boot.

    4. Собрать ядро Linux с своими ключами IMA/EVM

    5. Подписать ключом GRUB все его модули, ядра с своими ключами и инитрд

    6. Подписать все исполняемые файлы, начиная с init, библиотеки, настройки и не изменяемые данные ключами IMA/EVM

    Так выглядит полная верифицированная цепочка загрузки в Integrity.

     

  • 1.14, Diozan (ok), 11:41, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Зря пофиксили полезную фичу. Secury Boot не нужен...
     
     
  • 2.70, Аноним (68), 14:11, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Secury Boot очень нужен микрософту
     
  • 2.79, Аноним (-), 15:41, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Твои мусорные коменты не нужны
     
  • 2.165, Аноним (159), 15:43, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А мне нужен!

    Вы его просто не умеете готовить;)

    Пойдите курсы поваров..

     
     
  • 3.201, Michael Shigorin (ok), 13:51, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO достаточно будет?

    Мне вот хватило с запасом.  Очень рад, что занялся наконец вместо этого непотребства эльбрусами.

     

  • 1.17, Rodegast (ok), 11:50, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это не баг,а фича!
     
  • 1.18, Гыгыгы (?), 11:51, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Почему фанаты любят уточнять что любой Linux, это GNU/Linux, а когда сообщение о уязвимости, то я не вижу ни одного уточнения что это GNU GRUB 2?
     
     
  • 2.19, Аноним (11), 11:55, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А бывает non-GNU GRNUB?
     
     
  • 3.32, Аноним (32), 12:32, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А non-GNU Linux?
     
     
  • 4.34, Аноним (34), 12:36, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Linux + BusyBox
     
  • 4.43, Аноним (11), 12:56, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Android - GNU не содержащий Linux.
     
     
  • 5.47, Аноним (46), 13:14, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наоборот, в android linux ядро без gnu окружения.
     
     
  • 6.54, Аноним (11), 13:27, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ошибаешься в Android есть Linux но нет GNU.
     
  • 6.57, Аноним (11), 13:33, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Надо быть тупеньким, чтобы подумать что я написал что андрюша это гну без линукса.
     
     
  • 7.72, anonfhjvxd (?), 14:19, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но ты ровно это и написал. Тут даже и думать не надо. Достаточно уметь читать.
     
     
  • 8.75, Аноним (11), 14:52, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Спред - сливочного масла, не содержащий продукт тоже сомнения вызывает у тебя ... текст свёрнут, показать
     
     
  • 9.87, Аноним (87), 17:14, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да В твоей грамотности ... текст свёрнут, показать
     
     
  • 10.189, Аноним (-), 23:59, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Йода мастер учитель его был ... текст свёрнут, показать
     
  • 9.96, анонимус (??), 18:25, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Какое масло, друг Ты что-то вообще не в ту степь пошел ... текст свёрнут, показать
     
     
  • 10.110, Аноним (108), 19:46, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Как какое Пальмовое ... текст свёрнут, показать
     
  • 9.124, Аноним (124), 22:27, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Макбет недавно прочёл ... текст свёрнут, показать
     
  • 8.123, Аноним (124), 22:21, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет не достаточно Нужно знать грамматику Сравни Android - GNU не содержащий L... текст свёрнут, показать
     
  • 3.33, n00by (ok), 12:36, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Бывает systemd-boot... А-А-А-А куда вы меня тащи
     
     
  • 4.174, Аноним (182), 19:40, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ШОК! Можно загрузить systemd прямо из UEFI firmware в обход... большой текст свёрнут, показать
     
  • 2.21, Аноним (5), 11:59, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Почему фанаты <<<

    Это уже не фанаты, а сектанты:), - просто не обращайте внимания!

     
  • 2.23, тоже Аноним (ok), 12:01, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > любой Linux, это GNU/Linux

    Незачет и по матчасти, и по пунктуации.

     
  • 2.28, Аноним (30), 12:14, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Потому, что Linux это только ядро.
     
     
  • 3.37, Аноним (-), 12:44, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А документация, инструментарий сборки, включая gnu bash-скрипты с gnu makefile'ами, утилиты пространства пользователя?
     
     
  • 4.40, Аноним (40), 12:47, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чувак, если ChromeOS собирается на Gentoo оно становится ChromeOS/Gnu? Пара утилит ничего не меняет. Скрипты можно и на Fish запускать и на ZSH (внезапно), да хоть на KSH. Плевать абсолютно на чем запускать. Разфаначивайся уже.
     
     
  • 5.45, Аноним (-), 13:04, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Чувак, если ChromeOS собирается на Gentoo оно становится ChromeOS/Gnu?

    Неправильный вопрос. Linux собираетcя и работает в GNU-окружении.

    > Скрипты можно и на Fish запускать и на ZSH (внезапно), да хоть на KSH.

    Это в последнее время начали портировать скрипты на posix shell (к слову, fish не posix-shell), но все равно для _штатной_ сборки нужен именно gnu bash. Точно также нужен gcc. И gnu make. И gnu coreutils.

     
  • 5.51, Аноним (46), 13:22, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    GNU это операционная система, если ваша ОС называется ChromeOS то это не GNU очевидно.
     
     
  • 6.73, Аноним (11), 14:46, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Chrome OS это GNU/ содержащий продукт, в отличие от Android который GNU/ не содержащий продукт.
     
  • 3.38, Аноним (40), 12:44, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для фанатиков нет musl версии Linux без GNUтых утилит поттому что они ими не пользуются. Вон даже ядро можно с Clang собирать, но они будут упорно втирать всем про GNU.
     
     
  • 4.42, Аноним (5), 12:49, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Вот же время летит!
    А ведь когда-то про линукс ходил бородатый анектот: linux написан не на C, а на gcc:)
     
     
  • 5.81, warlock (??), 15:47, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тут больше заслуга clang, который поддерживает чуть ли не все расширения GCC, чем кода ядра.
     
     
  • 6.83, Аноним (-), 15:58, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ПроGNUлись?
     
     
  • 7.84, warlock (??), 16:21, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Расширения GNU не просто так появились. Решаемые ими проблемы нужно решать любому промышленному компилятору. А выдумывать для их этого новый несовместимый синтаксис, когда уже есть синтаксис gcc, нет никакого смысла.
     
     
  • 8.149, Аноним (10), 12:08, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Clang не нужен ... текст свёрнут, показать
     
     
  • 9.152, warlock (??), 13:01, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Очень нужен во-первых, другая архитектура, во-вторых лицензия Конкуренция опят... текст свёрнут, показать
     
     
  • 10.190, Аноним (-), 00:00, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да уж Где еще увидишь so весом 65 мегабайтов Архитектура монументальна ... текст свёрнут, показать
     
  • 4.111, Аноним (108), 19:53, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А что, не может быть дистра Linux одновременно с Musl и GNU Coreutils + Bash?
     
  • 2.44, Аноним (11), 12:59, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    К тому же Гига-Ричард Столлман обижается когда забывают добавлять GNU к Linux, GNU к Grub2. А мне не жалко.
     
     
  • 3.52, Аноним (46), 13:23, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты всё перепутал, GNU/Linux это операционная система, а к Linux дописывать GNU не нужно, это не проект GNU, а отдельное ядро.
     
     
  • 4.55, Аноним (11), 13:31, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Linux-ом называть можно и GNU/Linux и GNU-free/Linux дистрибутивы. Но если мы говорит конкретно про GNU-содержащий продукт, то почему не акцентировать на этом?  На том что Grub2 это GNU содержащий продукт не делают акцент потому что это подразумевается по умолчанию, потому что не существует GNU не содержащего Grub2.  
     

     ....большая нить свёрнута, показать (37)

  • 1.36, Аноним (40), 12:42, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наконец-то на анально огороженных устройствах можно запускать Gentoo без заморочек с подписью ядра и т.п.! Долой шиндошс рабство!
     
     
  • 2.50, Попандопала (?), 13:16, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Видел устройство где послетали серийники и там в UEFI было написано S N N/A из-за корявой прошивки ХЗ знает чем и не надо нчего было там подписывать. Винду только не активировать нормально,а так гуд.D
     
  • 2.113, nebularia (ok), 20:19, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И так можно было, либо отключив валидацию, либо запустив после shim обычный GRUB без цифровой подписи. Оба способа требуют маленько действий руками (что логично, т.к. не позволяет незаметно обойти Secure Boot), но потом мешаться не будет
     
     
  • 3.118, Попандопала (?), 21:20, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    ХЗ. я на Ютупе видел это. За что купил,за то и продаю.D
     

  • 1.56, Аноним (56), 13:33, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    не уязвимости а возможности!
     
  • 1.58, ИмяХ (?), 13:36, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >>дистрибутивам придётся сформировать

    А пока они не сформируют, тысячи и тысячи вирусов будут сидеть в прошивках линyкcoидовских компьютеров.

     
     
  • 2.61, microsoft (?), 13:41, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Поздравляю, у тебя cpu и мост с бэкдорами и вирусами. Твой ring -2, -1. Наслаждайся.
     
     
  • 3.74, Аноним (-), 14:50, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дядя Микрософт, а Вы только всякие дырявые shim'ы подписываете своими подписями?
     
     
  • 4.106, microsoft (?), 19:18, 08/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не только. А так же тем, кто как надо нагнулся, и ручку нам пожал.
     

  • 1.59, Аноним (32), 13:39, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Дырявый Secure Boot, но уязвимость в GRUB. Нормально.
     
  • 1.60, microsoft (?), 13:39, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ага... это усе у ваш проклятый грубе виноват.. что наш uefi secure не такой секюр как надо!
     
  • 1.63, Аноним (95), 13:48, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >позволяющие обойти UEFI Secure Boot

    Казалось бы, отличная новость!

     
  • 1.65, Аноним (-), 13:57, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Butthole2. М-да уж.
     
  • 1.69, Аноним (69), 14:09, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > UEFI

    Не было у бабы хлопот, купила баба порося.

     
  • 1.97, Аноним (97), 18:44, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    so physical access is required lol.
    am i the only one who sleeps by his computer and thus isn't worried about such minutia issues?
     
     
  • 2.172, Аноним (62), 18:16, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    yankee go home
     

  • 1.102, saahriktu (ok), 19:11, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Secure Boot ненужен.

    Я в своё время подписывал петицию от проекта GNU, где подписавшиеся обещали никогда не юзать железо с неотключаемым Secure Boot'ом.

    Были опасения, что таким образом Microsoft пытается ограничить загрузку других ОС. Но потом Microsoft всё-таки стал делиться ключами для подписывания ядер Linux'а. Хотя сам момент, что без ключей от Microsoft'а конструкция не работает, - это ещё тот троянский конь.

     
     
  • 2.161, Аноним (159), 15:26, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Intel Boot Guard и UEFI Secure Boot очень хорошие и нужные технологии.

    НО!

    Вы должны покупать только "девственное" железо которое разрешает пользователь устанавливать свои ключи для Inrel boot guard и UEFI Secure Boot.

    Да, если производитель установил ключ Intel boot guard и свои ключи UEFI Secure Boot то пользователь не владелец компа, а цифровой раб. Будет запускать ОС только с разрешения хозяина.

    Не покупайте железо с установленными ключами Intel Boot Guard и без штатной возможности смены всех ключей UEFI Secure Boot.

     
     
  • 3.204, Michael Shigorin (ok), 14:09, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Не покупайте железо с установленными ключами Intel Boot Guard

    http://imaxai.ru :)

     
  • 2.203, Michael Shigorin (ok), 14:07, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Были опасения, что таким образом Microsoft пытается ограничить загрузку других ОС.

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

    > Хотя сам момент, что без ключей от Microsoft'а конструкция не работает,
    > - это ещё тот троянский конь.

    Теоретически работает (если соответствующие пути исполнения кода для конкретной прошивки вообще хоть кем-то тестировались), практически же скорее не применяется -- never underestimate the power of the default, как значилось у одного старого знакомого в ~/.signature

     

  • 1.114, yet another anonymous (?), 20:23, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Одновременное использование UEFI Secure Boot и grub выглядит странно, избыточно и проблемно.

    У UEFI Secure Boot процедура ещё и стрёмная, плохо документированная и имеет вариации в разных реализациях, т.е. можно и окирпичить устройство.

     
     
  • 2.160, Аноним (159), 15:18, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Одновременное использование UEFI Secure Boot и grub выглядит странно, избыточно и проблемно.

    Странно выглядишь здесь ты.

    Для сертифицированной загрузки OS необходима следующая цепочька:

    1. Intel Boot Guard

    2. UEFI Secure Boot

    3. GRUB с check_signatures=enforce

    4. Linux с IMA/EVM

    В старых системах вместо первых 3 пунктов использовался TPM.

     
     
  • 3.191, Аноним (-), 00:05, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 1. Intel Boot Guard

    И мы поверим Intel и OEM что они белые и пушистые. Потому что свои ключи и код вписать ТУДА "почему-то" не дадут. Добрый белый человек как обычно подогнал тифозное одеяло.

    > 2. UEFI Secure Boot

    Только если оттуда можно вытряхнуть ВСЕ ключи интелов/майкрософтов и прочих никак не связанных с пользователей самоназначенных ауторити метящих в жандармы планеты. Что не факт.

    > 4. Linux с IMA/EVM

    Еще нехило kernel lockdown активировать. Иначе, видите ли, имеючи права рута я прекрасно отпатчу вам что угодно сходив по физическим адресам оперативки. После этого IMA и EVM пойдет лесом. Вы ж не будете в рантайм состояние кернела постоянно чекать? Хотя отдельные секурити маньяки это пытаются, что прикольно и похвально но опять же - проверяющего тоже можно пропатчить.

     
  • 3.195, yet another anonymous (?), 07:07, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот если сударь соизволил бы раскрыть для широкой аудитории цель, которая достигается по каждой из строчке вышеупомянутой "цепочЬки", то странность и избыточность были уже видны. А если ещё добавить то, чего сделать будет нельзя --- то и проблемность вылезет. На что вам тут (чуть выше) и указали.
     
  • 3.205, Michael Shigorin (ok), 14:10, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Для сертифицированной загрузки OS необходима следующая цепочька:

    Нет.

     

  • 1.121, Аноним (121), 21:28, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно узнать % компьютеров на линуксе со включённой unSecure Boot
     
  • 1.126, Нн (?), 22:37, 08/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    SBAT разработан совместно с Microsoft.

    Троянский конь. Ждем когда ефи закопают, и вместе с ним и x86

     
     
     
    Часть нити удалена модератором

  • 3.147, Аноним (-), 11:20, 09/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Хаха, а ведь ты прав - главное ведь что паники нет! Зачет))
     

  • 1.179, Аноним (179), 20:18, 09/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > SecureBoot

    А зачем вообще нужен этот cockcage? Чтобы работало только то, что разрешил ональный доминатор?

    Против UEFI ничего не имею, хорошая штука.

     
  • 1.180, Онаним (?), 20:22, 09/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот зачем секуребут?
    Все, кто хочет - все ... ломают.
     
  • 1.183, darkshvein (ok), 23:31, 09/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    о да. давайте, поработаем на майрософт.
    защит им уефи!
     
     
  • 2.192, Аноним (-), 00:06, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > о да. давайте, поработаем на майрософт.
    > защит им уефи!

    А потом они на двоих с wintel нас с наших же компьютеров и попрут нашим же кодом. Секурно. Приятные перспективы.

     

  • 1.194, Аноним (194), 02:40, 10/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хотя бы один нормальный человек использует Secure boot?
     
     
  • 2.199, Аноним (-), 10:34, 10/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Как "эксперт" по статистике скажу, нет нормального человека, а вот медианный есть, о как!
     
  • 2.207, onanim (?), 18:32, 11/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    если под "нормальными" понимать именно адекватных людей, понимающих, как работает их компьютер, и немного разбирающихся в информационной безопасности - да, использует.

    но по быстрому просмотру треда по диагонали очевидно, что опеннет постепенно становится хабром.

     

  • 1.206, onanim (?), 18:29, 11/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тред не читал. для тех, кто понимает важность и нужность Secure Boot - обратите внимание на github.com/noahbliss/mortar - возможность запускать подписанное ядро напрямую из UEFI без использования GRUB.

    а в GRUB вообще намеренно сломана поддержка Secure Boot, то ли саботаж, то ли халатность: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906124

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру