Вот поэтому надо все проверять через MeInfo -verbose, FPT и остальное, а еще лучше эти проверки встроить прямо в прошивку, чтобы она колом вставала при неправильных значениях, либо сама пыталась их исправить, насколько это возможно.
По рукам они бить не могут — руки не настолько длинные, и потому идут по правильному пути, снижая сложность настройки этих технологий, которая до этого была запредельной, а теперь стала просто высокой. Если они этот тренд продолжат, то где-нибудь к МЕv15 вендоры таки смогут (и потому начнут) включать все эти вещи «одной кнопкой», а пока там просто лес стал чуть менее темным.
Таки да? Вот этого я уже не застал, потому что теперь со включенным Manufacturing Mode платформа больше не стартует.
Опять же напомню еще раз, чтобы народ меньше пугался, что ME manufacturing mode умеет выключаться сам, если flash descriptor настроен правильно. К сожалению, это «правильно» по Intel'овски запрещает из региона МЕ чтение, а это портит жизнь довольно сильно, плюс дает Intel ложную уверенность в том, что на MFS можно хранить ключи и их оттуда никто не считает.
В итоге Apple пришлось выключать его вручную только потому, что «правильную» в смысле Intel конфигурацию они не используют, и МЕ у них открыт на чтение.
1. Если у вас все нужное вам работает без драйвера (например, используется внешняя видеокарта и изображение выводится именно ей) — ничего страшного от его недоступности не будет, перестанут работать пару утилит вроде XTU или Clock Commander, но если ими не пользоваться, то драйвер можно не ставить.
2. Обычному пользователю лучше не отключать, потому что вы переводите систему из категории «тестировалась в таком виде производителем» в категорию «не тестировалась никем и никогда», и во второй могут случаться всякие сюрпризы вроде загрузки по 30 секунд и зависаний при попытке обновления прошивки. Если вы энтузиаст и прошивку умеете патчить и обновлять в ручную (а еще вам не нужна встроенная видеокарта или вывод HDCP через нее, и вы не пользуетесь SGX) — можете смело отключать.
Два чая этим авторам, наконец-то описали уязвимость в деталях.
Вообще говоря, проблема не столько в Manufacturing Mode, сколько в возможности отката на уязвимую версию ME v11 несмотря на все попытки со стороны прошивки эту возможность закрыть (если они были вообще, таковые попытки), и если благодаря Максу и Марку Apple удалось убрать возможность локальной эксплуатации, то от физической атаки на МЕ-регион в SPI flash защиты на большинстве систем нет (для машин с ME v11, для которой имеется заведомо уязвимая версия прошивки, от такой атаки защищен только на iMac Pro).
Intel решили проблему с откатом до уязвимых версий в ME v12, добавив Security Version Number в FPF'ы, т.е. после обновления на версию с SVN=X, никакие версии с SVN < X на этой машине больше загрузиться не смогут, т.е. без обхода FPF'ов (а это гораздо более серьезная уязвимость) основную проблему таки получилось решить.
Банковская система в США сильно отличается от европейской или российской, т.к. появилась раньше и развивалась по другим законам и с другими умолчаниями.
Разница в том, что основная операция клиента европейского банка, которую он проводит сам — это перевод денег на определенный чужой счет, и открытые банковские реквизиты нужны для приема платежей, т.е. «отправьте вот эту сумму на этот счет».
В США основная операция — разрешение на снятие определенной суммы со счета в банке отправителя банком получателя, и открытые банковские реквизиты нужны для отправки платежей, т.е. «позвольте снять вот эту сумму вот с этого счета».
Американский банковский чек — это именно разрешение перевести указанную сумму с указанного в чеке счета, при этом куда именно — не важно уже, именно поэтому там нужна подпись, расшифровка суммы словами, названия организации или имя получателя, и подпись отправителя, а вот реквизитов получателя никаких нет.
В итоге простейшая задача отправить кому-то денег превращается в квест, и вокруг квеста каждая компания (Zello, PayPal, Apple, Samsung, etc.) пытается наладить свой небольшой гешефт.
Или, как вариант, это может быть extern const volatile-переменная. Писать в нее можно, но не в этом модуле.
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Только не записывать, а читать, потому что записывать мешает const.
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Тоже UB и для первого поля, потому что никто не мешает включить sanitizer и memory mapper, который вместо первого поля во все классы воткнет свою структуру, и все полетит к черту.
Отличается тем, что у нее размещение определено, выравнивание определено, и делать его по другому без явного на то указания компилятор не имеет права, и потому макросы вроде OFFSET_OF() и CR() до сих пор отлично работают. У класса (хоть с виртуальными функциями, хоть без) размещение не определено, точнее определяется реализацией, т.е. никто не мешает начать, к примеру, все поля тегировать (т.е. перед каждым полем вставить еще по полю с тегом), сам класс тегировать (вставить ему GUID вначале, чтобы за размещением экземпляров в памяти потом следить), и все это останется в рамках C++ (т.е. код на C++ работать не перестанет), а у вас либо reinterpret_cast вернет непонятно что, либо все завалится еще на ассертах.
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
Ну таковая передача на C++ невозможна по стандарту даже без разных языков. У языка не определен binary interface, и потому передавать приходится либо структуры из C (у которых таковой интерфейс есть), либо использовать сериализацию в промежуточные форматы вроде protobuf.
Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Все равно UB, потому что нет в стандарте никаких гарантий на расположение полей, и завтра в этот класс компилятор вдруг напихает каких-нибудь внутренних структур байт на 20, и все развалится. Даже если оно у вас сейчас работает — это волшебство, а не C++.
У вас переменная уже extern const, оптимизировать ее компилятор уже не будет, потому что она в другом translation unit, и положить ее в регистр если и получится, то только при LTO.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
А volatile ей тогда зачем? В голову приходит только какой-то глобальный объект в многопоточной программе, который можно читать из разных мест, а писать только в одном (либо только хитрым способом). Borrow checker для бедных.
Поддержу, современным разработчикам на ассемблере писать на них реализацию замыканий не нужно, и уже, скорее всего, не будет нужно.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
А давайте обсудим.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.
У PC HW все точно так же, и за некоторые решения хочется натурально убивать голыми руками, но всех все устраивает, продукт выпущен, все довольны, недовольных шлют по вектору. Работает — не трогай, перестанет — будем посмотреть.
Дык нет же, аналоговое аудио и по метровому кабелю Belkin не едет (у меня он на столе лежит, я проверял), а едет ли VL — пока еще непонятно. Все остальное — да, т.е. кабель почти универсальный и не толщиной с палец, конечно, но все равно набор из 3 кабелей попроще таки дешевле и большинству пользователей хватит такого набора за глаза.
По рукам они бить не могут — руки не настолько длинные, и потому идут по правильному пути, снижая сложность настройки этих технологий, которая до этого была запредельной, а теперь стала просто высокой. Если они этот тренд продолжат, то где-нибудь к МЕv15 вендоры таки смогут (и потому начнут) включать все эти вещи «одной кнопкой», а пока там просто лес стал чуть менее темным.
Опять же напомню еще раз, чтобы народ меньше пугался, что ME manufacturing mode умеет выключаться сам, если flash descriptor настроен правильно. К сожалению, это «правильно» по Intel'овски запрещает из региона МЕ чтение, а это портит жизнь довольно сильно, плюс дает Intel ложную уверенность в том, что на MFS можно хранить ключи и их оттуда никто не считает.
В итоге Apple пришлось выключать его вручную только потому, что «правильную» в смысле Intel конфигурацию они не используют, и МЕ у них открыт на чтение.
2. Обычному пользователю лучше не отключать, потому что вы переводите систему из категории «тестировалась в таком виде производителем» в категорию «не тестировалась никем и никогда», и во второй могут случаться всякие сюрпризы вроде загрузки по 30 секунд и зависаний при попытке обновления прошивки. Если вы энтузиаст и прошивку умеете патчить и обновлять в ручную (а еще вам не нужна встроенная видеокарта или вывод HDCP через нее, и вы не пользуетесь SGX) — можете смело отключать.
Вообще говоря, проблема не столько в Manufacturing Mode, сколько в возможности отката на уязвимую версию ME v11 несмотря на все попытки со стороны прошивки эту возможность закрыть (если они были вообще, таковые попытки), и если благодаря Максу и Марку Apple удалось убрать возможность локальной эксплуатации, то от физической атаки на МЕ-регион в SPI flash защиты на большинстве систем нет (для машин с ME v11, для которой имеется заведомо уязвимая версия прошивки, от такой атаки защищен только на iMac Pro).
Intel решили проблему с откатом до уязвимых версий в ME v12, добавив Security Version Number в FPF'ы, т.е. после обновления на версию с SVN=X, никакие версии с SVN < X на этой машине больше загрузиться не смогут, т.е. без обхода FPF'ов (а это гораздо более серьезная уязвимость) основную проблему таки получилось решить.
Следующий пост Брайана можно добавить, хоть он и озаглавлен неудачно:
dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust
Разница в том, что основная операция клиента европейского банка, которую он проводит сам — это перевод денег на определенный чужой счет, и открытые банковские реквизиты нужны для приема платежей, т.е. «отправьте вот эту сумму на этот счет».
В США основная операция — разрешение на снятие определенной суммы со счета в банке отправителя банком получателя, и открытые банковские реквизиты нужны для отправки платежей, т.е. «позвольте снять вот эту сумму вот с этого счета».
Американский банковский чек — это именно разрешение перевести указанную сумму с указанного в чеке счета, при этом куда именно — не важно уже, именно поэтому там нужна подпись, расшифровка суммы словами, названия организации или имя получателя, и подпись отправителя, а вот реквизитов получателя никаких нет.
В итоге простейшая задача отправить кому-то денег превращается в квест, и вокруг квеста каждая компания (Zello, PayPal, Apple, Samsung, etc.) пытается наладить свой небольшой гешефт.
Если программа однопоточная — volatile не нужен, только портит оптимизатору жизнь. Если многопоточная — его недостаточно, от гонок по данным так и не избавились.
Т.е. если там заведомо не регистры, то зачем?
Я не про то, что не знаю, зачем оно так, а про то, для чего может понадобится именно extern const volatile, а обычного extern const не хватит, и ничего кроме многопоточной программы и регистров в голову не приходит. В одном потоке переменная (обычная, не отображенная на регистр) из другого юнита меняться не может, т.к. это нарушает инварианты.
Разница в том, где именно происходит проверка на то, что правила доступа не нарушаются, и в C++ она не происходит, потому что вы об этом просите явно очень заметной конструкцией (в Rust таковые еще заметнее), а в JS у вас и соглашение в голове, и проверка его там же, и найти таковые нарушения grep'ом просто так не получится.
Если же использовать особенности конкретных реализаций, то это вновь волшебство, а не C++, потому что даже минорное обновление любого компонента компилятора может вам разломать все в самых неожиданных местах, и про котел в аду там выше не зря написано.
Borrow checker тут при том, что он гарантирует инвариант «доступ к переменной может быть либо из многих мест на чтение, либо из строго одного места на чтение и запись», а конструкция extern const volatile — это как раз про доступ к временной из разных мест на чтение, а для бедных он потому, что хоть и гарантирует, что значение при доступе действительно будет прочитано из переменной каждый раз, но не обеспечивает ни отсутсвие гонки по данным (т.е. чтение во время изменения), ни проверок во время компиляции.
На ассемблере сейчас пишут вещи, которые либо истинно зависимы от платформы (настройку таблиц трансляции памяти, запуск SGX-анклавов, разного рода хитрую математику с SSE 4.2, и т.п.), либо исполняются в атипичной вычислительной среде (программам на С и выше нужен стек, а если у вас стека нет вообще, потому что и основная оперативная память, и кэш второго уровня, который можно использовать как память, еще не инициализированы, а сам ваш код исполняется прямо из флеша).
В итоге замыкания что там, что там — нафиг не нужны, задач хватает и без них. Т.е. спросить про них конечно могут, и я бы ответил что-нибудь вроде «функция (часто анонимная, часто с параметрами) на языках высокого уровня, захватывающая либо переменные из контекста по списку, либо все вообще, которые ей видны», но сразу же задал бы контр-вопросы вроде «о каком ЯП идет речь, почему не используется обычная функция с параметрами, уверены, что вам оно надо». Написать их можно хоть на С, хоть на ассемблере, хоть в машинных кодах прямо, но это справедливо для любого кода вообще, но за попытку использования такого кода в бою вам, скорее всего, ваши же коллеги голову и оторвут.
const — не даст (без кастов) писать в переменную из кода, до которого компилятор дотягивается, а volatile не даст сработать агрессивным оптимизациям, которую эту переменную могли бы выкинуть вообще, или заменить на константу.
Итого получается что-то вроде «зарезервируй мне, компилятор, кусок памяти где-нибудь здесь, но писать в него обычным образом не давай».
Подойдет указателям на RO-регистры, доступные через MMIO.