Компания Intel представила (https://newsroom.intel.com/news/intel-drives-innovation-soft.../) на проходящей в эти дни конференции OSTS (Open Source Technology Summit) несколько новых экспериментальных открытых проектов. В рамках инициативы ModernFW (https://github.com/intel/ModernFW) ведётся работа по созданию масштабируемой и безопасной замены прошивок UEFI и BIOS. Проект находится на начальной стадии развития, но на данном этапе разработки в предложенном прототипе уже имеется достаточно возможностей для организации загрузки ядра операционной системы. Проект базируется на наработках TianoCore (https://www.tianocore.org/) (открытая реализация UEFI) и возвращает изменения в upstream.
ModernFW нацелен на предоставление минималистичных прошивок, пригодных для использования на вертикально интегрируемых платформах, таких как серверы для облачных систем. На подобных системах нет необходимости в поддержании в прошивке кода для обеспечения обратной совместимости и компонентов для универсального применения, свойственных традиционным прошивкам UEFI. Избавление от лишнего кода снижает число возможных векторов для атак и ошибок, что положительно сказывается на безопасности и эффективности. В том числе ведётся работа по выносу из прошивки поддержки устаревших типов устройств и функциональности, которая может выполняться в контексте операционной системы.
Оставлены только необходимые драйверы устройств и предоставлена минимальная поддержка эмулируемых и виртуальных устройств. По возможности, задачи, которые могут выполняться на уровне ОС, переносятся на уровнень операционной системы. Часть кода совместно используется в прошивке и ядре ОС. Предоставляется модульная и настраиваемая конфигурация. Поддержка архитектур пока ограничена системами x86-64, а из загружаемых ОС пока поддерживается только Linux (при необходимости может быть реализована поддержка и других ОС).Одновременно компания Intel представила (http://lists.opendev.org/pipermail/rust-vmm/2019-May/00021) проект Cloud Hypervisor (https://github.com/intel/cloud-hypervisor), в рамках которого предпринята попытка создания гипервизора на основе компонентов
совместного проекта Rust-VMM (https://github.com/rust-vmm), в котором кроме Intel также участвуют компании Alibaba, Amazon, Google и Red Hat. Rust-VMM написан на языке Rust и позволяет создавать специфичные для определённых задач гипервизоры. Cloud Hypervisor является одним из таких гипервизоров, который предоставляет высокоуровневый монитор виртуальных машин (VMM), работающий поверх KVM и оптимизированный для решения задач, свойственных для облачных систем. В контексте интересов Intel основной задачей Cloud Hypervisor является запуск современных дистрибутивов Linux с использованием паравиртуализированных устройств на базе virtio.Поддержка эмуляции сведена к минимуму (ставка делается на паравиртуализацию). В настоящее время поддерживаются только системы x86_64, но в планах имеется и поддержка AArch64. Для избавления от лишнего кода и упрощения настройка CPU, памяти, PCI и NVDIMM производится на этапе сборки. Предусмотрена возможность миграции виртуальных машин между серверами. Из ключевых задач упоминается: высокая отзывчивость, низкое потребление памяти, высокая производительность и сокращение возможных векторов для атак.
URL: https://newsroom.intel.com/news/intel-drives-innovation-soft.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50690
лучше бы дали возможность выпилить к чертям свой ME/AMT.
Я слышал System76 и еще какая-то фирма отключает ME на своих ноутах.https://www.tomshardware.com/news/system76-disables-intel-me...,36030.html
https://www.reddit.com/r/linux/comments/7gpcu5/system76_will.../
https://www.reddit.com/r/Purism/comments/8j1d8w/killing_inte.../
Еще какая-то фирма - это наверное Purism (https://puri.sm/)
Полностью отключить нельзя.AMD: зачастую в настройках Биоса есть опция "отключить"
Intel: недокументированные бит в настройках ME, для включения нужен программатор.
Минусы - вы просите это ядро обеспечения безопасности отключить себя. То есть, вы доверяете тому, что оно это сделает. А раз вы ему доверяете, то зачем его отключать?
У Intel можно повредить сегменты прошивки, не критичные для запуска системы, что даёт чуть больше уверенности. Но, повторяю, совсем отключить PSP или ME невозможно. На них в целях удешевления (писать на сях проще, чем на верилоге) вынесены задачи, критичные для старта системы.
Если на реддите пишут обратно, то пишущий не разбирается в теме.
> Минусы - вы просите это ядро обеспечения безопасности отключить себя. То есть, вы доверяете тому, что оно это сделает. А раз вы ему доверяете, то зачем его отключать?Мы можем доверять тому, что базовый функционал в нём работает, но предполагать наличие уязвимостей. Отключать надо для уменьшения attack surface.
>AMD: зачастую в настройках Биоса есть опция "отключить"Фейк такой же как и у гигабайта для интел. Отключить PSP нельзя - он проводит тренировку памяти.
>Минусы - вы просите это ядро обеспечения безопасности отключить себя. То есть, вы доверяете тому, что оно это сделает. А раз вы ему доверяете, то зачем его отключать?
Не просто бит а еще и удаление модулей.
>Если на реддите пишут обратно, то пишущий не разбирается в теме.
Это у Вас наблюдается полнейшее непонимание темы, увы. Советую тратить больше времени на изучение любой темы.
а) Можно провести тренировку памяти и отключить.
б) Можно провести тренировку памяти программно (возможно, медленнее).
Вы уверены, что прочитали мой комментарий полностью? Потому что, вы повторяете ровно то, что я написал - отключить эти "ядра обеспечения безопасности" полностью невозможно, а у ME мы можем хотя бы часть прошивки повредить.
Open Firmware striking back!
> Open Firmware striking back!Учитывая, кто был инициатором и продвигальщиком UEFI … воистину: "сделай плохо, а потому верни как было!".
референсная реализация uefi тоже условно-открыта - из нее, собственно, и тянутся все горе-поделки для qemu и прочих, кое-как позволяющие загрузку современных ос.но вам лишь бы крякать.
P.S. "открыта", разумеется, в том смысле, что ее можно достать и собрать, а не в смысле что освящена мочой поедателя мозолей.
>> Учитывая, кто был инициатором и продвигальщиком UEFI
> референсная реализация uefi тоже условно-открыта - из нее, собственно, и тянутся все
> горе-поделки для qemu и прочих, кое-как позволяющие загрузку современных ос.
> но вам лишь бы крякать.А тепереь читаем еще раз первый абзац
>>> В рамках инициативы ModernFW ведётся работа по созданию масштабируемой и безопасной замены прошивок UEFIи вспоминаем, что это "условно-открытое референсное" по факту вылилось в повсеместно закрытую, оверинжинирнутую, жирную *рень с патентованными технологиями MS, типа PE и FAT32
Как там было?
"To implement FAT32 without infringing patents, don't use long file names."
http://en.swpat.org/wiki/Microsoft_FAT_patentsНо вам лишь бы бросаться на защиту обожаемого штеуда ...
>> В рамках инициативы ModernFW ведётся работа по созданию масштабируемой и безопасной замены
>> прошивок UEFIна базе tianocore, которая и представляет собой развитие когда-то выкинутого интелом в открытые источники кода.
А что оно будет patent-free - вам никто, между нами, и не обещал.> "To implement FAT32 without infringing patents, don't use long file names."
uefi их и не использует - BOOTX64.EFI
Когда бы https://ru.wikipedia.org/wiki/Open_Firmware - так нет, опять пилят убогий и вместе с тем over-engineered UEFI. И то уж хорошо, что делают его чуть менее ужасным.Ну и развитие паравиртуализации на замену нереальной поверхности атаки (и пастбищу багов) QEMU радует.
Но тут вспоминается "бойтесь данайцев, дары приносящих" :-|
Т.е. на десктопы они забили? Там пусть M$ со своим UEBI всех нагибает, да?
Да. Почему они должны за тебя беспокоиться? Обратись к своему диллеру шапочек из фольги.
эта фольга не для шапочек, укурки недоделанные!
Все эти инициативы интел - лажа лютая.
Да пусть пробуют. Может что-нибудь путное из Rust выйдет. В любом случае, опыт его использования здесь будет полезен.
Я бы сказал жизненно важный для раста. Ибо если корпорации не будут вливать, так и останется хипстерским языком.
> ведётся работа по созданию масштабируемой и безопасной замены прошивок UEFI и BIOSГосподи, опять?! Я думал уефи и была той самой "масштабируемой и безопасной заменой" биос.
>Я думал уефи и была той самой "масштабируемой и безопасной заменой" биосДействительно думал, или просто поверил дяде?
Штеуд! Оставь BIOS в покое! Займись процессорами!
У них и с процессорами как-то хреново получается.
BIOS тесно связан с процессорами, поэтому пусть и этим занимамаются. А вот гипервизоры, да, пусть отставят. А то как Mozilla, браузер стал получаться плохо - занялись чем угодно.
Осилят ли, у них вон процессоры дырявые
выкинуть все ненужное из UEFI, безусловно, б-гоугодно
Я лично никогда не понимал, вот нафейхоа в UEFI TCP\IP ..? Причём у некоторых аж сразу DualStack, v4\v6.
Вроде как для обновления по сети из самого себя. На деле - дыра на дыре и дырой погоняет.
кажется, идея была в возможности подсосать нужный для загрузки драйвер, а не тащить его вместе с платой. Но, как обычно, вышло слишком сложно и китайцы ниасилили - "как-нибудь с флэшки загрузитесь, драйвер для нее в комплекте есть".удаленную консоль через этот же механизм без всяких корявых поделок а-ля ilo - тоже никто не запрещал сделать. Но и не сделал никто ;-) потому что у хепе есть ilo, у леновы свое непотребство трех разных несовместимых и непохожих вариантов, а супермикра торговала отдельными ipmi модулями и их "активацией", и не собиралась прекращать.
А интелу все как-то было недосуг, у него уйозвимости в процессорах, все силы брошены на придумывание еще тридцати новых хуков в микрокоде.
Уже был кейген https://peterkleissner.com/2018/05/27/reverse-engineering-su.../
да хрен с ним с ключом - те у кого полные стойки супермикр, могут и заплатить (могут и пожмотиться, не топтопу же ж, а админу бегать перетыкать раздолбанные консольники, поэтому кому-то тот кейген очень даже в жилу)ты представь куда его пихать и каким образом все это устроено. Особенно когда у тебя там линукс (для винды возможно есть какая-нибудь чудо-приложуха, позволяющая обойтись без перезагрузки). Вот оно щастье-то, когда таких стоек и не одна...
Но это еще цветочки, ягодки - когда на какой-нибудь матери особо жестко извратились, и модуль для ipmi - отдельная микроплатка за отдельные деньги (с отдельным p/n) - подключаемая microusb (разумеется, только по разъемам, внутри какая-то своя шина) в жопку на матери. Вывести из сервиса, выключить, отковырять все разъемы, выковырять из стойки, ничего другого не задев, отковырять верхнюю крышку (обычно для этого из стойки надо снимать целиком), засунуть, воткнуть кабель, закрыть и собрать все в обратном порядке.
У этих китаез там пасти от икоты еще не лопнули, интересно?
А что uefi позволила бы без всего этого траходрома обойтись - им пофигу.
> удаленную консоль через этот же механизм без всяких корявых поделок а-ля ilo - тоже никто не запрещал сделать. Но и не сделал никто ;-)Не сделал. Потому что - нельзя. Чтоб это была полноценная консоль, с поддержкой всего функционала IPMI 2.0 - приходится лепить отдельный модуль (BMC), со своим процом и т.д.
> а супермикра торговала отдельными ipmi модулями и их "активацией", и не собиралась прекращать.
Отдельными модулями BMC торгуют все кому не лень, у супермикры он давно интегрирован на мать, как iLO или RSA.
И кстати "лицензия" у супермикро практически не накладывает ограничений - ну бивиса там нельза обновить удаленно например. Это тебе не iLO, где без лицензии ты не можешь даже удаленной консолью воспользоваться.
Так, немножко ясности:
* IPMI BMC (baseboard management controller) -- это _базовая_ фунциклинальность: питание, ресет, датчики и SoL, для неё достаточно микроконтроллера;
* IPMI SP (service processor) -- это _довески_ вроде iKVM, remote media, веб-морды и всего такого, которым и нужен уже более полновесный обычно ARM (которые массово паять прям на материнки стали как раз лет десять назад).Насколько припоминаю, BMC должен достаточно тесно сидеть на плате (или в своём разъёмчике), а вот SP от железа отвязан посильней (ему бы до BMC доступиться) и его выносить в отдельные модули должно быть проще.
Ну и раз расвпоминались -- железки/прошивки до IPMI 2.0 любили жрать чужие пакеты, если сконфигурировать на shared lan (или dedicated просто нет). Потом всё же пролечили.
pxe?
не, pxe это отдельная штуковина, внутри драйвера (или как там оно правильно) сетевой карты того уефи, и работает только при выборе ее в качестве источника загрузки.А есть еще отдельный api, позволяющий поднять полноценную сеть, доступную другим модулям. Пользы от него по факту никакой, вред вполне возможен.
> pxe?Немного возился с этим делом дома. Самое веселье то, что TFTP сервер смотрит ответ от сетевушки, которая намеревается стартануть по PXE. Есть несколько видов кодов (PC BIOS, EFI32 IFE64, ARM EFI вроде), и под каждый вариант надо делать своё меню со своим софтом (у меня пока что только BIOS-загрузка сделана, машинок с UEFI дома нет).
Спасибо, занятно -- я как раз в UEFI PXE и не стал уже копать тогда в 2012... (miniITX-материнку в Москве могу одолжить для стендика, специально тогда покупал, а сейчас на полочке лежит)
> гипервизор на языке RustНу наконец-то! А то мы уже беспокоились, что давно ничего достаточно хипстерского не анонсировали.
возможно оно будет виснуть пореже чем tomcat в vmware ?
Насколько можно понять, весь этот хруст там для управления, а внутри как была kvm, так и осталась.
Без qemu, похоже. Вот ее и заменяют хрустоподелкой.
Ну, наконец-то! А то я уж беспокоился, что новость с упоминанием Rust'а, а никто не отреагировал на Rust.
Чем бы дитя ни тешилось, лишь бы дыры из процессоров не выпиливало.
Обалдеть, Google пишет на Rust. Их там, что бешеная лисичка покусала? )))
Google очень большой - в нем и програмисты на Visual Basic может есть ...Проблема Go что kernel на нем не написать а вот на rust можно...
> Google очень большой - в нем и програмисты на Visual Basic может
> есть ...Надеюсь, на GWBasic хотя бы нету :D.
Очередной комбайн. Coreboot хватит всем
Кстати, у меня одни знакомые могут быть заинтересованы в специалистах по коребуту -- если кому охота совместить сколько-то приятное с полезным, можете маякнуть в почту ;-)
lf e;!
Безопасная для кого замена UEFI? Сам UEFI к примеру безопасен для Microsoft и в некоторой степени для производителя материнки, но для потребителя является довольно опасным.