Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
Сообщение от opennews (??), 08-Июн-22, 11:01
В загрузчике GRUB2 устранено 7 уязвимостей, позволяющих обойти механизм UEFI Secure Boot и добиться запуска неверифицированного кода, например, осуществить внедрение вредоносного ПО, работающего на уровне загрузчика или ядра. Дополнительно отмечается одна уязвимость в прослойке  shim, которая также позволяет обойти UEFI Secure Boot.  Группа уязвимостей получила кодовое имя Boothole 3, по аналогии с аналогичными проблемами,  ранее выявленными в загрузчике... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57316
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+14 +/–
Сообщение от Аноним (1), 08-Июн-22, 11:01
Никогда такого не было и вот опять
Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+9 +/–
	Сообщение от _hide_ (ok), 08-Июн-22, 11:57
	Вообще не понятно, почему что-то вообще должно выполняться на уровне загрузчика? Как можно лечить проблему (загрузка вредоносного кода на уровне ядра системы) и создать новую проблему -- загрузка вредоносного кода на уровне загрузчика (и, кстати, UEFI, при определённых обстоятельствах) Кстати, никто не знает, почему запускаемый код называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает?
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+8 +/–
	Сообщение от Аноним (-), 08-Июн-22, 12:05
	> называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает? Цифровая бюрократия. Без бумажки, ой, цифровой подписи - ты букашка...
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от Аноним (30), 08-Июн-22, 12:20
	Скоро без оной и птицам нельзя за границу, и рыбам плыть запрещено.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от Аноним (68), 08-Июн-22, 14:08
	>> Если вирус подписать, то проблема исчезает? Проблема пользователя - нет. А вот проблема microsoft("почему никто не использует наш механизм подписей всего?") - да.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	100. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+15 +/–
	Сообщение от Аноним (100), 08-Июн-22, 19:00
	> Вообще не понятно, почему что-то вообще должно выполняться на уровне загрузчика? Это отличный вопрос к знатокам 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.... Она есть, просто всё принято тащить в ядро сочиняя себе новые API и ломая старое API, которое там было. Ну и поверх нужно сделать 100500 версий одного и того же ядра на уровне дистрибутивов. Но ладно драйверы... вся сетевая подсистема должна обновляться с ядром, включая файрвол и графика.... И соответственно триггерить смену подписей. Жуткая помойка, которая накопилась из нерешенных проблем с размерами монолитной кодовой базы. Молодежь уже даже не понимает, что такие вещи как kmod и dkms это адские костыли, которые прикрывают архитектурные проблемы фиговым листочком. > Кстати, никто не знает, почему запускаемый код называют "неверифицированным", а не вредоносным? Если вирус подписать, то проблема исчезает? Код которые не прошел проверку подлинности не обязательно вредоносный. Вредоносность - это качественное суждение гуманитарной подсистемы (антивирус, например, делит всё на хорошее и плохое). Неверифицированность - это технический вопрос того, была ли произведена проверка цифровой подписи или код был запущен в обход проверки. И даже если свой вирус подпишите, но потом запустите в обход проверки цифровых подписей его всё равно нужно расценивать как неверифицированный. Ну и последнее, PKI - это не безопасность, а номенклатурные отношения доверия. PKI в этом случае отвечает на вопрос, является ли код доверенным или нет, и кто гарантирует вам это доверие. Любая безопасность строится не на концепции абсолютной защиты (её нет), а на том, что нужно как можно дольше тянуть время и как можно громче сообщать, параллельно вставляя палки в колёса атакующему коду. Бюрократическая неповоротливость PKI замечательно показала себя по вопросам усложнения жизни тем кто хочет запустить недоверенный код, вот её и используют. P.S. Я вообще не понимаю, почему в GRUB не впилят поддержку MP3, очень не хватает слушать музло во время просмотра любимой картинки во время ожидания загрузки пункта меню. Народу явно больше зайдёт чем нормальная поддержка верификации кода на уровне ОС.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	107. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от microsoft (?), 08-Июн-22, 19:28
	> пользователь явно не разрешил Пользователя ни о чем не спрашивают. Его ставят перед фактом, и заставляют жрать че дали. А он и рад хрустеть да чавкать.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (116), 08-Июн-22, 21:14
	Благодарю, Аноним-100. Почитал лекцию с интересом. Скрывать не буду: что-то во мне дрогнуло.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	128. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (128), 08-Июн-22, 23:33
	> Потому что вместо того чтобы заниматься внедрением цифровой подписи кода в Linux истерически применялись попытки обойти это, теми же самыми костылями с shim, лишь бы не внедрять. Потому что в том виде как оно сделано в UEFI оно нах не нужно!!! Это не безопасность, а дерьмо какое-то, навязанное доверие Microsoft и еще кому-то. Вместо того, чтобы дать ПРОСТОЙ способ самостоятельно подписать свою систему СВОИМИ ключами. В принципе есть возможность удалить предустановленные ключи в UEFI и прописать свои, но во-первых, не на всех устройствах получится, во вторых, практическая реализация достаточно сложная, чтобы мало, кто стал связываться. Еще и с большим риском окирпичиться.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	130. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от Аноним (100), 09-Июн-22, 01:03
	> Это не безопасность, а дерьмо какое-то, навязанное доверие Microsoft и еще кому-то. PKI это вообще не безопасность, а инфраструктура открытого ключа. Задача такой инфраструктуры определить гарантов и субъекты. Гарантом выступает некое физическое или юридическое ЛИЦО, некоммерческая организация итп (корневой сертификат). Им предоставлена возможность уполномочить некоторое техническое подразделение, занимающееся выдачей и отзывом (промежуточный сертификат) сертификатов конечных субъектов. Это простая двухступенчатая PKI. Бывает и трёхступенчатая с двумя промежуточными звеньями и более, но такие PKI не публичные, они имеют отношение либо к государствам, либо к крупным корпорациям в которых есть вышестоящее подразделение, удостоверяющее нижестоящее. С учетом наличия объектов сертификации, политик назначения и возможности кросс-подписи проверка доверия в общем случае - это ориентированный граф, а не просто дерево. Задача PKI - удостоверять, подписывать и показывать доверие. Это не про безопасность, а про автоматизацию бюрократии. Если человек тебе представляется Васей, а ты ему не веришь, то ты можешь спросить его паспорт или другое удостоверение. Паспорт на имя Иванова Василия Петровича, который он тебе показал выдан не просто кем попало, а Отделением УФМС России по городу Крыжополю Мухосранской области в Кислодрищенском районе. Сделав официальный запрос, ты можешь убедиться в неподдельности этого паспорта. А если ты не веришь в полномочия того, кто выдал этот паспорт, ты можешь уточнить соответствующий подзаконный акт учреждающий соответствующее отделение. Также можно проверить полномочия назначения уполномоченного лица, подписавшего акт и законность существования паспортного стола. И так вплоть до Конституции. Является ли бюрократия гарантией безопасности? Сама по себе не является. Но на основании PKI (не ниже двух ступеней) можно построить такие отношения доверия, которые могут быть частью общей системы безопасности. Гарант доверия предоставляет корневой сертификат, который по определению самоподписанный. Доверие держится не на техническом вопросе, а на том, какие репутационные риски понесёт реальное юридическое лицо в случае компрометации цепочки доверия. Первично, кто кому доверяет в вопросах UEFI решает не Microsoft, а каждый конкретный производитель материнской платы. Именно производители принимают решения, какие корневые сертификаты по-умолчанию будут предустановлены в UEFI. Содержать промежуточные центры сертификации - это большая ответственность. Сольётесь - вас ждёт судьба COMODO, которое было вынуждено переименоваться в Sectigo, там идёт реальная потеря денег в том числе по страховым возмещениям. Публичная международная PKI это еще и страхование. Да, есть несколько моделей материнских плат, в которых у пользователя нет возможности редактировать хранилище доверенных корневых сертификатов. Это обычно какие-то специфичные модели железа, которые предполагается что вы либо будете использовать так как хочет их производитель, либо попросту откажетесь покупать (лучше второе). Но это единицы... Сам по себе Secure Boot отключаемый, а UEFI вовсе умеет работать в DUAL-режиме за исключением парочки ноутбуков. > Вместо того, чтобы дать ПРОСТОЙ способ самостоятельно подписать свою систему СВОИМИ ключами. Ох ты ж запросы у вас барские. А кто же, я стесняюсь спросить, вам такое ПРОСТО предоставит. Linux? Вся эта вонь вокруг Secure Boot происходит потому что вшивые комитеты вроде Linux Foundation, когда суть дошла до дела отказались предоставить своё лицо в качестве гаранта отношений доверия. Они не подняли свой центр сертификации и не начали выдавать дистрибутивам Linux подписи и уж тем более не пошли разговаривать с производителями железа по вопросам включения и с Microsoft по вопросам кросс-подписей. Причин две: 1) Деньги. Содержать центр сертификации - это нужно поставить инфраструктуру и наладить рабочие процессы, занять людей. А еще нужно договариваться, а не шашками махать на лекциях перед студентами рассказывая о степенях свободы GPL. 2) Лицо. Им нужно рисковать и отвечать, за провалы. Нужно нести ответственность, что уже достаточно тяжело учитывая весь зоопарк^W плюрализм мнений в Linux сообществе. Их позиция была проста: Слышь, Microsoft, ты себе хочешь запилить цифровые подписи. Запили и нам нахаляву иначе мы на тебя в антимонопольные комитеты подадим, а мы при этом не будем ничего делать. MS посчитал риски вздохнул и запилил центр сертификации для бомжей. Вдумайтесь! Об этом почему-то мало кто говорит, но знаете ли вы загрузка Windows и остальные ОС, которые заверяет Microsoft имеют разные цепочки доверия? С точки зрения PKI это логично, потому что уровни доверия разные. Одна подконтрольна целиком, а вторая делегирована безответственным ни за что не отвечающим сообществам. В случае компрометации всей цепочки связанной с Linux отзыв корневых сертификатов не вызовет проблемы при загрузке Windows. И вопреки самым алармистским параноикам, MS не грохнул никому ничего. Ну и конечно же нельзя заподозрить MS в излишней благородности и любви к Linux. Всё это не бесплатно, там не только рекет с антимонопольными угрозами от бездельников, там еще и Red Hat и другие вендоры Linux с MS договорились и платят, потому что посчитали, что содержать собственные ЦС и договариваться со всеми вендорами PC-железа включая консьюмерское, мягко говоря, им не выгодно. А сообщество Linux... ну оно вообще живёт в астрале, когда дело касается договороспособности. Ну и конечно же вы хотите, чтобы вам предоставили инструменты для Linux, которые позволят вам построить свою PKI и подписать всё и вся начиная от Secure Boot и заканчивая распоследним драйвером бесплатно без смс на высокой скорости... Этих инструментов не было много лет, пока MS не начал использовать Linux для виртуальных коммутаторов в Azure. Они их написали для Linux и теперь они есть. И недостающие модули ядра есть, но юзерспейсных частей нет. А Red Hat, который первично занимался внедрением поддержки Secure Boot много лет назад, чуть ли не поддержку PE (portable executable) пытался тащить в ядро, лишь бы сделать совместимым с Windows, потому что они деньги экономили и не хотели отвечать за очередные результаты голосований в Debian и прочий цирк. Закономерно, что "предложения" Red Hat были во многом выкинуты в помойку Торвальдсом лично в виду технической убогости. В итоге: 1. Разрешено ли вам грузить собственные ключи или нет - это вопрос разработчика оборудования, а не MS. Не покупайте бяку, потому что залоченные UEFI не только Linux не дают поставить, там и Windows не обновляется, вообще-то. 2. Способ подписать код ОС - это вопрос того кто занимается подготовкой дистрибутива. Возьмите и подпишите. И соберите еще модули ядра, которые держат ключи на уровне ядра и умеют работать с TPM. 3. Просто с PKI никогда не будет. Её цель - максимально всё усложнить, чтобы абы кто со стороны не смог вклиниться в доверие. И пожалуйста, не путайте "навязанное доверие Microsoft" с оптимизацией корпоративных затрат и рисков Red Hat, которая отказалась тянуть за всех лямку и бесполезностью Linux Foundation, которая в вопросах представительства и сертификации прикинулась ветошью.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от penetrator (?), 09-Июн-22, 04:16
	А зачем нам такая ущербная схема?
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 09:45
	> И вопреки самым алармистским параноикам, MS не грохнул никому ничего. Не надо категоричных заявлений, они портят общую картину. Вот эта HIPS  http://www.online-solutions.ru/products/osss-security-suite.... находила много всего, включая руткит, который Микрософт пришлось ловить совместно с сэрами мэйорами. В том числе и несанкционированные обновления ОС, от которых ныне стонет пользователь, могла считать подозрительной активностью и блокировать.
	Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

	138. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 09:36
	> Вместо того, чтобы дать ПРОСТОЙ способ самостоятельно подписать > свою систему СВОИМИ ключами. Прекратите орать. Почитайте умную книжку. Там пишут, как самостоятельно подписать.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	166. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 16:03
	Может там еще пишут как отключить бутгада и сделать СВОЙ root of trust а не майкрософто-интеловский? И даже прошивку ME подписать своим ключом дадут? Без всего этого секурити всей этой схемы около ноля.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 19:02
	Это надо детскую сказку "Теремок" почитать. Что бы научиться не так заметно увеличивать запросы.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 23:32
	> Это надо детскую сказку "Теремок" почитать. Что бы научиться не так заметно > увеличивать запросы. Система которая служит своему владельцу и делает что обещано а не кучу других непрошенных вещей не такое уж и большое желание. Особенно за свои деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 10-Июн-22, 09:02
	Мой комментарий оставлен по поводу совсем другого желания. Подписать ядро можно.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от tty0 (?), 09-Июн-22, 00:02
	Т.е, чтобы решить проблему имбицилов и им сочувствующим, я должен подписывать все модели ядра после сборки? Сторонними средствами и чужими ключами? Бред сумашедшего. UEFI - решение чрезвычайно узкоспециализированное и нужно только ИНДИВИДУАЛЬНЫМ пользователям Windows с ROOT правами. Для всего остальных - это какое-то извращение.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	131. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (100), 09-Июн-22, 01:46
	> Т.е, чтобы решить проблему имбицилов и им сочувствующим, я должен подписывать все модели ядра после сборки? Сторонними средствами и чужими ключами? Или купить оборудование, которое позволяет грузить свои ключи в прошивку. Или на заводе сделать своё оборудованием с PKI и ключиками. > UEFI - решение чрезвычайно узкоспециализированное и нужно только ИНДИВИДУАЛЬНЫМ пользователям Windows с ROOT правами. Аналог пользователя root в Windows - это Local System он может входить в систему только специальную сессию 0 для служб и пакетных заданий. У Windows есть разделение типов входов в систему, а не PAM, который всё считает локальным входом. В некоторые дистрибутивы это частично утащили, запрещая логиниться рутом, но тоже костыльно. Словарный пользователь Administrator с заранее известным идентификатором безопасности там выключен по умолчанию и оставлен для обратной совместимости. Каждый "локальный администратор" - это по сути то что в UNIX исторически называется колесом (wheel). UEFI - это стандарт прошивок, применяемых в современных материнских платах. Оно не только про загрузку ОС, там еще есть устройства. Не надо путать UEFI и Secure Boot. Многим устройствам периферии требуется процедура первичной инициализации, у них есть какой-то ROM и код который надо выполнить. Формат прошивки периферического устройства для BIOS и для EFI разный. Вообще, вы видимо мало железа видели или вам сильно повезло в жизни, и вы попросту не знаете, что процедуры инициализации периферии в BIOS и ранних версиях EFI не стандартизированы от слова СОВСЕМ и отличаются между разными производителями мат. плат и серверных платформ. UEFI позволяет унифицировать BIOS и EFI как стандарт для всех вендоров железа предоставляет универсальный инструментарий. Инициализация устройств становится как минимум предсказуемой. Для того чтобы, например сетевая карта работала в UEFI нужны 2 прошивки старая для BIOS и новая для UEFI. Для видеокарт тоже нужен UEFI-драйвер, который в старых видеокартах может вообще отсутствовать. Можно сколько угодно изолироваться в танке и жить старым железом и загружаться через BIOS, пока не встретится какой-нибудь ПЗУ-контроллер у которого BIOS-прошивка старая и грузится натурально 10 минут а UEFI, работает нормально. Кроме того есть контроллер NVMe. Удачи вам там ЗАГРУЗИТЬСЯ с NVMe диска в режиме BIOS/MBR. Это не с каждым прокатит. Для m.2 SSD оно еще сработает. Вендоры мат. плат предлагают стоковую прошивку, которая эмулирует вам SATA/AHCI для этого порта и уронит производительность IO, но оно хоть загрузится и будет работать. Если же у вас настоящий NVMe современного образца в PCI-Express, вас ждёт провал, причем старые PCI-Express SSD диски, наоборот, будут работать в BIOS но спустя столько лет найти живой такой можно только в музее. Если же вы при всем этом хотите использовать этот NVMe как кэш для большого SATA-диска (и поставить на него ОС) или у вас сервер, который будет использовать NVMe для размещения данных и потом вам это нужно в сеть раздавать и на сетевке у вас RDMA... удачи вам там с BIOS. А вообще, автомобиль ведь это тоже узкоспециализированное средство передвижения, которое нужно только индивидуальным пользователям, то ли дело упряжки с лошадьми...
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (134), 09-Июн-22, 07:30
	А чё там у вендоров с "договороспособностью"? Чё они столько лет "ветошью прикидывались", а, в итоге, свалили проблему с себя на других?
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от _hide_ (ok), 09-Июн-22, 10:00
	> Аналог пользователя root в Windows - это Local System Т.е. пользователь с правами администратора может поднять права до Local System и изменить код в загрузчике. А зачем столько слов? Чтобы запутать?
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	151. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (100), 09-Июн-22, 12:35
	Потому что там всё на самом деле запутано. Для начала вам нужно быть понять, что существуют типы входа в систему (типы сессий). И процессы не конвертируются между ними и не могут получить доступ друг к другу без RPC ну или как минимум порта/сокета. Этого всего нету в unix-подобных ОС, там PAM вместо аутентификации, который выдаёт одни и те же права удаленному пользователю, интерактивному пользователю, демонам и слыхом не слыхивал про Kerberos. PAM-у пофиг, его проектировали в 80-е годы и тащат до сих пор. Интерактивная сессия в WinNT никогда не превращается в служебную. Если у вас есть пользователь MYWINPC\vasya от лица которого вы вошли в систему и вот решили запустить службу от лица пользователя MYWINPC\vasya, предоставив этой учетной записи соответствующие привилегии, которых у нее по умолчанию не было, то в этом случае службы запущенные от лица Васи и процессы запущенные Васей окажутся физически в разных сессиях. Суть в том, что вы не обратитесь к такому процессу напрямую. Local System - это пользователь, который может запускать что бы то ни было только в специальной сессии и только аутентифицировавшись как служба или пакетное задание. Интерактивный пользователь не станет службой. Лучшее что может сделать интерактивный пользователь - это получить права на создание специально оформленного пакетного задания (нужно как минимум интерактивное повышение привилегий), которое он может поставить в планировщик и выполнить от лица Local System. Еще раз, напрямую не из какой оболочки вы не получите эти права, это не su и тем более не sudo. Дальше, когда вы создали пакетное задание, которое что-то делает и запустили его от имени Local System, это не значит что у процесса, который вы запустили есть все необходимые привилегии в дескрипторе безопасности, для того чтобы выполнять нужный вам код. Банально, чтобы сменить владельца файла на ФС, в неинтерактивном режиме ваш процесс должен обладать правами, дающими ему возможность выдать самому себе привилегию на смену владельцев (SeTakeOwnershipPrivilege). Для того чтобы выдать себе эти привилегии, вам нужно обратиться не куда-нибудь, а к юзерспейсной части ядра, в частности, к библиотеке advapi32.dll. И вот на этом этапе вас ждут сюрпризы, потому что по-умолчанию ни один сценарий никакой оболочки не может к ней обратиться, блочат все возможные антивирусы включая Defender. Чтобы это обойти вам нужно написать собственное приложение, которое будет обращаться к ядру и что-то там себе повышать. То есть вы запускаете уже не то что команду в оболочке, не то что скрипт в планировщике, а приложение .NET, дабы скрыть вызовы P/Invoke к этой библиотеке ядра. Ну вот вы после этого что-то там можете выполнить, но не всё. Даже для доступа к хранилищу ключей, вам нужно выдать себе отладочные привилегии (если нету ни виртуализации, ни TPM, если они есть, то всё вообще грустно). Без предварительной настройки своей сессии вы их себе по-тихому не дадите. Орать и вопить будет всё вплоть до ватермарков на картинке рабочего стола. Ну вот вы всё это написали и хотите поменять... что? Загрузчик? Максимум можно именно сломать загрузчик но незаметно подсунуть свой код, когда включен Secure Boot там не получится, подписи нужны. И вот суть в том, что если вы ваше приложение попытаетесь где-то кому-то распространить, то его внесут в антивирусные сигнатуры быстрее, чем вы получите сертификаты на подпись кода. P.S. Чтобы окончательно не "путать" вас я умышленно писал только про обычные службы (по сути как демоны) и не упоминаю ни про фоновые процессы магазина ни про специально оформленные user-services, запускаемые как экземпляры внутри интерактивной сессии, с еще более низкими привилегиями от лица других SID, с пониженными профилями энергопотребления и сразу в swap-е... А вообще давайте так, сядьте и получите права Local System из оболочки напрямую, без всяких слов и путаницы, отпишитесь об успехах, может я узнаю что-то новое =)
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 14:26
	> Для того чтобы выдать себе эти привилегии, вам нужно обратиться не > куда-нибудь, а к юзерспейсной части ядра, в частности, к библиотеке advapi32.dll. Начали во здравие, а завернули невесть куда. advapi32.dll - это не ядро. Это часть подсистемы Win32 (как и kernel32.dll). Ядро это ntoskrnl.exe, и вот что там выполняется не в arbitrary thread context, а в выделенном потоке - это почти всегда аналог root. В просторечии это называется "драйвер". Что бы затруднить эксплуатацию уязвимостей в сервисах режима ядра и прочих привилегированных компонентах системы и ввели подпись загрузчика - якобы атакующий, даже попав в ядро, закрепиться в системе не сможет. > А вообще > давайте так, сядьте и получите права Local System из оболочки напрямую, > без всяких слов и путаницы, отпишитесь об успехах, может я узнаю > что-то новое =) Note: some anti-virus scanners report that one or more of the tools are infected with a "remote admin" virus. None of the PsTools contain viruses, but they have been used by viruses, which is why they trigger virus notifications. https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (100), 09-Июн-22, 17:41
	> Это часть подсистемы Win32 (как и kernel32.dll) А Win32 это часть подсистемы чего? Гриба? Яблока? Табуретки? В Windows ядро не монолитное и часть подсистем вынесена в юзерспейс, часть в Ring 0, а Win32 API между ними единое. А "сервисы режима ядра" тогда что? Это мелкие вопросы терминологии. Гораздо важнее, что тот, кому я отвечал предполагает, что получить полного рута и подменить загрузчик в Windows можно просто волшебной командой, а не специально написанным приложением, которое само по себе должно быть заверено сертификатами и одобрено антивирусными комитетами, и его код для инжекта должен быть заверенным. Ну и приводить в пример старое доброе psexec человеку, который в общих чертах описывает как реализовать схожую утилиту на лету, с объяснением почему нельзя просто так взять и захватить права без написания такой утилиты, это, как минимум, странно. Я у него спрашивал про то как права захватить скриптом из оболочки с использованием стандартных средств при помощи простого текстового сценария в оболочке, не отхватив от антивирусов и всего остального... Отвечая на свой вопрос, можно, например, запустить PowerShell в котором в отдельном потоке запустить задание планировщика, перехватывая вывод в основную сессию, и выполнить там скрипт, который объявляет самописный динамически компилируемый тип на С#, который маршалит P/Invoke и выдаёт своему процессу все нужные привилегии. Но ни до цифровых подписей драйверов, ни до загрузчика там в общем случае не добраться. На практике, было бы желание, но массовости у такого решения не будет. Так-то в теории ничего не мешает маршалить всё Win32 напрямую из PowerShell, вот только это требует отключения кучи всего антивирусного, чтобы оно прекратило вопить. И драйверы можно подсунуть какие попало, если отключить Secure Boot и запустить ядро с опцией отключающей цифровые подписи драйверов. Причем антивирусы блокируют сейчас любое такое обращение без разбора, в том числе невесть откуда на лету скачанные psexec. Если у вас есть решение проще, милости прошу, рассказывайте.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 19:41
	>> Это часть подсистемы Win32 (как и kernel32.dll) > А Win32 это часть подсистемы чего? Гриба? Яблока? Табуретки? Ну я даже и не знаю, что тут можно сказать. Раньше это был такой термин от производителя ОС, который не вызывал удивления у тамошних специалистов. Попробуйте написать фидбэк Микрософту https://docs.microsoft.com/en-us/windows-hardware/drivers/dd... > В Windows ядро не монолитное Ну да. Это значит, что часть ядра оформлено в виде загружаемых в пространство ядра модулей формата PE/COFF. > и часть подсистем вынесена в юзерспейс, часть в Ring > 0, а Win32 API между ними единое. Каких подсистем? Вышеупомянутой Win32 и опциональной со времён NT4 Posix subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem которую сменили на WSL? Это не части ядра. > А "сервисы режима ядра" тогда что? Это сервисы, созданные с флагами SERVICE_KERNEL_DRIVER или SERVICE_FILE_SYSTEM_DRIVER https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nf... > Это мелкие вопросы терминологии. Это вопросы понимания, в каких адресных пространствах и с какими правами исполняется код. В данном случае под правами понимаются кольца защиты. > Гораздо важнее, что тот, кому > я отвечал предполагает, что получить полного рута и подменить загрузчик в > Windows можно просто волшебной командой, а не специально написанным приложением, которое > само по себе должно быть заверено сертификатами и одобрено антивирусными комитетами, > и его код для инжекта должен быть заверенным. Он написал, что ответ слишком объёмен и сложен для восприятия. Я добавил, что местами он вносит терминологическую путаницу. Достаточно указать худший сценарий - код не важно как попал в ядро и хочет закрепиться в системе, подменив загрузчик -  так называемый "буткит". Вот от них и защищает SecureBoot, как заявляет Микрософт. > Ну и приводить в пример старое доброе psexec человеку, который в общих > чертах описывает как реализовать схожую утилиту на лету, с объяснением почему > нельзя просто так взять и захватить права без написания такой утилиты, > это, как минимум, странно. Ну как же нельзя, когда там написано буквально: вирусы берут эту утилиту и применяют для своих целей. А если для этого потребовался антивирус, значит ОС самостоятельно не справляется.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от bergentroll (ok), 09-Июн-22, 08:41
	Всё вы классно написали. Непонятно только, что хорошего за «доверием» ходить на поклон к «батюшке»-Майкрософту™.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	146. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от Аноним (-), 09-Июн-22, 10:53
	> за «доверием» ходить на поклон к «батюшке» Так это основной принцип бюрократии, про который он не написал. Чтобы цепочка доверия хоть что-то гарантировала нужно найти "доверенные" концы: начиная от "доверенного" железа, на котором проверяется доверие, до заранее записанных "доверенных" сертификатов. Это достигается тупым вендорлок'ом: железо и софт только от "доверенного" поставщика (например, продукция от apple и прочих андроид-телефонов [хотя андроид - это тоже франкештейн с гуглом]). В случае с uefi secure boot такой вендорлок не пропустили. Получился франкенштейн, когда поставщик железа прописывает чужие корневые сертификаты. В итоге никто ни за что не отвечает, потому что не может.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 09:43
	> Secure Boot > Ну и последнее, PKI - это не безопасность, а номенклатурные отношения доверия. Как обычно, подмена понятий.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	143. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 10:16
	> Под Linux таких вирусов нет, потому что там нет пользователя Андроид - это linux?
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	167. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 16:05
	Дерьмовенький и специфичный, да. А что, под него именно вирусы бывают? Не путать с троянами и иной малварью, вирус должен самораспостряняться, на андроиде с этим неудобно.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 16:20
	> А что, под него именно вирусы бывают? Не ко мне вопрос, что подразумевается под "таким вирусом". Мой вопрос был: есть пользователи linux (android - linux?), и как следствие, есть ли "такие вирусы" для linux? > вирус должен самораспостряняться (Само)распространение кастомных прошивок со взломанными загрузчиками - это вирус?
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 23:44
	> (Само)распространение кастомных прошивок со взломанными загрузчиками - это вирус? Наверное сойдет за вирус. А оно такое вообще бывает? Там так то довольно много вещей которые могут пойти не так и это сложно сделать незаметно и без действий юзера. Это кто-то вообще делал? Или это чисто теоретически? Если вдруг это у кого получится, положите на гитхабчик, посмотреть на то как оно вообще работает избегая многих веселых факапов системного уровня :)
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 15:34
	> GRUB2 по своим размерам тянет на небольшую ОС. UEFI тоже тянет на это. И?
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	170. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 16:29
	>> Это отличный вопрос к знатокам GRUB2. Примерно за тем же зачем ему поддержка PNG, BMP, TGA и прочего. GRUB2 по своим размерам тянет на небольшую ОС. > UEFI тоже тянет на это. И? В uefi-прошивке есть "поддержка PNG, BMP, TGA и прочего"?
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 23:48
	> В uefi-прошивке есть "поддержка PNG, BMP, TGA и прочего"? Зависит от UEFI прошивки. В некоторые даже флешер встроен, не то что PNG. Более того - как GRUB может догружать модули (вон то оформлено модулями) так и EFI может догружать внешние программы. Хуже, оно может runtime-сервисы и дрова железа подпихивать свои. Оставаясь частично in charge даже после того как ядро запустилось. GRUB в этом плане не такой зловредный сам по себе. В режиме эмуляции EFI он даже умеет runtime services по минимуму вывешивать, но то ж опенсорсный код и мало, а не 16-метровый блобина фирмвари мамки где черти что и с боку бантик, но вы можете расколупать эту блоботу и посмотреть что оно там умеет...
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 10-Июн-22, 09:52
	Ну, вот, я же говорил во всем опенсорсный grub виноват, а не любимые оффтопщикам доверенные блобы, подписанные доверенными сертификатами, выданные доверенными компаниями.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (182), 09-Июн-22, 20:44
	Посоветуй систему изоляции для приложений пользовательского пространства для linux?
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	125. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от AlexN (??), 08-Июн-22, 22:32
	И вообще! Это не уязвимость - это фича. Secure Boot - происки мелкософта.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	24. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от alex (??), 08-Июн-22, 12:02
	Не помню новости про уязвимости, к которой не было бы такого комментария. Где ваша креативность, баянисты?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	62. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+5 +/–
	Сообщение от Аноним (62), 08-Июн-22, 13:46
	Никогда такого комментария не было, и вот опять!
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (116), 08-Июн-22, 21:15
	Никогда такого комментария не было, и вот опять!
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (182), 10-Июн-22, 13:27
	Однажды я написал креативный комментарий, и вот что произошло... большой текст свёрнут, показать
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	25. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+12 +/–
	Сообщение от Аноним (25), 08-Июн-22, 12:03
	> Никогда такого не было и вот опять Хз что там не было никогда с GRUB, но возможность обойти Secure Boot, это не баг, это фича. Я надеюсь что в аду есть приготовили отдельный котёл для тех, кто эту ерунду с Secure Boot затеял.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	89. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от YetAnotherOnanym (ok), 08-Июн-22, 17:35
	Рядом с котлом для разрабов одного не в меру развесисто-фичастого загрузчика. Нефиг в загрузчик пихать обработку png или jpeg, или разбор заголовков http.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Ooiiii (?), 08-Июн-22, 17:38
	>в аду есть приготовили
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

2. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+37 +/–
Сообщение от Аноним (2), 08-Июн-22, 11:04
ШОК! Имея физический доступ к компьютеру, можно запустить в нем все, что угодно. Уязвимость получила кодовое имя Boothole 3. Для устранения уязвимости принимайте перед сном одну столовую ложку обычного советского... Читать далее >>
Ответить | Правка | Наверх | Cообщить модератору

	3. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+6 +/–
	Сообщение от Жироватт (ok), 08-Июн-22, 11:12
	Найдены фото секретных исходников UEFI! Там видно самого... Читать далее>>
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (8), 08-Июн-22, 11:23
	Чтобы пропатчить KDE2 под FrreBSD, достаточно каждый втирать... Читать далее>>
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+7 +/–
	Сообщение от Аноним (11), 08-Июн-22, 11:36
	Вы не поверите, но все кто использовал Linux умерли... Читать далее>>
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+4 +/–
	Сообщение от InuYasha (??), 08-Июн-22, 11:37
	Ползователи в ШОКЕ! Если два раза нажать кнопку "питание" можно удвоить... Смотреть далее >>
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	119. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (116), 08-Июн-22, 21:20
	ШОК!!! Электрический ток обладает... Читать далее >>
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от Аноним (-), 08-Июн-22, 21:30
	На соревнованиях по плаванию электрик Сидоров замкнул тройку лидеров << Вернуться
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от Аноним (22), 08-Июн-22, 12:00
	Виндовс пользователей разделят на органы ... Читать далее>>
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	91. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Ooiiii (?), 08-Июн-22, 17:42
	А вы знали стало с теми кто перешёл обратно на уиндоуз... Читать далее>>
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (182), 09-Июн-22, 20:15
	Девушка узнала, что её парень пользуется линуксом и решила... большой текст свёрнут, показать
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	112. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Дмитрий (??), 08-Июн-22, 20:15
	А ведь наши дедушки и бабушки для этого использовали надёжный советский... Читать далее>>
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	10. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–8 +/–
	Сообщение от Аноним (10), 08-Июн-22, 11:33
	> Имея физический доступ ..., можно ... все, что угодно. В цивилизованных странах за это посадить (на счетчик) могут.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	76. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от наме (?), 08-Июн-22, 15:21
	В нецивилизованных просто пристреливают.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Neon (??), 08-Июн-22, 18:16
	Причем неизвестно что гуманнее.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от Бывалый смузихлёб (?), 08-Июн-22, 11:45
	Почему Читать далее не нажимаеццо !??
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	27. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+4 +/–
	Сообщение от Аноним (-), 08-Июн-22, 12:14
	Потому что нужен платный аккаунт. Платный аккаунт увеличивает... Читать далее>>
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (30), 08-Июн-22, 12:17
	Erlarge your penis!
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от AleksK (ok), 08-Июн-22, 14:00
	Erlang your penis.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (11), 08-Июн-22, 14:18
	Главное чтобы не eating
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от АнонимкаРастуимка (?), 08-Июн-22, 14:07
	Почему я жму на "читать далее" и ничего не происходит?! Читать далее >>
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	85. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Читать далее (?), 08-Июн-22, 16:58
	Жмите!
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (88), 08-Июн-22, 17:24
	Как правильно нажимать... ? Читать далее >>
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	101. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (101), 08-Июн-22, 19:08
	Да хватит уже... Читать далее >>
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (116), 08-Июн-22, 21:22
	Нет, не хватит... Читать далее >>>
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (182), 09-Июн-22, 20:25
	Учёные выяснили, чего не хватает людям для комфортного общения... большой текст свёрнут, показать
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (145), 09-Июн-22, 10:40
	> ШОК! Имея физический доступ к компьютеру, можно запустить в нем все, что угодно. Разное образование сказывается. Их учат, что минимальный уровень безопасности ОС - C1, должен гарантировать неизменность всего исполняемого и невозможность запуска всего стороннего! ЗЫ: по теме половины уязвимостей там нет: png и прочие входящие данные проходят верификацию по цифровой подписи. Их не подменить. Shim - самим своим существованием противоречит фундаментальным принципам Integrity. Сторонние ключи не допускаются. Уязвимости по сети надо смотреть.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	150. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (10), 09-Июн-22, 12:15
	> должен гарантировать неизменность всего исполняемого и невозможность запуска всего стороннего! А что, "безопасники" уже решили "проблему останова"?
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 14:36
	Решили, но не для общего случая: BLM заявляют ныне, что "белый список" ущемляет их права.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 14:54
	Если "белый список" полный по Тьюрингу?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 19:53
	Не полный, а бодипозитивный.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 10-Июн-22, 10:01
	бодипозитивный - это толстый полный - это укомплектованный на 100%
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 10-Июн-22, 13:52
	Укомплектованный на все 100% по Тьюрингу инклюзивный чёрно-белый список?
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (159), 09-Июн-22, 14:55
	> уже решили "проблему останова"? Это что? Выключение компа? Гибернации?
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

4. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+6 +/–
Сообщение от Аноним (4), 08-Июн-22, 11:16
Уязвимости в GRUB2, позволяющих обойти ненужно
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+4 +/–
Сообщение от Аноним (5), 08-Июн-22, 11:17
Кто-нибудь, пожалуйста, научите уже системных программистов тестировать код:(
Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Rev (?), 08-Июн-22, 12:21
	Это невозможно. Для решения систематических ошибок программистов и был разработан новый язык программирования. О нём тут все знают.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (5), 08-Июн-22, 12:45
	даже там Тестирование, никто не отменяет!
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (48), 08-Июн-22, 13:15
	Но никто и не выполняет...
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (5), 08-Июн-22, 13:24
	Если это действительно так, то это весьма печально:(
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от warlock (??), 08-Июн-22, 15:39
	Пользователи протестируют.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	82. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (5), 08-Июн-22, 15:54
	Увы, к сожалению да, - это стратегия большинства, ака тяп-ляп и в продакшн:( Про корпарасов я вообще молчу! Например, мелкомягкие, так вообще решили что им не нужны профессиональные тестировщики, и по сути переложили всю работу на так называемых инсайдеров, - и получили соответствующий результат!
	Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+7 +/–
Сообщение от beduin747 (ok), 08-Июн-22, 11:18
Это был не баг! Это была фича!
Ответить | Правка | Наверх | Cообщить модератору

	193. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от анон_тот самый (?), 10-Июн-22, 00:41
	я вот тоже такого мнения. было бы круто еслиб груб мог сам заменить уефай и вернуть старый добры биос. а то с этим поделием чую куда то не туда свернули.
	Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
Сообщение от Аноним (7), 08-Июн-22, 11:20
Пора уже закопать этого перегруженного уродца
Ответить | Правка | Наверх | Cообщить модератору

	41. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (41), 08-Июн-22, 12:47
	А на что заменить?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от НяшМяш (ok), 08-Июн-22, 13:15
	systemd-boot /s
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от qetuo (?), 08-Июн-22, 18:06
	Зря. Отличный легковесный boot manager.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от warlock (??), 08-Июн-22, 15:41
	Есть ELILO.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	86. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (86), 08-Июн-22, 16:59
	das u-boot.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	108. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (108), 08-Июн-22, 19:39
	Das ist Fantastisch!
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (104), 08-Июн-22, 19:15
	>А на что заменить? 1. компилируешь ядро как efi-приложение 2. загружаешь из UEFI efi-приложение (efibootmgr в помощь) profit! И никакой systemг-bootd не нужен.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	135. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (134), 09-Июн-22, 08:02
	Давно заменил на Арче mkinitcpio на dracut, а GRUB2 на systemd-boot. Хуком для pacman собираю initrd как UEFI-приложение. Брат жив.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	162. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (159), 09-Июн-22, 15:32
	GNU/GRUB - отличный загрузчик! По его возможностям просто нет альтернатив. Возьмем, например, только две с его фич: 1. Загрузка с шифрованого раздела 2. Верификация всех подгружаемых модулей, настроек, ядер OS и initrd с помощью публичного ключа. Альтернативы какие?
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	92. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Ooiiii (?), 08-Июн-22, 17:48
	Но не обязательно же использовать все лишние компоненты. Можно самому написать grub.cfg из 5 строк, и больше не запускать update-grub.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	109. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (108), 08-Июн-22, 19:43
	Тем более, что этот update-grub в каких-то случаях не находит образ inird, не вписывает его в grub.cfg. В результате этот пункт меню оказывается неспособным загрузиться.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 23:52
	> Но не обязательно же использовать все лишние компоненты. Можно самому написать grub.cfg > из 5 строк, и больше не запускать update-grub. Как бы update grub нужен в основном чтобы при установке например нового ядра пакетный менеджер сразу бы дернул хук который пропишет это ядро в меню загрузки. Ах да, о том что уметь грузить несколько ядер полезно мы узнаем после очередного апдейтак, который таки все сломал. И есть довольно большая разница между "совсем не грузится" или "пришлось нажать пару кноп, вгрузив более старое ядро"
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

9. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
Сообщение от mos87 (ok), 08-Июн-22, 11:26
>В загрузчике GRUB2 устранено UEFI SecureBoot
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+4 +/–
Сообщение от InuYasha (??), 08-Июн-22, 11:39
А можно просто загрузить свой ключ и сертификат в UEFI и жить в безSHIMном мире?
Ответить | Правка | Наверх | Cообщить модератору

	16. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от Аноним (16), 08-Июн-22, 11:49
	Людишки не могут EFISTUB осилить и грузятся через промежуточный загрузчик, ну о чём ты говоришь...
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от n00by (ok), 08-Июн-22, 12:40
	А при чём здесь пользователи? Баш-программисты POCA LINUX XPOM не умеют добавить 10 банальных строк в инсталлятор, а тут ещё и немножко подумать требуется.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (46), 08-Июн-22, 13:12
	Потому что промежуточный загрузчик удобнее EFISTUB и позволяет настраивать загрузку без запуска ОС. Когда сделаете в EFISTUB такую же удобную консоль как в grub, тогда и будете рассказывать про людишек.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	64. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (16), 08-Июн-22, 13:49
	> позволяет настраивать загрузку без запуска ОС. А сам GRUB ты поставишь не из ОС? Или тебе нужна именно возможно что либо поправить, когда ты по дури снесёшь себе систему? Ну так тебя это не спасёт... И главный вопрос - ты хоть раз этой консолью воспользовался?
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (-), 09-Июн-22, 23:56
	> А сам GRUB ты поставишь не из ОС? 1) Прописать в boot image оси заранее. Это конечно тоже из ОС будет, но из совсем другой. 2) Live CD/USB - это конечно тоже из ОС, но - опять же другой. > Или тебе нужна именно возможно что либо поправить, когда ты по дури снесёшь себе систему? Это актуально если например i++'й кернел не взлетел почему-то. Это конечно редкость, но есть некоторая разница между компьютером превративщимся в полный кирпич и экстренным хардкором с его починкой и просто выбором предыдущего ядра (или даже кастомных опций командлайна) в менюшке. > И главный вопрос - ты хоть раз этой консолью воспользовался? Я пользовался. Иногда полезно, например для кастомного командлайна ядру.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (95), 08-Июн-22, 18:25
	>Людишки не могут EFISTUB осилить А вот может ли этот ваш EFISTUB грузить 64-х битное ядро linux из uefi32? А вот grub может! Я как личный владелец планшета на bay trail говорю
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	115. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+2 +/–
	Сообщение от Попандопала (?), 08-Июн-22, 21:03
	Включите в ядре EFI mixed mode support  и 64 битное ядро  будет робит с 32 битной UEFI.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (133), 09-Июн-22, 07:08
	Только этому вашему "EFI mixed mode support" нужен промежуточный загрузчик, типа grub
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от Аноним (153), 09-Июн-22, 13:11
	Минусаторы вот вам пруфы - 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.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от n00by (ok), 09-Июн-22, 14:42
	Это всё недостаточно авторитетный пруф. Сам директор POCA LINUX заявил, что "нами даже решён вопрос ..., когда 64-разрядный дистрибутив устанавливается на компьютер с 32-разрядным UEFI" и фанаты уверовали, тогда как науке подтверждения не известны.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 16:09
	В нем еще и эмуляция EFI кажись есть для BIOS систем. И выбирая между EFI от wintel и прочих AWARD_SW - ну вы поняли.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	142. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (134), 09-Июн-22, 10:00
	Шо на необразованных людишек пенять, если преуспевающие мамкины хозяйчики никак не могут нормальный UEFI-загрузчик для своих матюршинных плат напейсать, чтобы просто работало и не окирпичивалось при малейшем дуновении ветра.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	164. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (159), 09-Июн-22, 15:42
	> А можно просто загрузить свой ключ и сертификат в 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.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

14. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+10 +/–
Сообщение от Diozan (ok), 08-Июн-22, 11:41
Зря пофиксили полезную фичу. Secury Boot не нужен...
Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+3 +/–
	Сообщение от Аноним (68), 08-Июн-22, 14:11
	Secury Boot очень нужен микрософту
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (-), 08-Июн-22, 15:41
	Твои мусорные коменты не нужны
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	165. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (159), 09-Июн-22, 15:43
	А мне нужен! Вы его просто не умеете готовить;) Пойдите курсы поваров..
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	201. "Уязвимости в GRUB2, позволяющих обойти UEFI Secure Boot "	+/–
	Сообщение от Michael Shigorin (ok), 10-Июн-22, 13:51
	http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO достаточно будет? Мне вот хватило с запасом.  Очень рад, что занялся наконец вместо этого непотребства эльбрусами.
	Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+2 +/–
