Они этот кусок используют как признак manufacturing mode, и в этом самом режиме отключают много чего, в том числе и проверку хеша DXE-тома. Позор это, или дизайн такой — мне не ведомо, но на самых новых машинах вроде бы исправили уже.
Еще более смешной баг был у AMI, эти отмочили следующее: драйвер BootGuardPei, накрытый BG вместе со всем остальным PEI-томом и хешами, действительно успешно проверял хеши DXE-тома, только вот при несовпадении он не отключал машину и не переводил ее в режим восстановления прошивки, а создавал HOB с одним байтом, чтобы потом BootGuardDxe уже показал пользователю нужный UI и занимался восстановлением уже из DXE. Я когда это осознал — ржал минут десять, а потом пошел и удалил весь BootGuardDxe, и все ожидаемо заработало.
Какие IBV, такие и цепочки доверия, и даже если сам по себе BG может быть настроен идеально, он покрывает только первое звено, а второе может быть любого качества, в том числе и вот такого.
Я считаю, что это честно в определенном смысле, потому что обманутые ожидания хуже отсутствия таковых. Вся большая четверка азиатских ОЕМов (Asus, Gigabyte, MSI, Asrock) на своих десктопных платах BootGuard не настраивает специально, оставляя простор для модификации прошивок энтузиастами, и потому купить десктопную плату с BG — это целый отдельный квест. С другой стороны этих баррикад у нас Lenovo, которая якобы заботится о безопасности, и якобы настраивает BG, и даже почти перестала косячить с его настройками, но потом выясняется, что проверка DXE-тома отключается одним битом после сигнатуры LNVBBSEC, а сама эта сигнатура лежит в свободном месте тома с NVRAM, который даже PRRами не накрыт. Вот такой BG — хуже, чем никакого.
Главное чтобы его немедленно не откопали IBV, и не начали продавать как value-add, хвалясь совместимостью их новейших систем с MSDOS 6.22 и Windows ME…
И опять у нас в комментариях теории заговора против открытых систем, и отличные-отличные идеи поставить физический переключатель, и забыть о проблемах (и об обновлениях тоже).
Не люблю цитировать сам себя, но придется:
Необходимость двигать тумблер сразу же лишает возможности автоматического обновления прошивки, а т.к. там десяток мегабайт кода (после распаковки), который из крупных кусков кода на С и Ассемблере разных производителей низкооплачиваемые азиатские инженеры собрали на скотч и отборный мат, то в таком коде неизбежны баги, и их очень хочется починить таким образом, чтобы пользователю для этого ничего делать не пришлось. Именно для этого у нас сейчас обновления прошивки ставятся через ESRT прямо из Windows Update и Linux Vendor Firmware Service так же, как и обновления драйверов и остального софта. Просто прошивка современного ПК и сервера — давно уже намного более software, чем firmware, там сетевой стек от FreeBSD, драйверы для FAT32 и NTFS, и OpenGL в BIOS Setup. А сделаешь тумблер — и все, никаких тебе автоматических обновлений, потому что у пользователя лапки, и никакие тумблеры он переключать не будет, потому что боится, потому что сложно, и потому что «лошадь в ванне с огурцами.жпг».
И тумблер WE/RO, и резервирование, и несколько микросхем физически — все это делается давно и успешно на промышленной электронике, обслуживаемой профессионалами за деньги. А тут у нас домашняя электроника, которую пользователь боится больше, чем она его, и потому все подобные начинания будут немедленно зарезаны отделом дизайна и отделом маркетинга у всех компаний, ориентирующихся не на энтузиастов. Для остальных есть ребята типа Purism и system76, у которых там и прошивки все открытые, и тумблер они могут поставить легко, если их убедить в том, что с тумблером их целевая аудитория энтузиастов купит больше их продукции.
По некоторым данным иногда все-же запускается, но на полутора платах с двумя с половиной древними версиями прошивки, которые, скорее всего, просто CSM не полностью отключают.
Действительно на удивление хорошо получилось, пользуюсь давно, привык, удивляться уже перестал. Пользуюсь MBP 13" на M1, и он быстрый, холодный, тихий даже при высокой постоянной нагрузке, держит батарею по два дня, и при этом на нем практически все, чем я пользуюсь, работает быстрее, чем на рабочем MBP 16" на i9 с конфигурацией дороже вчетверо.
Другие ОСи там обязательно заведут (возможность запускать свой код вместо ядра XNU имеется), но непонятно, насколько хорошо они там заработают на голом железе, с учетом того что документации открытой нет, и драйверы придется писать по результатам реверса. Да и не очень понятно, зачем оно все, если виртуализация уже сейчас работает достаточно хорошо и быстро из коробки, Linux запускается без проблем, Windows для ARM тоже завели теперь.
Тяжелый был год, перешли на другую архитектуру, значительно переделали SecureBoot, теперь вот без остановки ловим и чиним баги, плюс еще удаленка, из за которой не работаешь из дома, а живешь на работе. Некогда в итоге писать, да и не хочется особо.
Пожалуйста. Вообще статья получилась плюс-минус «обо всем и не о чем», но в качестве иллюстрации к тому, что надо бы сначала версию выяснить, а потом идти код смотреть — пойдет.
Error: success, особенно если это был errno — весьма популярная ситуация даже у тех, кто на C давно пишет, да и сама по себе идея errno довольно глупая (потому что одна глобальная переменная без каких-либо метаданных о том, кто ее выставил и когда — это, скажем так, недостаточно), но теперь уже никто исправлять стандартную библиотеку не станет, поэтому приходится жить с этим всем.
Обратите внимание на пятый коммутатор прямо рядом с M.2-слотом, и на вот эту ремарку на сайте самой платы: *If PCIE5 slot is occupied, M2_2 will be disabled. Чуете подвох?
Там отдают либо все 16 линий в один слот, если один занят, а второй — нет, или по 8 на оба, поэтому и приходится активничать. Можно, конечно, поставить тумблер и дать все это коммутировать вручную, но пользователь нынче балованный и такую фигню терпеть не будет.
Устройства эти пассивные (и тупые как пробка, управляются одним выводом SEL), в дереве их не увидеть.
Эти пять коммутаторов — они не для чипсета, они как раз для тех двадцати дифференциальных пар, которые идут непосредственно от CPU. Почему их ставят: так дешевле, чем встраивать коммутацию в процессор (придется тащить вдвое больше линий от него), поэтому коммутируют уже на месте.
Мне кажется, мы тут несколько не договорились о терминологии, и потому называем «коммутатором» разные устройства. Вот эти вот — тупые физические переключалки туда-сюда, а не хитрые умножители одной линии на 4, со своим PCIe-адресом, прошивкой, роутером и перепаковщиком пакетов.
Тем не менее, если тупой физический переключатель не влезает в тайминги и\или импедансы, нужные для PCIe 4.0, то как 4.0 он не заведется.
Сам нашел в итоге, NXP CBTL04083B, 3.3 V, 4 differential channel, 2: 1 multiplexer/demultiplexer switch for PCI Express Gen3. Будет ли он работать с PCIe 4.0 — одному рандому известно, производитель ничего не гарантирует.
Очень часто линий не хватает (у десктопных процессоров их может быть всего 16, если DMI до чипсета не считать), поэтому коммутаторы ставят и на эти линии тоже, чтобы автоматически делать из 1x16 2x8 на две видеокарты. Так вот, эти коммутаторы тоже надо ставить с запасом, и в свое время ASUS пришлось выпускать платы серии GEN3, которые от обычных отличались только моделью коммутаторов. На Z490 тот же ASUS поставил нужные коммутаторы заранее.
Это от того, что половина этих настроек толком не работает, а вторая — совсем не работает, т.е. скрывают их не от хорошей жизни. Более того, каждая показанная пользователю настройка — это контракт, потому что а) ее нужно документировать в мануале, б) ее нужно поддерживать по ходу обновлений, в) любая комбинация настроек должна хоть как-то работать, т.е. все сложные взаимосвязи нужно найти и запрограммировать, и г) каждая показанная пользователю настройка увеличивает тестовую матрицу кратно на количество ее значений, отчего очень быстро происходит комбинаторный взрыв и тестирование такой прошивки нормально просто не может закончиться. В результате адекватные вендоры выбирают себе определенный набор настроек, которые они готовы поддерживать и тестировать, и скрывают все остальные, а неадекватным китайским суньхуйвчаям на это категорически навалить.
В стародавние времена, когда DFi еще выпускала платы для массового рынка, они отличались полным доступом ко всем настройкам, и при этом отсутствием какой-либо автоматики вообще, вот ручки — крутите. Платы эти были нежно любимы оверклокерами и прочими фанатами и энтузиастами, зато простой народ их не покупал, и в конце концов DFi перестали делать их, переориентировав бизнес на CoM, SBC и ODM.
На дорогие платы ставят коммутаторы, чтобы линий побольше было, а они у PCIe 4.0 дороже сильно, поэтому просто так их на вырост не ставят. В остальном я согласен с предыдущим оратором, потому что signal integrity это не хер собачий, и обеспечить нормальную работу даже 3.0 — это очень задорные танцы с бубном (зато 1.0 можно завести по мокрой бельевой веревке буквально).
Чтобы вот этим всем не заниматься, в UEFI 2.5 мужики придумали Audit Mode, в котором можно сказать SecureBoot'у «вот эти ОРОМы мне разреши, пес», не переподписывая их. К сожалению, опция вышла малопопулярная, и надо бы еще одну статью написать, «Укрощаем UEFI SecureBoot, пять лет спустя», чтобы подробнее рассказать про то, что там изменилось с прошлой и как с этим всем теперь жить.
Еще более смешной баг был у AMI, эти отмочили следующее: драйвер BootGuardPei, накрытый BG вместе со всем остальным PEI-томом и хешами, действительно успешно проверял хеши DXE-тома, только вот при несовпадении он не отключал машину и не переводил ее в режим восстановления прошивки, а создавал HOB с одним байтом, чтобы потом BootGuardDxe уже показал пользователю нужный UI и занимался восстановлением уже из DXE. Я когда это осознал — ржал минут десять, а потом пошел и удалил весь BootGuardDxe, и все ожидаемо заработало.
Какие IBV, такие и цепочки доверия, и даже если сам по себе BG может быть настроен идеально, он покрывает только первое звено, а второе может быть любого качества, в том числе и вот такого.
Заодно могу порекомендовать вот эту презентацию об относительно недавней TOCTOU-атаке на Boot Guard, из которой я взял картинку выше.
Не люблю цитировать сам себя, но придется:
Другие ОСи там обязательно заведут (возможность запускать свой код вместо ядра XNU имеется), но непонятно, насколько хорошо они там заработают на голом железе, с учетом того что документации открытой нет, и драйверы придется писать по результатам реверса. Да и не очень понятно, зачем оно все, если виртуализация уже сейчас работает достаточно хорошо и быстро из коробки, Linux запускается без проблем, Windows для ARM тоже завели теперь.
Error: success, особенно если это был errno — весьма популярная ситуация даже у тех, кто на C давно пишет, да и сама по себе идея errno довольно глупая (потому что одна глобальная переменная без каких-либо метаданных о том, кто ее выставил и когда — это, скажем так, недостаточно), но теперь уже никто исправлять стандартную библиотеку не станет, поэтому приходится жить с этим всем.
Эти пять коммутаторов — они не для чипсета, они как раз для тех двадцати дифференциальных пар, которые идут непосредственно от CPU. Почему их ставят: так дешевле, чем встраивать коммутацию в процессор (придется тащить вдвое больше линий от него), поэтому коммутируют уже на месте.
Мне кажется, мы тут несколько не договорились о терминологии, и потому называем «коммутатором» разные устройства. Вот эти вот — тупые физические переключалки туда-сюда, а не хитрые умножители одной линии на 4, со своим PCIe-адресом, прошивкой, роутером и перепаковщиком пакетов.
Тем не менее, если тупой физический переключатель не влезает в тайминги и\или импедансы, нужные для PCIe 4.0, то как 4.0 он не заведется.
В стародавние времена, когда DFi еще выпускала платы для массового рынка, они отличались полным доступом ко всем настройкам, и при этом отсутствием какой-либо автоматики вообще, вот ручки — крутите. Платы эти были нежно любимы оверклокерами и прочими фанатами и энтузиастами, зато простой народ их не покупал, и в конце концов DFi перестали делать их, переориентировав бизнес на CoM, SBC и ODM.