The OpenNET Project / Index page

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



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

Оглавление

Критическая уязвимость в загрузчике GRUB2, позволяющая обойти UEFI Secure Boot, opennews (?), 30-Июл-20, (0) [смотреть все]

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


59. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от Аноним (59), 30-Июл-20, 08:52 
MBR не умеет в GPT, не умеет больше 4 физических разделов, не умеет разделы > 2Тб
EFI/UEFI это хорошо, а вот SecureBoot плохо
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

63. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (60), 30-Июл-20, 08:59 
не MBR не умеет, а отвратительные недостаточно модульные биосы, сделанные с расчётом на запланированное устаревание.
Ответить | Правка | Наверх | Cообщить модератору

83. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (81), 30-Июл-20, 09:45 
Ставь GPT и малюсенький раздел для BIOS GRUB, перед разделом /boot и все у тебя будет работать без ограничений.

SecureBoot это необходимая технология в цепочке верификации загрузки компьютера. Она нужна для проверки целостности и аутентичность загрузчика OS.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

84. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от aa (?), 30-Июл-20, 09:51 
>MBR не умеет в GPT

добавить поддержку никто не мешает - это всего лишь прочитать пару секторов

>, не умеет больше 4 физических разделов

во-первых что такое "физический раздел"? физически на диске разделы не создаются, бывают только логические
во-вторых не умеет как раз таки досовская таблица разделов, а в первом пункте мы уже добавили поддержку гпт

>, не умеет разделы > 2Тб

см п.2

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

101. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от kkk (??), 30-Июл-20, 11:35 
1. GPT - это раздутая и искуственно усложнённая система разделения диска.

2. Больше 4-х основных разделов мало кому нужно. Но даже если нужно, то есть:
  А. Варианты MBR с поддержкой большего числа основных разлелов
  Б. Extended Partition, внутри которого можно насоздовать сколько угодно логических разделов

3. Partition entry в MBR имеет размер в 16 байт, которые просто используются неэффективно. Смотри сам:

1 byte - статус раздела (реально используется лишь один бит - признак того, что раздел загрузочный)
3 bytes - CHR адрес начала раздела
1 byte - тип раздела
3 bytes - CHR адрес конца раздела
4 bytes - LBA адрес начала раздела
4 bytes - LBA размер раздела

CHR давно никто не использует и эти две записи, по три байта каждая, можно использовать для расширения разрядности LBA записей. Там даже место останется, поскольку для современных LBA достаточно 48 бит. Признак расширения можно хранить в первой записе статуса раздела. Этот же признак защитит от неправильного восприятия нового формата partition entry старыми программами. Для них статус раздела, отличный от 0x00 и 0x80 - это невалидный раздел.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

119. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от kmeaw (?), 30-Июл-20, 12:35 
GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать разделы, не залезая в структуры fs, которые могут быть неизвестны системе (например в случае, если раздел неизвестной хосту ОС прокидывается внутрь виртуальной машины), или когда ОС и прошивка видят диски в разном порядке, что неудивительно, учитывая количество интерфейсов, через которые их можно подключить. Ещё разделам можно давать человекочитаемые имена. И partition type в MBR размером в один байт уже как-то мало (Linux Swap vs Solaris).

GPT имеет две копии, в начале и в конце диска, что удобно для восстановления данных после ошибки пользователя.

GPT удобно использовать на EFI-системах — нет больше проблем с многостадийной загрузкой IPL->bootsector->stage1(\.5)?->stage2. Можно просто положить файл (с максимальным размером аж в 2G) на ESP, и прошивка его загрузит. Не надо никуда записывать загрузочные сектора, с файлами работать гораздо проще. И писать код загрузчика стало проще, никакого больше real mode с подготовкой таблиц и переключением в protected mode, а потом проблем с доступом к диску.

Для совсем простых сценариев можно обойтись вообще без разметки диска — создать файловую систему (или даже LVM) прямо на /dev/sda. А весь загрузочный код унести в прошивку.

Ответить | Правка | Наверх | Cообщить модератору

125. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от kkk (??), 30-Июл-20, 13:25 
Что ты понимаешь под "однозначно идентифицировать разделы"? В MBR ты знаешь всё, что тебе необходимо знать для разделения диска на разделы и старта системы. Как именно их монтировать или как они называются к MBR не относится, является избыточной и дублируемой информацией, которую придётся постоянно синхронизировать с тем, что знает OS или сами эти разделы.

