«Вы не поверите!» И USB-дисководы к ним, чтобы тестировать.
В промышленности и эмбеддеде весь этот Apple с их think different даже рядом не плавал, там нужна обратная совместимость с технологиями тридцатилетней давности, т.к. ради «прогресса» никто свое оборудование на миллионы долларов менять не намерен и не будет. За совместимость готовы платить приличные и неприличные деньги, а наша задача, как производителей решений для индустрии, состоит в том числе и в том, чтобы эту самую совместимость обеспечить.
До сих пор на платах для Skylake поддерживается Windows CE 6, которая загружается COM-файлом из MSDOS 6.22, а если через пару лет Intel откажется от поддержки CSM — ее придется всять на себя, т.к. гарантированный срок поддержки сегодняшних решений — 10 лет минимум, а они до сих пор в legacy mode по умолчанию.
Именно, только теперь уже TPM 2.0 на дворе, т.к. SHA1 теперь доверять не принято. Прямо по ссылке написано: «Apple simply does not use the TPM hardware», и потому любое шифрование дисков, любые пароли на EFI, и любая pre-boot безопасность на машинах Apple решаются одним вредоносным DXE-драйвером, который пишется за неделю, или вредоносным OROMом на внешнем устройстве вроде такого. И это все — только верхушка айсберга.
На здоровье. С юниксовыми ФС тоже больших проблем нет, драйверы для Ext2/3/4 и HfsPlus уже написаны. Проблем особых написание таких драйверов не составляет, чаще всего их можно из *nix портировать без особого бубна.
Там, скорее всего, FSP будет вместо PEI, а это такой же блоб на мегабайт, как и все остальное, плюс BootGuard под coreboot скорее всего отключат. Брать на массовом рынке стало катастрофически нечего, хоть сам бери и пиши прошивку с нуля, купив у Intel лицензию на MRC…
Кнопки, которые есть, но не используются лично вами, значительно лучше, чем те, которые вам нужны, а их нет. Вы пользуетесь Pause, Print Screen /SysRq или Scroll Lock? А я пользуюсь каждый день, и если их на клавиатуре нет — это повод достать нормальную клавиатуру.
Добавлю, что там еще и прошивка — полный хлам, застрявший на уровне 2007 года. BootGuard'а нет, SMM нет, SecureBoot'а нет, защиты от вредоносных OROM'ов нет, TPM не поддерживается. Да, у них теперь есть пара очень хороших специалистов по безопасности прошивки, но там, как в старом анекдоте, «всю систему надо менять».
Если получится запустить из OROM, будет совсем хорошо, спасибо за попытку заранее.
По руссификации — не сталкивался с этой задачей, но думаю, что пары протоколов будет достаточно (знать бы только каких именно...). В крайнем случае, интерфейс можно весь в графической консоли битмапами рисовать, как в старые добрые времена.
В данном случае, это все же больше для скриншотов, чем для примера.
Интересущихся «вирусами» советую посмотреть код SMM Backdoor уважаемого d_olex, и его запись в блоге о разработке этого бэкдора.
И тогда этих EbcDxe тоже надо с собой носить по количеству архитектур. Если основной драйвер огромный (UGA/GOP-драйвер для Radeon for MAC, к примеру), то есть смысл собрать его в EBC и носить с собой пригоршню интерпретаторов на каждый случай, а вот для таких поделок в 3 экрана EBC — только лишний оверхед.
Просто потому, что в игры играют миллионы, а настройками BIOS Setup делятся десятки. Денег на этой фиче не заработать, только из за нее плату у тебя, а не у конкурента, никто не купит — т.е. для производителя смысла в этой фиче почти нет. Мне она понадобилась — вот я ее и написал.
Что мешает — да ничего, собственно. ASUS, к примеру, давно уже позволяет сохранить по F12 скриншот BIOS Setup в формате BMP. Почему это до сих пор не внедрено в массы — черт его знает, разработчики не видят необходимости (у них перенаправление текстовой консоли есть, его хватает в 95% случаев), менеджеры никогда не работали с BIOS Setup и не знаю про него ничего, а пользователи не могу достучаться до людей, принимающих решения, через три линии «технической поддержки».
Придется держать отдельные версии в любом случае — исполнитель EBC стартует в начале фазы DXE, а там еще до этого две фазы на полмегабайта кода суммарно, которые делают всю черную работу по инициализации процессора, кэша L2, оперативной памяти и других жезненно необходимых устройств. Это все на EBC не напишешь, как не крутись.
Драйверы те написаны на тулките GNU-EFI и тоже собираются по экземпляру для каждой архитектуры, на данный момент только для x86 и amd64.
Большое пожалуйста.
Драйвер собирается для целевой архитектуры и для разных архитектур нужны разные драйверы. По идее, есть возможность собрать DXE-драйвер в байткод EBC, но, во-первых, далеко не во всех прошивках есть драйвер для исполнения этого байткода (зовут его EbcDxe, можете открыть свою прошивку в UEFITool и поискать такой), во-вторых, сам этот исполнитель пока собирается только для IA32, AMD64 и IA-64, т.е. ARM, MIPS и PPC все равно в пролете, в-третьих, компилятор в EBC стоит денег, а бесплатно можно только писать непосредственно на байткоде, как это делает icbook.
В общем, намного проще собрать несколько платформо-зависимых драйверов и рядом их положить, места сейчас для OptionROM хватает, а для обычной прошивки кроссплатформенность вообще не нужна, если процессор вдруг не поменятся с x86 на ARM (у AMD были планы сделать попиново совместимые процессоры с различными ядрами, но от них отказались, и правильно, на мой взгляд).
Я подпишусь не только на UEFI, но на нее — в первую очередь. И я хочу, чтобы статья целиком про UEFI была хотя-бы в хабе firmware, а не просто в «системном программировании», которое слишком общее, и к которому можно подвести разработку собственной ОС, и написание драйверов для FUSE, и обзор новых WinAPI.
Замените в своем комментарии UEFI на Derby.js и получится то же самое по смыслу — а хаб отдельный для нее есть.
Пиши сюда в «системное программирование», как и предлагается, и пусть вылезает все, что нужно. И аудитория найдется, если в пятницу вечером не публиковать.
А теги у вас перестали работать потому, что кто-то поставил вам в карму минус, а контр-плюс туда поставить невозможно, т.к. у вас нет публикаций. Скажите, вас это сильно мотивирует взять и написать отличную статью прямо сегодня? А ведь задумка была именно такая, ЕМНИП.
Добавлю еще, что невозможность поставить плюс в карму пользователю без статей на корню убило такое явление как «комментарий полезнее поста». Примеров тьма, вот JerleShannara — человек пишет о своем опыте работы с прошивками, с BIOS, с coreboot, оставляет полезные комментарии, а поставить ему плюс в карму я не могу, у него, видите ли, нет публикаций. Т.к. минус поставить можно, то такие пользователи рано или поздно оказываются в режиме «один комментарий в час» и уходят с Хабра. Эта политика не мотивирует к написанию новых постов, уважаемое НЛО. Сделайте с ней что-нибудь, прошу.
Хабр снова торт! Спасибо большое за статью.
Сталкивался с SystemC во время учебы, и тогда он показался достаточно интересным, но проблемы с открытыми (или хотя бы дешевыми) утилитами для синтеза останавливали. Видно, что с тех пор прогресс ушел далеко вперед, но утилит таких по прежнему нет — печально.
В промышленности и эмбеддеде весь этот Apple с их think different даже рядом не плавал, там нужна обратная совместимость с технологиями тридцатилетней давности, т.к. ради «прогресса» никто свое оборудование на миллионы долларов менять не намерен и не будет. За совместимость готовы платить приличные и неприличные деньги, а наша задача, как производителей решений для индустрии, состоит в том числе и в том, чтобы эту самую совместимость обеспечить.
До сих пор на платах для Skylake поддерживается Windows CE 6, которая загружается COM-файлом из MSDOS 6.22, а если через пару лет Intel откажется от поддержки CSM — ее придется всять на себя, т.к. гарантированный срок поддержки сегодняшних решений — 10 лет минимум, а они до сих пор в legacy mode по умолчанию.
По руссификации — не сталкивался с этой задачей, но думаю, что пары протоколов будет достаточно (знать бы только каких именно...). В крайнем случае, интерфейс можно весь в графической консоли битмапами рисовать, как в старые добрые времена.
Интересущихся «вирусами» советую посмотреть код SMM Backdoor уважаемого d_olex, и его запись в блоге о разработке этого бэкдора.
Драйверы те написаны на тулките GNU-EFI и тоже собираются по экземпляру для каждой архитектуры, на данный момент только для x86 и amd64.
Драйвер собирается для целевой архитектуры и для разных архитектур нужны разные драйверы. По идее, есть возможность собрать DXE-драйвер в байткод EBC, но, во-первых, далеко не во всех прошивках есть драйвер для исполнения этого байткода (зовут его EbcDxe, можете открыть свою прошивку в UEFITool и поискать такой), во-вторых, сам этот исполнитель пока собирается только для IA32, AMD64 и IA-64, т.е. ARM, MIPS и PPC все равно в пролете, в-третьих, компилятор в EBC стоит денег, а бесплатно можно только писать непосредственно на байткоде, как это делает icbook.
В общем, намного проще собрать несколько платформо-зависимых драйверов и рядом их положить, места сейчас для OptionROM хватает, а для обычной прошивки кроссплатформенность вообще не нужна, если процессор вдруг не поменятся с x86 на ARM (у AMD были планы сделать попиново совместимые процессоры с различными ядрами, но от них отказались, и правильно, на мой взгляд).
Замените в своем комментарии UEFI на Derby.js и получится то же самое по смыслу — а хаб отдельный для нее есть.
Сталкивался с SystemC во время учебы, и тогда он показался достаточно интересным, но проблемы с открытыми (или хотя бы дешевыми) утилитами для синтеза останавливали. Видно, что с тех пор прогресс ушел далеко вперед, но утилит таких по прежнему нет — печально.