Сообщение от Rodegast (ok), 08-Июн-22, 11:50
Это не баг,а фича!
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от Гыгыгы (?), 08-Июн-22, 11:51
Почему фанаты любят уточнять что любой Linux, это GNU/Linux, а когда сообщение о уязвимости, то я не вижу ни одного уточнения что это GNU GRUB 2?
Ответить | Правка | Наверх | Cообщить модератору

	19. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (11), 08-Июн-22, 11:55
	А бывает non-GNU GRNUB?
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (32), 08-Июн-22, 12:32
	А non-GNU Linux?
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (34), 08-Июн-22, 12:36
	Linux + BusyBox
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (11), 08-Июн-22, 12:56
	Android - GNU не содержащий Linux.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	47. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (46), 08-Июн-22, 13:14
	Наоборот, в android linux ядро без gnu окружения.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (11), 08-Июн-22, 13:27
	Ты ошибаешься в Android есть Linux но нет GNU.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (11), 08-Июн-22, 13:33
	Надо быть тупеньким, чтобы подумать что я написал что андрюша это гну без линукса.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	72. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от anonfhjvxd (?), 08-Июн-22, 14:19
	Но ты ровно это и написал. Тут даже и думать не надо. Достаточно уметь читать.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (11), 08-Июн-22, 14:52
	Спред - сливочного масла, не содержащий продукт тоже сомнения вызывает у тебя?
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (87), 08-Июн-22, 17:14
	Да. В твоей грамотности.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 23:59
	> Да. В твоей грамотности. Йода мастер учитель его был.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от анонимус (??), 08-Июн-22, 18:25
	Какое масло, друг? Ты что-то вообще не в ту степь пошел.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	110. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (108), 08-Июн-22, 19:46
	Как какое? Пальмовое.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (124), 08-Июн-22, 22:27
	Макбет недавно прочёл?
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	123. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (124), 08-Июн-22, 22:21
	> Но ты ровно это и написал. Тут даже и думать не надо. Достаточно уметь читать. Нет не достаточно. Нужно знать грамматику. Сравни: Android - GNU не содержащий Linux. Android - GNU, не содержащий Linux.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	33. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+5 +/–
	Сообщение от n00by (ok), 08-Июн-22, 12:36
	Бывает systemd-boot... А-А-А-А куда вы меня тащи
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	174. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (182), 09-Июн-22, 19:40
	ШОК! Можно загрузить systemd прямо из UEFI firmware в обход... большой текст свёрнут, показать
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (5), 08-Июн-22, 11:59
	>>> Почему фанаты <<< Это уже не фанаты, а сектанты:), - просто не обращайте внимания!
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	23. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от тоже Аноним (ok), 08-Июн-22, 12:01
	> любой Linux, это GNU/Linux Незачет и по матчасти, и по пунктуации.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	28. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (30), 08-Июн-22, 12:14
	Потому, что Linux это только ядро.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	37. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 08-Июн-22, 12:44
	А документация, инструментарий сборки, включая gnu bash-скрипты с gnu makefile'ами, утилиты пространства пользователя?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (40), 08-Июн-22, 12:47
	Чувак, если ChromeOS собирается на Gentoo оно становится ChromeOS/Gnu? Пара утилит ничего не меняет. Скрипты можно и на Fish запускать и на ZSH (внезапно), да хоть на KSH. Плевать абсолютно на чем запускать. Разфаначивайся уже.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 08-Июн-22, 13:04
	> Чувак, если ChromeOS собирается на Gentoo оно становится ChromeOS/Gnu? Неправильный вопрос. Linux собираетcя и работает в GNU-окружении. > Скрипты можно и на Fish запускать и на ZSH (внезапно), да хоть на KSH. Это в последнее время начали портировать скрипты на posix shell (к слову, fish не posix-shell), но все равно для _штатной_ сборки нужен именно gnu bash. Точно также нужен gcc. И gnu make. И gnu coreutils.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (46), 08-Июн-22, 13:22
	GNU это операционная система, если ваша ОС называется ChromeOS то это не GNU очевидно.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	73. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (11), 08-Июн-22, 14:46
	Chrome OS это GNU/ содержащий продукт, в отличие от Android который GNU/ не содержащий продукт.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (40), 08-Июн-22, 12:44
	Для фанатиков нет musl версии Linux без GNUтых утилит поттому что они ими не пользуются. Вон даже ядро можно с Clang собирать, но они будут упорно втирать всем про GNU.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	42. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (5), 08-Июн-22, 12:49
	Вот же время летит! А ведь когда-то про линукс ходил бородатый анектот: linux написан не на C, а на gcc:)
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от warlock (??), 08-Июн-22, 15:47
	Ну тут больше заслуга clang, который поддерживает чуть ли не все расширения GCC, чем кода ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 08-Июн-22, 15:58
	ПроGNUлись?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от warlock (??), 08-Июн-22, 16:21
	Расширения GNU не просто так появились. Решаемые ими проблемы нужно решать любому промышленному компилятору. А выдумывать для их этого новый несовместимый синтаксис, когда уже есть синтаксис gcc, нет никакого смысла.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (10), 09-Июн-22, 12:08
	> А выдумывать ...,  когда уже есть ..., нет никакого смысла. Clang не нужен?
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от warlock (??), 09-Июн-22, 13:01
	> Clang не нужен? Очень нужен: во-первых, другая архитектура, во-вторых лицензия. Конкуренция опять же.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 10-Июн-22, 00:00
	Да уж. Где еще увидишь .so весом 65 мегабайтов? Архитектура монументальна.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (108), 08-Июн-22, 19:53
	А что, не может быть дистра Linux одновременно с Musl и GNU Coreutils + Bash?
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	44. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (11), 08-Июн-22, 12:59
	К тому же Гига-Ричард Столлман обижается когда забывают добавлять GNU к Linux, GNU к Grub2. А мне не жалко.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	52. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	–1 +/–
	Сообщение от Аноним (46), 08-Июн-22, 13:23
	Ты всё перепутал, GNU/Linux это операционная система, а к Linux дописывать GNU не нужно, это не проект GNU, а отдельное ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+4 +/–
	Сообщение от Аноним (11), 08-Июн-22, 13:31
	Linux-ом называть можно и GNU/Linux и GNU-free/Linux дистрибутивы. Но если мы говорит конкретно про GNU-содержащий продукт, то почему не акцентировать на этом?  На том что Grub2 это GNU содержащий продукт не делают акцент потому что это подразумевается по умолчанию, потому что не существует GNU не содержащего Grub2.
	Ответить | Правка | Наверх | Cообщить модератору

36. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от Аноним (40), 08-Июн-22, 12:42
Наконец-то на анально огороженных устройствах можно запускать Gentoo без заморочек с подписью ядра и т.п.! Долой шиндошс рабство!
Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Попандопала (?), 08-Июн-22, 13:16
	Видел устройство где послетали серийники и там в UEFI было написано S N N/A из-за корявой прошивки ХЗ знает чем и не надо нчего было там подписывать. Винду только не активировать нормально,а так гуд.D
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от nebularia (ok), 08-Июн-22, 20:19
	И так можно было, либо отключив валидацию, либо запустив после shim обычный GRUB без цифровой подписи. Оба способа требуют маленько действий руками (что логично, т.к. не позволяет незаметно обойти Secure Boot), но потом мешаться не будет
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	118. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Попандопала (?), 08-Июн-22, 21:20
	ХЗ. я на Ютупе видел это. За что купил,за то и продаю.D
	Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от Аноним (56), 08-Июн-22, 13:33
не уязвимости а возможности!
Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	–2 +/–
Сообщение от ИмяХ (?), 08-Июн-22, 13:36
>>дистрибутивам придётся сформировать А пока они не сформируют, тысячи и тысячи вирусов будут сидеть в прошивках линyкcoидовских компьютеров.
Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от microsoft (?), 08-Июн-22, 13:41
	Поздравляю, у тебя cpu и мост с бэкдорами и вирусами. Твой ring -2, -1. Наслаждайся.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 08-Июн-22, 14:50
	Дядя Микрософт, а Вы только всякие дырявые shim'ы подписываете своими подписями?
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от microsoft (?), 08-Июн-22, 19:18
	Нет, не только. А так же тем, кто как надо нагнулся, и ручку нам пожал.
	Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от Аноним (32), 08-Июн-22, 13:39