Проблема многостадийной загрузки - это проблема конкретной файловой системы. Зачем городить огород с EFI программами и специальным разделом, для их хранения, когда можно загрузить код загрузчика из специально указанной области самой файловой системы? Почему код загрузчика привязан к вендору и сидит в прошиве, а не выбирается мной и сидит на диске? Прошивка должна максимум спрашивать какой раздел загружать, если, скажем, несколько разделов помечены загрузочными. Да и кроме как для пользователей нескольких OS на одном компьютере в дуалбуте это никому не нужно.

Ответить | Правка | Наверх | Cообщить модератору

149. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от kmeaw (?), 30-Июл-20, 15:36 
> Что ты понимаешь под "однозначно идентифицировать разделы"? В MBR ты знаешь всё, что тебе необходимо знать для разделения диска на разделы и старта системы.

После того, как система запустилась, ей может быть нужно найти раздел на диске. Например в сценарии, когда я выделил раздел для виртуальной машины на своём диске, и хочу запустить qemu, мне надо что-то написать в -drive file=/dev/sda4. Как мне найти этот sda4?

> Проблема многостадийной загрузки - это проблема конкретной файловой системы.

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

> Прошивка должна максимум спрашивать какой раздел загружать, если, скажем, несколько разделов помечены загрузочными.

В случае с EFI всё равно так и есть. Можно позвать boot menu, и тогда на экране появится список всех разделов, где есть файл EFI/BOOT/bootx64.efi.

> Да и кроме как для пользователей нескольких OS на одном компьютере в дуалбуте это никому не нужно.

При апгрейде компьютера я хочу просто скопировать все файлы с одного диска на другой, а не возиться с переносом структур, нужных для запуска загрузчика. В случае с GPT+UEFI достаточно создать два раздела: ESP и раздел с данными, после чего скопировать пофайлово (rsync -aHAXx) из источника.

Если дуалбут не нужен, и хочется минимализма без EFI, то можно и от MBR-разметки избавится. Но если разделы всё-таки нужны, то ИМХО от GPT больше пользы.

Ответить | Правка | Наверх | Cообщить модератору

159. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от kkk (??), 30-Июл-20, 16:29 
> После того, как система запустилась, ей может быть нужно найти раздел на диске. Например в сценарии, когда я выделил раздел для виртуальной машины на своём диске, и хочу запустить qemu, мне надо что-то написать в -drive file=/dev/sda4. Как мне найти этот sda4?

Разве Linux до сих пор не умеет находить /dev/sda4? Как он вообще работал всё это время?

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

Boot code внутри MBR вообще не предназначен для загрузки операционной системы. Он необходим лишь для того, чтобы загрузить загрузчик из раздела, помеченного как active. Дальше должен работать другой код, специфичной для файловой и операционной системы, которые там установлены. Прошивка BIOS/UEFI/etc. не должна диктовать как это должно дальше работать, это просто не её дело.

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

Даже древний DOS так умеет. Почему Linux до сих пор не научился? Почему вместо решения настоящей проблемы нам навязывают UEFI, GPT и Secure Boot?

Ответить | Правка | Наверх | Cообщить модератору

169. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от пох. (?), 30-Июл-20, 17:30 
> Даже древний DOS так умеет. Почему Linux до сих пор не научился?

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

Древний дос так не умеет, в нем была команда sys и format/s - и не просто так. Вам могло случайно повезти с копированием - надо было чтобы первые файлики поблочно легли в фиксированные секторы диска - этого при незамысловатости той fs и однозадачной системе кое-как можно было добиться без специальных команд, но могло и нет.

> Почему вместо решения настоящей проблемы нам навязывают UEFI, GPT и Secure

потому что uefi таки _решает_ проблему без необходимости фиксировать блжад, _логические_секторы_ ядра системы (и потом еще и читать их через апи 80го года - ломающийся на больших дисках или на недисках вообще, которых в 80м году еще вообразить не могли) - что было приемлемо во времена дос, но нихрена не выглядит разумно в XXI веке. И файлы можно просто класть в efi-раздел в любом порядке и любыми инструментами - они читаются как файлы, а не набор гвоздем прибитых секторов.
GPT - решает проблему что у современного диска нет никаких доступных загрузчику "головок", "дорожек" и так далее, а есть логический номер сектора, изрядно превосходящий возможности 16битных процессоров, для которых писали древнюю досовую partition table (попутно там еще предусмотрена некоторая дополнительная надежность, уменьшающая шанс искать потом по всему диску границы разделов из-за неудачно записавшегося одного сектора - современные диски немного долго это будут делать), да и разделов в нем может быть поболее четырех.

