История изменений

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно. По аналогичным причинам я «хейчу» и SystemD, и многое другое «фичастое но дырявое».

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого. Да, придётся иногда немного «страдать с FDT образами» - но дополнительная безопасность стоит того, чтобы пожертвовать некоторыми удобствами.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

Нормальные дистрибутивы так не делают, + нет необходимости держать дурацкий /boot/efi . Да и какие «другие ОС» вы здесь имеете ввиду - винду, что ли? Если важна безопасность, то винде есть место лишь в максимально изолированной виртуалке, а лучше вообще от неё отказаться. Иначе «ломать» будут уже вас - во все дыры Windows/UEFI/SystemD и прочего ныне модного непотребства.

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно. По аналогичным причинам я «хейчу» и SystemD, и многое другое «фичастое но дырявое».

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого. Да, придётся иногда немного «страдать с FDT образами» - но дополнительная безопасность стоит того, чтобы пожертвовать некоторыми удобствами.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

Нормальные дистрибутивы так не делают, + нет необходимости держать дурацкий /boot/efi . Да и какие «другие ОС» вы здесь имеете ввиду - винду, что ли? Если важна безопасность, то винде есть место лишь в максимально изолированной виртуалке, а лучше вообще от неё отказаться. Иначе «ломать» будут уже вас - во все дыры Windows/UEFI/SystemD и прочего ныне модного непотребства.

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно. По аналогичным причинам я «хейчу» и SystemD, и многое другое «фичастое но дырявое».

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого. Да, придётся иногда немного «страдать с FDT образами» - но дополнительная безопасность стоит того, чтобы пожертвовать некоторыми удобствами.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

Нормальные дистрибутивы так не делают, + нет необходимости держать дурацкий /boot/efi . Да и какие «другие ОС» вы здесь имеете ввиду - винду, что ли? Если важна безопасность, то винде есть место лишь в максимально изолированной виртуалке, а лучше вообще от неё отказаться. Иначе «ломать» будут уже вас - во все дыры Windows/UEFI/SystemD и прочего ныне модного непотребства.

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно.

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого. Да, придётся иногда немного «страдать с FDT образами» - но дополнительная безопасность стоит того, чтобы пожертвовать некоторыми удобствами.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

Нормальные дистрибутивы так не делают, + нет необходимости держать дурацкий /boot/efi . Да и какие «другие ОС» вы здесь имеете ввиду - винду, что ли? Если важна безопасность, то винде есть место лишь в максимально изолированной виртуалке, а лучше вообще от неё отказаться. Иначе «ломать» будут уже вас - во все дыры Windows/UEFI/SystemD и прочего ныне модного непотребства.

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно.

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

Нормальные дистрибутивы так не делают, + нет необходимости держать дурацкий /boot/efi . Да и какие «другие ОС» вы здесь имеете ввиду - винду, что ли? Если важна безопасность, то винде есть место лишь в максимально изолированной виртуалке, а лучше вообще от неё отказаться. Иначе «ломать» будут уже вас - во все дыры Windows/UEFI/SystemD и прочего ныне модного непотребства.

Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры UEFI - у человека, желающего обеспечить максимальную безопасность системы вместо погони за фичами, возникает закономерное стремление бойкотировать UEFI как класс. Так что моё «хейтерство» вполне обоснованно.

В случае x86, u-boot может быть использован лишь поверх coreboot, а схема «coreboot --> дополнение u-boot --> его реализация EFI» - если и не невозможна, то выглядит крайне неоптимально, и я пока ещё не встречал человека который бы так делал. Даже Tianocore, который накатить на coreboot намного проще, и то мало кто использует - все на SeaBIOS.

На альтернативных архитектурах вроде RISC-V и ARM, с которыми вы работает, у u-boot дела обстоят намного лучше т.к. он может быть использован нативно. Но там и дополнительный функционал EFI выглядит излишним, т.к. u-boot может грузить и без этого.

Самодельщики уже не слышали про BIOS и пишут сразу под UEFI

Если пройтись по OSDev Projects, даже среди активных проектов в UEFI там умеют считанные единицы.

Программу для UEFI можно за 5 минут написать используя clang/lld.

Но зачем, если она будет работать только с UEFI, которого по крайней мере на x86 следует избегать.

Линуксы имеют тенденцию перезаписывать MBR и ломать другие ОС в случае BIOS загрузки

На нормальных дистрибутивах такой проблемы нет.