Вынимают весь ассемблер в отдельные функции и (с учетом того, что соглашение о вызове известно) вызывают из потом из кода на С.
Такой подход, кстати, лучше вставок, т.к. и целевые машины, и ассемблеры бывают разные, и потому можно иметь несколько реализаций одной и той же функции в проекте и переключать их через систему сборки, а не через препроцессор, как это пришлось бы делать со вставками.
Да, нужно несколько драйверов для полноценной поддержки TPM 2.0 прошивкой. Вот тут лежат их открытые реализации, но у IBV обычно свои (сделанные из этих же, но пропатченные под свои нужды и для совместимости со своими платформами).
Забыл упомянуть один серьезный для меня недостаток: глянцевая крышка, которую нужно постоянно протирать от пыли и отпечатков. Весь остальной корпус при этом нормальный, а на крышке вот оттянулся какой-то дизайнер очередной.
Да и в станках х86 для управления никто не применяет.
Да как сказать… Целая индустрия выпускает платы с интерфейсами COM-Express, QSeven, SMARC, ETX и т.п., которые ставят потом в станки, медицинское, измерительное и контрольное оборудование, и всякое такое. При этом там почти везде x86 (есть еще ARM, но не очень много), потому что по производительности и доступности нормального ПО архитектура х86 пока еще выигрывает с большим отрывом.
Использую NUC7i3 как домашнюю машину с Windows, плюс экспериментирую с прошивкой, потому что Интел не стали защищать ее BootGuard'ом, а сама она — одна из самых продвинутых и защищенных вариантов AMI AptioV на сегодняшний день. Историю с предустановкой копеечного Optane в единственный слот M.2 (который у меня занят нормальным SSD — Samsung SM951 NVMe) я не очень понимаю, но чем бы маркетологи не тешились.
По факту — нормальная замена не очень производительному десктопу, сильно не шумит, особо не греется, работает себе и в ус не дует. Все эти разноцветные лампочки отключаются в BIOS Setup, из разъемов не хватает только аудиоджека на задней панели, каких-то особо сильных глюков за полгода эксплуатации я не помню, а не особо сильные вылечились обновлением прошивки.
А если зарепортить вот прямо мне в Л/С? Постараемся исправить.
Понятно, что никто не будет приводить MacEFI к полному соответсвию спецификации UEFI 2.3+, но такие откровенные баги мы все же стараемся чинить.
Не стану спорить с вами, вам нравится — замечательно, покупайте, пользуйтесь. А я жду начала производства процессоров с открытой архитектурой RISC-V, для которых наконец-то можно будет написать полностью открытую прошивку и не опасаться, что твоим кодом и данными на самом деле управляет какая-то дрянь, написанная очередными «стратегическими партнерами АНБ».
Цель там основная — fTPM 2.0, который требуется для получения сертификата Windows 10 Pro Ready, все остальное — не более, чем приятный бонус. Реализовано оно все при этом достаточно плохо, и сильно мешает нормальной работе платформы, потому что на PSP зачем-то повесили все, до чего дотянулись руки: тренировку памяти, вывод системы из S3 sleep, хранение S3 BootScript'а, криптоускорение и кучу всего еще, сильно усложнив разработку и отладку прошивки (именно поэтому, кстати, нормальных прошивок все еще нет, ибо раньше ты сам мог отладить и починить все, что тебе в исходниках выдали, а теперь пиши репорты в АМД и жди, пока они сами починят, если вообще починят).
Я не упарываюсь тем, что все пропало, но с моей точки зрения как специалиста по безопасности прошивок, количество этих самых прошивок нужно уменьшать, а не увеличивать, иначе ни о какой безопасности через некоторое время речь вести уже не получится — слишком много будет векторов атаки на самый низкий уровень, где защищаться практически нечем. У АМД и так уже в процессоре и прошивка IMC, и прошивка контролера XHCI, и теперь вот PSP еще. И аудит исходников этих прошивок приходится у них буквально боем выбивать, а потом ездить к ним в офис, чтобы проводить его за закрытыми дверями.
Это все отлично, конечно, только вот Ryzen — первый CPU от AMD, в который добавили PSP, прошивка которого (основанная на Trustonic TEE) подписана и зашифрована, а сам он занимается на платформе тренировкой памяти, возвратом системы из S3, реализует fTPM 2.0 и криптоускорение, и неминуемо содержит бэкдоры от АНБ. У AMD был шанс выпустить нормальный производительный процессор, которому можно доверять, но вместо этого они догнали и перегнали Intel с их Management Engine, да еще и AGESA стали поставлять в виде BLOB'а, а ведь еще относительно недавно (в 2011) эти же люди обещали всегда поставлять ее в исходниках и поддерживать проект coreboot. В итоге, на рынке ни осталось ни одного процессора от Intel и AMD без «ядра обеспечения безопасности», и это печально.
Я не предлагаю не решать задачи совсем, я предлагаю решать практические задачи вместо олимпиадных, потому что от решения первых появляются навыки и полезное ПО, а от решения вторых — только навыки, а практически все написанное ПО — на выброс. Открытым проектам не хватает разработчиков, а потенциальные разработчики тем временем занимаются соревнованиями по решению задач, решение которых уже известно и никому не нужно. На мой взгляд, это печально.
Меня в олимпиадах по программированию смущает только то, что все усилия, направленные на решения задач, тратятся практически впустую, а само решение этих задач от обычного "боевого" программирования отличается так же, как морская свинка от дикого кабана.
Ребят, вместо того, чтобы зарабатывать себе строчку в резюме участием в олимпиадах, выберите задачу, у которой нет хорошего решения с открытым кодом и смело его пилите вместе с сообществом. Вам не хватает софта какого-то — напишите его!
Нерешенных практических задач — вагон и маленький бронепоезд, нужных открытых проектов — огромное количество, ваши усилия нужны там, а не соревнованиях по знанию алгоритмов!
Участвуйте в жизни сообщества, попробуйте поучаствовать в Google Summer Of Code, пишите код и статьи — и за это вам будут плюсы и в карму, и в резюме, и люди вам скажут большое спасибо за софт, который решает их практические задачи, а не выдуманные. Заодно вы научитесь код не только писать, но и поддерживать, отлаживать, рефакторить и удалять.
Практический опыт написания и поддержки программного продукта, на мой взгляд, намного ценнее опыта любых олимпиад, потому что для работы разработчика ПО нужен именно он.
Советую также посмотреть презентацию с 32c3 (видео, слайды) — When hardware must «just work», там очень хорошо пояснено, почему баги в процессорах до сих пор регулярно находятся, и почему сделать процессор без единого бага — практически нереально.
Непонятно, зачем называть ошибку (да еще и уже исправленную обновлением микрокода) «критической уязвимостью»?
Уязвимостью этот баг станет только тогда, когда с его помощью научатся обходить какие-то защитные механизмы процессора\прошивки\ОС, а пока это просто баг, один из многих, в прошлый раз так пришлось TSX на Haswell отключить.
Хороший пост, но с оценкой качества прошивки я не согласен — это обычный референс от AMI вообще без каких-либо доработок со стороны производителя, кроме базового бринг-апа. Хорошо это или плохо — сильно зависит от задач пользователя, но я могу точно сказать, что а) за 5 минут можно найти комбинацию настроек, которая либо никогда не тестировалась и не работает, либо вообще вешает машину намертво, б) никакая безопасность и защита от несанкционированного обновления прошивки там, скорее всего, не ночевала, и в) сопровождение прошивки никто осуществлять не будет, поэтому все баги и недоработки останутся там навсегда.
Короче, Intel NUC, с точки зрения прошивки — лучше на порядок, пусть и дороже.
И ладно бы просто реклама, так ведь еще и реклама откровенно низкокачественных товаров по 10 долларов за пучок. Хороший инструмент нужен и для работы, и для DIY, а с этом хламом вы только нервы зря потратите.
Ерунду говорят. Для EFI используются микросхемы QuadSPI NOR Flash с ~100к циклов записи\стирания, вот даташит на одну из самых популярных на данный момент микросхем. Если очень-очень стараться, чип можно вывести из строя, конечно, но это справедливо для любого оборудования.
По поводу включится ли — определенно, никакие данные с диска для работы прошивки не нужны. ОС, понятно, перестанет загружаться, но это дело поправимое.
Вынимают весь ассемблер в отдельные функции и (с учетом того, что соглашение о вызове известно) вызывают из потом из кода на С.
Такой подход, кстати, лучше вставок, т.к. и целевые машины, и ассемблеры бывают разные, и потому можно иметь несколько реализаций одной и той же функции в проекте и переключать их через систему сборки, а не через препроцессор, как это пришлось бы делать со вставками.
Да, нужно несколько драйверов для полноценной поддержки TPM 2.0 прошивкой. Вот тут лежат их открытые реализации, но у IBV обычно свои (сделанные из этих же, но пропатченные под свои нужды и для совместимости со своими платформами).
Да как сказать… Целая индустрия выпускает платы с интерфейсами COM-Express, QSeven, SMARC, ETX и т.п., которые ставят потом в станки, медицинское, измерительное и контрольное оборудование, и всякое такое. При этом там почти везде x86 (есть еще ARM, но не очень много), потому что по производительности и доступности нормального ПО архитектура х86 пока еще выигрывает с большим отрывом.
По факту — нормальная замена не очень производительному десктопу, сильно не шумит, особо не греется, работает себе и в ус не дует. Все эти разноцветные лампочки отключаются в BIOS Setup, из разъемов не хватает только аудиоджека на задней панели, каких-то особо сильных глюков за полгода эксплуатации я не помню, а не особо сильные вылечились обновлением прошивки.
А если зарепортить вот прямо мне в Л/С? Постараемся исправить.
Понятно, что никто не будет приводить MacEFI к полному соответсвию спецификации UEFI 2.3+, но такие откровенные баги мы все же стараемся чинить.
Я не упарываюсь тем, что все пропало, но с моей точки зрения как специалиста по безопасности прошивок, количество этих самых прошивок нужно уменьшать, а не увеличивать, иначе ни о какой безопасности через некоторое время речь вести уже не получится — слишком много будет векторов атаки на самый низкий уровень, где защищаться практически нечем. У АМД и так уже в процессоре и прошивка IMC, и прошивка контролера XHCI, и теперь вот PSP еще. И аудит исходников этих прошивок приходится у них буквально боем выбивать, а потом ездить к ним в офис, чтобы проводить его за закрытыми дверями.
и неминуемо содержит бэкдоры от АНБ. У AMD был шанс выпустить нормальный производительный процессор, которому можно доверять, но вместо этого они догнали и перегнали Intel с их Management Engine, да еще и AGESA стали поставлять в виде BLOB'а, а ведь еще относительно недавно (в 2011) эти же люди обещали всегда поставлять ее в исходниках и поддерживать проект coreboot. В итоге, на рынке ни осталось ни одного процессора от Intel и AMD без «ядра обеспечения безопасности», и это печально.Аналогично.
Я не предлагаю не решать задачи совсем, я предлагаю решать практические задачи вместо олимпиадных, потому что от решения первых появляются навыки и полезное ПО, а от решения вторых — только навыки, а практически все написанное ПО — на выброс. Открытым проектам не хватает разработчиков, а потенциальные разработчики тем временем занимаются соревнованиями по решению задач, решение которых уже известно и никому не нужно. На мой взгляд, это печально.
Меня в олимпиадах по программированию смущает только то, что все усилия, направленные на решения задач, тратятся практически впустую, а само решение этих задач от обычного "боевого" программирования отличается так же, как морская свинка от дикого кабана.
Ребят, вместо того, чтобы зарабатывать себе строчку в резюме участием в олимпиадах, выберите задачу, у которой нет хорошего решения с открытым кодом и смело его пилите вместе с сообществом. Вам не хватает софта какого-то — напишите его!
Нерешенных практических задач — вагон и маленький бронепоезд, нужных открытых проектов — огромное количество, ваши усилия нужны там, а не соревнованиях по знанию алгоритмов!
Участвуйте в жизни сообщества, попробуйте поучаствовать в Google Summer Of Code, пишите код и статьи — и за это вам будут плюсы и в карму, и в резюме, и люди вам скажут большое спасибо за софт, который решает их практические задачи, а не выдуманные. Заодно вы научитесь код не только писать, но и поддерживать, отлаживать, рефакторить и удалять.
Практический опыт написания и поддержки программного продукта, на мой взгляд, намного ценнее опыта любых олимпиад, потому что для работы разработчика ПО нужен именно он.
Это вы там еще прошивку не видели… Я до сих пор по ночам вздрагиваю, хотя уже больше года прошло с тех пор, как с линейкой Atom я больше не работаю.
Уязвимостью этот баг станет только тогда, когда с его помощью научатся обходить какие-то защитные механизмы процессора\прошивки\ОС, а пока это просто баг, один из многих, в прошлый раз так пришлось TSX на Haswell отключить.
Короче, Intel NUC, с точки зрения прошивки — лучше на порядок, пусть и дороже.
По поводу включится ли — определенно, никакие данные с диска для работы прошивки не нужны. ОС, понятно, перестанет загружаться, но это дело поправимое.