К сожалению, ваше старческое слабоумие мешает вам в этом разобраться, поэтому такие сложные вещи как secureboot вам лучше даже не пытаться понять.

Ответить | Правка | Наверх | Cообщить модератору

179. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 30-Июл-20, 20:43 
> дедушка, вы таблетку от склероза забыли принять. Если сожрали вместо нее эклер - он не помогает.

Типичный напыщенный хам. Это ты таблетку забыл принять.

> Древний дос так не умеет, в нем была команда sys и format/s - и не просто так. Вам могло случайно повезти с копированием - надо было чтобы первые файлики поблочно легли в фиксированные секторы диска - этого при незамысловатости той fs и однозадачной системе кое-как можно было добиться без специальных команд, но могло и нет.

Ты глуп и невежественен. В бутсекторе даже DOS дискеты есть код, ищущий конкретные файлы по именам, а не на фиксированных секторах.

> потому что uefi таки _решает_ проблему без необходимости фиксировать блжад, _логические_секторы_ ядра системы (и потом еще и читать их через апи 80го года - ломающийся на больших дисках или на недисках вообще, которых в 80м году еще вообразить не могли) - что было приемлемо во времена дос, но нихрена не выглядит разумно в XXI веке.

Откуда ты такой вылупился? int 13h в BIOS был расширен до 64 бит, что даже больше 48-бит LBA, в далёком 1995 году. Выдыхай, невежда!

> GPT - решает проблему что у современного диска нет никаких доступных загрузчику "головок", "дорожек" и так далее, а есть логический номер сектора, изрядно превосходящий возможности 16битных процессоров, для которых писали древнюю досовую partition table

И снова в лужу, невежда! MBR давно использует LBA, а CHR в нём не используется. Ты даже не потрудился прочесть описание partition record, которое я дал выше.

> К сожалению, ваше старческое слабоумие мешает вам в этом разобраться, поэтому такие сложные вещи как secureboot вам лучше даже не пытаться понять.

К сожалению ты просто дурак.

Ответить | Правка | Наверх | Cообщить модератору

180. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 30-Июл-20, 20:53 
> Ты глуп и невежественен. В бутсекторе даже DOS дискеты есть код, ищущий конкретные файлы по
> именам

лол.
Дальше можешь не продолжать.

Дос ты видел только в ютубчике, а описание партишнрекорд - "читал", ага. Жаль не понял.

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

Ответить | Правка | Наверх | Cообщить модератору

221. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (221), 31-Июл-20, 11:38 
Эм, по-моему бутсектор логического диска (не партишна) искал нечто типа IO.SYS или MSDOS.SYS? А оно потом - командкома уже.
Ответить | Правка | Наверх | Cообщить модератору

249. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 31-Июл-20, 19:22 
Да, именно так. А никак не на специальные секторах диска. Именно поэтому IO.SYS MSDOS.SYS и COMMAND.COM можно было копировать в корень руками, хоть на пустой диск, хоть на не очень, в любом порядке. Имена этих файлов видны даже без дизассемблирования просто в дампе бутсектора FAT.
Ответить | Правка | Наверх | Cообщить модератору

265. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 01-Авг-20, 10:25 
> Эм, по-моему бутсектор логического диска (не партишна) искал нечто типа IO.SYS

да ничего он не "искал", в нем за вычетом bpb места еще меньше чем в mbr, и того половина занята выводом юзерфрендли сообщения "not a dos disk, replace user and press anykey". (заметь, в груб даже такое не поместилось) Тупо сравнивал несколько байтиков по фиксированному адресу, а потом по другому адресу подряд несколько секторов читал. Поэтому байтики и секторы должны были находиться строго там, где он их рассчитывал увидеть.
Это только местный клоун может думать, что туда драйвер файловой системы мог поместиться.

grub и lilo заметь, попродвинутей будут - в них blocklist записан, а не гвоздем прибит. Правда, из-за этого уже даже на такое "юзерфрендли" не осталось места, гадай на первых буковках, почему оно вдруг повисло.

> MSDOS.SYS? А оно потом - командкома уже.

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

