Да пишите уже, пофиг, достаточно там народа или нет, народ сам понемногу подтянется из поисковых систем, если ему интересно будет. Понятно, что создание контента — это тяжелый труд, но тут получается известная уловка 22, и разорвать цикл «нет контента» -> «нет читателей» -> «нет смысла писать» -> «нет контента» можно только на этапе «нет смысла писать», выдумав себе этот смысл. Я в свое время три десятка статей так написал (и посмотрите до чего они меня довели!), и очень постараюсь продолжить писать, когда снова время найду и НДА спадут.
Хитрый план, т.е. раньше мы кормили PSP настройками из PEI, а теперь будем их класть прямо на его ФС, чтобы он память до отпускания ресета тренировал? Забористое курят, не отнять…
Очень много задач бринг-апа х86 вообще не освещено на русском нигде, совсем. Да тот же, прости рандом, IRQ routing, про который как раз и можно рассказать, заодно рассказав про PIC/APIC/X2APIC, или про MSI (и их связь с SIPI). Про PCIe можно вообще книгу писать, и не одну, то же самое про CPU power management, то же самое про ACPI, и т.п. Вот это все — оно интересное очень, но действительно удел узкой группы людей, и продолжит таковым быть, если не писать про это.
Чтобы тратить его в тот момент, когда продавать акции крайне невыгодно, а наличность все равно нужна на текущие расходы.
Добавление низкорисковых активов и снижает бету вашего портфеля, и добавляет диверсификацию в другой класс активов. Диверсификация — это отлично, а вот низкая бета автоматически означает и низкую премию за систематический риск, поэтому 90\10 считается весьма рисковым портфелем для тех, кто не пугается уменьшения его стоимости в разы во время очередного кризиса, 60\40 — консервативным портфелем для тех, кто этого пугается. По факту, чем больше доля облигаций и\или кэша, тем более долгий кризис можно будет пересидеть без продажи акций в убыток, но и тем медленнее рост.
У меня самого сейчас 75\25 на обычном аккаунте, и 90\10 на пенсионном (401к), и я уже раза три подумывал над тем, чтобы перейти на обоих на 95\5 или даже 100\0, но т.к. я на пережил пока что всего один короткий кризис (мартовский этого года), и пока что свою собственную толерантность к риску достоверно не могу оценить, то пока что оставляю вот так. Посмотрим, когда начнется, и как долго продлится следующий…
Экономика сильно глобализована, и рынки акций все равно получаются сильно скорректированными, потому если вам реально нужно защищаться от падения, то лучше всего купить активы другого класса, которые при падении рынка акций не падают (VBTLX какой-нибудь). И то это нужно все только тем, у кого обязательства перед кредиторами или жизнь за счет средств с фондового рынка (т.е. нужно постоянное поступление наличных денег независимо от ситуации на рынке акций), если же у вас есть дополнительные источники дохода, то лучшая стратегия — просто пересидеть падение, не продавая ничего.
У меня самого портфель из AAPL(30%, только RSU и ESPP, которые я меняю на VTSAX сразу же после того, как они получают статус long-term capital gain, т.е. через год для RSU и через два года для ESPP), VTSAX(40%), VBTLX(15%), VTIAX(13%), и резервного фонда (2%). Новые покупаю раз в месяц на свободные средства так, чтобы проценты оставались плюс-минус в нужных коридорах, за альфой не гонюсь — пусть другие гонятся, да и кризис мартовский пересидел нормально (смотреть на уполовинивание суммы в долларах было неприятно, но если смотреть на это не как «блин, как портфель то жестко подешевел», а как на «фигасе как все пошли в нал переливаться, и как он сразу подорожал», то полегче, да и закончилось быстро все относительно).
Там еще совершенно конские комиссии за управление мешают, если о российском рынке говорить. Какой-нибудь VTSAX с его 0.04% или FZROX вообще с 0% — это самое простое решение для тех, кому за альфой гоняться лень, и бета вокруг единицы их полностью устраивает. Такой же ПИФ на российском рынке хочет сумасшедший 1% за управление, снижая и без того не очень высокую премию за весьма серьезный риск. Вот поэтому там есть еще какой-то плюс-минус смысл собирать портфели самому, регрессии строить, перетряхивать эти портфели, etc.
Лишку хватанул, признаю. Rust умеет выкидывать часть проверок в релизе (например, проверки на переполнение целочисленных типов, и то можно попросить оставить), но не проверки на выход за границы массивов.
Проверка одна все равно будет, там, где тип i будет ограничен диапазоном 0..200, т.е. на языке с достаточно строкой типизацией в этой программе выше будет ошибка на строке a[i] = i, потому что слева на i наложены более строгие ограничения, чем справа. В результате компилятор скажет вам «гражданин, наложите дополнительные ограничения на i (предлагаю 0..200), или я вам ничего не соберу, спасибо». А потом добавит эту проверку (один раз при получении значения снаружи), и забыть ее не получится.
Не надо ничего запрещать, но необходимо улучшать инструменты, чтобы делать меньше ошибок. Никто не говорит ни о запрете (написал же выше, нравится — пользуйтесь на здоровье), ни о полном решении проблемы ошибок. Я тут говорю о том, что нужно бороться с постулатом из известной шутки про то, что «если бы строители строили так, как программисты программы пишут, то первый же залетевший дятел разрушил бы всю цивилизацию». Улучшать инструменты, обучать человеков пользоваться ими, искать замену технологиям, которые доказали свою принципиальную сложность и непознаваемость.
Дык это, в релизных конфигурациях этих проверок нет, только в отладочных. А нет их в релизных потому, что в Rust и других подобных языках с развитой системой типов компилятор может доказать отсутствие переполнений и выкинуть проверки на них, при условии, что сам язык не нарушает свои собственные инварианты (т.н. soundness) и что эти инварианты не нарушены программистом в unsafe-блоках. В том то и фишка, что никто не предлагает проверять все подряд все время, предлагают писать код так, чтобы проверял компилятор во время сборки.
Проблема именно в языке как таковом. Язык оказался принципиально не совместим с человеками, потому что человеки делают на нем ошибки (они неизбежны по человеческой природе), а ошибки эти имеют непредсказуемые последствия. Вот такие, например, последствия имеет банальное переполнение буфера даже с учетом всех вообще технологий предотвращения эксплуатации. И это на платформе, в безопасность которой ежегодно вкладываются сотни миллионов долларов, а в результате все равно одна небольшая ошибка (забыли добавить новое значение в switch, отчего сработал слишком разрешительный default) приводит к получению полного контроля над удаленным устройством без участия его владельца.
Хорошо сделанная система, которая взаимодействует с людьми, должна учитывать ограничения этих самых людей, и минимизировать как количество ошибок, как и глубину распространения эффектов от них, а в С вместо этого половина конструкций языка — это undefined behavior, а из другой половины разного рода острые грани торчат, про которые никто толком не знает, пока эти грани в очередной раз не разорвут всю безопасность на немецкий крест. Хороший язык должен по умолчанию следить за тем, чтобы пользователь не творил ерунды, а если ему надо ее творить, чтобы это творение было явным, и чтобы у каждого такого места «пошел в пень, компилятор, я лучше знаю» обязательно стояла табличка «ОСТОРОЖНО, РАБОТАЮТ ЛЮДИ!». А в С эту табличку надо программисту на лбу рисовать перманетным маркером.
Отнюдь, проблема именно в С, а точнее, в несовместимости С с потоковой крупномасштабной коммерческой разработкой. Язык для своей ниши требует слишком высокой дисциплины от всех участников процесса, а дисциплину эту настолько высокую практически невозможно обеспечить, потому что это самое обеспечение требует несовместимых с реальностью затрат времени.
Вот хороший пример кода на С, обмазанного достаточным количеством кода на AstraVer для того, чтобы доказать его корректность. Написание всего этого кода (весь проект — гарантированно безопасный загрузчик PE-образов для UEFI) заняло у двух не самых глупых товарищей полгода, а я такой же загрузчик на том же С (но уже без каких-либо гарантий, кроме «от фаззинга не падает» и «мамой клянусь») написал в 2016 году за три дня. В итоге программировать на С так, чтобы гарантировать отсутсвие ошибок, могут себе позволить только те, кто сидит на финансировании из бюджета, и потому по времени практически не ограничен, а коммерческие компании вынуждены бежать, сломя голову, только чтобы на своем месте оставаться, и потому практически весь их код на С не выдерживает никакой критики с точки зрения безопасности.
В итоге недостатки слишком много позволяющего языка пытаются чинить в железе, уже занесли туда теневой стек (Intel CET), подписывание указателей (ARM PAC), тегирование памяти (ARM MTE), и теперь работают над заносом туда же контрактов, которые будет расставлять компилятор, потому что программиста это делать невозможно заставить (CHERI).
Понятно, что для микроконтроллеров, к которых вся прошивка — это конечный автомат на десяток состояний, это все не нужно, и там можно продолжать писать на С спокойно, потому что вся программа влезает в голову одного инженера. Проблемы начинаются там, где в программе уже больше миллиона строк кода, и над ней работает сотня-другая людей непрерывно. Именно там становятся нужны любые возможные способы обеспечить локальность эффектов, предотвратить ошибку до того, как она попала в репозиторий, остановить разработчика от необдуманных поступков вроде создания гонки по данным и передачи данных в соседний поток без использования примитивов синхронизации, т.е. в конце концов именно там мы приходим к необходимости языков вроде Rust.
Короче, если у вас пока что на С все работает и жрать не просит — смело продолжайте на нем писать. А у нас вот давно уже от С геморрой сплошной, а заменить его толком не на что, потому что C++ — это такое же хтоническое чудовище, вид сбоку, а внедрение Rust пока буксует по экономическим причинам (дорого переучивать всю ораву, дорого писать клей, дорого переписывать то, что не получилось приклеить, а дело делать надо уже сейчас).
Ничего себе, а Хабр то, видимо, снова торт!
Спасибо огромное за эту серию статей, потому что теперь есть куда послать интересующихся или сомневающихся русскоязычных товарищей, которых раньше приходилось слать в статьи Фамы и Френча, переведенные автоматикой.
Виртуальную машину EBC наконец-то выкинули (точнее, сделали опциональной, но это по факту выкинули) в UEFI 2.8. Причин этому много, основная — практически ничего на EBC так и не написали, потому что и ВМ сама по себе получилась медленная, глупая, и компилятор для нее Интел зажала открывать и требовала за него деньги, а на ассемблере писать хоть и можно стало рано или поздно благодаря стараниям энтузиастов, но дураков писать на нем драйверы не нашлось. До 2018 года UEFI реально работала только на х86, и потому никаких причин собирать драйвер в EBC, чтобы он запускался на разных архитектурах, у корпораций не было.
Прошивка никогда не будет делить драйверы для какого-то нетривиального оборудования с полноценной ОС, потому что объем поддерживаемых фич у ОРОМа и драйвера из ОС несравнимый. Драйверу графической карты для UEFI («видеобиосу») нужен, по сути, только фреймбуфер (исключения вроде CoreEG2 у Apple, в котором 42 функции и который поддерживает 3d-ускорение ради того, чтобы recoveryOS не выглядела убого, из за чего некоторым картам приходится шить специальные видеобиосы, редки, и потому я их рассматривать тут не стану), а в ОС уже нужен полноценный драйвер. Замечали тот факт, что видеобиос занимает 128\256\512кб, а видеодрайвер — 200мб? Ну вот поэтому универсальных драйверов и нет — они нафиг не нужны, и задачи сделать их таковыми никогда не ставилось.
Что плохого в переключателе я уже выше пояснил: простой пользователь его боится, а назначение его кому-либо, кроме энтузиастов, практически невозможно пояснить. Подавляющее большинство обычных людей даже не знают, что у них там прошивка какая-то вообще есть в компьютере, для чего она нужна и кому, они открывают крышку ноутбука и видят перед собой экран входа в систему. Вся внутренняя кухня этому пользователю активно не интересна, и он из множества вариантов выберет тот, у которого никакие непонятные ручечки крутить не нужно, и непонятные кнопочки нажимать. Пользователь пришел работать и развлекаться, а не принимать решения о запрете\разрешении обновления прошивки. Для энтузиастов же уже сейчас есть возможность купить у purism систему с нужными физическими переключателями, потому что производитель этот — именно на них в качестве своей целевой аудитории и ориентируется, и берет за это вполне осязаемые дополнительные деньги, потому что энтузиастов таковых не много, и больше их не становится.
Про Dell ничего такого не помню, но они использую AMI AptioV на десктопах и серверах, так что вполне могли использовать тот же самый уязвимый код и не заметить.
Они этот кусок используют как признак 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 — хуже, чем никакого.
Добавление низкорисковых активов и снижает бету вашего портфеля, и добавляет диверсификацию в другой класс активов. Диверсификация — это отлично, а вот низкая бета автоматически означает и низкую премию за систематический риск, поэтому 90\10 считается весьма рисковым портфелем для тех, кто не пугается уменьшения его стоимости в разы во время очередного кризиса, 60\40 — консервативным портфелем для тех, кто этого пугается. По факту, чем больше доля облигаций и\или кэша, тем более долгий кризис можно будет пересидеть без продажи акций в убыток, но и тем медленнее рост.
У меня самого сейчас 75\25 на обычном аккаунте, и 90\10 на пенсионном (401к), и я уже раза три подумывал над тем, чтобы перейти на обоих на 95\5 или даже 100\0, но т.к. я на пережил пока что всего один короткий кризис (мартовский этого года), и пока что свою собственную толерантность к риску достоверно не могу оценить, то пока что оставляю вот так. Посмотрим, когда начнется, и как долго продлится следующий…
У меня самого портфель из AAPL(30%, только RSU и ESPP, которые я меняю на VTSAX сразу же после того, как они получают статус long-term capital gain, т.е. через год для RSU и через два года для ESPP), VTSAX(40%), VBTLX(15%), VTIAX(13%), и резервного фонда (2%). Новые покупаю раз в месяц на свободные средства так, чтобы проценты оставались плюс-минус в нужных коридорах, за альфой не гонюсь — пусть другие гонятся, да и кризис мартовский пересидел нормально (смотреть на уполовинивание суммы в долларах было неприятно, но если смотреть на это не как «блин, как портфель то жестко подешевел», а как на «фигасе как все пошли в нал переливаться, и как он сразу подорожал», то полегче, да и закончилось быстро все относительно).
Хорошо сделанная система, которая взаимодействует с людьми, должна учитывать ограничения этих самых людей, и минимизировать как количество ошибок, как и глубину распространения эффектов от них, а в С вместо этого половина конструкций языка — это undefined behavior, а из другой половины разного рода острые грани торчат, про которые никто толком не знает, пока эти грани в очередной раз не разорвут всю безопасность на немецкий крест. Хороший язык должен по умолчанию следить за тем, чтобы пользователь не творил ерунды, а если ему надо ее творить, чтобы это творение было явным, и чтобы у каждого такого места «пошел в пень, компилятор, я лучше знаю» обязательно стояла табличка «ОСТОРОЖНО, РАБОТАЮТ ЛЮДИ!». А в С эту табличку надо программисту на лбу рисовать перманетным маркером.
Вот хороший пример кода на С, обмазанного достаточным количеством кода на AstraVer для того, чтобы доказать его корректность. Написание всего этого кода (весь проект — гарантированно безопасный загрузчик PE-образов для UEFI) заняло у двух не самых глупых товарищей полгода, а я такой же загрузчик на том же С (но уже без каких-либо гарантий, кроме «от фаззинга не падает» и «мамой клянусь») написал в 2016 году за три дня. В итоге программировать на С так, чтобы гарантировать отсутсвие ошибок, могут себе позволить только те, кто сидит на финансировании из бюджета, и потому по времени практически не ограничен, а коммерческие компании вынуждены бежать, сломя голову, только чтобы на своем месте оставаться, и потому практически весь их код на С не выдерживает никакой критики с точки зрения безопасности.
В итоге недостатки слишком много позволяющего языка пытаются чинить в железе, уже занесли туда теневой стек (Intel CET), подписывание указателей (ARM PAC), тегирование памяти (ARM MTE), и теперь работают над заносом туда же контрактов, которые будет расставлять компилятор, потому что программиста это делать невозможно заставить (CHERI).
Понятно, что для микроконтроллеров, к которых вся прошивка — это конечный автомат на десяток состояний, это все не нужно, и там можно продолжать писать на С спокойно, потому что вся программа влезает в голову одного инженера. Проблемы начинаются там, где в программе уже больше миллиона строк кода, и над ней работает сотня-другая людей непрерывно. Именно там становятся нужны любые возможные способы обеспечить локальность эффектов, предотвратить ошибку до того, как она попала в репозиторий, остановить разработчика от необдуманных поступков вроде создания гонки по данным и передачи данных в соседний поток без использования примитивов синхронизации, т.е. в конце концов именно там мы приходим к необходимости языков вроде Rust.
Короче, если у вас пока что на С все работает и жрать не просит — смело продолжайте на нем писать. А у нас вот давно уже от С геморрой сплошной, а заменить его толком не на что, потому что C++ — это такое же хтоническое чудовище, вид сбоку, а внедрение Rust пока буксует по экономическим причинам (дорого переучивать всю ораву, дорого писать клей, дорого переписывать то, что не получилось приклеить, а дело делать надо уже сейчас).
Спасибо огромное за эту серию статей, потому что теперь есть куда послать интересующихся или сомневающихся русскоязычных товарищей, которых раньше приходилось слать в статьи Фамы и Френча, переведенные автоматикой.
Прошивка никогда не будет делить драйверы для какого-то нетривиального оборудования с полноценной ОС, потому что объем поддерживаемых фич у ОРОМа и драйвера из ОС несравнимый. Драйверу графической карты для UEFI («видеобиосу») нужен, по сути, только фреймбуфер (исключения вроде CoreEG2 у Apple, в котором 42 функции и который поддерживает 3d-ускорение ради того, чтобы recoveryOS не выглядела убого, из за чего некоторым картам приходится шить специальные видеобиосы, редки, и потому я их рассматривать тут не стану), а в ОС уже нужен полноценный драйвер. Замечали тот факт, что видеобиос занимает 128\256\512кб, а видеодрайвер — 200мб? Ну вот поэтому универсальных драйверов и нет — они нафиг не нужны, и задачи сделать их таковыми никогда не ставилось.
Что плохого в переключателе я уже выше пояснил: простой пользователь его боится, а назначение его кому-либо, кроме энтузиастов, практически невозможно пояснить. Подавляющее большинство обычных людей даже не знают, что у них там прошивка какая-то вообще есть в компьютере, для чего она нужна и кому, они открывают крышку ноутбука и видят перед собой экран входа в систему. Вся внутренняя кухня этому пользователю активно не интересна, и он из множества вариантов выберет тот, у которого никакие непонятные ручечки крутить не нужно, и непонятные кнопочки нажимать. Пользователь пришел работать и развлекаться, а не принимать решения о запрете\разрешении обновления прошивки. Для энтузиастов же уже сейчас есть возможность купить у purism систему с нужными физическими переключателями, потому что производитель этот — именно на них в качестве своей целевой аудитории и ориентируется, и берет за это вполне осязаемые дополнительные деньги, потому что энтузиастов таковых не много, и больше их не становится.
Еще более смешной баг был у AMI, эти отмочили следующее: драйвер BootGuardPei, накрытый BG вместе со всем остальным PEI-томом и хешами, действительно успешно проверял хеши DXE-тома, только вот при несовпадении он не отключал машину и не переводил ее в режим восстановления прошивки, а создавал HOB с одним байтом, чтобы потом BootGuardDxe уже показал пользователю нужный UI и занимался восстановлением уже из DXE. Я когда это осознал — ржал минут десять, а потом пошел и удалил весь BootGuardDxe, и все ожидаемо заработало.
Какие IBV, такие и цепочки доверия, и даже если сам по себе BG может быть настроен идеально, он покрывает только первое звено, а второе может быть любого качества, в том числе и вот такого.