Спасибо за статью, хоть она и насквозь рекламная.
Одна просьба: пользуйте, пожалуйста, стандартное оформление статей вместо этого «модного», а то за один только дурацкий эффект «меееедленное появление текста при прокрутке» хочется убивать, ведь на него тратися время и он сбивает фокус. В итоге, уже к середине статьи хочется взять адблок и вырезать к чертовой бабушке весь джаваскрипт со страницы. И шрифт слишком крупный, и текст зажат между пустыми белыми полями, и изображение сверху не несет никакой нагрузки… Пожалейте читателей, иначе их очень быстро не станет совсем.
Программы пишутся не только (и не столько) для компьютеров, но и для программистов. И писать их нужно так, чтобы их мог читать, понимать и изменять человек, а не машина. А тут предлагается ради упрощения парсеров и улучшения подсказок (которыми не пользуется процентов 30-40 разработчиков на низкоуровневых языках) сломать последовательно и редакторы, и компиляторы, и системы контроля версий, и вообще практически все наработки вокруг программирования за последние 50 лет ради того, чтобы разработчикам утилит было проще жить. Бинарные логи systemd и реестр Windows — теперь у вас в IDE, ура!
Пока не придуман прямой интерфейс мозг-машина и мозг-мозг, текст — лучшее, что у нас есть. Пожалуйста, не трогайте его, с ним все хорошо и так.
Ключевые слова в вашем комментарии — «для себя и своих проектов». В этом случае хороши любые средства, и любое программирование, хоть велосипедов, хоть нет — на пользу. А вот на деньги компании стоит заниматься решением задач, а не написанием своего кода на каждый чих. Если эти задачи можно решить вообще без кода — лучше решать их именно так, ибо у ненаписанного кода нулевые затраты на сопровождение, а если нельзя — стоит в любом случае рассмотреть использование готовых решений, прежде чем бросаться писать собственное.
Я вот прямо сейчас пытаюсь решить задачу замены QString, QByteArray и QDir/QFile/QFileInfo на отдельные классы вне Qt, чтобы отвязать от нее свой движок для разбора файлов UEFI. И если с последними еще как-то можно справиться при помощи boost:fs, а второй эмулировать поверх std::basic_string<uint8_t>, то что делать с QString — решительно непонятно. На что заменить tr().arg()? Как сделать конструктор, принимающий форматную строку и переменное число аргументов, не занимаясь при этом велосипедостроением. Пока использую cbstring и его метод format, но это боль, кровь, кишки и переписывание тысячи строк кода.
Даже в области работы с железом и прошивками сложность решений такова, что подобная стратегия — пустая трада времени специалиста и денег компании. Если вы этим занимаесь дома в качестве хобби — прекрасно, но если вы вместо использования готовых, оттестированных, качественных решений предпочитаете собственный велосипед, который нужно сначала весь написать, затем отладить, а затем поддерживать (причем чаще всего силами других специалистов) — вы либо гениальный разработчик, либо кошмарный велостроитель.
Повторное использование отлаженного кода — одна из целей любого программирования начиная с процедурного, т.е. с 60 годов прошлого века, и желание «все взять и переписать» нужно у новичков купировать сразу же, иначе никакой пользы они не принесут. Понятно, что случаи бывают разные, и иногда решений либо нет совсем, либо они не устраивают по каким-то объективным причинам, но «не понимаю, как устроено» и «я уверен, что могу написать лучше» — причины весьма плохие.
// Мама дорогая, мракобесие и джаз. :)
Надо срочно садиться и писать статью про TPM 1.2 и 2.0 вообще, и firmware TPM в частности, а то тут ситуация еще хуже, чем с SecureBoot.
Тут спрашивают, чем она так плоха, эта десятка, что с бесплатным обновлением на нее приходится воевать.
Отвечаю от себя лично: explorer.exe безнадежно испорчен .NET'ом, рабочий стол, который со времен Windows 98 обновлялся мгновенно, теперь не обновляется по 2 секунды на машине с восьмиядерным процессором и 32 Гб оперативной памяти. Создает какая-то программа на столе файл, и ты сидишь и ждешь, пока он наконец соизволит отрисоваться…
А если включить тяжелую компиляцию, которая загрузит все ядра на 100%, то через некоторое время рабочий стол, меню Пуск и все остальное перестает отвечать вообще, хоть ресет нажимай. Последний раз видел такое на Windows XP, и теперь оно снова с нами, всем радоваться полчаса.
Три разных конфигурации попробовал, четыре раза пытался перейти — и все время откатывался на Win 8.1 со StartIsBack, где с GUI все в порядке.
Замечу про BIOS — называть нынешнюю прошивку BIOS'ом вполне можно, т.к. и «по букве» (т.е. как базовая система ввода-вывода) и по духу (т.е. как motherboard firmware) термин вполне подходящий. UEFI — это вообще говоря только интерфейс между прошивкой и OS, и реализовывать его может что угодно, даже coreboot или Uboot.
Короче: термин уже стал нарицательным, и не стоит ругать за него.
Без rEFInd то же самое делается добавлением этого драйвера в переменную DriverXXXX, и он будет грузиться самой прошивкой, если она поддерживает спецификацию UEFI не ниже 2.3.
Что за модель ноутбука?
BBS Popup (то самое меню выбора устройства) есть практически во всех прошивках последних 5 лет, но иногда его нужно включать отдельно. Проверьте свою прошивку на наличие Advanced Mode в дополнение к EZ Mode, возможно, нужное меню и его горячая клавиша просто отключены по умолчанию.
Поддержка других ФС добавляется соотвествующими драйверами, которые с ESP может грузить как сама прошивка, так и системы управления загрузкой вроде rEFInd. Почему ругается установщик — он расчитан на систему «среднего» пользователя, у которого в прошивке никаких драйверов, кроме FAT, нет, и он не будет разбираться, почему после установки на загрузчика раздел EXT4 он не появился в списке.
UEFI видит только один специальный ESP-раздел, обычно он имеет размер 100-200 мегабайт и форматирован в FAT32 (бывает в FAT16)
Это неверно. UEFI видит все разделы, для ФС которых в конкретной реализации прошивки имеются драйверы. ESP же отличается от остальных разделов только тем, что а) для FAT драйвер иметь обязательно и б) на разделе ESP осуществляется поиск загрузчиков и автоматическое создание соответсвующих переменных BootXXXX, если загрузчики нашлись.
Но сам просматривать ESP-разделы и добавлять новые записи он не умеет, эти обязанности возложены на EFI Shell и операционные системы.
Еще как умеет, и это умение требуется спецификацией начиная с UEFI 2.2 (SecureBoot появился в UEFI 2.3.1C). Я советую полностью отказаться от использования efibootmgr, т.к. утилита эта имеет давнюю историю порчи вполне валидных переменных на платах с прошивками на кодовой базе Insyde H2O и Phoenix SCT. Если вам не нравится управление загрузчиками и приоритетами из BIOS Setup — используйте команду bcfg из UEFI Shell, она работает значительно лучше и проблем с ней я не видел ни разу, в отличие от.
Преимущества объективно:
— понятный и стандартный 64(реже 32)-битный интерфейс вместо 16-битного набора костылей, программных прерываний, ресетов через порт клавиатуры и передачи управления на MBR.
— для загрузки ОС больше не нужны соственнно загрузчики, и даже вот эти «системы управления загрузкой» вроде rEFInd нужны только тем, кого по каким-то непонятным причинам не устраивает стандартное меню выбора загрузочного устройсва.
— отсутсвие легаси времен царя гороха позволяет использовать прошивку в качестве корня доверия, с SecureBoot и TPM measured boot, и быть уверенным, что загрузчик не подменен атакующим на такой же, только с бэкдором.
— то же самое отсутствие костылей ускоряет загрузку, особенно это ускорение заметно на системах с большим количеством OROMов, например, в аппаратным RAID-контролером, но даже на обычном ноутбуке видно невооруженным глазом.
— значительно более простая расширяемость, в том числе и конечным пользователем, через подсистему DriverXXXX/KeyXXXX, о которой надо бы написать статью, а то она пока не очень известна массам
— много других, но конечный пользователь их не замечает и это правильно
Есть и недостатки, основной — UEFI-загрузчик имеет доступ к большему количеству «мяса и кишок» прошивки, и потому к нему должна быть более высокая степень доверия, чем к старому коду из MBR/PBR. Именно поэтому совет по отключению SecureBoot, который в этой статье дается — он крайне вредный, и лучше научиться пользоваться этой технологией, чем отключать ее лишь потому, что она «слишком сложная» и с ней «бывают проблемы».
Intel Anti-Theft, упомянутый в разделе «Защита», получил статус EOL еще в январе 2015 года, и на данный момент ни один из провайдеров ATT (Symantec, McAfee, Computrace и сам Intel) больше не поддерживает эту технологию, поэтому рекламировать её через полтора года после отключения — это просто непрофессионально, господа.
Я тоже с ними почти не работаю, потому что в Embedded и Industrial все эти вещи стараются отключить, т.к. они плохо влияют на предсказуемость системы. Сколько Intel и AMD не стараются убрать это влияние, оно все равно есть и очень заметно для людей, пытающихся выжать из x86-64 хотя бы SoftRT.
Тем не менее, «врага нужно знать в лицо», поэтому буду рад, если у вас все же получится написать что-нибудь по теме.
Одна просьба: пользуйте, пожалуйста, стандартное оформление статей вместо этого «модного», а то за один только дурацкий эффект «меееедленное появление текста при прокрутке» хочется убивать, ведь на него тратися время и он сбивает фокус. В итоге, уже к середине статьи хочется взять адблок и вырезать к чертовой бабушке весь джаваскрипт со страницы. И шрифт слишком крупный, и текст зажат между пустыми белыми полями, и изображение сверху не несет никакой нагрузки… Пожалейте читателей, иначе их очень быстро не станет совсем.
Программы пишутся не только (и не столько) для компьютеров, но и для программистов. И писать их нужно так, чтобы их мог читать, понимать и изменять человек, а не машина. А тут предлагается ради упрощения парсеров и улучшения подсказок (которыми не пользуется процентов 30-40 разработчиков на низкоуровневых языках) сломать последовательно и редакторы, и компиляторы, и системы контроля версий, и вообще практически все наработки вокруг программирования за последние 50 лет ради того, чтобы разработчикам утилит было проще жить. Бинарные логи systemd и реестр Windows — теперь у вас в IDE, ура!
Пока не придуман прямой интерфейс мозг-машина и мозг-мозг, текст — лучшее, что у нас есть. Пожалуйста, не трогайте его, с ним все хорошо и так.
Повторное использование отлаженного кода — одна из целей любого программирования начиная с процедурного, т.е. с 60 годов прошлого века, и желание «все взять и переписать» нужно у новичков купировать сразу же, иначе никакой пользы они не принесут. Понятно, что случаи бывают разные, и иногда решений либо нет совсем, либо они не устраивают по каким-то объективным причинам, но «не понимаю, как устроено» и «я уверен, что могу написать лучше» — причины весьма плохие.
Rust с каждым релизом все ближе к UEFI, скоро, скоро праздник будет и на моей улице, и я смогу писать на нем DXE- и SMM-драйверы почти без костылей.
Надо срочно садиться и писать статью про TPM 1.2 и 2.0 вообще, и firmware TPM в частности, а то тут ситуация еще хуже, чем с SecureBoot.
Отвечаю от себя лично: explorer.exe безнадежно испорчен .NET'ом, рабочий стол, который со времен Windows 98 обновлялся мгновенно, теперь не обновляется по 2 секунды на машине с восьмиядерным процессором и 32 Гб оперативной памяти. Создает какая-то программа на столе файл, и ты сидишь и ждешь, пока он наконец соизволит отрисоваться…
А если включить тяжелую компиляцию, которая загрузит все ядра на 100%, то через некоторое время рабочий стол, меню Пуск и все остальное перестает отвечать вообще, хоть ресет нажимай. Последний раз видел такое на Windows XP, и теперь оно снова с нами, всем радоваться полчаса.
Три разных конфигурации попробовал, четыре раза пытался перейти — и все время откатывался на Win 8.1 со StartIsBack, где с GUI все в порядке.
Короче: термин уже стал нарицательным, и не стоит ругать за него.
BBS Popup (то самое меню выбора устройства) есть практически во всех прошивках последних 5 лет, но иногда его нужно включать отдельно. Проверьте свою прошивку на наличие Advanced Mode в дополнение к EZ Mode, возможно, нужное меню и его горячая клавиша просто отключены по умолчанию.
Это неверно. UEFI видит все разделы, для ФС которых в конкретной реализации прошивки имеются драйверы. ESP же отличается от остальных разделов только тем, что а) для FAT драйвер иметь обязательно и б) на разделе ESP осуществляется поиск загрузчиков и автоматическое создание соответсвующих переменных BootXXXX, если загрузчики нашлись.
Еще как умеет, и это умение требуется спецификацией начиная с UEFI 2.2 (SecureBoot появился в UEFI 2.3.1C). Я советую полностью отказаться от использования efibootmgr, т.к. утилита эта имеет давнюю историю порчи вполне валидных переменных на платах с прошивками на кодовой базе Insyde H2O и Phoenix SCT. Если вам не нравится управление загрузчиками и приоритетами из BIOS Setup — используйте команду bcfg из UEFI Shell, она работает значительно лучше и проблем с ней я не видел ни разу, в отличие от.
— понятный и стандартный 64(реже 32)-битный интерфейс вместо 16-битного набора костылей, программных прерываний, ресетов через порт клавиатуры и передачи управления на MBR.
— для загрузки ОС больше не нужны соственнно загрузчики, и даже вот эти «системы управления загрузкой» вроде rEFInd нужны только тем, кого по каким-то непонятным причинам не устраивает стандартное меню выбора загрузочного устройсва.
— отсутсвие легаси времен царя гороха позволяет использовать прошивку в качестве корня доверия, с SecureBoot и TPM measured boot, и быть уверенным, что загрузчик не подменен атакующим на такой же, только с бэкдором.
— то же самое отсутствие костылей ускоряет загрузку, особенно это ускорение заметно на системах с большим количеством OROMов, например, в аппаратным RAID-контролером, но даже на обычном ноутбуке видно невооруженным глазом.
— значительно более простая расширяемость, в том числе и конечным пользователем, через подсистему DriverXXXX/KeyXXXX, о которой надо бы написать статью, а то она пока не очень известна массам
— много других, но конечный пользователь их не замечает и это правильно
Есть и недостатки, основной — UEFI-загрузчик имеет доступ к большему количеству «мяса и кишок» прошивки, и потому к нему должна быть более высокая степень доверия, чем к старому коду из MBR/PBR. Именно поэтому совет по отключению SecureBoot, который в этой статье дается — он крайне вредный, и лучше научиться пользоваться этой технологией, чем отключать ее лишь потому, что она «слишком сложная» и с ней «бывают проблемы».
Тем не менее, «врага нужно знать в лицо», поэтому буду рад, если у вас все же получится написать что-нибудь по теме.