Дырявый Secure Boot, но уязвимость в GRUB. Нормально.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+2 +/–
Сообщение от microsoft (?), 08-Июн-22, 13:39
Ага... это усе у ваш проклятый грубе виноват.. что наш uefi secure не такой секюр как надо!
Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от Аноним (95), 08-Июн-22, 13:48
>позволяющие обойти UEFI Secure Boot Казалось бы, отличная новость!
Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+3 +/–
Сообщение от Аноним (-), 08-Июн-22, 13:57
Butthole2. М-да уж.
Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от Аноним (69), 08-Июн-22, 14:09
> UEFI Не было у бабы хлопот, купила баба порося.
Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от Аноним (97), 08-Июн-22, 18:44
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?
Ответить | Правка | Наверх | Cообщить модератору

	172. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (62), 09-Июн-22, 18:16
	yankee go home
	Ответить | Правка | Наверх | Cообщить модератору

102. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+2 +/–
Сообщение от saahriktu (ok), 08-Июн-22, 19:11
Secure Boot ненужен. Я в своё время подписывал петицию от проекта GNU, где подписавшиеся обещали никогда не юзать железо с неотключаемым Secure Boot'ом. Были опасения, что таким образом Microsoft пытается ограничить загрузку других ОС. Но потом Microsoft всё-таки стал делиться ключами для подписывания ядер Linux'а. Хотя сам момент, что без ключей от Microsoft'а конструкция не работает, - это ещё тот троянский конь.
Ответить | Правка | Наверх | Cообщить модератору

	161. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (159), 09-Июн-22, 15:26
	Intel Boot Guard и UEFI Secure Boot очень хорошие и нужные технологии. НО! Вы должны покупать только "девственное" железо которое разрешает пользователь устанавливать свои ключи для Inrel boot guard и UEFI Secure Boot. Да, если производитель установил ключ Intel boot guard и свои ключи UEFI Secure Boot то пользователь не владелец компа, а цифровой раб. Будет запускать ОС только с разрешения хозяина. Не покупайте железо с установленными ключами Intel Boot Guard и без штатной возможности смены всех ключей UEFI Secure Boot.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Michael Shigorin (ok), 10-Июн-22, 14:09
	> Не покупайте железо с установленными ключами Intel Boot Guard http://imaxai.ru :)
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Michael Shigorin (ok), 10-Июн-22, 14:07
	> Были опасения, что таким образом Microsoft пытается ограничить загрузку других ОС. Как делавший поддержку UEFI и совместимость с секирбутом в альте -- подтверждаю: все эти игрища в "UEFI CA" и нюансы (вплоть до неожиданного возврата к "x32" для некоторых атомов) очень сильно напоминали типовые попытки "сдерживания", когда в лобовую идти страшно, но напакостить хочется. > Хотя сам момент, что без ключей от Microsoft'а конструкция не работает, > - это ещё тот троянский конь. Теоретически работает (если соответствующие пути исполнения кода для конкретной прошивки вообще хоть кем-то тестировались), практически же скорее не применяется -- never underestimate the power of the default, как значилось у одного старого знакомого в ~/.signature
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

114. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
Сообщение от yet another anonymous (?), 08-Июн-22, 20:23
Одновременное использование UEFI Secure Boot и grub выглядит странно, избыточно и проблемно. У UEFI Secure Boot процедура ещё и стрёмная, плохо документированная и имеет вариации в разных реализациях, т.е. можно и окирпичить устройство.
Ответить | Правка | Наверх | Cообщить модератору

	160. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	–2 +/–
	Сообщение от Аноним (159), 09-Июн-22, 15:18
	> Одновременное использование UEFI Secure Boot и grub выглядит странно, избыточно и проблемно. Странно выглядишь здесь ты. Для сертифицированной загрузки OS необходима следующая цепочька: 1. Intel Boot Guard 2. UEFI Secure Boot 3. GRUB с check_signatures=enforce 4. Linux с IMA/EVM В старых системах вместо первых 3 пунктов использовался TPM.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (-), 10-Июн-22, 00:05
	> 1. Intel Boot Guard И мы поверим Intel и OEM что они белые и пушистые. Потому что свои ключи и код вписать ТУДА "почему-то" не дадут. Добрый белый человек как обычно подогнал тифозное одеяло. > 2. UEFI Secure Boot Только если оттуда можно вытряхнуть ВСЕ ключи интелов/майкрософтов и прочих никак не связанных с пользователей самоназначенных ауторити метящих в жандармы планеты. Что не факт. > 4. Linux с IMA/EVM Еще нехило kernel lockdown активировать. Иначе, видите ли, имеючи права рута я прекрасно отпатчу вам что угодно сходив по физическим адресам оперативки. После этого IMA и EVM пойдет лесом. Вы ж не будете в рантайм состояние кернела постоянно чекать? Хотя отдельные секурити маньяки это пытаются, что прикольно и похвально но опять же - проверяющего тоже можно пропатчить.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от yet another anonymous (?), 10-Июн-22, 07:07
	Вот если сударь соизволил бы раскрыть для широкой аудитории цель, которая достигается по каждой из строчке вышеупомянутой "цепочЬки", то странность и избыточность были уже видны. А если ещё добавить то, чего сделать будет нельзя --- то и проблемность вылезет. На что вам тут (чуть выше) и указали.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

	205. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Michael Shigorin (ok), 10-Июн-22, 14:10
	> Для сертифицированной загрузки OS необходима следующая цепочька: Нет.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

121. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от Аноним (121), 08-Июн-22, 21:28
Интересно узнать % компьютеров на линуксе со включённой unSecure Boot
Ответить | Правка | Наверх | Cообщить модератору

126. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+2 +/–
Сообщение от Нн (?), 08-Июн-22, 22:37
SBAT разработан совместно с Microsoft. Троянский конь. Ждем когда ефи закопают, и вместе с ним и x86
Ответить | Правка | Наверх | Cообщить модератору

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

	147. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 09-Июн-22, 11:20
	Хаха, а ведь ты прав - главное ведь что паники нет! Зачет))
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

179. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от Аноним (179), 09-Июн-22, 20:18
> SecureBoot А зачем вообще нужен этот cockcage? Чтобы работало только то, что разрешил ональный доминатор? Против UEFI ничего не имею, хорошая штука.
Ответить | Правка | Наверх | Cообщить модератору

180. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от Онаним (?), 09-Июн-22, 20:22
Вот зачем секуребут? Все, кто хочет - все ... ломают.
Ответить | Правка | Наверх | Cообщить модератору

183. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от darkshvein (ok), 09-Июн-22, 23:31
о да. давайте, поработаем на майрософт. защит им уефи!
Ответить | Правка | Наверх | Cообщить модератору

	192. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+1 +/–
	Сообщение от Аноним (-), 10-Июн-22, 00:06
	> о да. давайте, поработаем на майрософт. > защит им уефи! А потом они на двоих с wintel нас с наших же компьютеров и попрут нашим же кодом. Секурно. Приятные перспективы.
	Ответить | Правка | Наверх | Cообщить модератору

194. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от Аноним (194), 10-Июн-22, 02:40
Хотя бы один нормальный человек использует Secure boot?
Ответить | Правка | Наверх | Cообщить модератору

	199. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от Аноним (-), 10-Июн-22, 10:34
	Как "эксперт" по статистике скажу, нет нормального человека, а вот медианный есть, о как!
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
	Сообщение от onanim (?), 11-Июн-22, 18:32
	если под "нормальными" понимать именно адекватных людей, понимающих, как работает их компьютер, и немного разбирающихся в информационной безопасности - да, использует. но по быстрому просмотру треда по диагонали очевидно, что опеннет постепенно становится хабром.
	Ответить | Правка | К родителю #194 | Наверх | Cообщить модератору

206. "Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot "	+/–
Сообщение от onanim (?), 11-Июн-22, 18:29
тред не читал. для тех, кто понимает важность и нужность Secure Boot - обратите внимание на github.com/noahbliss/mortar - возможность запускать подписанное ядро напрямую из UEFI без использования GRUB. а в GRUB вообще намеренно сломана поддержка Secure Boot, то ли саботаж, то ли халатность: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906124
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема