Рональд Минних (Ronald Minnich), основатель проекта CoreBoot,
выступил (https://osseu17.sched.com/event/ByYt/replace-your-exploit-ri... на завершившейся несколько дней назад конференции LinuxCon с докладом (https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI&... в котором рассказал о развиваемом в Google открытом проекте NERF (https://github.com/osresearch/heads/tree/nerf) (Non-Extensible Reduced Firmware).В рамках NERF предпринята попытка разработки прозрачной и открытой замены прошивкам UEFI, в основе которой использовано ядро Linux и урезанное программное окружение. Конечной целью является предоставление средств для замены (UEFI) или отключения (SMM, Intel ME) всех прослоек, выполняемых вне основной операционной системы, и блокирования любой связанной с UEFI и Intel ME фоновой активности.
NERF также рассчитан на снижение векторов возможных атак, расширение возможностей по контролю за активностью прошивок, исключение излишней функциональности (например, TCP-стек и web-сервер), удаление встроенных механизмов обновления в пользу обновления из базового Linux-окружения. В состав NERF входит избавленный от блобов упрощённый вариант прошивки для Intel ME (Management Engine), урезанная прошивка для UEFI, код для отключения SMM, ядро Linux, образ initramfs c системой инициализации и инструментарием u-root (http://u-root.tk/), написанными на языке Go.В прошивке для Intel ME оставлены только компоненты для начальной инициализации CPU, все остальные модули удалены (https://www.opennet.me/opennews/art.shtml?num=47091) при помощи инструментария me_cleaner (https://github.com/corna/me_cleaner) (прошивка сокращена с 5 Мб до 300 Кб). Код обработчиков SMM (https://ru.wikipedia.org/wiki/System_Management_Mode) (System Management Mode) также отключен и переведён на обработку прерываний SMI через ядро Linux.
Прошивка для UEFI переведена на использование ядра Linux, наработок CoreBoot и инструментария u-root (https://github.com/u-root/u-root). U-root написан на языке Go и включает в себя легковесную систему инициализации, оболочку rush и набор типовых утилит (https://github.com/u-root/u-root/tree/master/cmds), таких как cp, mv, ls, grep, sort, dd, insmod, wget, netcat и т.п.
Примечательно, что в формируемый при помощи u-root образ корневой ФС включается лишь процесс инициализации и несколько исполняемых файлов с компилятором языка Go. Все команды собираются только при необходимости - если запущенная утилита не была собрана ранее, то её компиляция осуществляется на лету после попытки первого запуска. Результат компиляции вызванной утилиты помещается в tmpfs и доступен для повторного использования в рамках текущего сеанса.
Таким образом, в u-root все утилиты предлагаются в исходных текстах, а для адаптации инструментария требуется лишь настройка компилятора. Компиляция занимает доли секунды и не приводит к ощутимым задержкам при вызове. Подобный подход позволяет сделать образ u-root универсальным и распространять единый образ корневой ФС для всех платформ, поддерживаемых компилятором языка Go (для каждой новой архитектуры требуется лишь подготовить 4 исполняемых файла, в одном образе могут содержаться сборки компилятора для разных архитектур). Дополнительно предусмотрены варианты c компиляцией всех утилит во время загрузки или поставки готовых сборок (для минимизации размера прошивки все утилиты могут быть собраны в один исполняемый файл, по аналогии с busybox).
Необходимость замены UEFI обусловлена тем, что на современных компьютерах параллельно с основной операционной системой по сути параллельно выполняется ещё несколько неконтролируемых программных окружений (UEFI, SMM, Intel ME), которые формируются на основе проприетарных прошивок. Код UEFI продолжает работать после загрузки основной ОС и выполняется на уровне кольца защиты Ring -2 (https://en.wikipedia.org/wiki/Protection_ring). Данные закрытые окружения создают дополнительные угрозы безопасности. Например, внедрённый в прошивку UEFI вредоносный код может оставаться невидимым из основной ОС, но полностью контролировать всю систему.В частности, ресурс WikiLeaks в этом году раскрыл (https://wikileaks.org/vault7/) сведения о разработке в ЦРУ имплантов (https://wikileaks.org/ciav7p1/cms/page_13763820.html) для контроля за системой, внедряемых в прошивки UEFI. Современные прошивки сильно усложнены и включают многие атрибуты обычных ОС, включая TCP-стек, http-сервер, DHCP, драйверы, файловые системы и web-интерфейс. С учётом значительного размера кодовой базы прошивок UEFI, которая составляет около 2 млн строк кода, и недоступностью кода прошивок для независимого аудита, также возникают опасения о наличии в прошивках большого количества неисправленных уязвимостей (https://www.opennet.me/opennews/art.shtml?num=44740).
URL: https://news.ycombinator.com/item?id=15579592
Новость: http://www.opennet.me/opennews/art.shtml?num=47469
Coreboot, который взлетит?
Если я правильно понимаю, Coreboot занимается только инициализацией железа, дальше управление передаётся в payload, а там может быть что хочешь (https://ru.wikipedia.org/wiki/Coreboot), в том числе TianoCore.Так что это альтернатива TianoCore
Более всего радует, что google активно участвует в разработке coreboot и есть прекрасные шансы на то, что вся это радость уйдет в глубокий опенсорс.
Гугл коммерческая компания, они это делают для своих серверов, которые они разрабатывают вместе с фейсбуком, вряд ли что-то из этого запустится на обычном ibm pc из магазина.
Типа-нерасширяемая замена uefi. Но вот интересно, зачем там встроенный компилер go если оно "нерасширяемое"? Надо было git еще встроить - если имплант в rootfs сразу не взлетел, можно будет пропатчить. А если напортачили - откатить.
>UEFI переведена на использование ядра ... u-root.
>U-root написан на языке GoСборщик мусора в биосе? Нет пути.
Пофиг. Там не создается столько объектов, что бы сборщик мусора смог налажать, и, наверно, его можно оптимизировать-подтюнить-отключить в таком случае.Смотри на это со стороны "скрипты в биосе", которые транслируются в байткод для оптимизации. Если это всё дело взлетит на армах и других не-x86 - это будет победа.
Нахера гадать сколько там объектов создается, налажает или нет GC, что-то там тюнить-хуюнить-оптимизировать, если можно написать на C и/или ASM?
оно придумано ПРОТИВ утечек памяти и переполнений стека, а не ДЛЯ.
тогда уже Rust.
Конкурент же.
Никто не мещает. Пиши на Rust, если осилишь. Что за дурная привычка тех, кто нихрена не делает тем, "советовать" тем кто решил что-либо сделать. Да хоть тетрис Гугел на своем Go сваяет, это их личное дело, тебе никто ничего не навязывает.
> Что за дурная привычка тех, кто нихрена не делает тем, "советовать" тем кто решил что-либо сделать.Страна Советов, однако.
А давайте напишем аналог UEFI на JavaScript. Это же самый безопасный и популярный язык!
Тогда зачем там Линукс, к-й на С?
> оно придумано ПРОТИВ утечек памяти и переполнений стека, а не ДЛЯ.Правильно, со встроенным компилером импланты можно догружать как белый человек, без всяких эксплойтов. Залил сорец, скомпилилось, красота.
Потому что меньше шансов получить уязвимость в таком интимном месте.
Если нет сетевого стека, следовательно удалённого доступа, то ББ не поэкслуатирует. А локальная уязвимость в момент загрузки как-то мало полезна.
чей-то нет-то? В Твоей системе нет сетевого стека?
>исключение излишней функциональности (например, TCP-стек и web-сервер)
Ага, а теперь срочно беги ставить CoreBoot, потому что 100% всех x86 BIOS уязвимы.
если можно написать на C и/или ASM? - можно. пишите. уверен, ребята из треда только за. если создадите на github запись то, достигнув зрелости проекта наверняка найдете последователей.а ребята из гугола решили на go писать. вполне может быть потому и только лишь потому, что любят они это дело.
Потому что быстрее и проще, а профита от C (а тем более ассемблера) там - никакого - это довольно высокоуровневый код.
> если можно написать на C и/или ASM?Так и быть, разрешаю писать на Си или Assembly!
>Нахера гадать сколько там объектов создается, налажает или нет GC, что-то там тюнить-хуюнить-оптимизировать,Тут ты прав - гадать не надо, в Го есть инструментов чтоб знать _точно_. Сюрприз?
>если можно написать на C и/или ASM?ну а чё ж _ты_ не написал? Впрочем ладно - ты, лузер, но ведь и годные проггеры что то не очень чтобы и написали годное ... coreboot так и не взлетел если чё ...
Может хоть это взлетит (скрестил пальцы)
Если это всё дело взлетит на армах и других не-x86 - это будет победа. - в arm/mips обычно device tree. там обычно нет bios. bios это обычно x86 костыль.понятное дело есть исключения.
> Сборщик мусора в биосе? Нет пути.То есть целый linux тебя не смутил, а вот сборщик мусора чем-то не нравится?
> То есть целый linux тебя не смутилна некоторых ранних чипсетах интел там целый солярис - и ничего, жуем...
430-х или 440-х, или ещё ранее? ;)
не, не настолько - по-моему, началась эта радость с ICH7 (в общем-то уже преданье старины глубокой), но тогда там была какая-то неведомая rtos, причем встроенная в (встроенную) интеловскую сетевуху.А вот к ich9 все наладилось - процессор сменили на sparc-совместимый, ось на какой-то кастрированный клон солярки, ни за что не угадаешь, зачем.
А отгадка очень простая - оно на ЖАБЕ было ;-) (кому там go в загрузчике не нравитсо? ;-)
Пару лет назад на сайте интела еще можно было найти красивых картинок, в каких версиях какой именно марки анальный зонд и с какой резьбой (откуда, собственно, сокровенное знание и берется). Но после известных событий что-то, похоже, все попрятали. (или до? Паковка неведомыми кодами началась задолго до истории с дырой в amt)
> А вот к ich9 все наладилось - процессор сменили на sparc-совместимый, ось на какой-то кастрированный клон солярки, ни за что не угадаешь, зачем.А теперь стало совсем просто: стандартный x86 intel quark. И поэтому посыпались сообщения об успехах с обличениями и обходом ME. Для анализа x86 опыта собрано поболее.
У AMD был 32-х битный opensource процессор LatticeMico32 в их x86 процессорах, но памяти на полноценную ОС там явно не хватает:https://events.ccc.de/congress/2014/Fahrplan/events/6103.html
https://events.ccc.de/congress/2014/Fahrplan/system/attachme...
Точно, надо было (как и сам Intel) взять Minix.
OS для микроконтроллеров, много их.
Я за BugurtOS ;)
>> Сборщик мусора в биосе? Нет пути.
> То есть целый linux тебя не смутил, а вот сборщик мусора чем-то
> не нравится?Что ты имеешь против линукса на компьютере? Подразумевается, же что то же ядро и будет все дальше грузить и обслуживать, разве нет?
> Подразумевается, же что то же ядро и будет все дальше грузить и обслуживать, разве нет?Нет.
Не-е-е-е-е-ет…
Там особый, уличный линукс, после которого будет уже грузиться загрузчик и потом ось. Ну или напрямую, без внешнего загрузчика.
> То есть целый linux тебя не смутил, а вот сборщик мусора чем-то
> не нравится?В линуксе тоже несколько сборщиков мусора есть. А хотя-бы и на си :)
> В линуксе тоже несколько сборщиков мусора есть. А хотя-бы и на си :)Что поделать, если знатоки не в курсе наличия аналога сборщика мусора в реализациях аллокаторов.
> Что поделать, если знатоки не в курсе наличия аналога сборщика мусора в
> реализациях аллокаторов.Там не в аллокаторах дело. Некоторые ресурсы таки тоже собираются сборщиком мусора, по каким-то своим причинам. Например, сисколы можно ускорить если ресурсы не освобождать немедленно после завершения операции. К тому же если однотипным ресурсом захочет попользоваться кто-то другой, можно не выделять его еше раз.
>> Что поделать, если знатоки не в курсе наличия аналога сборщика мусора в
>> реализациях аллокаторов.
> Там не в аллокаторах дело. Некоторые ресурсы таки тоже собираются сборщиком мусора,Это да. Но насчет аллокатора, скорее был намек на то, что и классический free/malloc обычно таки иногда должен проверять и мержить блоки (и делать другие телодвижения), чтобы избежать излишней фрагментации.
>Сборщик мусора в биосе? Нет пути.В интел ME среди прочего, реализована, цитата:
>Загрузка и исполнение подписанных Intel Java-апплетовJAVA апплетов Марк!
А как без джавы в биосе поднять графовую базу данных?
Дык эта ... _лучшая_ графовая БД сделанна на ... ТА_ДАМ! ... сделано на Go :)
> В интел ME среди прочего, реализована, цитата:
>>Загрузка и исполнение подписанных Intel Java-апплетов
> JAVA апплетов Марк!чего тебя удивляет, весь пресловутый AMT, насколько я понял, сплошная (server-side, да) жаба. Может даже EE ;-)
Надо было писать на раст. Но rust is not invented in google.
> Надо было писать на раст. Но rust is not invented in google.
> rust is not invented in google.А знатокам истинных языков и парадигм надо было не слишком прогуливать английский.
что-то не так?
> что-то не так?Все так. Ин, бай - и правда, какая разница?
Главное и далее нахваливать ЯП, норамально изучать который пока что можно только на английской мове.
>> что-то не так?
> Все так. Ин, бай - и правда, какая разница?Почему нет? Invented in Russia.
Или на митапах в коворкингах только шаблонными фразами научили изъясняться?> Главное и далее нахваливать ЯП, норамально изучать который пока что можно только
> на английской мове.То есть любой ЯП.
>>> что-то не так?
>> Все так. Ин, бай - и правда, какая разница?
> Почему нет? Invented in Russia.
> Или на митапах в коворкингах только шаблонными фразами научили изъясняться?Не знаю, чему вас там учили на митапах и коворкингах, а разницу между "Кем/Чем?" и "Где?" и частую некорректность дословного перевода нам еще в школе объясняли.
Invented by Vasya Pupkin/Google. Invented in Russia/Muchosransk.>> Главное и далее нахваливать ЯП, норамально изучать который пока что можно только на английской мове.
> То есть любой ЯП.Ну почему, мейнстримные языки вполне можно изучать почти совсем не зная английского.
Опять же, необязательны только крайности "прекраснейшее владение языком" и "абсолютное незнание".
> Не знаю, чему вас там учили на митапах и коворкингах, а разницу
> между "Кем/Чем?" и "Где?" и частую некорректность дословного перевода нам еще
> в школе объясняли.Гугл может быть и кем и чем и где.
>>> норамально изучать который пока что можно только на английской мове.
>> То есть любой ЯП.
> необязательны только крайности "прекраснейшее владение языком" и "абсолютное
> незнание".Написано было 'нормально изучать' ЯП. Именно нормально именно изучать именно ЯП.
>> Не знаю, чему вас там учили на митапах и коворкингах, а разницу
>> между "Кем/Чем?" и "Где?" и частую некорректность дословного перевода нам еще
>> в школе объясняли.
> Гугл может быть и кем и чем и где.Жопа тоже может быть и кем и чем и где. Тем не менее …
>>>> норамально изучать который пока что можно только на английской мове.
>>> То есть любой ЯП.
>> необязательны только крайности "прекраснейшее владение языком" и "абсолютное
>> незнание".
> Написано было 'нормально изучать' ЯП. Именно нормально именно изучать именно ЯП.Читать в контексте, не?
А "владение языком", в этом случае, относится к знанию английского.
Я за питон, немножечко эрланга, обёрточку на руби и интерфейс на пхп.
и плангины на nodejs
что-нибудь сегодня употребляли? (:
а что есть закон обязующий все сборщики мусора работать плохо? да и в общем-то этот "инструментарий" U-root не в биосе, а вокруг него.( что забавно там есть два описания в одном 4 не гошных бинаря в другом уже 5)
>>UEFI переведена на использование ядра ... u-root.
>>U-root написан на языке Go
> Сборщик мусора в биосе? Нет пути.Да щаз:
http://www.opennet.me/opennews/art.shtml?num=35973
http://www.opennet.me/opennews/art.shtml?num=39018
> отключения (SMM, Intel ME)Жаба и гадюки
Звучит как просто сказка какая-то!> В прошивке для Intel ME оставлены только компоненты для начальной инициализации CPU, все остальные модули удалены при помощи инструментария me_cleaner
А на сколько это законно - распространять прошивки с обрезками IntelME?
Одно дело когда Вася из соседнего подъезда выложил на гитхаб скрипт для чистки блобов. Его интел судить не будет. Во-первых, он не блобы выложил, а свой собственный скрипт, во-вторых, всё равно взять с него нечего.
А тут гугл, да сразу с блобами. Или автор новости что-то не так перевёл?
> А на сколько это законно - распространять прошивки с обрезками IntelME?Они распространяют чистилку прошивки, который из Flash убирает всё лишнее. Т.е. урезают оригинальную прошивку, ничего не распространяя.
> А тут гугл, да сразу с блобами. Или автор новости что-то не так перевёл?17 слайд:
NERF components
* De-blobbed ME ROM
* UEFI ROM reduced to its most basic parts
* SMM disabled or vectored to Linux
* Linux kernel
* Userland written in Go (http://u-root.tk)
Так МЕ содержит Миникс - он же открытый, разве нет?
> Так МЕ содержит Миникс - он же открытый, разве нет?Миникс-то открытый, а вот МЕ - нет. Да и большой вопрос: Миникс ли там вообще?
Исследователи писали что он. По крайней мере в части версий МЕ.
> Исследователи писали что он. По крайней мере в части версий МЕ.интел писал - прямо у себя на сайте. где-то там была табличка развития поколений этой хрени, правда, со второй, а не первой.
после очередного редизайна куда-то подевалась. случайно, наверное.
>Миникс-то открытый, а вот МЕ - нет.respect BSDL
Надо. Обязательно надо.
Много лет у нас был BIOS, который умел довольно много, но был прост и понятен.
Потом оказалось, что большая часть программ в BIOSе написаны абы как и ОС перестали использовать BIOS для обращения к дискам, видео и т.п.
Потом нам дали UEFI, котрый вообще умел чёрт знает что, который можно было научить далать ещё больше, но ОС не стали использовать всё это поскольку оно всё равно было глючным и тормознутым.
И теперь Гугл предлагает обрезать UEFI, но впихнуть в него ядро Линукс (урезать, ага).
А может всё таки стоило бы вернуться к истокам и просто убрать из BIOSа неиспользуемые ф-ции и пусть он занимался бы тем, чем фактически занимался при своей жизни: инициализацией железа и передачей управления загрузчику?
Но нет, мы впихнём Линукс для загрузки Линукса. И назовём это упрощением.
> Много лет у нас был BIOSэто у вас на x86 был биос
А UEFI есть разве на других платформах?
> А UEFI есть разве на других платформах?Если я не совсем глюкую - на армах вроде тоже оно водится.
Верно, в aarch64 только UEFI, никаким BIOS там и не пахнет.
Он вообще-то на IA64 впервыые появился
Да кому какое дело до мертвечины?
> Да кому какое дело до мертвечины?Было бы никакого, если бы она вынырнув из гроба и хлюпая кишками, к x86 присосаться не пыталась.
просто EFI, без U
На других платвормах есть EFI
Сотрю тут набег школоты! Открывайте педивикию по слову OpenFirmware - этому уже лет 25 как, с той лишь разницей, что там всё на Форте.
> Но нет, мы впихнём Линукс для загрузки Линукса. И назовём это упрощением.Чувак, мы протюнинговали твой ПК и теперь у тебя есть Линцкс прибитый к урезанному UEFI для загрузки Линукса! Инновейшнс.
Этор лучше чем полный UEFI бюез линук или, паче, какая-то экзотическая армовская загружалка.
> А может всё таки стоило бы вернуться к истокам и просто убрать
> из BIOSа неиспользуемые ф-ции и пусть он занимался бы тем, чем
> фактически занимался при своей жизни: инициализацией железа и передачей управления загрузчику?Coreboot уже есть.
Биос, как и уефи, всегда были блобами.
Гугл, же сделает его исходником, хоть и на своём Гоу.
> Биос, как и уефи, всегда были блобами.Qemu-лятор смотрит на тебя, как на https://packages.debian.org/src:bios
> Гугл, же сделает его исходником, хоть и на своём Гоу.
> Qemu-лятор смотрит на тебяНеа, на тебя. На реальном современном железе не заведётся.
> Много лет у нас был BIOS, который умел довольно много, но былу вас, походу, много лет не было. Те кто его застали, отлично помнят, что умел он хрен да нихрена, зависел от кривого чипа с параметрами и без конца глючил, когда требовался функционал лишь чуть побольше умения загрузиться с дискеты.
> Потом оказалось, что большая часть программ в BIOSе написаны абы как и
оказалось что они ничего полезного не делают, только и всего.
> Потом нам дали UEFI, котрый вообще умел чёрт знает что, который можно
и почти ничего - полезного, как и в прошлый раз.
Для банальной задачи загрузки притащенного операционной системой настоящего загрузчика он чудовищно избыточен и неописуемо крив. но альтернативы, к сожалению, только хуже.> было научить далать ещё больше, но ОС не стали использовать всё
куда б они делись? На современном железе уже либо вовсе нет legacy, либо он недоступен без потерь функциональности.
> И теперь Гугл предлагает обрезать UEFI, но впихнуть в него ядро Линукс
> (урезать, ага).индусы по другому не умеют.
> А может всё таки стоило бы вернуться к истокам и просто убрать
> из BIOSа неиспользуемые ф-ции и пусть он занимался бы тем, чем
> фактически занимался при своей жизни: инициализацией железа и передачей
> управления загрузчику?как только ты задумаешься, что такое "инициализация железа" (отличного от описанного в дедушкиной книжке "компоненты IBM PC") и что собой представляет современный загрузчик (а так же - откуда он может нынче браться, перечисли не менее пяти вариантов) - сразу же обратно uefi получится.
это мы еще не вспомнили про управление питанием, out of band management (который далеко не рептилоиды изобрели чтобы за тобой удаленно следить), криптографические подписи загружаемой системы и драйверов, fingerprint unlock, старт с полностью зашифрованного носителя и другие интересные штуки, которые никак не получится полностью реализовать в обычной системе - слишком многое нужно сделать еще до того, как ее ведро прочитается в память.
> Вась, ты после уроков почитай, кто такой дядя Рон, а потом уже
> про индусов вякай, ок?какую задачу копченый миддл поставил - ту и будет отрабатывать (включая яростный свист в ее защиту в этих ваших интернетах), иначе можно отправиться из уютного офиса нахрен.
Приличные люди в гугле не работают уже лет десять именно по этой причине (первое время им даже разрешали сваливать с деньгами и целыми лабораториями, потом фишку просекли и лавочку прикрыли).
> Приличные люди в гугле не работают уже лет десять именно по этой
> причине (первое время им даже разрешали сваливать с деньгами и целыми
> лабораториями, потом фишку просекли и лавочку прикрыли).Столько апломба...
Я надеюсь ты успел поработать в гугле 10 лет назад, чтоб так говорить? Или причина в том, что 10 лет назад трава была зеленее, компьютеры непонятнее а в гугле работали боги? Хотя в целом согласен, год назад наблюдал как в Купертино из оффиса эппла работники в автобус садятся после работы - там почти нет белых, все с серьёзным Бангалорским загаром.
> Я надеюсь ты успел поработать в гугле 10 лет назад, чтоб так говорить?нет, просто один знакомый не успел оттуда уволиться (и еще один не захотел, но там особый случай). Разница "фоток с коллегами" тогда и сейчас - да, впечатляет.
десять лет назад (мы тогда были,гхм...в общем, довольно тесно сотрудничали с гуглем) было все же сильно лучше - не боги, рюйских вон понанимали, в виду кадрового голода, но хоть не поголовно индусские отделы с индусами-начальниками и соответствующим режимом принятия решений, про 'don't be evil' еще трещали, хотя "какая такая еще privacy в интернете" уже прозвучало...
но, собственно, где-то к 12-му году _тот_ народ начал оттуда массово валить, сперва по схеме "собраться всем отделом, продать акции гугля и на вырученное открыть свой стартап с тем же, чем занимались в гугле", потом лавку халявы как-то прикрыли, и уже просто кто куда.
> там почти нет белых, все с серьёзным Бангалорским загаром.
беда в том, что это уже и не рядовые программисты, это руководители так выглядят.
И вот в частности - любые публичные заявления сотрудников надо рассматривать в этом контексте.
> Те кто его застали, отлично помнят, что умел он хрен да нихренаНу не надо! Это был BIOS, т.е. basic input/output system, и базовый ввод/вывод он таки умел. До сих пор помню: 10-е прерывание - работа с экраном, 13-е - с диском, 16-е - с клавиатурой...
> basic input/output system, и базовый ввод/вывод он таки умел. До сих пор помню: 10-е прерывание - работа с экраном, 13-е - с диском, 16-е - с клавиатурой...именно за этого его и любим! Это очень классная абстрация. Чего нет на АРМах и всяхки других MIPS.
Если сабжевая реинкарнация будет предоставлять что-то такое для множества архитектур, будет интересно на это посмотреть
>> basic input/output system, и базовый ввод/вывод он таки умел. До сих пор помню: 10-е прерывание - работа с экраном, 13-е - с диском, 16-е - с клавиатурой...Причём 10h к системному BIOS вообще отношения не имело.
Причём уже DOS 3 прерываниями биоса после загрузки не пользовалось.
> Причём уже DOS 3 прерываниями биоса после загрузки не пользовалось.INT 10h всегда был в ходу. Как минимум для инициализации видеорежима.
А зачем оно? Для множества архитектур уже есть старая-добрая абстракция - системные вызовы ОС.
> Но нет, мы впихнём Линукс для загрузки Линукса. И назовём это упрощением.а почему нет ?
1) линукс-ядро очень сильно обрезается до чисто того что и должен сделать биос (найти железо и пнуть железо, линь при загрузке ещё ж может и на ходу ядро заменить, так что линубиос может на ходу превратиться в просто линукс ?)
2) они предлагают использовать не застывшее ядро а обновляемоактуальное ?
> они предлагают использовать не застывшее ядро а обновляемоактуальное ?Сомневаюсь.
> 2) они предлагают использовать не застывшее ядро а обновляемоактуальное ?Ага, тянуть с гитхаба и компилять каждый раз когда хочешь загрузиться. =)
в прошивке будет только гцц и гоцц.
>> который умел довольно много, но был прост и понятенСтранно, я общался с некоторыми программистами, которым приходилось плотно работать в этой сфере. И все дружно плевались от того, что BIOS это набор костылей, смотанных скотчем.
Уточните, он был прост и понятен для вас, как для кодера или как для потребителя?
Как для программиста.
Там было не так уж много ф-ций. Десяток для работы с диском (подвигать головки, считать/записать сектор и т.п.), пару для клавы и немного для возни с видеорежимами. Может ещё чего было, но я туда не лез.
>Много лет у нас был BIOS, который умел довольно много, но был прост и понятен.Много лет у нас был BIOS, который умел довольно много, но был проприетарен и не стандартизирован.
мелкофикс
> Много лет у нас был BIOS, который умел довольно много, но был
> проприетарен и не стандартизирован.Современное уефанство не менее проприетарно и не менее не стандартизовано.
да, UEFI намного хуже
Самое смешное в том, что UEFI - это тоже БИОС.
Сидели программеры и голову ломали есть 10 стандартов не совместимых с собой, подумали и решили написать свой стандарт который бы оказался универсальным. И так теперь мы имеем 11 не совместимых стандартов.
> Сидели программеры и голову ломали есть 10 стандартов не совместимых с собой,
> подумали и решили написать свой стандарт который бы оказался универсальным. И
> так теперь мы имеем 11 не совместимых стандартов.В оригинале 14 => 15. https://duckduckgo.com/?q=xkcd+standards
Теперь реклама будет сразу при включении компьютера? Замечательно.
Теперь у Васи закончится fud
ИМХО оно только на хромбуках будет.
> U-root написан на языке Go и включает в себя легковесную систему инициализации, оболочку rush и набор типовых утилит, таких как cp, mv, ls, grep, sort, dd, insmod, wget, netcat и т.п.Молодцы. Взяли и переписали на го coreutils. Им блин делать нечего больше? Ради чего это всё? Просто ради го? Го ради го?
управление памятью. потому что никому не нужны в биосе утечки, переполнения буферов и стека, вот это вот всё.
> никому не нужны в биосе утечки, переполнения буферов и стека, вот это вот всё.Какие утечки? То говорят, что на го не страшно, ведь там не так много работы, что GC будет напрягать, а теперь говорят, что "ой, утечки!". Причём какие блин нафиг утечки в команднах ls, cp, mv, и иже с ними? Совсем отупели там программисты, что не могут ls без утечек сделать?
>> никому не нужны в биосе утечки, переполнения буферов и стека, вот это вот всё.
> Какие утечки? То говорят, что на го не страшно, ведь там не
> так много работы, что GC будет напрягать, а теперь говорят, что
> "ой, утечки!". Причём какие блин нафиг утечки в команднах ls, cp,
> mv, и иже с ними? Совсем отупели там программисты, что не
> могут ls без утечек сделать?А если ls -AlR и на каждой директории и/или файлу по одному (мега)байту терять? Эдак команда может и до конца не доработать ;)
Там 5 (пять) файлов. 5 мегабайт памяти - это оченно большие потери, да...
640Кб должно быть достаточно каждому!
>> U-root написан на языке Go и включает в себя легковесную систему инициализации, оболочку rush и набор типовых утилит, таких как cp, mv, ls, grep, sort, dd, insmod, wget, netcat и т.п.
> Молодцы. Взяли и переписали на го coreutils. Им блин делать нечего больше?
> Ради чего это всё? Просто ради го? Го ради го?думаю будет не сложно заменить в имадже эти утилиты на coreutils
заслуга гугл не в этом (этим они сделали заявку на кросплатформенность типо)
> этим они сделали заявку на кросплатформенность типоКак и buildroot + busybox с их голым Си кроссплатформены. Но ведь они не пошли этим путём, а потратили сколько-то тысяч человекочасов на тупое переписывание. Ради чего?
Чтобы иметь там всё в исходных кодах
Хнык-хнык, они же там дальше заявляют, что на самом деле всё лучше в бинарях сразу поставлять, в едином файле как busybox. И чё тебе эти исходники дадут? Сидишь такой на канале аниме и спрашиваешь, а как пропатчить ls под NERF?
Они там дальше заявляют, что в зависимости от ситуации возможны разные варианты. Что есть вообще правильных подход. Исходники в данном случае в основном ради упрощения портирования на новые железки - скопировал и готово, а собирать надо только один бинарь на всё про всё. Учитывая, что этот бинарь всё равно нужен для реализации самой логики загрузки - в общем логично.
Вот и я подумал, у них есть две причины не использовать busybox. 1) То, что он написан не на Go. 2) То, что лицензия не Опач.
>Взялида
>и переписали на го coreutils.Нет. Взяли готовое. https://github.com/u-root/u-root
>Им блин делать нечего больше? Ради чего это всё? Просто ради го? Го ради го?Го-Го - Иго-го! А у тебя батхерт.
А почему нет собственно? Не драйвера же. Там под Го вообщето линукс уши торчат :)
КоТ простой и понятный см линк на гитхаб. Всё поставляется в сорцах, как скрипты какие :)
Мне расклад нравиЦЦо, желаю им удачи.
Херня какая-то... урезанный линукс ставят над полноценным линуксом и говорят "это архитектурно оправдано". Ага-ага. А может стоит эту всю оправданность вынести к чертям? В смысле, _вообще_ всю? Не, ну а кто, кто сказал что пзу-биос вообще нужен для чего-то кроме как стартовать загрузчик оси?! Как по мне, так это единственная, реально востребованная функция. А, чуть не забыл: еще дату-время выставляем через него. Все остальное - это от лукавого /производителя/.
> Херня какая-то... урезанный линукс ставят над полноценным линуксом и говорят "это архитектурно
> оправдано". Ага-ага. А может стоит эту всю оправданность вынести к чертям?
> В смысле, _вообще_ всю? Не, ну а кто, кто сказал что
> пзу-биос вообще нужен для чего-то кроме как стартовать загрузчик оси?! Как
> по мне, так это единственная, реально востребованная функция. А, чуть не
> забыл: еще дату-время выставляем через него. Все остальное - это от
> лукавого /производителя/.Верно, ПЗУ BIOS нужен, чтоб искал загрузчик на винте и пинал его пнуть ядро ОС. Всё
ну, ещё вывод на экран, чтобы показать ошибку, когда она случитсяну, ещё ввод с клавиатуры, чтобы выбрать, откуда грузиться
ну, ещё usb стек, чтобы грузиться с флешек
ну, ещё поддержка загрузки по сети, потому что тоже бывает нужно
ну, ещё спикером нужно уметь бибикать, чтобы как-то сообщить об ошибке до стадии инициализации видеоадаптера
ну, ещё какая-нибудь утилита воостановления нужна, на случай отключения питания при перепрошивке
а так - да, прочитать с винта загрузчик и передать управление.
ага, конечно.
Все это отлично умеет BIOS и без всякой уефи.Главное отличие в том, что без уефи ось получает доступ к оборудованию напрямую, а с уефи через прослойку, которая _якобы_ предоставляет дополнительную секурность.
Причем, когда начинаешь копать, то выясняется что секурность эта нужна главным образом производителям коммерческих осей (в некоторых случаях оборудования) для того что бы покупателей сегментировать, так как это выгодно им, а вовсе не самим покупателям.
Вдогонку.Подумайте еще вот на чем: может проще загрузчик выучить всем этим финтифлюшкам, благо современные загрузчики много чего умеют делать такого, на фоне чего "usb стек, чтобы грузиться с флешек" просто полная ерунда?
> Подумайте еще вот на чем: может проще загрузчик выучить всем этим финтифлюшкам,
> благо современные загрузчики много чего умеют делать такого, на фоне чего
> "usb стек, чтобы грузиться с флешек" просто полная ерунда?современные загрузчики "много чего умеют делать" ровно с помощью использования стандартных api, предоставляемых либо uefi, либо биосом. (rто-то еще забыл инициализацию оперативной памяти, которая нынче полностью cpu-controlled, еще до первой попытки хоть одну переменную в нее сохранить)
А если ты попытаешься реализовать полноценную поддержку usb (потому что, внезапно, может вообще не быть других носителей), хотя бы минимальную - видеокарты, полноценную (потому что нужен pxe) поддержку не просто всех на свете сетевых карт, а tcp/udp (включая v6) поверх (и смотри не сотвори remote exploit на этапе загрузки, когда защитных механизмов считай нет) - получится обратно линуксное ведро, да еще и с тонной userspace утилит, далеко не все из которых хорошо написаны.
>А если ты попытаешься реализовать полноценную поддержку usb (потому что, внезапно, может вообще не быть других носителей)Полноценная поддержка USB в данном случае не нужна. Необходимо и достаточно поддержать загрузку с USB-носителей, все остальное - дело ядра.
И не надо говорить, что управлять устройствами - это не его /ядра/ дело. Это _именно_ дело ядра.
В самом крайнем случае, загрузчик может грузить ядро для тех целей, что вы назвали, указывая, к примеру, определенные опции загрузки. На самом деле, это все решаемо.
Попробуйте услышать наконец: единственная функция для чего нужно что-то выше ОС, это загрузчик этой самой ОС. И само наличие этого "чего-то еще" диктуется только многообразием разных осей. Грубо говоря: если бы у нас была всего одна ось, то никакого пзу-биоса нам бы и не понадобилось. Он был бы просто лишним.
И любые попытки притянуть за уши какие-то еще функции родят монстра фнанкенштейна в области системной архитектуры. И все только для того, что бы нечистые на руку дельцы вроде Майкрософт получили возможность диктовать какую можно, а какую -нет ось ставить на конкретное железо. Других целей просто нет
> Попробуйте услышать наконец: единственная функция для чего нужно что-то выше ОС, это загрузчик этой самой ОС.<юмор>Который может находиться на флешке, жёстком диске, сети т.д.</юмор>
Ещё раз. Как при такой логике по сети грузиться будем?
Загрузить что-нибудь умеющее работать с сетью, дальше оно само. Тогда можно будет грузиться даже через какой-нибудь ipfs, которого не было на момент покупки железа.
Откуда загрузить? какое "что-нибудь"? как это "что-нибудь" будет работать с сетевой картой? Чем это лучше, чем загрузить лиуксовое ядро, которое все эти проблемы решает?
> Откуда загрузить? какое "что-нибудь"? как это "что-нибудь" будет работать с сетевой картой?Preboot раздел размером в 128 килобайт на флеше решит все проблемы загрузки с любого доступного г0внища. Включаемый по необходимости, заполняемый исключительно драйвером загрузки на чистом x86 без всяких преосей.
При такой логике по сети грузится будем так: загрузчик (допустим тот же grub) начинает загрузку initramfs, передавая ему параметры загрузки. Эти параметры устанавливает админ на этапе конфигурежки загрузчика. И поскольку initramfs знает (из параметров загрузки) что требуется не монтировать рут, а загружаться по сети, то он и делает это, благо к этому времени все сетевые устройства уже определены и правильно инициализированны.Кстати, тоже самое происходит и при всех остальных сценариях связанных с:
- зашифрованными разделами
- нестандартными носителями
- хитрыми клавиатурами
- и т. д.Плюсы такой схемы: вся логика ПОЛНОСТЬЮ подконтрольна администратору оси.
Минусы схемы: ядро с модулями должно грузится всегда.
Хотя минус этот не так что бы и минус: ведь в той схеме что гугль предлагает линуксовое ядро так и так грузится. А в той что есть сейчас... ну, там ядро ведь тоже грузится, только ядро это не линуксовое, а бинарь уефи из не пойми чьего кармана.
initramfs - это как бы ядро linux с рутом в памяти...
> initramfs - это как бы ядро linux с рутом в памяти...это рут в памяти (или его архив на диске), без всякого ядра линукс.
При желании можно этот архив загнать внутрь кода ядра. А вот код надо где-то взять, положить в память по правильному смещению и правильно передать ему управление. А у нас нечем.
> При такой логике по сети грузится будем так: загрузчик (допустим тот же grub)стоп-стооооп, откуда при загрузке по сети у вас взялся груб и сама загрузка по сети?
Вы же uefi похоронили (bios за вас похоронят, он производителей современных мультиядерных сетевух еще лет десять назад затрахал до смерти. попробуй-ка ее заставить вообще работать в real mode и с недостартовавшим процессором) А grub работает через либо биосэмуляцию, либо это grub-efi - сам он ни про сетевуху ничего толком не знает, ни про то, что ему вообще надо ее использовать, он для этого как раз стандартные efi-интерфейсы и применяет.
У вас НИЧЕГО нет. Вам все это придется с нуля и под любое железо реализовать в флэш-памяти (причем даже оперативная память в этот момент в непроинициализированном состоянии и недоступна. Обычно этим занимается проклятый борцунами с проприетаразмом ME).> благо к этому времени все сетевые устройства уже определены и правильно
> инициализированны.кем, вот в чем вопрос? Причем включая сетевые устройства, о которых сегодня никто ничего не знает, потому что их выпустят через месяц.
Сейчас это забота вендора - он реализует стандартный efi-драйвер, и при старте системы тот подцепится штатным образом.В случае гугля - это будет забота гугля, найти и всосать линуксный кернельный драйвер в свой чудо-лоадер, для хромобука и серверов-на-картонке эта задача будет возникать раз в пятилетку.
> Плюсы такой схемы: вся логика ПОЛНОСТЬЮ подконтрольна администратору оси.
одной единственной, ибо даже загрузить что-то, отличное от линукса мы не можем - оно тоже хочет uefi.
> Плюсы такой схемы: вся логика ПОЛНОСТЬЮ подконтрольна администратору оси.Внезапно не подконтрольна. Катастрофически неподконтрольна...
> Полноценная поддержка USB в данном случае не нужнану правильно, мы ж загружаемся только с флоппи-диска в первом слоте, да?
Полноценная поддержка usb тебе нужна, потому что биоса или уефи у тебя нет, а в usb может оказаться что угодно - сетевуха, внешний диск (или cdrom, опа, еще один драйвер) или кардридер (у этих еще и свой интерфейс бывает, и его тоже надо поддерживать), а то и вовсе какая экзотика, типа bt-адаптера к которому подключен внешний диск. Сейчас тебе не надо об этом думать - разработчики такого диска пусть думают, у них голова большой, и несут скрипты и драйвера для uefi - для того он, в частности, и придуман, чтобы это им cделать было просто.Ну и по мелочи - клавиатуру там, хотя бы, чтоб было где нажать F1, если, внезапно, загрузочное устройство отвалилось нафиг, или нужно его прооверрайдить. У нее, кстати, два взаимоперпендикулярных режима usb-поддержки, а еще она может быть встроена в композитное устройство, которое сперва надо разобрать на составляющие.
> В самом крайнем случае, загрузчик может грузить ядро для тех целей, что вы назвали,
> указывая, к примеру, определенные опции загрузки.у тебя клавиатуры ж нет - куда опции-то будем совать? ;-)
> Попробуйте услышать наконец: единственная функция для чего нужно что-то выше ОС, это
> загрузчик этой самой ОС.попробуйте услышать: если у вас не вендорлокнутое железо с одним-единственным раз навсегда утвержденным порядком загрузки и аж тремя возможными выборами устройств - "загрузчик этой самой ос" окажется другой ос. С драйверами, файловой системой, шеллом, утилитами, возможно веб-сервером в комплекте (а то сам пойдешь к стойке номер 116 ряд 12 место 43 - 43, кстати, это на высоте два метра от пола, попрыгай, авось до разъема дотянешься). Что в общем и получилось в случае uefi.
(а до нее - эмуляция клавиатуры, отваливающаяся в самый нужный момент, когда мы свитчнулись в прот-мод а драйвер не загрузили, потому что ой, не тот, битва за int13 и 14 с непредсказуемыми результатами, когда участников больше двух, press ctrl-a,b,c,d,s,z и смотри в правильную секунду, для попадания в меню настроек правильного устройства и много еще чего, что я уже забыл и вспоминать не хочу. И еще внутрисерверный usb-разъем, как крайнее средство.)
>[оверквотинг удален]
> стойке номер 116 ряд 12 место 43 - 43, кстати, это
> на высоте два метра от пола, попрыгай, авось до разъема дотянешься).
> Что в общем и получилось в случае uefi.
> (а до нее - эмуляция клавиатуры, отваливающаяся в самый нужный момент, когда
> мы свитчнулись в прот-мод а драйвер не загрузили, потому что ой,
> не тот, битва за int13 и 14 с непредсказуемыми результатами, когда
> участников больше двух, press ctrl-a,b,c,d,s,z и смотри в правильную секунду, для
> попадания в меню настроек правильного устройства и много еще чего, что
> я уже забыл и вспоминать не хочу. И еще внутрисерверный usb-разъем,
> как крайнее средство.)Еще раз: все проблемы что вы описали должны решаться на уровне ОС, поскольку связанны с опознанием и инициализацией устройств, а так же и реализацией различных сценариев загрузки. А это все является прерогативой ядра оси и ее загрузочных скриптов.
Делать что-то выше оси для решения _этих_ проблем, ИМХО, контр-продуктивно.
> Полноценная поддержка usb тебе нужна, потому что биоса или уефи у тебя
> нет, а в usb может оказаться что угодно - сетевуха, внешний
> диск (или cdrom, опа, еще один драйвер) или кардридер (у этих
> еще и свой интерфейс бывает, и его тоже надо поддерживать), а
> то и вовсе какая экзотика, типа bt-адаптера к которому подключен внешний
> диск.А какая гуй разница, если это оказавшееся на int19h просоплит правильный бутром. Для особых извращений см. выше - preboot раздел на 128K (64K, 32K, 16K) решит все проблемы.
> А какая гуй разница, если это оказавшееся на int19h просоплит правильный бутром.нету уже никакого int19h, забудьте эту хрень. Осталась в прошлом веке.
Оно задрало производителей железа настолько, что они радостно ухватились за efi (придуманый вообще для не-pc платформы, где никакого биоса не было предусмотрено), и даже заставили/уговорили интел поделиться патентом - так им понравилась идея наконец-то от этого легаси каменного века избавиться.
Все, скоро вы вообще никакого биоса в своих компьютерах не увидите. В серверных системах его уже сто лет как нет, во многих ноутах тоже ("legacy boot" это uefi Compatibility Support Module - эмулятор биоса _внутри_ uefi, разумеется, использующий все те же драйвера)
> Для особых извращений см. выше - preboot раздел на 128K (64K,
> 32K, 16K) решит все проблемы.не решит, ведро линукса, прошивки и userland не поместятся. А понадобится, если вы хотите закатить солнце вручную.
Решит. Потому что ведру, прошивкам и т.п. там тупо не место. Его задача - залить максимально дешёвым способом как раз первый блок со всем этим счастьем через установленное дерьмище, и отпустить бразды правления.
Причём - внимание - только если это руками юзером настроено для бута с чего либо кроме стандартной периферии, висящей на стандартных портах и интах.
> Причём - внимание - только если это руками юзером настроено для бутав стойке под 40 серверов (при неудаче может быть 60-70), стоек сорок штук (не особо большой сектор в датацентре). Хочешь побыть тем юзером, который руками побежит по всем настраивать? Замечу, удовольствие все это распаковать, смонтировать, подключить провода и так очень не айс, занимаются этим специально обученные ребята, которые на предложение ко ВСЕМ по очереди ящикам прогуляться с подключением клавиатур и мониторов чтобы что-то там руками настроить, думаю, тебя расчленят, и потроха поховают под стойками. (в случае гугля - сбросят с Hoover Dam одним куском, там никто не найдет)
И да, при первом включении, разумеется, порядок загрузки часто отличается от "стандартного", потому что надо еще что-то туда установить и настроить.
> с чего либо кроме стандартной периферии, висящей на стандартных портах и
> интах.нету уже вашего мсдоса и флопов 5", нету. Вся "стандартная" нынче настолько сложная, что для ублажения админов локалхостов проще оказалось интелу написать эмулятор любимого ими биоса.
Если мы в итоге грузимся с какого-то непонятного дерьмища типа PXE через паблик, то один раз воткнуть флешку, которая зальёт пребут, не обломинго.А если грузимся с нормальных устройств, где есть нормальный бутром - оно и не надо.
И да - как нет мсдоса? А UEFI?
Где там мысыдос? Домохозяйка, идите в сад! (С)
Суслика нет, но ушки отовсюду торчат.
> в стойке под 40 серверов (при неудаче может быть 60-70), стоек сорок
> штук (не особо большой сектор в датацентре). Хочешь побыть тем юзером,
> который руками побежит по всем настраивать? Замечу, удовольствие все это распаковать,
> смонтировать, подключить провода и так очень не айс, занимаются этим специально
> обученные ребята, которые на предложение ко ВСЕМ по очереди ящикам прогуляться
> с подключением клавиатур и мониторов чтобы что-то там руками настроить, думаю,
> тебя расчленят, и потроха поховают под стойками. (в случае гугля -
> сбросят с Hoover Dam одним куском, там никто не найдет)деби-(здесь не могло бы быть вашей рекламы)-лоиды отплясывают по серверным... вот как это называется.
На этих ваших серверах в стойках никто не мешает быть предустановленному хоть DOS. Которая будет запускаться при первой загрузке...
> деби-(здесь не могло бы быть вашей рекламы)-лоиды отплясывают по серверным... вот как
> это называется.с точки зрения гордого локалхостового админа, видимо, да.
уровень его знаний очевиден, раз он в uefi где-то дос увидел. (последний намек, для не совсем уж феноменально тyпорылых: в windows2016, да и в линуксе тоже, есть драйвер fat, и в первой даже есть шелл, похожий на command.com куда больше чем efi'шный. И это ни разу не делает их досом. А документация хотя бы Framework вполне доступна без nda. Драйвер по ней не напишешь, но глупостей про какой-то там дос болтать тоже не будешь.)
так что дальше с ним спорить и всерьез относиться к его идеям бессмысленно. Он что про uefi нихрена не знает, что про системы, отличные от его единственного десктопа. Одни высосанные из пальца фантазии.
> На этих ваших серверах в стойках никто не мешает быть предустановленному хоть DOS.
кто будет предустанавливать, кому еще и этот мартышкин труд поручим? Где он этим будет заниматься? Что будем делать, когда что-то пошло не так в датацентре за пол-глобуса от тебя, если вариант удаленно дернуть питание и загрузиться с сетевого rescue или просто автоматически переустановить нужное - недоступен?
А главное - чего стоит твое мнение, если ты с этим никогда не сталкивался и даже не понимаешь, о чем речь? В общем, присоединяюсь к анону - домохозяйка, идите к своим кастрюлям, очень зря буллу Григория IX отменили.
> Решит. Потому что ведру, прошивкам и т.п. там тупо не место.ну да, его ж злые рептилоиды назло тебе напихали, да?
> Его задача - залить максимально дешёвым способом как раз первый блок со
и обломаться, поскольку в 512 байт не влезет ничего, способного обойтись без драйверов и прошивок, чтобы прочитать следующий кусок.
Варианты - либо уже неподдерживаемое производителями аппаратуры легаси, имеющее в принципе нерешаемые проблемы, потому что его писали, когда 640k было enough for all. Либо полноценная операционная система. И тогда да, можно обойтись даже меньше чем 512, потому что это уже не "блок", а обычный файл, где написано, где искать загрузчик (или,как в uefi, даже не файл, а гвоздем прибитый путь к файлу, "редактируется" при помощи mv).
Для тех, кого не устраивала "проклятая проприетарная интеловская" - гугль расстарался и сделал непроприетарную гуглевскую. Прошивки плат от этого, разумеется, открытыми не стали, но можно делать вид, что ты что-то контролируешь.
зачем оно гуглю - отдельный интересный вопрос.
> и обломаться, поскольку в 512 байт не влезет ничего, способного обойтись безИ не обломаться, поскольку "блок" - это не сектор.
Причём с таким пребутом можно поддержать вообще любые FS и прочее, без необходимости держать FAT32-уефанство на устройстве. Можно даже GRUB stage 1, например.
Эксперт, блин, диванный! Например, на сломанной машине без оси кто тебе спикером пищать будет? Оркестр пекинской оперы?!
Аноним, для этого как раз и нужен ПЗУ-БИОС, его необходимость никто и не отрицает.Однако, согласись, что есть разница между пищать спикером и, допустим, проверять цифровую подпись файла ядра. Это я даже не говорю о том, что уефи претендует на роль прослойки между аппаратурой и осью. И если ось тебе подконтрольна, то уефи-то - ни разу. А оно тебе надо, на машине иметь что-то не подконтрольное тебе? Мне вот лично - нет.
> Это я даже не говорю о том, что
> уефи претендует на роль прослойки между аппаратурой и осью.Ну вообще-то это ваша любимая BIOS такие претензии имело...
> А если ты попытаешься реализовать полноценную поддержку usb (потому что, внезапно, может вообще не быть других носителей), хотя бы минимальную - видеокарты, полноценную (потому что нужен pxe) поддержку не просто всех на свете сетевых карт, а tcp/udp (включая v6) поверх (и смотри не сотвори remote exploit на этапе загрузки, когда защитных механизмов считай нет) - получится обратно линуксное ведро,Нет, получится u-boot :)
> Херня какая-то... урезанный линукс ставят над полноценным линуксом и говорят "это архитектурно
> оправдано". Ага-ага. А может стоит эту всю оправданность вынести к чертям?
> В смысле, _вообще_ всю? Не, ну а кто, кто сказал что
> пзу-биос вообще нужен для чего-то кроме как стартовать загрузчик оси?! Как
> по мне, так это единственная, реально востребованная функция. А, чуть не
> забыл: еще дату-время выставляем через него. Все остальное - это от
> лукавого /производителя/.https://www.opennet.me/openforum/vsluhforumID3/112629.html#51
конец комментария
>Не, ну а кто, кто сказал что пзу-биос вообще нужен для чего-то кроме как стартовать загрузчик оси?! Как по мне, так это единственная, реально востребованная функция.Поэтому приходим к выводу, самый правильный "BIOS" - U-boot
Ага, ага. Пан не в курсе, насколько вообще должна эта вся фигня быть self-aware, чтоб взлететь? Советую посмотреть на инициализацию arm'ов.А так конечно UEFI и BIOS один пес, IEEE-1275 FTW.
> Ага, ага. Пан не в курсе, насколько вообще должна эта вся фигня
> быть self-aware, чтоб взлететь? Советую посмотреть на инициализацию arm'ов.
> А так конечно UEFI и BIOS один пес, IEEE-1275 FTW.слава яйцам, хоть кто-то вспомнил про open firmware. а то я уж думал, что школота совсем изжила нормальных людей )
> Таким образом, в u-root все утилиты предлагаются в исходных текстах, а для адаптации инструментария требуется лишь настройка компилятора.
> Подобный подход позволяет сделать образ u-root универсальным и распространять единый образ корневой ФС для всех платформ, поддерживаемых компилятором языка Go (для каждой новой архитектуры требуется лишь подготовить 4 исполняемых файла, в одном образе могут содержаться сборки компилятора для разных архитектур).И чем это лучше, чем если бы они сразу положили все бинари (cp, mv, ls, ...) под поддерживаемые архитектуры? buildroot, там, не знаю, в помощь взять и проблем нет...
> Дополнительно предусмотрены варианты c компиляцией всех утилит во время загрузки или поставки готовых сборок (для минимизации размера прошивки все утилиты могут быть собраны в один исполняемый файл, по аналогии с busybox).А, то есть всё-таки распространение исходников + JIT всё-таки не подходит, и поэтому они всё-таки собирают бинари под все архитектуры сразу. Ну едрить, маркетологи/менеджеры, которые оправдывают потреченное время на всякую хрень...
> для минимизации размера прошивки все утилиты могут быть собраны в один исполняемый файл, по аналогии с busyboxНо взять busybox религия не позволяет?
У гугля GPL-боязнь.
> И чем это лучше, чем если бы они сразу положили все бинари
> (cp, mv, ls, ...) под поддерживаемые архитектуры?А чем хуже?
> А чем хуже?Чем голый исходник хуже бинаря? Ну не знаю, наверное, тем, что для БИОС-подобного поделия совсем не нужно: парсить исходники, проверять синтаксис, семантику, строить деревья, оптимизировать, транслировать, линковать и затем уже исполнять. А то со временем получится как с web'ом - тормозит на супербыстрых компах, хотя в 2000-ых и так всё работало и было норм. Так и получим, комп долно грузится на биосе, надо бы процессор обновить, а то го долго компилит исходники...
Учитывая, что оно нужно бывает не каждый год, не всё ли равно? Или ты, может, из EFI-шелла комменты строчишь?
Кстати, компилит го шустро.
> Современные прошивки сильно усложнены и включают многие атрибуты обычных ОС... и поэтому мы запихнём вместо UEFI ядро Linux!!!пыщпыщпыщ
> С учётом значительного размера кодовой базы прошивок UEFI, которая составляет около 2 млн строк кода
А наше ядро Linux (чтобы работал го и был некий минимальный набор периферии) + все core утилиты будут не 2 млн строк, а всего лишь 1.5 млн строк!!!пыщпыщпыщ
ядро линукс + обвеска - поддерживаемые и обновляемые.проприетарные фирмвари через два года после выхода железа - нет.
> ядро линукс + обвеска - поддерживаемые и обновляемые.Дооооо, расскажи, как твой производитель андроида обновляет телефончики. До сих пор ли смартфоны 5-ти летней давности в обновлённом и свежем виде находятся? Производитель не кинул ведь так? Всё поддерживается и обновляется да?
>> ядро линукс + обвеска - поддерживаемые и обновляемые.
> Дооооо, расскажи, как твой производитель андроида обновляет телефончики. До сих пор ли
> смартфоны 5-ти летней давности в обновлённом и свежем виде находятся? Производитель
> не кинул ведь так? Всё поддерживается и обновляется да?если бы твой производитель телефончика сказал "у нас коребиос, отыитесь за обновлениями на их сайт" у тебя бы не было проблем обновить биос твоего телефончика
> если бы твой производитель телефончика сказал "у нас коребиос, отыитесь за обновлениями на их сайт" у тебя бы не было проблем обновить биос твоего телефончикаНет, конечно! Но в реальности ведь не так. Производитель не будет поддерживать SoC'и предыдущих поколений, потому что оно ему нафиг не нужно. А весь зоопарк SoC'ов никто не будет поддерживать.
>> если бы твой производитель телефончика сказал "у нас коребиос, отыитесь за обновлениями на их сайт" у тебя бы не было проблем обновить биос твоего телефончика
> Нет, конечно! Но в реальности ведь не так. Производитель не будет поддерживать
> SoC'и предыдущих поколений, потому что оно ему нафиг не нужно. А
> весь зоопарк SoC'ов никто не будет поддерживать.в этом то и фишка - весь зоопарк старых SoC'ов будет перекинут на плечи линукса
(на сколько верно он будет поддерживать местечковые маааленькие переделочки стандартных SoC'ов без спецификаций и документаций - другой вопрос)производитель будет поддерживать линукс (и вхреначить бы туда гпл3 или что-там чтоб были обязаны все свои мааалюсенькие перехреначивания драйверочков публиковать)
И никто и никогда не будет ничего обновлять. Ровно ноль кода для проприетарного железа закомичено в ядро линукса. Даже банальные исходники дров под интеловские атомы, которые на планшетах ставили, в интернете косячные ходят, без допила не работают. А что уж говорить про всякие soc китайцев? Они продадут партию чипов, покупателю всучат бумажку с стрелочками что и как собрать, скинут на почту мегабайт 10 ужасного корявого кода на ядре 2.6 - и готово. Никто не будет заморачиваться. Пока система не открыта от корки до корки, пока над ней не работает на постоянной основе хотя бы пара человек - она не будет так радужно обновляться магическим образом какими то мистическими плечами линукса. У него плечей нет, это люди обновляют и поддерживают, люди, которым платят деньги. И вряд ли кому то платят деньги за поддержку старых телефонов и роутеров(это не выгодно производителям).
чушь. Единственно правильный вариант - это полностью открытая система, типа тех которые сейчас пилят на OpenPOWER
Зато этот вариант куда реалистичнее и, в общем, не так плох.
Нацелено на то, чтобы в хромых буках остались только свои гуглозонды. Гугл не хочет ни с кем делиться. Но дальше это не пойдёт. Ну, энтузиасты, как обычно, будут перепрошивать свои тазики и транслировать всем окружающим, что гуглозонды слаще интеловских и прочих.
Сектанты уже сейчас думают что amr trustzone лучше чем intel me и не так жмёт.
Что Google поссорился с Intel? Блобы Intel не дают покоя Google?
> Что Google поссорился с Intel? Блобы Intel не дают покоя Google?Ищите где то на просторах Интернета статьи о том, что Гугель использует свое (или специально для них разработанное и воплощенное в реальность) железо. Так что я думаю Интель для них не указ!
Теперь телеметрия будет отправляться сразу при загрузке Биоса. Боролись с мелкомягкими и вырастили другого монстра.
Так она и так отправляется. Интел постарался с МЕ. Да и сами ведоры. В два места отправляется получается, а может еще и в АНБ.
> Так она и так отправляется. Интел постарался с МЕ. Да и сами
> ведоры. В два места отправляется получается, а может еще и в
> АНБ.Пруфы?
https://habrahabr.ru/company/dsec/blog/282546/Вот про ИнтелМЕ и там по ссылкам походи.
Про вендора - комп моих родственников HP периодически просит обновления UEFI. Чего-то там он постоянно шлет и получает.
Утилита HP из под винды что-то шлёт, получает и требует? Да как они посмели! А может это вообще cpu microcode update?
А апдейт не запрашивает НР? И не из под венды, а при старте компа, до груба.
> а может еще и в АНБ.Почему "может"?
> Боролись с мелкомягкимидиванные войска? Как-то уж очень пафосно звучит
> диванные войска?Эти тоже внесли свою лепту.
> Теперь телеметрия будет отправляться сразу при загрузке Биоса. Боролись с мелкомягкими
> и вырастили другого монстра.Ну да, армия неосиляторов в ужосе! А прочекать исходники на "закладки" и собрать свою версию тебе что не позволяет? Это на порядки полегче, чем искать насекомых в бинарном коде проприетарных UEFI/BIOS.
Так там и не будет закладок. Будет а н а л и т и к а ! Но вы же доверяете такой доброносной и открытой компании как Гугл, верно? Что плохого вам способны сделать их встроенные анал-итические сервисы? Это же не закладки, правильно?
> Так там и не будет закладок. Будет а н а л и
> т и к а ! Но вы же доверяете такой доброносной
> и открытой компании как Гугл, верно? Что плохого вам способны сделать
> их встроенные анал-итические сервисы? Это же не закладки, правильно?А прочекать исходники на ...
О! Оно развивается в рамках проекта Heads.
Шапка опередит их и загрузкой ДО операционки будет рулить systemd
> Шапка опередит их и загрузкой ДО операционки будет рулить systemdНа чьём железе? Шапка выпустит своё железо?
Конечно нет, ей микрософт дозволит.
>оболочку rush и набор типовых утилит, таких как cp, mv, ls, grep, sort, dd, insmod, wget, netcatОсталось добавить gcc с компанией и можно считать это полноценной linux системой
Не, надо ещё node.js...
> Не, надо ещё node.js...И оболочку на Electron!
Появление UEFI и GPT до сих пор вызывает массу проблем совместимости во многих дистрибутивах. Если к этому зоопарку добавят ещё и этот NERF совсем грустно будет. В большенстве случаев вполне хватает старого доброго unsecure boot (BIOS) и MBR.
> Появление UEFI и GPT до сих пор вызывает массу проблем совместимости во многих дистрибутивах.И что это за "многие дистрибутивы"? Ты же не перечислил. Я вот не знаю таких.
Вот только что в новшествах скорой Fedore 27 прочиталSome x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel and distribution on these systems. So far this setup has not been supported in Fedora. This feature is about adding support for installing and booting Fedora on this hardware.
Не прошло и сколько лет с тех пор, как UEFI появился и RedHat удосужился это починить?
> Не прошло и сколько лет с тех пор, как UEFI появился и RedHat удосужился
> это починить?ms этого чинить вовсе не собирается - и ничего, прекрасно живет, а вы все "неготовы для десктопа" (надеюсь, у вас не серверное железо с uefi32, которое вам никак не удавалось использовать без этого, довольно таки, заметим, кривого хака, который в любой момент может сломаться без предупреждения?)
сравнивать количество установленных windows10 и не-серверных установок вообще любых линуксов будем, или и так все понятно?
> Не прошло и сколько лет с тех пор, как UEFI появился и RedHat удосужился это починить?
это не починить, это сломать. uefi для таких фокусов не предназначен. Редхат доломал у себя в rhel поддержку 32битных версий, и решил сохранить хорошую мину при плохой игре, тем более что от него требовалась пара строчек внутри анаконды, остальное сделали любители хаков бесплатно.
актуально только в случае попыток скрестить ужа с ежом, например, взгромоздить таки 64битную версию на нетбук (с двумя гигами оперативки, как правило).
Зачем она тебе на нетбуке?Или, как совсем невероятный вариант - на платформу 2009го года выпуска, у древних-древних интеловских платформ был efi (не uefi даже) - правда, у них был честный legacy boot при этом, а зачем на такой одноразовая федора со сроком поддержки полтора месяца тоже неясно, ее бы такую списать побыстрее, запчасти золотые.
А в случае обычного BIOS и MBR это вообще не важно. Код загрузчика MBR вообще 16-и битный и ничего, всё прекрасно работает. Зато сколько нестандартных костылей с загрузчиками придумали линуксоиды. За один только mbr gap и невозможность загрузки без него (в некоторых дистрибутивах) нужно руки поотрывать.
> А в случае обычного BIOS и MBR это вообще не важно.если ты готов и дальше работать на своем IBM PC XT - то не важно.
> Код загрузчика MBR вообще 16-и битный и ничего, всё прекрасно работает.
очень неважно он работает - например, эта MBR на больших дисках давно фуфловая, а значит, всегда есть риск, что какой-нибудь глупый софт тех же времен примет ее за чистую монету и что-то изгадит.
С чтением за пределами 8го терабайта у этого кода полная беда (и с четвертым-то успех частичен), не смотря на все костыли и подпорки в виде lba и еще больше lba, здравствуйте бут-партишны в "начале" (того, у чего и начала-то никакого скоро не будет). С native 4k дисками просто полная задница, настолько, что все попытки вывести их на рынок юзерского сегмента провалились.и это только диски. А еще есть сетевые карты, современные, под тяжелую нагрузку - которым вообще хрен объяснишь, как, с их внутренней мультиядерностью, жить на полузапустившемся процессоре. И еще много чего странного есть.
И поддерживать эту легаси уже давно всем надоело.
> Зато сколько нестандартных костылей с загрузчиками придумали линуксоиды.
именно потому, что "все прекрасно работало". Если, конечно, у тебя ms-dos 3.3, иначе как-то разом становилось менее прекрасно.
Да, про прелесть "умести начальный загрузчик в 512 байт минус данные и метки или хрен его вообще знает, куда тебе его девать" я забыл упомянуть.все эти и многие другие проблемы как раз и решает uefi. Не нужно умещаться в 512 байт, и потом еще в те 640 которых should be enough, совершенно все равно в какой части какого диска лежит efi-раздел и лежит ли вообще (если нет, возьмем загрузчик с tftp, если он большой - с http тоже можем), не нужно страдать с недозапущенным процессором в 16битном режиме, логично, а не через задницу и неполнофункционально встраивается удаленное управление загрузкой. Но дятлы продолжают упорно долбить "дайте нам биос и int13".
> 8го терабайтагигабайта же.
Кстати, нахваливающим "старые добрые" я бы посоветовал просто полистать Ralf Brown's interrupt list и всю ту кучу экстеншенов и воркароундов ...
http://www.ctyme.com/intr/int.htm
http://www.ctyme.com/intr/int-13.htmну или можно глянуть в код груба, там тоже "костылей обхода" вагон и маленькая тележка.
https://github.com/coreos/grub/blob/40e2f6fd353061fdb3ec4dd6...* This is a workaround for buggy BIOSes which don't pass boot
* drive correctly. If GRUB is installed into a HDD, check if
* DL is masked correctly. If not, assume that the BIOS passed
* a bogus value and set DL to 0x80, since this is the only
https://github.com/coreos/grub/blob/40e2f6fd353061fdb3ec4dd6...
* Determine the hard disk geometry from the BIOS!
* We do this first, so that LS-120 IDE floppies work correctly.https://github.com/coreos/grub/blob/40e2f6fd353061fdb3ec4dd6...
* %dl may have been clobbered by INT 13, AH=41H.
* This happens, for example, with AST BIOS 1.04.https://github.com/coreos/grub/blob/40e2f6fd353061fdb3ec4dd6...
/* Check if unsuccessful. Ignore return value if carry isn't set to
workaround some buggy BIOSes. */https://github.com/coreos/grub/blob/40e2f6fd353061fdb3ec4dd6...
/* Some buggy BIOSes doesn't return the total sectors
correctly but returns zero. So if it is zero, compute
it by C/H/S returned by the LBA BIOS call. */
total_sectors = ((grub_uint64_t) drp->cylinders)
Почему ты решил, что в реализации UEFI нет подобных багов и следовательно подобных же костылей?
> Почему ты решил, что в реализации UEFI нет подобных багов и следовательно подобных же костылей?Почему ты решил, что я ратую за другую крайность, а не за прекращение нахваливания старого легаси по причине того, что новое УЕФИ -- то еще «изделие»?
А за что ты ратуешь в таком случае? Старый легаси вполне можно осовременить, как в сообщении об MBR ниже. Это было проще и надёжнее.
Мусье тщательно умалчивает про отдельное уефанство, превращающее после загрузки железо в кирпич.
Partition entry в MBR занимает 16 байт, чего вполне достаточно для полной LBA-48 адресации и дополнительной информации. Первый байт Partition entry - это байт статуса, в котором реально используется лишь один бит для указания статуса active. Ничто не мешало использовать другой бит для индикации нового формата Partition entry без давно отживших свой век CHS адресов. Так же ничто не мешало увеличить место под таблицу разделов уменьшив bootstrap code area. Тем более, что такие варианты MBR давно существуют. Короче говоря ничто не мешало осовременить MBR. Но что сделали изобретатели GPT? Они придумали совершенно новый формат, внутри которого оставили всё тот же MBR, якобы для совместимтости. В результате получаются дикии глюки несоответствия между GPT и MBR. При этом GPT пихают в диски гораздо меньше 2TB, даже во флешки с одним единственным разделом, где никакой реальной пользы от GPT нет и не будет.Legacy в BIOS - это в основном несколько прерываний, таких как int 10h и int 13h. Его так никто и не убрал и уверяю тебя, не уберут ещё очень долго. Зато туда впихнули целую операционную систему, с массой зондов. И всё это ради UEFI, "безопасного бута" и красивого интерфейса для хомячков? int 10h и int 13h - это просто детскии шалости, по сравнению со всем этим непотребством.
Проблема вообще не в способе разделения дисков, а в непродуманности файловых систем, которые, как правило, ничего не знают про boot и соответственно не умеют резервировать место под загрузчик (настоящий загрузчик, а не boot record). Из-за этого приходится либо создавать целый загрузочный раздел либо использовать gap, что вообще неправильно.
> Не прошло и сколько лет с тех пор, как UEFI появился и
> RedHat удосужился это починить?А оно кому-то надо, ну реально? На дешманском железе нет Legacy Mode / BIOS? ССЗБ.
Пааанимаааешь ... оно __пока__ есть. Но всё идёт к тому, что не будет. Так что чесаться по этому поводу надо ещё вчера :-\
> Пааанимаааешь ... оно __пока__ есть. Но всё идёт к тому, что не будет.не, не идет - интел о них позаботился.
CSM - встроенный в EFI (и намертво) эмулятор (надо полагать, цельная x86 vm). Помимо очевидной фичи, включателя которой в менюшках биоса могут уже не предусмотреть вовсе, есть неочевидная - поддерживать совместимость со stone-age firmware (да, с него даже загрузиться можно, api тоже транслируется). Это надолго.> Так что чесаться по этому поводу надо ещё вчера
поздно вам чесаться. Даже красивый модный окошкоменюшковый сетап на современной плате - скорее всего на проверку окажется uefi скриптом(sic!) или модулем.
Единственный реальный недостаток uefi - что интел, действительно, насмерть не хочет делиться нормальной документацией (есть у меня нехорошее подозрение, что нечем ему делиться, * Copyright (C) 2005-2008 Intel Co.
* Fenghua Yu <fenghua.yu@intel.com>
* Bibo Mao <bibo.mao@intel.com>
* Chandramouli Narayanan <mouli@linux.intel.com>
* Huang Ying <ying.huang@intel.com>
ну вы поняли, кто это писал после 2005го)
>А оно кому-то надо, ну реально?А еще раньше поле мотыгами копали, и всех устраивало. И никаких компуктеров не было
Системды-то тоже на го перепишуть?
На Po
Не взлетит. Уровень влияния в стеке технологий у Google находиться много выше. Ни их GoogleOS, ни тем более что-то ниже никому из производителей железа не нужно.
А зачем им производители железа (нужны, конечно, но), если они сами уже производитель? Будет такой себе Apple2, с чуть большим заигрыванием с сообществом.
Устами младенца глаголет.. детский лепет :)
>Будет такой себе Apple2, с чуть большим заигрыванием с сообществом.А ведь тут была новость, что они выкатили на продажу какой-то эпплообразный ноут. С виду только логотипом отличается.
Chromebook? :)))
Вооооот!
Производители материнок повязаны и Интелом таким коконом договоров, что ни о каком производстве плат с альтернативными прошивками и речи быть не может. А если Гугл вдруг захочет что-то выпускать сам, Интел достанет свои патенты и скажет: я запрещаю добавлять на этих платах поддержку таких-то функций. Всё, досвидос.
И будет послан. Зачем гуглу Ынтели? Для их целей нынешних армов - за глаза!
AMD!
И вы!
Вместо процессора ?
Спросите в любом компьютерном магазине, сколько они продают малинок-апельсинок и сколько - плат под интеловскую архитектуру.
>Intel MEБесполезно мазать гангрену зелёнкой, нужно всю систему менять.
Мы нашу, мы новую Землю построим..
Вот вы смеетесь, а кря.
> Вот вы смеетесь, а кря.Да, кря.
А тут средство как раз похлеще зелёнки - скальпель! :) Вырезали основную интелогниль, остальные компоненты - открытые и легко подлежащие аудиту. Так и надо делать, ведь _существующие_ платы - их надо как-то улучшать! *слабая надежда*
> А тут средство как раз похлеще зелёнки - скальпель! :) Вырезали основную
> интелогниль, остальные компоненты - открытые и легко подлежащие аудиту. Так и
> надо делать, ведь _существующие_ платы - их надо как-то улучшать! *слабая
> надежда*Улучшение, оно кому нужно? Можно в относительных величинах.
Улучшение, оно на сколько дороже будет? Можно в относительных величинах.
Улучшение, оно случайно (ну вот просто случайно ;) не будет бойкотировано одной мелкой и мягкой организацией, одним из лучших "друзей" open source?С другой стороны.
Сколько времени понадобится:
Интел, что бы спрятать это еще глубже и/или совсем сделать не отключаемым?
Производителям MBoards, что бы сделать так, что бы очистка от всякой неведомой ..., происходила только с паяльником в руках и через ...?
Итд итп.
Побольше джамперов на плате, и ППЗУ с ультрафиолетовым стиранием.
> Побольше джамперов на плате, и ППЗУ с ультрафиолетовым стиранием.И порт клавиатуры отдельный верните!!! А USB выкиньте!!!
> И порт клавиатуры отдельный верните!!! А USB выкиньте!!!
# dmesg|grep PS/2
[1] psm0: <PS/2 Mouse> irq 12 on atkbdc0
>> Побольше джамперов на плате, и ППЗУ с ультрафиолетовым стиранием.
> И порт клавиатуры отдельный верните!!! А USB выкиньте!!!Про USB - поддерживаю многократно, это просто ПОЗОР ИНЖЕНЕРИИ! Apple Lightning - стократ более правильный разъём.
>Про USB - поддерживаю многократно, это просто ПОЗОР ИНЖЕНЕРИИ!Они исправили свои косяки, смотри USB-C
>Apple Lightning - стократ более правильный разъём.идёт в комплекте с а-зонтом (С) - нафик!
USB-C - очередной позор увы. Да один очевидный косяк исправили, но все остальные - остались.
Увы, но реально Lightning - образец того как надо делать, USB (любой) - образец того как НЕ надо делать разъемы.
Не надо песен, у вас просто зонт раскрылся :)
Все это появится на двух с половиной совместимых материнках и все, но возможно заставит производителей двигаться к упрощению уефи
> ... образ initramfs c системой инициализации и инструментарием u-root, написанными на языке Go.Знают как в бочку мёда положить половник дерьма.
>> ... образ initramfs c системой инициализации и инструментарием u-root, написанными на языке Go.
> Знают как в бочку мёда положить половник дерьма.Слово "Google" в заголовке не заметил, что ли? Где ж тебе мёд-то примерещился? Маркетинг превращается, превращается тыква.... в элегантный гипер-половник.
> Знают как в бочку мёда положить половник дерьма.Не, не знают: ты в половник не помещаешся.
> параллельно с основной операционной системой параллельно выполняется ещё несколько неконтролируемых программных окружений (UEFI, SMM, Intel ME), которые формируются на основе проприетарных прошивок. Код UEFI продолжает работать после загрузки основной ОС и выполняется на уровне кольца защиты Ring -2.Они поедают ресурсы моего ЦПУ? или висят на отдельном служебном проце?
> Они поедают ресурсы моего ЦПУ? или висят на отдельном служебном проце?uefi - на твоем, это ж драйвера всякой мелкой хрени, типа rtc (больше там после загрузки ничего не остается)
ME - на своем, встроенном в чипсет (что забавно, в современных это очередной интел), ему надо работать когда основной пошел погулять или вовсе обесточен.
>> Они поедают ресурсы моего ЦПУ? или висят на отдельном служебном проце?
> uefi - на твоем, это ж драйвера всякой мелкой хрени, типа rtc
> (больше там после загрузки ничего не остается)
> ME - на своем, встроенном в чипсет (что забавно, в современных это
> очередной интел),LOL. Хорошая оговорчка по Фрейду: ME работает не на твоём чипсете, а на их ) Хоть ты его купил, но владеет им кто-то другой )
> ему надо работать когда основной пошел погулять или вовсе обесточен.
или когда товарищу майору надо
>> Они поедают ресурсы моего ЦПУ? или висят на отдельном служебном проце?
> uefi - на твоем, это ж драйвера всякой мелкой хрени, типа rtc
> (больше там после загрузки ничего не остается)
> ME - на своем, встроенном в чипсет (что забавно, в современных это
> очередной интел), ему надо работать когда основной пошел погулять или вовсе
> обесточен.Большое спасибо за ответ!
меня терзают смутные сомнения (c), анб с цру борются за каналы слежки? Открытый загрузчик? И для кого открытость? Ну в свете андроида.
Нууу... Пока производители оборудования не примут на вооружение, будет ещё и что-то, типа, CyanogenMode для BIOS :))
Мало ли в Бразилии кирпичей! :)))
хорошая новость
Если это будет действительно с открытыми исходниками, то это здорово.
Сплошные зонды вокруг... Может и правда на Эльбрус пора переползать...