Открыть список
Как стать автором
Обновить

Комментарии 9

А почему на КДПВ GRUB, но не GRUB2 (нет, это не разные версии одного загрузчика… ну, то есть, разные версии одного загрузчика, но настолько разные, что проще их рассматривать как два разных загрузчика)?
Вы предъявляете слишком высокие требования к редактору хабра. Написано же на картинке GRUB? Значит, картинка подходит! А там кто их разберёт, все эти ваши версии…
тем более, что grub2 настолько давно стал дефакто, а grub1 настолько давно стал легаси, что под grub часто подразумевается именно grub 2.

и как это оправдывает использование скриншота grub1 в качестве иллюстрации к статье про grub2?!?

Да легко. Смотришь кто автор и видишь, что это не разработчик и не системный администратор, а «хабраредактор». Поэтому если в названии grub и на скриншоте grub, то это отлично, что там не скриншот от fdisk, например.
С тем же успехом можно рассуждать в стиле «Скриншот же с компьютера? Уже хорошо»
Все познается в сравнении.
Могла быть и рисованная от руки картинка с троллейбусов из буханки хлеба.
Ожидается, что Microsoft выпустит обновленный файл отзыва UEFI для устранения уязвимостей.

Либо «помоги себе сам»: небольшой PS-скрипт
#Requires -RunAsAdministrator

$SplitDbxContent= $PSScriptRoot+"\SplitDbxContent.ps1"

Start-Process -FilePath "curl" -ArgumentList "https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin","--output dbxupdate_x64.bin" -NoNewWindow -Wait
&$SplitDbxContent dbxupdate_x64.bin
Set-SecureBootUefi -Name dbx -ContentFilePath .\content.bin -SignedFilePath .\signature.p7 -Time 2010-03-06T19:17:21Z -AppendWrite
Remove-Item signature.p7, content.bin, dbxupdate_x64.bin

SplitDbxContent.ps1 это модуль SplitDbxContent
dbxupdate_x64.bin это UEFI Revocation List File, содержащий хэши загрузчиков, которые запрещено загружать. Правда, он в последний раз обновлялся в октябре прошлого года.

Как только будут забанены уязвимые версии GRUB2, старые сборки дистрибутивов Linux уже невозможно будет запустить без отключения SecureBoot (и это правильно).

Также, в GRUB2 уже реализовали поддержку UEFI Secure Boot Advanced Targeting, которая позволит в будущем в таких ситуациях не переподписывать ядро, shim и сам GRUB2.

Летом 2020 у Redhat уже был факап с обновлением GRUB, крайне не хотелось бы снова наступить на эти же грабли

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