Ноль технической информации, зато SEO из текста просто течет.
Весь пост можно ужать до "мы добавили к карточкам 2FA через мобильное приложение". И люди, у которых по каким-то причинам нет смартфона, уже шлют вас в лес, а то и дальше.
Пожалуйста, не убивайте нам Хабр вот такими постами, а то он и так уже на ладан дышит.
Поддержку NVDIMM уже добавили в UEFI 2.5, доступные реализации которого на подходе вместе со следующим поколением десктопных процессоров Intel с микроархитектурой Kaby Lake. По поводу железа — инженерные образцы уже циркулируют, но до открытой продажи еще примерно с год. Что со стороны ОС — пока не знаю, железо подходящее его не попадало в руки.
Истинно так, причем использована реализация MD5 под GPL (/installer/legacy/md5.h, md5.cpp), при том, что MD5 используется во множестве проектов и под значительно более открытыми лицензиями (вот, к примеру, эпловская под LGPL, а вот эта вообще public domain, спасибо SD за нее). В общем, есть ощущение, что за лицензионной чистотой сильно не следили…
Ничего такого ни LGPL2.1, под которой выкладываются текущие версии Qt, ни LGPL3, под которой выйдет версия 5.7, не требуют.
Обе эти лицензии требуют делиться всеми изменениями в коде самой библиотеки, а в случае статической линковки — еще и объектными файлами, которые линкуются к ней. Код же продуктов, использующих LGPL-билиотеки, открывать вовсе не обязательно, и этим LGPL, по большому счету, и отличается от "большой" GPL.
Если интересны примеры из практики — при разработке на низком уровне иногда алгоритмы разные нужны позарез, а никаких библиотек нет и не предвидится. Чаще всего получается портировать существующий код, но его проще написать заново с учетом всех ограничений.
К примеру, в фазе PEI BeforeMem кучи нет совсем, а стека настолько мало, что большая часть параметров передается через регистры, а вызов функций происходит через прямой переход по известному адресу (т.е. все исполняемые файлы в этой фазе — XIP). Тем не менее, однажды пришлось реализовывать в таких условиях алгоритм Бойера-Мура-Хорспула.
В фазе DXE уже есть куча и много-много памяти, но нет стандартной библиотеки, поэтому некоторые вещи все равно приходится переписывать или портировать, недавно занимался реализацией функции Argon2 в виде DXE-драйвера, к примеру. Из менее "серьезных алгоритмов" — иногда нужны конечные автоматы (для драйверов устройств), сортировки (там же, плюс список загрузочных устройсв надо иногда сортировать, но там хватает вообще любого алгоритма почти всем), разные виды поиска, в общем — вроде бы мелочь, но всю её приходится писать самому, т.к. библиотек никаких нет.
Я не имел в виду только быстроту, скорее упомянутую выше "внутреннюю кривизну архитектуры". Признаюсь честно и публично — мне абсолютно до лампочки внутренняя архитектура Qt при написании GUI-приложений на нем, пока не приходится лезть внутрь библиотеки с молотком и паяльником. Я знаю, что "некрасивый самолёт не может летать", но я бы не назвал ни саму Qt, ни код, который получается писать с её использованием очень уж уродливыми. Да, макросы, да, MOC, да, кое-где можно сделать лучше, только вот альтернатив толковых многим классам QtCore (да тому же, прости рандом, QString) я так и не смог подобрать.
Есть две категории ПО — "моя программа работает в 10 раз быстрее твоей и имеет в разы более красивый код" и "ага, зато моя работает", и Qt — яркий представитель второй категории.
Я недавно отвязывал движок своего OpenSource-проекта от Qt (по лицензионным причинам, LGPL нравится не всем), и пришлось столкнуться лицом к лицу с "голым" C++, в котором даже директорию на ФС нельзя создать кроссплатформенным образом, не говоря уже о нормальной поддержке UCS2, локализации, дизайнера UI и чертовой прорвы всего остального, ради которого я готов потерпеть MOC, даже если он будет всегда.
Ничего не скажу про Эльбрус, т.к. не в курсе, но у AMD даже в системах без PSP достаточно закрытых компонентов, которые имеют доступ к внутренностям SoC. К примеру, контролеру XHCI нужна бинарная прошивка, т.к. он был приобретен у строннего поставщика IP-ядер, система управления частотами и питанием (SMU) сделана на контролере Lattice и тоже имеет бинарную закрытую прошивку, в которой уже находили уязвимости, встроенный EC тоже нуждается в бинарной прошивке, и так далее.
По факту, на x86 уже давно толком ничего не остается, и если вас не связывает с этой архитектурой груз обратной совместимости, то лучше свои безопасные системы делать на какой-нибудь более другой.
Т.к. именно OEM решает, какие модули поставлять, вместе с этим решается и вопрос с драйверами. Кто-то поставляет минимальный драйвер heci.sys на пару десятков килобайт, а кто-то другой — полный пакет с софтом и службами для поддержки PAVP и DAL.
Для своих плат Intel выкладывает пакет драйверов для МЕ, вот, к примеру для NUC.
Только самому собирать. Coreboot для этих машин недоступен, насколько я знаю, а из UEFI можно удалить лишнее, используя UEFITool и программатор. Если интересно, посмотрите мое выступление на ZeroNights2015 и слайды к нему, я там как раз рассказывал о модификации прошивки ноутбука с Insyde H2O.
Посмотрел, ничего особенного. WPBT поддерживается, но самой таблицы в прошивке нет, только драйвер для нее, используется устаревший интерфейс IHISI при наличии более нового UEFI Capsule, т.е. обладая инженерными утилитами Insyde можно прошить вредоносный код, следов Computrace/LoJack я не нашел, BootGuard/BiosGuard тоже отключены. Плюс видна защита от повреждения S3 BootScript'а и NVRAM, так что общий уровень защиты прошивки я бы оценил как "выше среднего", если смотреть только по бинарю.
Бороться, писать статьи, поддерживать разработчиков открытого железа (LowRISC, OpenRISC, MIPS, даже Quark и Minnowboard от Intel, которые "открытее", чем все остальное) финансово и информационно, свести к минимуму использование закрытых продуктов, в общем — голосовать ногами. Либо расслабиться и попытаться получить удовольствие от процесса, утешая себя тем, что "честным людям скрывать нечего", "кому я нужен, такой незначительный" и т.п.
Идеи хактивизма и свободы — они отличные, но очень мало кто хочет за них бороться. Единицы говорят о том, что состояние стоит читать вредным, десятки задумываются о том, что закрытую платформу без возможности аудита её пользователем вообще не стоит считать сколько-нибудь "своей" или "безопасной", сотни готовы покупать полностью открытые продукты даже если за это придется заплатить и деньгами, и доступными возможностями, и временем на настройку. При этом миллионы идут в walled garden совершенно добровольно, покупают себе смартфоны, которые следят за ними 24/7/365, устанавливают Windows 10, встраивают чужой дырявый код в лампочки и дверные замки — в общем, издеваются над самой идеей информационной безопасности, анонимности, свободы и всего остального, и индустрия ориентируется именно на них, ибо им можно продать что угодно, если завернуть это в красивую обертку и рассказать, что в этом сезоне это модно.
Я помню времена, когда скандалом была любая программа, которая "звонила домой". Прошло 10 лет, и теперь "домой" звонят даже пуговицы на "умной" одежде, а обычный вроде-бы телефон обладает таким количеством датчиков и такой вычислительной мощностью, что его можно смело использовать как полетный контролер для ракет средней дальности. При этом все вокруг радостно приветствуют такой прогресс. Вот такая вот лирика, от которой хочется матом разговаривать.
Добавлю, что у Lenovo это скорее всего Computrace (удаленное управление и блокировка) и WPBT (ACPI-таблица для запуска хранящегося в прошивке кода после установки или переустановки Windows). Если укажете конкретную модель — могу посмотреть и сказать точнее.
Моветон, наверное, отвечать на риторические вопросы, но скорее всего правильный ответ — нет.
С другой стороны, задача ИБ — не в том, чтобы быть уверенным на 100%, а в том, чтобы сделать получение информации дороже самой информации. Т.е. если нужно обрабатывать что-то совершенно секретное — лучше разрабатывать и производить все вычислительные устройства самостоятельно на своих мощностях, а если нужно читать твиттер и постить котиков — подойдет железо с любыми бэкдорами, которые этому не мешают.
Идеальный компьютер для бизнеса без TPM, без SecureBoot, без защиты от вредоносных OROMов и с прошивкой стандарта EFI 1.10 выпуска 2007 года. Энтерпрайз во все поля.
Все, что не находится прямо на чипе, можно выпилить при наличии сильного желания, пары хороших специалистов и некоторого количества времени. В данном же случае для двухчиповых решений для избавления от МЕ придется разрабатывать собственный PCH, а для SoC — смиряться и получать удовольствие. В конце концов, можно купить сервер на Intel Xeon без iDRAC и iLO, а вот без ME — уже нет.
Принципиально — уровнем интеграции. Карту IPMI можно вынуть или отключить от питания, BMC выпаять с платы и выпатчить его инициализацию из прошивки, а здесь приходится либо мириться с тем, что МЕ есть и будет есть, либо платить Intel кучу денег за его отключение, которое все равно не совсем полное.
Integrated Clock Control (управление частотами и разгон)
Firmware TPM (программный TPM 2.0, появился недавно)
Protected Audio-Video Path (защита медиаконтента от перехвата во время просмотра, DRM в общем)
Dynamic Application Loader (загрузка и исполнение подписанных Intel Java-апплетов)
Все остальное — зависит от OEM, кто-то покупает еще модулей, а кто-то старается от DAL и PAVP избавиться.
Никакие возможности MEBx и удаленного администрирования декларируются недоступными для Consumer-вариантов ME, но что там по факту — знают 3,5 специалиста из Intel.
Отличная обзорная статья, спасибо.
Рад, что с 2009 года никаких серьезных уязвимостей в МЕ не нашли, спасибо SeCoE за это. С другой стороны, грустно, что приходится слепо доверять неизвестному коду, имеющему слишком большие привилегии и при этом наглухо закрытому даже от анализа.
Если вам не нравятся процессоры с подобными "подсистемами обеспечения безопасности" — у AMD еще есть десктопные процессоры без PSP, а вот последним ноутбучным было семейство eKabini, все более новые SoC серии Falcon — уже даже память через PSP тренируют и S3 resume им же делают, так что там теперь еще большее болото, чем с ME у Intel.
Весь пост можно ужать до "мы добавили к карточкам 2FA через мобильное приложение". И люди, у которых по каким-то причинам нет смартфона, уже шлют вас в лес, а то и дальше.
Пожалуйста, не убивайте нам Хабр вот такими постами, а то он и так уже на ладан дышит.
Ничего такого ни LGPL2.1, под которой выкладываются текущие версии Qt, ни LGPL3, под которой выйдет версия 5.7, не требуют.
Обе эти лицензии требуют делиться всеми изменениями в коде самой библиотеки, а в случае статической линковки — еще и объектными файлами, которые линкуются к ней. Код же продуктов, использующих LGPL-билиотеки, открывать вовсе не обязательно, и этим LGPL, по большому счету, и отличается от "большой" GPL.
К примеру, в фазе PEI BeforeMem кучи нет совсем, а стека настолько мало, что большая часть параметров передается через регистры, а вызов функций происходит через прямой переход по известному адресу (т.е. все исполняемые файлы в этой фазе — XIP). Тем не менее, однажды пришлось реализовывать в таких условиях алгоритм Бойера-Мура-Хорспула.
В фазе DXE уже есть куча и много-много памяти, но нет стандартной библиотеки, поэтому некоторые вещи все равно приходится переписывать или портировать, недавно занимался реализацией функции Argon2 в виде DXE-драйвера, к примеру. Из менее "серьезных алгоритмов" — иногда нужны конечные автоматы (для драйверов устройств), сортировки (там же, плюс список загрузочных устройсв надо иногда сортировать, но там хватает вообще любого алгоритма почти всем), разные виды поиска, в общем — вроде бы мелочь, но всю её приходится писать самому, т.к. библиотек никаких нет.
Я недавно отвязывал движок своего OpenSource-проекта от Qt (по лицензионным причинам, LGPL нравится не всем), и пришлось столкнуться лицом к лицу с "голым" C++, в котором даже директорию на ФС нельзя создать кроссплатформенным образом, не говоря уже о нормальной поддержке UCS2, локализации, дизайнера UI и чертовой прорвы всего остального, ради которого я готов потерпеть MOC, даже если он будет всегда.
По факту, на x86 уже давно толком ничего не остается, и если вас не связывает с этой архитектурой груз обратной совместимости, то лучше свои безопасные системы делать на какой-нибудь более другой.
Для своих плат Intel выкладывает пакет драйверов для МЕ, вот, к примеру для NUC.
Я помню времена, когда скандалом была любая программа, которая "звонила домой". Прошло 10 лет, и теперь "домой" звонят даже пуговицы на "умной" одежде, а обычный вроде-бы телефон обладает таким количеством датчиков и такой вычислительной мощностью, что его можно смело использовать как полетный контролер для ракет средней дальности. При этом все вокруг радостно приветствуют такой прогресс. Вот такая вот лирика, от которой хочется матом разговаривать.
С другой стороны, задача ИБ — не в том, чтобы быть уверенным на 100%, а в том, чтобы сделать получение информации дороже самой информации. Т.е. если нужно обрабатывать что-то совершенно секретное — лучше разрабатывать и производить все вычислительные устройства самостоятельно на своих мощностях, а если нужно читать твиттер и постить котиков — подойдет железо с любыми бэкдорами, которые этому не мешают.
Все остальное — зависит от OEM, кто-то покупает еще модулей, а кто-то старается от DAL и PAVP избавиться.
Никакие возможности MEBx и удаленного администрирования декларируются недоступными для Consumer-вариантов ME, но что там по факту — знают 3,5 специалиста из Intel.
Рад, что с 2009 года никаких серьезных уязвимостей в МЕ не нашли, спасибо SeCoE за это. С другой стороны, грустно, что приходится слепо доверять неизвестному коду, имеющему слишком большие привилегии и при этом наглухо закрытому даже от анализа.
Если вам не нравятся процессоры с подобными "подсистемами обеспечения безопасности" — у AMD еще есть десктопные процессоры без PSP, а вот последним ноутбучным было семейство eKabini, все более новые SoC серии Falcon — уже даже память через PSP тренируют и S3 resume им же делают, так что там теперь еще большее болото, чем с ME у Intel.