Надо статью писать давно уже, и про DriverXXXX, и про KeyXXXX, и про SysPrepXXXX, а то авторы спецификации потребовали, IBV молча реализовали, и никто не в курсе, кроме атакующих, очень удобно...
@ValdikSS, приколись, как они могут. Я думал, что всякую фигню UEFI CA подписывать, а потом ее героически (неправильно) банить - это максимум того, что эта "индустрия" может, но здесь Insyde превзошли и самих себя, и всех остальных. Очень веселый тамада, и очень интересные конкурсы...
Тоже столкнулся в полный рост с тем, что безопасный парсер бинарных данных на С или С++ написать очень сложно. "Боевых" библиотек для парсеров-комбинаторов нет, а то, что есть - примерно такого же качества, как тут в статье и описано, т.е. либо "заброшено", либо "автор не чинит известные уязвимости, и гордится этим".
Остановился в итоге на двух решениях, которые к парсингу подходят с разных сторон. На KaitaiStruct пишу то, что для безопасности критическим не является, и для чего удобство разработки парсера важнее его безопасности. Реально критическое по безопасности делаю на WUFFS.
Вам - ничего не хочу, потому что ваши примерны никакого отношения к простоте не имеют. Костылить строки вместо стандартных, собирать запросы вручную при наличии prepared statements, открывать API без аутентификации на всю сеть - это все не про "так проще", а про "мы вообще не в курсе, чем мы тут занимаемся, но надо сделать вчера еще, поэтому некогда объяснять - срезаем все углы".
Просто - это не значит плохо, или глупо, или недоработано, или дыряво, или еще как-то с изъяном, просто - это так, чтобы сделано было все необходимое, и не сделано было ничего лишнего. Подчеркиваю, все необходимое, и ничего лишнего. Что-то перестало быть нужным - удаляйте, removed is debugged, что-то понадобилось - добавляйте, но руководствуясь тем же принципом.
Software - оно потому и soft, что легко поддается изменениям, и бороться с неконтролируемым ростом сложности (а с ней и неконтролируемым ростом числа уязвимостей, потому что уязвимости - они тоже следствие сложности в первую очередь) в нем нужно в момент потенциального добавления этой сложности, другого момента у вас зачастую уже не будет.
Выбирай сложность согласно максимально возможному будущему развитию проекта. Ты повидал многое, ты знаешь, как случаются факапы, как случаются успешные успехи, которые не случаются потому что в кузнице не оказалось гвоздя. Ты знаешь куда ведут все модные тенденции, не стесняйся закладывать их в проект, если он может туда прийти.
Дорогой Мастер, от лица специалиста по безопасности, которому потом поручат чинить уязвимости в вашем переусложненном шедевре, покорнейше прошу вас проследовать в афедрон. Если вы умеете будущее предсказывать - бросайте дурацкое ИТ и зарабатывайте миллиарды на ставках на спорт и лотереях, а здесь сложность систем и так запредельная, чтобы ее еще дополнительно делать "на вырост". You Ain't Gonna Need It! Вы исполнитель и не принимаете управленческих решений, не знаете, как будет происходить развитие вашего продукта, не отвечаете за его судьбу, и не представляете, как дорого чинить результаты подхода "надо предусмотреть вообще все, что нам предсказывает наша внутренняя Ванга".
Из трех моих рабочих виз в США (все три - H-1B) на дополнительную проверку отправляли две, оба раза это затягивало процесс получения визы на 4 месяца. Триггер - не гражданство РФ (у меня есть еще и немецкое, и визы ставились в немецкий паспорт), а профиль работы (т.е. если назвать себя firmware security engineer - под проверку попадешь однозначно, а если low-level software developer - уже могут быть варианты). В третий раз я именно так себя и назвал, но интервьюер в Мюнхенском консульстве дополнительно уточнила, мол, у вас должность официально называется Software Engineer ICT4 - Security, скажите, а вот эта безопасность - она не про работу с критическими системами для правительства США или министерства обороны США. Нет, говорю, у меня клиренса нет, а коллегам с ним запрещено общаться со мной, чтобы не потерять свой, поэтому и я с ними не работаю, и они со мной, опасности нет. В итоге вместо 5 месяцев визу удалось получить за 20 дней.
Я работал над тем, чтобы сделать эту технологию безопасной без каких-либо "если" и "но", в течение всего 2023 года, и верю и себе, и бывшим коллегам, которые работали над ней вместе со мной. Ваше право не верить им, мне, корпорации в чужой юрисдикции - это ваше право, но "ни одна модель, ни один ассистент кода, ни одно автодополнение из интернета ваши данные конфиденциальными не оставит" - это крайне сильное утверждение, требующее доказательств.
Спасибо вам за то, что вы серьезно относитесь к безопасности ваших данных, и именно благодаря вам, и таким как вы, весь этот Apple Intelligence можно отключить одним слайдером, и он реально отключится.
Очень много очень серьезной работы было сделано для того, чтобы задачи построения таких контекстов, которые из за вычислительной сложности нельзя было выполнить локально, можно было выполнить на удаленном сервере таким образом, чтобы никто, вот прямо совсем никто, даже очень ресурсный атакующий внутри корпорации, не мог ничего сделать с ними.
Ваш покорный слуга почти год участвовал в портировании SEPOS на виртуальную машину (вместе с драйверами всех аппаратных устройств, которых, кроме как у SEP и у внутреннего cycle-accurate симулятора SEP, не было больше ни у кого).
Могу сказать искреннее большое спасибо Apple за то, что весь этот прости рандом "интеллект" отключается одним слайдером, так же, как и Siri, и остается отключенным (передаю привет идиоту из менеджмента, который продавил принудительное включение Apple Intelligence при обновлении на .3, посылаю ему лучи ураганной диареи).
Пока всякие любители прогресса и последователи истинной веры в то, что нейросети спасут их от работы, а умножение матриц поможет решить их проблемы, сетуют на то, что в их "искусственный интеллект" недокладывают интеллекта, мы тут в своем погребе спокойно ждем, пока волна идиотского хайпа наконец закончится, и корпорации перестанут тратить триллионы долларов на ерунду, от которой до сих пор на клиентских устройствах нет никакого толка, а все ее применения - либо игрушки, либо "давайте еще сильнее сломаем уже и так испорченный копирайтингом и SEO Интернет", либо крайне нишевые.
С кем бы я серьезно но обсуждал прогресс больших языковых моделей и новую волну "ИИ", практически каждый говорит о том, что в его профессиональной области знаний и навыков ИИ пока что ничего, кроме буллшита, не выдает, и потому нафиг там не нужен, но в других областях его выхлоп выглядит правдоподобно. В том то и дело, ребята! Там, где вы эксперты - вы легко отличаете специалиста от дурака, а там, где нет - уже не можете отличить так легко, а цифровой дурак специально сделан так, чтобы красиво нанизывать токены друг на друга и выглядеть правдоподобным. Иногда это интересно и полезно, но если вы начнете верить тому, что этот цифровой дурак несет - не удивляйтесь потом, что он вам посоветует ботулотоксин от простуды.
Выбирая между "релизить говно" и "отложить или отменить, если не получается не релизить говно" Apple раз за разом выбирает второе, и за это радоваться надо, в не статьи эмоциональные писать. В городе Купертино все отлично.
Опыт показывает, что и DT можно сделать нормально, и ACPI можно зафакапить так, что устанешь ядро патчить.
ACPI, вообще говоря, ортогонален UEFI (хоть теперь и управляется одними и теми же людьми), тем более EDK2, и потому относительно независимую реализацию ACPI сделать не мешает ничего, кроме дороговизны мероприятия.
Более того, я теперь попробовал хорошие альтернативы ACPI, а не только тот русский рэп, который предлагают всякие человеки-эмбеддо-свиньи (не в обиду нормальным эмбеддерам), и могу сказать, что идея "давайте абстрагируем платформу до такого состояния, чтобы любую ОС можно было прямо как есть переносить с любого ПК на любой другой" - она такая же глупая и нежизнеспособная, как и обратная ей идея "нахер вообще вам переносимость, собирайте кастомное ядро под каждую ревизию платы". ACPI - это реально очень удобно, когда работает, но зачастую оно не работает, и работать начнет примерно к ишачьей пасхе, а должно бы уже вчера. В том числе поэтому вместо нормального сопроцессора безопасности у нас в обычном ПК хорошо если есть TPM 2.0, а зачастую и вообще ничего нет, и приходится ходить на костылях там, где можно было ехать на Синкансэне.
На скриншотах ниже — прошивка нашего сервера, которая открыта в утилите UEFITool. Эта утилита разработана нашим соотечественником (@CodeRush, спасибо за утилиту 🙂).
Молодцы, что не стали пользоваться услугами IBV, а решили все делать сами на базе "голого" EDK2. После определенного опыта работы со всеми тремя платформами, которые нынче предлагают IBV (AMI AptioV, Phoenix SCT, Insyde H2O) - это лучшее решение, к которому пришли в свое время и Apple, и Microsoft.
По поводу однопоточности - уровень использования CpuMpProtocol зависит от вас самих, и никто не мешает на AP (ядрах, которые не являются BSP) запускать что угодно, с любой степенью параллелизма, Qualcomm вон вообще запускает свою RTOS на всех ядрах, и компоненты традиционного UEFI запускает уже из нее как приложения, а SMM (который теперь официально называется просто MM, потому что к архитектуре x86(-64) сама идея Management Mode имеет мало отношения) реализует через TrustZone.
После десятка лет работы с UEFI я все сильнее соглашаюсь с @checkpoint, но не в смысле "троянского коня" (не приписывайте злой умысел тому, что можно объяснить глупостью), а в смысле "UBoot или любая другая более простая альтернатива UEFI PI, реализующая UEFI как интерфейс - строго лучше, чем любая прошивка, основанная на EDK2". Дело в том, что современный EDK2 (а сейчас у нас 2025 год) заметно отягощен решениями, которые Intel принимал в 1998 году, для процессора, который уже и не выпускается, и не поддерживается, принятыми людьми, которые до этого занимались разработкой драйверов для Windows NT. С тех пор воды утекло заметно, и системное программирование развилось заметно, а в EDK2 продолжают заниматься поллингом на одном потоке, танцами вокруг TPL, передачей управления хрен знает куда вместо человеческого IPC, загрузкой сотни драйверов по одному в цикле, пока нечего станет загружать, наглухо отбитым интерфейсом к NVRAM (API so nice you have to call it twice), плохо прикрученной через 13 лет безопасной загрузкой, и т.д. и т.п.
Понятно, что любые альтернативы - это отличный способ снова прогуляться по всем граблям разработки системного ПО, но в текущем виде продукт, основанный на EDK2, и при этом радикально не переделанный в сторону уменьшения влияния особенностей EDK2 на него - не может быть ни быстрым, ни безопасным, ни простым в отладке. Когда Apple выкинули MacEFI в пользу iBoot на машинах с Apple Silicon - жить стало лучше и веселее, то же самое сделали ребята из Oxide, и теперь у них отличная прошивка, написанная в основном на Rust, которая их здоровенное облако-на-сервере загружает за пару секунд.
С другой стороны, я очень рад, что в России появились люди, способные не только АПМДЗ в AMI AptioV внедрять, но и реализовывать работающие серверные прошивки для разработанного ими же железа, а потом об этом еще и статьи нормальные писать. Так держать!
Хорошо, годно, автор - красавчик, хабр - торт. Вот из за таких вот прекрасных парней и девчонок в свое время пришлось приделать к SEP целый отдельный блок защиты от шевелителей частот и напряжений, и ПО научиться так писать и компилировать, чтобы пропуск любой инструкции к краху систем защиты не приводил.
Пользовался в свое время аппаратным оценивателем качества сигнала PCIe Gen3, который выглядел как многоканальный высокоскоростной осциллограф с Windows XP на борту, софтом для построения глазных диаграмм и софтом для оценки соответствия этих диаграмм спецификации. Интересная была железка, только дорогая очень, себе домой такую не купишь.
Какое счастье, что вся вот эта мода и прочая фигня нужна только тем, кто торгует внешним видом. Программисты, насколько я успел понять за свои скромные 15 лет карьеры, внешним видом не торгуют, и потому могут надевать любую чистую и опрятную одежду, а всех недовольных их внешним видом спокойно слать в жопу. Носите футболки с прикольными надписями, худи с конференций, карго-штаны и жилетки как у Вассермана, и кладите с прибором на вот это все, мои чуваки. Хер моде, слава анонимусу!
Судя по почти сотне плюсов этой не очень хорошей, на мой взгляд, статье, в которой вроде бы препарировать начали, но как-то действительно раскидали все кишки по столу, а цельной картины не нарисовали, сейчас на Хабре существует запрос на обучающие статьи по языку "С для прошивок", и присутствуют несколько людей, способных такие статьи писать. Только вот статей не появляется, и приходится комментировать всякий переводной шлак.
Если вы хотите что-то реально поменять, пишите не комментарии, а статьи, такого же примерно формата. "Вот так выглядит Hello World для какой-нибудь умной пуговицы на 8051", или "пишем на С прошивку для самодельного паяльника Т12", или "какой-нибудь промышленный 1Ггц\16к осциллограф за миллиард управляется древним Intel Atom или AMD Geode LX, ковыряем установленную на нем Windows XP" и т.п.
Ничего нельзя сделать, задавая вопросы в комментариях, если мы хотим, чтобы молодежь училась и интересовалась, надо её учить и интересовать. Я тоже пойду учить и интересовать, когда уволюсь из корпорации. Мой бывший начальник Xeno Kovah уже так и сделал в 2020 году, и теперь делится знаниями на OpenSecurityTraining2, про который я тут в комментариях тоже без конца повторяю, как попугай.
Я не думаю, что бывает какой-то "канонический вариант использования языка" в принципе, потому что С для прошивок и С для прикладных программ - очень разные языки, и тут в статье показан второй как раз. Первый при этом никуда не девается, и со вторым если и пересекается, то не очень сильно.
Буквально недавно объяснял интернам важность правильного указания выравнивания у структур и опасность добавления новых переменных в середину этих самых структур, являющихся частью XNU ABI, и понял, что первому языку не учат нигде, кроме как на работе, а с привычками, сформированными вторым, потом приходится бороться годами.
Или другой пример: Intel в свое время решили, что вместо стандартных memcpy и memset у них в EFI будут gBS->CopyMem и gBS->SetMem, а стандартной библиотеки не будет совсем. И все бы ничего, только вот компиляторы по стандарту языка С99 имею право заменять присваивания структурных переменных на вызов memcpy, и получается полная херня, когда тебе линкер сообщает, что линковать не будет, потому что у тебя нет memcpy, а у тебя в коде его и нет нигде, иди ищи присваивание, удачи.
IOMMU/DART решают эту задачу, и DMA-атаки перестали быть сколько-нибудь серьезной проблемой на любых нормально настроенных устройствах уже лет пять примерно.
Надо статью писать давно уже, и про DriverXXXX, и про KeyXXXX, и про SysPrepXXXX, а то авторы спецификации потребовали, IBV молча реализовали, и никто не в курсе, кроме атакующих, очень удобно...
Вторая часть на английском, русскую версию напишу чуть позже.
@ValdikSS, приколись, как они могут. Я думал, что всякую фигню UEFI CA подписывать, а потом ее героически (неправильно) банить - это максимум того, что эта "индустрия" может, но здесь Insyde превзошли и самих себя, и всех остальных. Очень веселый тамада, и очень интересные конкурсы...
Тоже столкнулся в полный рост с тем, что безопасный парсер бинарных данных на С или С++ написать очень сложно. "Боевых" библиотек для парсеров-комбинаторов нет, а то, что есть - примерно такого же качества, как тут в статье и описано, т.е. либо "заброшено", либо "автор не чинит известные уязвимости, и гордится этим".
Остановился в итоге на двух решениях, которые к парсингу подходят с разных сторон. На KaitaiStruct пишу то, что для безопасности критическим не является, и для чего удобство разработки парсера важнее его безопасности. Реально критическое по безопасности делаю на WUFFS.
Вам - ничего не хочу, потому что ваши примерны никакого отношения к простоте не имеют. Костылить строки вместо стандартных, собирать запросы вручную при наличии prepared statements, открывать API без аутентификации на всю сеть - это все не про "так проще", а про "мы вообще не в курсе, чем мы тут занимаемся, но надо сделать вчера еще, поэтому некогда объяснять - срезаем все углы".
Просто - это не значит плохо, или глупо, или недоработано, или дыряво, или еще как-то с изъяном, просто - это так, чтобы сделано было все необходимое, и не сделано было ничего лишнего. Подчеркиваю, все необходимое, и ничего лишнего. Что-то перестало быть нужным - удаляйте, removed is debugged, что-то понадобилось - добавляйте, но руководствуясь тем же принципом.
Software - оно потому и soft, что легко поддается изменениям, и бороться с неконтролируемым ростом сложности (а с ней и неконтролируемым ростом числа уязвимостей, потому что уязвимости - они тоже следствие сложности в первую очередь) в нем нужно в момент потенциального добавления этой сложности, другого момента у вас зачастую уже не будет.
Дорогой Мастер, от лица специалиста по безопасности, которому потом поручат чинить уязвимости в вашем переусложненном шедевре, покорнейше прошу вас проследовать в афедрон. Если вы умеете будущее предсказывать - бросайте дурацкое ИТ и зарабатывайте миллиарды на ставках на спорт и лотереях, а здесь сложность систем и так запредельная, чтобы ее еще дополнительно делать "на вырост". You Ain't Gonna Need It!
Вы исполнитель и не принимаете управленческих решений, не знаете, как будет происходить развитие вашего продукта, не отвечаете за его судьбу, и не представляете, как дорого чинить результаты подхода "надо предусмотреть вообще все, что нам предсказывает наша внутренняя Ванга".
Из трех моих рабочих виз в США (все три - H-1B) на дополнительную проверку отправляли две, оба раза это затягивало процесс получения визы на 4 месяца. Триггер - не гражданство РФ (у меня есть еще и немецкое, и визы ставились в немецкий паспорт), а профиль работы (т.е. если назвать себя firmware security engineer - под проверку попадешь однозначно, а если low-level software developer - уже могут быть варианты). В третий раз я именно так себя и назвал, но интервьюер в Мюнхенском консульстве дополнительно уточнила, мол, у вас должность официально называется Software Engineer ICT4 - Security, скажите, а вот эта безопасность - она не про работу с критическими системами для правительства США или министерства обороны США. Нет, говорю, у меня клиренса нет, а коллегам с ним запрещено общаться со мной, чтобы не потерять свой, поэтому и я с ними не работаю, и они со мной, опасности нет. В итоге вместо 5 месяцев визу удалось получить за 20 дней.
Я работал над тем, чтобы сделать эту технологию безопасной без каких-либо "если" и "но", в течение всего 2023 года, и верю и себе, и бывшим коллегам, которые работали над ней вместе со мной. Ваше право не верить им, мне, корпорации в чужой юрисдикции - это ваше право, но "ни одна модель, ни один ассистент кода, ни одно автодополнение из интернета ваши данные конфиденциальными не оставит" - это крайне сильное утверждение, требующее доказательств.
Спасибо вам за то, что вы серьезно относитесь к безопасности ваших данных, и именно благодаря вам, и таким как вы, весь этот Apple Intelligence можно отключить одним слайдером, и он реально отключится.
[Citation Needed] (tm). Пожалуйста найдите способ вынуть ваши данные из Private Cloud Compute и получите неплохую прибавку к зарплате.
Очень много очень серьезной работы было сделано для того, чтобы задачи построения таких контекстов, которые из за вычислительной сложности нельзя было выполнить локально, можно было выполнить на удаленном сервере таким образом, чтобы никто, вот прямо совсем никто, даже очень ресурсный атакующий внутри корпорации, не мог ничего сделать с ними.
Ваш покорный слуга почти год участвовал в портировании SEPOS на виртуальную машину (вместе с драйверами всех аппаратных устройств, которых, кроме как у SEP и у внутреннего cycle-accurate симулятора SEP, не было больше ни у кого).
В итоге эта работа стала частью виртуальной системы vresearch101, которая позволит независимым исследователям проверить обещания Apple, найти уязвимости и получить за них награду.
Могу сказать искреннее большое спасибо Apple за то, что весь этот прости рандом "интеллект" отключается одним слайдером, так же, как и Siri, и остается отключенным (передаю привет идиоту из менеджмента, который продавил принудительное включение Apple Intelligence при обновлении на .3, посылаю ему лучи ураганной диареи).
Пока всякие любители прогресса и последователи истинной веры в то, что нейросети спасут их от работы, а умножение матриц поможет решить их проблемы, сетуют на то, что в их "искусственный интеллект" недокладывают интеллекта, мы тут в своем погребе спокойно ждем, пока волна идиотского хайпа наконец закончится, и корпорации перестанут тратить триллионы долларов на ерунду, от которой до сих пор на клиентских устройствах нет никакого толка, а все ее применения - либо игрушки, либо "давайте еще сильнее сломаем уже и так испорченный копирайтингом и SEO Интернет", либо крайне нишевые.
С кем бы я серьезно но обсуждал прогресс больших языковых моделей и новую волну "ИИ", практически каждый говорит о том, что в его профессиональной области знаний и навыков ИИ пока что ничего, кроме буллшита, не выдает, и потому нафиг там не нужен, но в других областях его выхлоп выглядит правдоподобно. В том то и дело, ребята! Там, где вы эксперты - вы легко отличаете специалиста от дурака, а там, где нет - уже не можете отличить так легко, а цифровой дурак специально сделан так, чтобы красиво нанизывать токены друг на друга и выглядеть правдоподобным. Иногда это интересно и полезно, но если вы начнете верить тому, что этот цифровой дурак несет - не удивляйтесь потом, что он вам посоветует ботулотоксин от простуды.
Выбирая между "релизить говно" и "отложить или отменить, если не получается не релизить говно" Apple раз за разом выбирает второе, и за это радоваться надо, в не статьи эмоциональные писать. В городе Купертино все отлично.
Опыт показывает, что и DT можно сделать нормально, и ACPI можно зафакапить так, что устанешь ядро патчить.
ACPI, вообще говоря, ортогонален UEFI (хоть теперь и управляется одними и теми же людьми), тем более EDK2, и потому относительно независимую реализацию ACPI сделать не мешает ничего, кроме дороговизны мероприятия.
Более того, я теперь попробовал хорошие альтернативы ACPI, а не только тот русский рэп, который предлагают всякие человеки-эмбеддо-свиньи (не в обиду нормальным эмбеддерам), и могу сказать, что идея "давайте абстрагируем платформу до такого состояния, чтобы любую ОС можно было прямо как есть переносить с любого ПК на любой другой" - она такая же глупая и нежизнеспособная, как и обратная ей идея "нахер вообще вам переносимость, собирайте кастомное ядро под каждую ревизию платы". ACPI - это реально очень удобно, когда работает, но зачастую оно не работает, и работать начнет примерно к ишачьей пасхе, а должно бы уже вчера. В том числе поэтому вместо нормального сопроцессора безопасности у нас в обычном ПК хорошо если есть TPM 2.0, а зачастую и вообще ничего нет, и приходится ходить на костылях там, где можно было ехать на Синкансэне.
@serg_blackout, пожалуйста.
Молодцы, что не стали пользоваться услугами IBV, а решили все делать сами на базе "голого" EDK2. После определенного опыта работы со всеми тремя платформами, которые нынче предлагают IBV (AMI AptioV, Phoenix SCT, Insyde H2O) - это лучшее решение, к которому пришли в свое время и Apple, и Microsoft.
По поводу однопоточности - уровень использования CpuMpProtocol зависит от вас самих, и никто не мешает на AP (ядрах, которые не являются BSP) запускать что угодно, с любой степенью параллелизма, Qualcomm вон вообще запускает свою RTOS на всех ядрах, и компоненты традиционного UEFI запускает уже из нее как приложения, а SMM (который теперь официально называется просто MM, потому что к архитектуре x86(-64) сама идея Management Mode имеет мало отношения) реализует через TrustZone.
После десятка лет работы с UEFI я все сильнее соглашаюсь с @checkpoint, но не в смысле "троянского коня" (не приписывайте злой умысел тому, что можно объяснить глупостью), а в смысле "UBoot или любая другая более простая альтернатива UEFI PI, реализующая UEFI как интерфейс - строго лучше, чем любая прошивка, основанная на EDK2". Дело в том, что современный EDK2 (а сейчас у нас 2025 год) заметно отягощен решениями, которые Intel принимал в 1998 году, для процессора, который уже и не выпускается, и не поддерживается, принятыми людьми, которые до этого занимались разработкой драйверов для Windows NT. С тех пор воды утекло заметно, и системное программирование развилось заметно, а в EDK2 продолжают заниматься поллингом на одном потоке, танцами вокруг TPL, передачей управления хрен знает куда вместо человеческого IPC, загрузкой сотни драйверов по одному в цикле, пока нечего станет загружать, наглухо отбитым интерфейсом к NVRAM (API so nice you have to call it twice), плохо прикрученной через 13 лет безопасной загрузкой, и т.д. и т.п.
Понятно, что любые альтернативы - это отличный способ снова прогуляться по всем граблям разработки системного ПО, но в текущем виде продукт, основанный на EDK2, и при этом радикально не переделанный в сторону уменьшения влияния особенностей EDK2 на него - не может быть ни быстрым, ни безопасным, ни простым в отладке. Когда Apple выкинули MacEFI в пользу iBoot на машинах с Apple Silicon - жить стало лучше и веселее, то же самое сделали ребята из Oxide, и теперь у них отличная прошивка, написанная в основном на Rust, которая их здоровенное облако-на-сервере загружает за пару секунд.
С другой стороны, я очень рад, что в России появились люди, способные не только АПМДЗ в AMI AptioV внедрять, но и реализовывать работающие серверные прошивки для разработанного ими же железа, а потом об этом еще и статьи нормальные писать. Так держать!
Все хорошо, ребят, кроме одного - Xeno Kovah при правильной передаче его имени на русский язык будет "Зино", а не "Ксено". Послушайте сами.
Хорошо, годно, автор - красавчик, хабр - торт. Вот из за таких вот прекрасных парней и девчонок в свое время пришлось приделать к SEP целый отдельный блок защиты от шевелителей частот и напряжений, и ПО научиться так писать и компилировать, чтобы пропуск любой инструкции к краху систем защиты не приводил.
Пользовался в свое время аппаратным оценивателем качества сигнала PCIe Gen3, который выглядел как многоканальный высокоскоростной осциллограф с Windows XP на борту, софтом для построения глазных диаграмм и софтом для оценки соответствия этих диаграмм спецификации. Интересная была железка, только дорогая очень, себе домой такую не купишь.
Какое счастье, что вся вот эта мода и прочая фигня нужна только тем, кто торгует внешним видом. Программисты, насколько я успел понять за свои скромные 15 лет карьеры, внешним видом не торгуют, и потому могут надевать любую чистую и опрятную одежду, а всех недовольных их внешним видом спокойно слать в жопу. Носите футболки с прикольными надписями, худи с конференций, карго-штаны и жилетки как у Вассермана, и кладите с прибором на вот это все, мои чуваки. Хер моде, слава анонимусу!
И я вас, Алексей.
Судя по почти сотне плюсов этой не очень хорошей, на мой взгляд, статье, в которой вроде бы препарировать начали, но как-то действительно раскидали все кишки по столу, а цельной картины не нарисовали, сейчас на Хабре существует запрос на обучающие статьи по языку "С для прошивок", и присутствуют несколько людей, способных такие статьи писать. Только вот статей не появляется, и приходится комментировать всякий переводной шлак.
Если вы хотите что-то реально поменять, пишите не комментарии, а статьи, такого же примерно формата. "Вот так выглядит Hello World для какой-нибудь умной пуговицы на 8051", или "пишем на С прошивку для самодельного паяльника Т12", или "какой-нибудь промышленный 1Ггц\16к осциллограф за миллиард управляется древним Intel Atom или AMD Geode LX, ковыряем установленную на нем Windows XP" и т.п.
Ничего нельзя сделать, задавая вопросы в комментариях, если мы хотим, чтобы молодежь училась и интересовалась, надо её учить и интересовать. Я тоже пойду учить и интересовать, когда уволюсь из корпорации. Мой бывший начальник Xeno Kovah уже так и сделал в 2020 году, и теперь делится знаниями на OpenSecurityTraining2, про который я тут в комментариях тоже без конца повторяю, как попугай.
Я не думаю, что бывает какой-то "канонический вариант использования языка" в принципе, потому что С для прошивок и С для прикладных программ - очень разные языки, и тут в статье показан второй как раз. Первый при этом никуда не девается, и со вторым если и пересекается, то не очень сильно.
Буквально недавно объяснял интернам важность правильного указания выравнивания у структур и опасность добавления новых переменных в середину этих самых структур, являющихся частью XNU ABI, и понял, что первому языку не учат нигде, кроме как на работе, а с привычками, сформированными вторым, потом приходится бороться годами.
Или другой пример: Intel в свое время решили, что вместо стандартных memcpy и memset у них в EFI будут gBS->CopyMem и gBS->SetMem, а стандартной библиотеки не будет совсем. И все бы ничего, только вот компиляторы по стандарту языка С99 имею право заменять присваивания структурных переменных на вызов memcpy, и получается полная херня, когда тебе линкер сообщает, что линковать не будет, потому что у тебя нет memcpy, а у тебя в коде его и нет нигде, иди ищи присваивание, удачи.
IOMMU/DART решают эту задачу, и DMA-атаки перестали быть сколько-нибудь серьезной проблемой на любых нормально настроенных устройствах уже лет пять примерно.