Исправление SakuraKun, (текущая версия) :
Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры 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 и прочего ныне модного непотребства.
Исправление SakuraKun, :
Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры 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 и прочего ныне модного непотребства.
Исправление SakuraKun, :
Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры 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 и прочего ныне модного непотребства.
Исправление SakuraKun, :
Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры 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 и прочего ныне модного непотребства.
Исправление SakuraKun, :
Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры 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 и прочего ныне модного непотребства.
Исходная версия SakuraKun, :
Так как любая лишняя строка кода является потенциальным источником багов и уязвимостей, возникает естественное желание к минимизации размера исходного кода, особенно когда дело касается прошивок - критически важного компонента системы с максимально привилегированным доступом к железу. Учитывая, что постоянно всплывают новости вроде этой про дыры 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 загрузки
На нормальных дистрибутивах такой проблемы нет.