Ответить | Правка | К родителю #221 | Наверх | Cообщить модератору

273. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 01-Авг-20, 17:54 
Дурачок, когда же ты хотя бы просто посмотришь дамп бутсектора FAT? Я уже не говорю о том, чтобы попробовать скопировать три системных файла DOS на дискету, в любом порядке вмести с любыми другими файлами. Зачем ты так упорно несёшь откровенный бред?
Ответить | Правка | Наверх | Cообщить модератору

278. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 02-Авг-20, 16:28 
> Дурачок, когда же ты хотя бы просто посмотришь дамп бутсектора FAT?

ты свой ник не в то поле вписал. "дамп бутсектора" лолшта - FAT? Отлично, просто прекрасно.

> Я уже не говорю о том, чтобы попробовать скопировать три системных файла DOS на дискету, в любом
> порядке вмести с любыми другими файлами.

ну так попробуй, и убедись что не работает.
Именно так как ты описал - "в любом порядке и вместе с другими файлами" - нет. Например, сначала command.com, потом msdos.sys, потом удалить смеху ради command.com - и скопировать io.sys а потом заново command.com (кто, в отличие от тебя не "дамп посмотрел", а знает как оно устроено - поймет, в чем фишка)

Это будет нормальный fat, нормальные файлы (их даже можно cнова скопировать уже единственноправильным образом на другой носитель, и он загрузится), только не загрузится. Причем не выдаст ошибку, а повиснет.

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

Ответить | Правка | К родителю #273 | Наверх | Cообщить модератору

286. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 03-Авг-20, 09:27 
> "дамп бутсектора" лолшта - FAT?

Первый сектор файловой системы. Посмотри что написано в первом секторе, дурачок.

> ну так попробуй, и убедись что не работает.

Пробовал неоднократно, работает.

> Именно так как ты описал - "в любом порядке и вместе с другими файлами" - нет. Например, сначала command.com, потом msdos.sys, потом удалить смеху ради command.com - и скопировать io.sys а потом заново command.com

Снова специально для тебя:
https://www.youtube.com/watch?v=mk5Z2aX9kWE

> кто, в отличие от тебя не "дамп посмотрел", а знает как оно устроено - поймет, в чем фишка

В отличии от меня ты НЕ ЗНАЕШЬ как оно работает.

> Это будет нормальный fat, нормальные файлы (их даже можно cнова скопировать уже единственноправильным образом на другой носитель, и он загрузится), только не загрузится. Причем не выдаст ошибку, а повиснет.

Ты снова сел в лужу, дурачок :-))

Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

248. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 31-Июл-20, 19:18 
Это ты DOS никогда не видел и даже не потрудился проверить то, что тебе говорят. Типичный напыщенный идиот.
Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

274. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 01-Авг-20, 19:44 
Специально для тебя:

https://www.youtube.com/watch?v=V5tMCTOcg8k

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

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

172. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от Sarcastic scutosaurus (?), 30-Июл-20, 17:32 
> Разве Linux до сих пор не умеет находить /dev/sda4?

Замечательно умеет. Только при очередной перезагрузке это может оказаться раздел совсем другого диска.

> Даже древний DOS так умеет. Почему Linux до сих пор не научился?

Все беды оттого, что нет диска C:. Был бы диск C: — жили бы и горя не знали.

Ответить | Правка | К родителю #159 | Наверх | Cообщить модератору

184. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 20:56 
>Замечательно умеет. Только при очередной перезагрузке это может оказаться раздел совсем другого диска.

Ты вменяемый?

Ответить | Правка | Наверх | Cообщить модератору

187. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Sarcastic scutosaurus (?), 30-Июл-20, 21:24 
Не знаю, давно не проверялся. А что?
Или ты просто не в курсе, что инициализация контроллеров в ядре происходит параллельно, так что в зависимости от того, какой проинициализируется раньше, диски sda и sdb (условно) могут внезапно поменяться местами?
Ответить | Правка | Наверх | Cообщить модератору

191. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 22:08 
> Не знаю, давно не проверялся. А что?
> Или ты просто не в курсе, что инициализация контроллеров в ядре происходит
> параллельно, так что в зависимости от того, какой проинициализируется раньше, диски
> sda и sdb (условно) могут внезапно поменяться местами?

Т. е. про UUID ты не в курсе?

Ответить | Правка | Наверх | Cообщить модератору

242. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от Sarcastic scutosaurus (?), 31-Июл-20, 16:34 
UUID чего? У раздела в случае msdos-разметки нет никакого UUID. Они могут быть у чего-то на разделе, типа файловой системы. А теперь поднимись по треду и почитай сообщения, на которые я отвечал.
Ответить | Правка | Наверх | Cообщить модератору

244. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от AlexYeCu_not_logged (?), 31-Июл-20, 18:18 
> UUID чего? У раздела в случае msdos-разметки нет никакого UUID. Они могут
> быть у чего-то на разделе, типа файловой системы. А теперь поднимись
> по треду и почитай сообщения, на которые я отвечал.

Ну почитал. у гражданина какие-то невнятные проблемы с поиском раздела sdx: он хочет писать именно sdx и никак иначе, вывода blkid он в жизни не видел. Ты утверждаешь, что sdx при каждой перезагрузке разный. Допустим. Но! Я смотрю в fstab — вижу UUID. Смотрю в grub.cfg — вижу UUID. То, что он «у чего-нибудь типа файловой системы» не особо важно: я в любом случае могу его получить на вменяемой системе (подсказка: на той, что « без диска C»). Так в чём проблема-то? В какой гипотетической ситуации это может сыграть?

Ответить | Правка | Наверх | Cообщить модератору

246. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Sarcastic scutosaurus (?), 31-Июл-20, 18:37 
> у гражданина какие-то невнятные проблемы с поиском раздела sdx: он хочет писать именно sdx и никак иначе, вывода blkid он в жизни не видел.

Проблема описана вполне внятно: на разделе может быть нечто, не идентифицируемое ядром и, соответственно, никакого UUID прочитано не будет, даже если он там есть. При использовании GPT раздел имеет UUID (или GUID, как его клятый M$ называет) независимо от содержимого.

> Ты утверждаешь, что sdx при каждой перезагрузке разный.

Ну, положим, не при каждой, а если все диски подключены к одному контроллеру, такого и вовсе не произойдёт, но всё же это случается.

Ответить | Правка | К родителю #244 | Наверх | Cообщить модератору

266. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от пох. (?), 01-Авг-20, 10:39 
>> Ты утверждаешь, что sdx при каждой перезагрузке разный.
> Ну, положим, не при каждой, а если все диски подключены к одному

ну могу тебе показать машину, где именно при каждой, угадай где у нас сегодня диски (затрахало преизрядно, ну ЧТО мешало дятлам научиться читать вместо этого бреда человекочитаемые labels? Они ж блжад - ЕСТЬ!  А, ну да, ну да - "как в венде, только НАХАЛЯВУ и побольше!")

> контроллеру, такого и вовсе не произойдёт, но всё же это случается.

а "контроллер" называется fc switch ;-) От какого из его хвостов миллисекундой раньше прилетит заголовок, тот первым и будет. А поскольку еще и старт асинхронный, то даже если есть еще и локальные диски - никогда не угадаешь, они до fc'шных окажутся или после.

Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

269. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 01-Авг-20, 12:12 
> ну ЧТО мешало дятлам научиться читать вместо этого бреда человекочитаемые labels? Они ж блжад - ЕСТЬ!

И в чём у тебя проблема с лейблами? Хоть руками mount -L делай, хоть в fstab их прописывай, хоть в командную строку ядра — отовсюду подхватятся. Только полагаться на них лично я бы не стал: воткнёт тебе кто-то незаметно флешку с лейблом TMP, потом выдернет и будет изучать, что на ней интересного осело. Или интереснее — с лейблом BOOT…

Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

277. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 02-Авг-20, 16:19 
> И в чём у тебя проблема с лейблами? Хоть руками mount -L делай

то что ты даже не понял, о каких лейблах речь.

Ответить | Правка | К родителю #269 | Наверх | Cообщить модератору

279. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 02-Авг-20, 20:21 
Заинтриговал.
Ответить | Правка | К родителю #277 | Наверх | Cообщить модератору

292. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 04-Авг-20, 03:11 
> Заинтриговал.

не, сам запутался - -L это именно оно, partition label (в отличие от LABEL=, который доступен только если fs вообще уже удалось как-то угадать и распарсить, поскольку он лежит внутри нее и в ей одной ведомом месте - как и почему-то горячо любимый всеми UUID= )

Жаль что в fstab их пихать некуда (в линуксный, у других есть варианты). Впрочем, все равно он немодный.

Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

295. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 04-Авг-20, 22:45 
> не, сам запутался - -L это именно оно, partition label (в отличие от LABEL=, который доступен только если fs вообще уже удалось как-то угадать и распарсить

Эээ… А где этот partition label лежать-то должен? В DOS disk label на каждый раздел всего 16 байт отведено, и все под другое заняты.

Ответить | Правка | К родителю #292 | Наверх | Cообщить модератору

297. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 05-Авг-20, 00:17 
> Эээ… А где этот partition label лежать-то должен?

в partition table, вестимо. Если она, конечно, GPT. Собственно, это одна из причин, почему хватит уже трахать мертвую бабушку доса, пора бы торжественно предать земле.
Правда, нормально пользоваться можно только во фре (бессмысленных и ненужных guid'ов там при этом даже не видно. Логично - чего на них смотреть, если ни запомнить, ни сравнить?)

Ответить | Правка | К родителю #295 | Наверх | Cообщить модератору

301. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 05-Авг-20, 23:01 
А, ты про GPT… Просто выше-то MBR обсуждали. Но и что в GPT можно имена разделам задавать — не знал. А для монтирования они, видимо, не используются, потому что не обязаны быть уникальными, в отличие от GUID/UUID. Если gdisk'ом делать, он по умолчанию обзовёт всё "Linux filesystem". Так себе идентификатор.
Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

305. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 06-Авг-20, 18:49 
> Но и что в GPT можно имена разделам задавать — не знал. А для монтирования они, видимо, не
> используются, потому что не обязаны быть уникальными, в отличие от GUID/UUID.

повторяю: в той _единственной_ реальной ситуации, когда на самом деле могут возникнуть эти проблемы - в систему воткнут диск от чужой системы - guid запросто оказывается тоже неуникальным, потому что это клон.

> Если gdisk'ом делать

отсутствие в линухе вменяемой замены для gpart - мы тут уже обсуждали, ну что ты хочешь от системы любителей синих окошечек и косплея винды? Они скосплеили древнюю досовскую утиль, которую когда-то только и застали, а на большее их фантазии не хватило. Да и ту не затянули в автоматику установки как следует, чтобы ей можно было сделать что-то разумное.

P.S. ты, кстати, тип раздела с меткой не путаешь? А то "Linux filesystem" очень похожа на тип, а не метку. Есть у microsoft такой ;-) Причем еще есть отдельный от него linux-lvm - старались.

Ответить | Правка | К родителю #301 | Наверх | Cообщить модератору

302. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 05-Авг-20, 23:04 
Впрочем, можно их при желании в fstab зафигачить. /dev/disk/by-partlabel/...
Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

303. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 06-Авг-20, 13:38 
> Впрочем, можно их при желании в fstab зафигачить. /dev/disk/by-partlabel/...

о, научились.
Но, похоже, это фича ядер после 4.какой-то, мое так не умеет и такого каталога нет вообще.


Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

304. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 06-Авг-20, 16:05 
На, дарю:

ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_NAME}=="?*", SYMLINK+="disk/by-partlabel/$env{ID_PART_ENTRY_NAME}"

Куда вставить, надеюсь, найдёшь.

Ответить | Правка | К родителю #303 | Наверх | Cообщить модератору

306. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от пох. (?), 06-Авг-20, 18:55 
> Куда вставить, надеюсь, найдёшь.

ты мне лучше найди куда вставить создание этих меток. Причем - динамическое. Причем где-то в районе firstboot или аналогов - поскольку система создается клонированием.
Собственно, я и на fs-labels согласен, только их нельзя поменять на примонтированной fs.
(для замены uuid есть специальный черезанусный апи, требующий, не много ни мало - специфических метаданных в fs)


Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

307. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 07-Авг-20, 11:41 
Э не, вот это уже только за деньги.
Ответить | Правка | К родителю #306 | Наверх | Cообщить модератору

293. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от пох. (?), 04-Авг-20, 03:18 
> И в чём у тебя проблема с лейблами? Хоть руками mount -L

то что в fstab вместо них автоматически записывается неведомая вредная херня?

> — отовсюду подхватятся. Только полагаться на них лично я бы не
> стал: воткнёт тебе кто-то незаметно флешку с лейблом TMP, потом выдернет

