Дело в том, что криптография — это раздел математики, а не разработки ПО, так что еще до того, как написать первую строчку кода, нужен положительный результат криптоанализа предложенного алгоритма (лучше всего в виде статьи в нормальном журнале, чтобы собрать критику со специалистов), иначе весь этот код — поделка на коленке, а использование такой "потреотичных" реализации — хуже, чем отсутствие шифрования вообще, т.к. дает ложное чувство защищенности.
Бремя доказательства лежит на авторах утверждений вроде "позволяет при сохранении уровня стойкости ограничиваться меньшим числом раундов", так что это не нам всем тут слабо взломать, а вам слабо предоставить не только алгоритм, но и результаты его анализа.
Спасибо огромное за исследования, наконец-то общественности стало известно то, что производители встраемового железа используют уже давно.
Интересно, что раньше этот бит хранился в дескрипторе:
К сожалению, отключать ME ни один производитель систем для широких народных масс (ну, за исключением Purism, наверное) не будет — Интел этот режим не поддерживает, PAVP работать перестает (т.е. HDCP для встроенной видеокарты придется заводить с серьезным таким бубном), да и вообще АНБ не велит не комильфо.
Отвечаю: замыкать надо вывод чипсета HDA_SDO на единицу (т.е. на 3.3В или 1.8В на Атомах). Если удобных площадок нет, надо работать с тем, что есть, но что будет от замыкания шестой ноги на питание — тут я не могу сказать наверняка, это зависит от модели аудочипа.
Добавлю, что в этом режиме дескриптор и все остальные регионы становятся открытыми на запись, а это в свою очередь весьма нехорошо для безопасности платформы. Использовать этот режим нужно только в случае, если регион ME поврежден и нежно его восстановление, а программатора под рукой нет или подключить его слишком сложно (привет новым системам с флешками в корпусе TFBGA24).
Вынимают весь ассемблер в отдельные функции и (с учетом того, что соглашение о вызове известно) вызывают из потом из кода на С.
Такой подход, кстати, лучше вставок, т.к. и целевые машины, и ассемблеры бывают разные, и потому можно иметь несколько реализаций одной и той же функции в проекте и переключать их через систему сборки, а не через препроцессор, как это пришлось бы делать со вставками.
Да, нужно несколько драйверов для полноценной поддержки 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, пишите код и статьи — и за это вам будут плюсы и в карму, и в резюме, и люди вам скажут большое спасибо за софт, который решает их практические задачи, а не выдуманные. Заодно вы научитесь код не только писать, но и поддерживать, отлаживать, рефакторить и удалять.
Практический опыт написания и поддержки программного продукта, на мой взгляд, намного ценнее опыта любых олимпиад, потому что для работы разработчика ПО нужен именно он.
Дело в том, что криптография — это раздел математики, а не разработки ПО, так что еще до того, как написать первую строчку кода, нужен положительный результат криптоанализа предложенного алгоритма (лучше всего в виде статьи в нормальном журнале, чтобы собрать критику со специалистов), иначе весь этот код — поделка на коленке, а использование такой "потреотичных" реализации — хуже, чем отсутствие шифрования вообще, т.к. дает ложное чувство защищенности.
Бремя доказательства лежит на авторах утверждений вроде "позволяет при сохранении уровня стойкости ограничиваться меньшим числом раундов", так что это не нам всем тут слабо взломать, а вам слабо предоставить не только алгоритм, но и результаты его анализа.
Примерно из этих соображений некоторые компании не используют никакие сетевые карты Intel в своих продуктах.
Актуально на всех чипсетах Intel, которые поддерживают descriptor mode, т.е. с ICH7 и до самых последних.
Это ничего еще, NVRAM который лежит на флеше — вот где засада.
Спасибо огромное за исследования, наконец-то общественности стало известно то, что производители встраемового железа используют уже давно.
Интересно, что раньше этот бит хранился в дескрипторе:
К сожалению, отключать ME ни один производитель систем для широких народных масс (ну, за исключением Purism, наверное) не будет — Интел этот режим не поддерживает, PAVP работать перестает (т.е. HDCP для встроенной видеокарты придется заводить с серьезным таким бубном), да и вообще
АНБ не велитне комильфо.Отвечаю: замыкать надо вывод чипсета HDA_SDO на единицу (т.е. на 3.3В или 1.8В на Атомах). Если удобных площадок нет, надо работать с тем, что есть, но что будет от замыкания шестой ноги на питание — тут я не могу сказать наверняка, это зависит от модели аудочипа.
Добавлю, что в этом режиме дескриптор и все остальные регионы становятся открытыми на запись, а это в свою очередь весьма нехорошо для безопасности платформы. Использовать этот режим нужно только в случае, если регион ME поврежден и нежно его восстановление, а программатора под рукой нет или подключить его слишком сложно (привет новым системам с флешками в корпусе TFBGA24).
Вынимают весь ассемблер в отдельные функции и (с учетом того, что соглашение о вызове известно) вызывают из потом из кода на С.
Такой подход, кстати, лучше вставок, т.к. и целевые машины, и ассемблеры бывают разные, и потому можно иметь несколько реализаций одной и той же функции в проекте и переключать их через систему сборки, а не через препроцессор, как это пришлось бы делать со вставками.
Да, нужно несколько драйверов для полноценной поддержки 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, пишите код и статьи — и за это вам будут плюсы и в карму, и в резюме, и люди вам скажут большое спасибо за софт, который решает их практические задачи, а не выдуманные. Заодно вы научитесь код не только писать, но и поддерживать, отлаживать, рефакторить и удалять.
Практический опыт написания и поддержки программного продукта, на мой взгляд, намного ценнее опыта любых олимпиад, потому что для работы разработчика ПО нужен именно он.