меня пока больше интересует что делать, если сделал dd if=/dev/sda of=/dev/sdb - и как теперь  распутать эту вермишель. Лично для меня это гораздо более реальный сценарий.
Учитывая что изменение uuid на подмонтированной fs - внезапно, нетривиальная задача, потребовавшая специфических патчей в ведре (кажется, в 3.x их еще нет ни в каких).

> и будет изучать, что на ней интересного осело. Или интереснее —
> с лейблом BOOT…

а он `hostname`.boot - и нихрена ты не угадал. А вот клонирование флэшки - куда более вероятная ситуация, и никакие бесполезно-uuid тут не помогают, только усложняют жизнь.

Ответить | Правка | К родителю #269 | Наверх | Cообщить модератору

296. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (102), 04-Авг-20, 22:50 
В случае с dd лейблы никак не помогут, с ними ровно такая же путаница будет.
Ответить | Правка | К родителю #293 | Наверх | Cообщить модератору

298. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от пох. (?), 05-Авг-20, 00:23 
> В случае с dd лейблы никак не помогут, с ними ровно такая

лэйблы помогут - тем что ты это увидишь и сможешь понять, где какой - если я сейчас поменял clone1 на clone2 - я не забуду это в момент редактирования fstab завтра.
А с guid через секунду будешь пялиться на бессмысленный набор знаков - "это тот который был, или который новый?" "вроде тот на 3afa начинался? Или нет?"

Поэтому и не нужны они ни для чего - ни уникальность не гарантируют, ни удобства не дают.

hostname.part в пределах локальной сети, кстати, дают и то и другое. Но дистрибутивоклепателей уже не остановить.


Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

251. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от kkk (??), 31-Июл-20, 19:50 
> Замечательно умеет. Только при очередной перезагрузке это может оказаться раздел совсем другого диска.

При наличии одного SATA контроллера с несколькими портами? Ты уверен?

Кроме того у тебя есть /dev/disk/by-path/ и /dev/disk/by-id/
То есть UUID снова не нужен.

И как ты запишешь UUID если не можешь идентифицировать чистый диск без него? Представь себе, что это новый или свежезабитый нулями диск. Никакого GPT на нём ещё нет.

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

182. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 20:55 
>Как мне найти этот sda4?

0_0. Эм, а вы вообще /etc/fstab видели когда-нибудь?

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

133. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –3 +/
Сообщение от Аноним (-), 30-Июл-20, 14:51 
> GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать

...всяких бакланов, подпихивая им небольшое персональное клеймо? :)

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

183. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 30-Июл-20, 20:55 
>> GPT хорош наличием GUID у диска и раздела. Это позволяет однозначно идентифицировать
> ...всяких бакланов, подпихивая им небольшое персональное клеймо? :)

не будь лохом, скопируй uuid у другого баклана!

(правда, потом будет немного обидно присесть за его cp)

Ответить | Правка | Наверх | Cообщить модератору

222. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (221), 31-Июл-20, 11:39 
> не будь лохом, скопируй uuid у другого баклана!

Ну, давай сюды свой :)

> (правда, потом будет немного обидно присесть за его cp)

Так зачем же CP копировать, толко гуид :)

Ответить | Правка | Наверх | Cообщить модератору

299. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от пох. (?), 05-Авг-20, 00:30 
>> не будь лохом, скопируй uuid у другого баклана!
> Ну, давай сюды свой :)

держи: e139ce78-9841-40fe-8823-96a304a09859

>> (правда, потом будет немного обидно присесть за его cp)
> Так зачем же CP копировать, толко гуид :)

дык cp найдет товарищмайор, и решит что ты и есть тот баклан. Вот же, uuid тот!

P.S. не ссы, их несколько десятков тысяч. Половина хранит котиков и хомпорно.


Ответить | Правка | Наверх | Cообщить модератору

181. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  –1 +/
Сообщение от AlexYeCu_not_logged (?), 30-Июл-20, 20:53 
>GPT хорош наличием GUID у диска и раздела.

Решается на уровне ОС, а за её пределами — зачем?

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

105. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +3 +/
Сообщение от Аноним (102), 30-Июл-20, 11:50 
> MBR не умеет в GPT

Да блин, что за каша в головах у людей? Если имеете в виду grub-pc, то так и пишите. MBR — это просто область на диске, она не может "работать" или "во что-то уметь".

P. S. Да, к сведению: на машине, с которой я пишу, grub-pc и GPT. Всё работает.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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