В период между 1926 и 2009 года индекс S&P 500 падал на протяжение 24 из 84 лет (25% времени).
Статистика… То же самое предложение можно переформулировать вот так: 75% времени индекс рос, так что вместо попыток выиграть в рулетку у рынка, лучший способ заработать на бирже — купить каких-нибудь VTSAX или SWPPX сегодня, и держать их до самой пенсии, докупая их же на все свободные деньги по ходу. Никаких структурных продуктов, минимальные комиссии и брокеров, и управляющих фондом (не 1% в год, как на российском фондовом рынке, а 0.02%-0.05%, т.е. ~$50 затрат за 10 лет на каждые $10k вложенных), а в случае окончательного и бесповоротного карачуна всего фондового рынка (еще хуже, чем крах 1929 года) рухнут и бонды, и REITы, и деривативы, и сама мировая экономика, вместе с зарплатами, и готовиться к такому надо закупкой спичек, гречки и тушенки, а не балансировкой портфеля в сторону менее рисковых активов.
Постараюсь отсоветовать, у меня были NUC7i3/5 с KabyLake, и оба не подошли по разным причинам. Даже i5 (не говоря про i7) сильно шумит и троттлит уже при средней нагрузке, а i3, хоть и не шумит, зато задушен насмерть и пользоваться современной Windows 10 и тяжелым софтом (Visual Studio, например) очень трудно.
Все еще сижу на NUC7i3, но уже морально готов заменить его на MacMini 2018 года (еще не заменил, потому что домашний ПК нужен все меньше).
Авторы преподнесли проблемы с имплементацией отдельных библиотек как проблемы с самим алгоритмом. Очень странно слышать такие вещи от людей которые пытаются учить людей криптографии.
В прикладной криптографии (которая внутри «разработки ПО», а не «математики») нет собой разницы между алгоритмом и реализацией алгоритма, потому что никаких других алгоритмов, кроме реализованных или самостоятельно разработчиком, или разработчиками библиотек, там нет. И атакуют там именно реализации.
Так вот с точки зрения прикладного криптографа RSA — действительно плохой алгоритм, потому что его практически невозможно «держать правильным образом», о чем авторы статьи и сообщают. И не только они, вот отличный пример того, как недостатки криптографических API приводят к тому, что 70% криптографического кода имеет серьезные проблемы, которые никто из разработчиков не в состоянии заметить.
Любые работающие технологии безопасности должны быть простыми как палка, и при этом стараться максимально усложнить свое неправильное использование (при помощи системы типов, статического анализа, или других инструментов), а нынешние (а тем более прошлые) реализации RSA в большинстве своем похожи скорее на OpenSSL, чем на упомянутый авторами libsodium.
Именно так из звучит, и такую статью тоже написать не грех.
Очень много областей, где Си давно пора перестать использовать именно поэтому, но его продолжают там использовать, а когда в очередной раз приходит атакующий и все разламывает в клочья после получаса реверса — винят кого угодно, только не инструмент кривой.
Дали коновалам в руки скальпель, а теперь удивляются, что вся комната в крови…
Если посмотреть на профиль автора на SO, то становится понятно, почему за 30 лет работы (неясно откуда взявшиеся, потому что он ВУЗ закончил в 2004 году) он так и не научился пользоваться отладчиками — просто не нужно было, все проблемы решались и без них.
Это не означает, что проблем не было, это всего лишь означает, что эти "проблемы с медведями" решали совсем другие товарищи за совсем другие деньги.
Ответ сильно зависит от того, что вы на вашем процессоре делаете.
Если у вас там конечный автомат на десяток состояний, то вы его отлично отладите и так, а если у вас там РТОС на 50 процессов, активно работающая с внешним оборудованием, то система ваша явно с недостатком, т.к. даже на одну ногу можно завести отладочный интерфейс (debugWIRE у Atmel), а если отвоевать еще одну, то хватит на полноценный Test Access Port по cJTAG или SWD.
Многое очень спорно, но вот это реально покоробило:
Я уж молчу о том, что отладчики сами по себе плохи, они просто не оказывают той помощи, которой от них многие ждут.
Пожалуйста, изучайте свои инструменты откладки и тестирования, фаззеры, санитайзеры, и т.п. Любая ошибка, замеченная ими, значительно дешевле, чем она же, но замеченная пользователем. Если ваша система не позволяет подключить к себе отладчик во время работы — это недостаток системы, а не отладчика! Если вы не умеете пользоваться инструментами — это недостаток квалификации, а не инструментов!
Отладка кода заведомо сложнее его написания, но почему-то автор не предлагает заменить свою IDE на ed, зато предлагает оказаться от отладчика, потому что он якобы «не оказывает помощи»…
Непонятно, к чему этот FPGA подключен, так что собрать себе на нем NES и играть в Черного Плаща прямо на коммутаторе не получится, я думаю, но и без этого уже зашквар полный. С другой стороны, дизайн нормальной цепочки доверия — не хрен собачий, а реализация — и подавно, и потому можно тут смеяться над ними в кулак, пока внезапно не окажется, что у самих рыло в пуху.
Именно так, и даже веселее еще, потому что можно менять не только корневой сертификат, но и вообще все поведение корня доверия, причем там даже не код меняется как таковой, а FPGA bitstream. Всякое видел в своей жизни, но такое — в первый раз.
Еще какая уязвимость, повышение привилегий от локального рута до полного, окончательного и бесповоротного контроля над устройством, включая его root-of-trust.
У gRT->SetVariable, функции, которую ОС вызывает для того, чтобы в NVRAM писать, есть флаг APPEND_WRITE, который позволяет к уже имеющимся revocation list'ам дописать новых записей. Т.к. записи эти хранятся в NVRAM, который в свою очередь хранится на SPI-чипе материнской платы, переустановка ОС не меняет их значений. Если значения там уже есть, SetVariable вернет EFI_SUCCESS, но менять ничего не будет, так что и не перезаписываются, и не дублируются, на самом деле.
Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
Тем не менее, питон для STM32, для FreeRTOS можно адаптировать (потому что на голом железе оно уже работает), а то, что интерпретатор жрет — мало кто ожидал что жрать будет не мегабайты.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
Удивительный вопрос, я даже несколько теряюсь. Ручные обновления = отсутствие обновлений = известные и эксплуатируемые уязвимости, которые значительно хуже, чем новые, еще не известные и не эксплуатируемые. Если вы готовы сами следить за обновлениями и нести ответственность за безопасность системы — я только за, но вас таких снова три с половиной, а защитить хоть как-нибудь и закрыть хотя бы известные дыры стараются для всех. UEFI Forum разработал и внедрил общих механизм для обновления всех компонентов прошивки — ESRT, которым пользуются клиенты вроде Windows Update и Linux Vendor Firmware Service. Очень жаль, что поддерживаются эти сервисы пока далеко не всеми, потому что нужны они еще вчера.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
Добавлю, что это не только удорожает продукт, но и делает автоматические обновления невозможными в принципе, потому что от пользователя требуется нетривиальное (т.е. не «нажмите Ввод») физическое присутствие, которое невозможно обеспечить либо по причине «у пользователя лапки», либо потому, что система установлена в дата-центре в закрытый шкаф.
Никто другого и не ждал, за 7 лет с запуска UEFI CA им успели подписать такое количество всякой дырявой фигни, что доверять ему теперь — то еще решение. При этом не будешь доверять — OROMы перестанут запускаться, т.е. технология сразу переходит из разряда «включил и работает» в «требует постоянного внимания администратора», и потому отключать ее начнут теперь еще более яростно.
1) Полно таких ноутбуков, а под старый текстовый интерфейс мимикрируют потому, что IBV так захотели. На десктопах давно уже AMI правит бал, и потому там давно уже вакханалия с OpenGL в Setup и GIFами анимированными, а на ноутбуках еще используют Phoenix и Insyde, которые по умолчанию выглядят «как встарья», и которые надо переделывать под мышь самому. Dell, к примеру, переделывает, а другие не парятся.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.
Статистика… То же самое предложение можно переформулировать вот так: 75% времени индекс рос, так что вместо попыток выиграть в рулетку у рынка, лучший способ заработать на бирже — купить каких-нибудь VTSAX или SWPPX сегодня, и держать их до самой пенсии, докупая их же на все свободные деньги по ходу. Никаких структурных продуктов, минимальные комиссии и брокеров, и управляющих фондом (не 1% в год, как на российском фондовом рынке, а 0.02%-0.05%, т.е. ~$50 затрат за 10 лет на каждые $10k вложенных), а в случае окончательного и бесповоротного карачуна всего фондового рынка (еще хуже, чем крах 1929 года) рухнут и бонды, и REITы, и деривативы, и сама мировая экономика, вместе с зарплатами, и готовиться к такому надо закупкой спичек, гречки и тушенки, а не балансировкой портфеля в сторону менее рисковых активов.
Все еще сижу на NUC7i3, но уже морально готов заменить его на MacMini 2018 года (еще не заменил, потому что домашний ПК нужен все меньше).
В прикладной криптографии (которая внутри «разработки ПО», а не «математики») нет собой разницы между алгоритмом и реализацией алгоритма, потому что никаких других алгоритмов, кроме реализованных или самостоятельно разработчиком, или разработчиками библиотек, там нет. И атакуют там именно реализации.
Так вот с точки зрения прикладного криптографа RSA — действительно плохой алгоритм, потому что его практически невозможно «держать правильным образом», о чем авторы статьи и сообщают. И не только они, вот отличный пример того, как недостатки криптографических API приводят к тому, что 70% криптографического кода имеет серьезные проблемы, которые никто из разработчиков не в состоянии заметить.
Любые работающие технологии безопасности должны быть простыми как палка, и при этом стараться максимально усложнить свое неправильное использование (при помощи системы типов, статического анализа, или других инструментов), а нынешние (а тем более прошлые) реализации RSA в большинстве своем похожи скорее на OpenSSL, чем на упомянутый авторами libsodium.
Очень много областей, где Си давно пора перестать использовать именно поэтому, но его продолжают там использовать, а когда в очередной раз приходит атакующий и все разламывает в клочья после получаса реверса — винят кого угодно, только не инструмент кривой.
Дали коновалам в руки скальпель, а теперь удивляются, что вся комната в крови…
Это не означает, что проблем не было, это всего лишь означает, что эти "проблемы с медведями" решали совсем другие товарищи за совсем другие деньги.
Если у вас там конечный автомат на десяток состояний, то вы его отлично отладите и так, а если у вас там РТОС на 50 процессов, активно работающая с внешним оборудованием, то система ваша явно с недостатком, т.к. даже на одну ногу можно завести отладочный интерфейс (debugWIRE у Atmel), а если отвоевать еще одну, то хватит на полноценный Test Access Port по cJTAG или SWD.
Пожалуйста, изучайте свои инструменты откладки и тестирования, фаззеры, санитайзеры, и т.п. Любая ошибка, замеченная ими, значительно дешевле, чем она же, но замеченная пользователем. Если ваша система не позволяет подключить к себе отладчик во время работы — это недостаток системы, а не отладчика! Если вы не умеете пользоваться инструментами — это недостаток квалификации, а не инструментов!
Отладка кода заведомо сложнее его написания, но почему-то автор не предлагает заменить свою IDE на ed, зато предлагает оказаться от отладчика, потому что он якобы «не оказывает помощи»…
Если хотите подробностей, все это описано подробно в спецификации UEFI 2.3.1C+ в разделе Runtime Services: SetVariable.
Меня этот проект интересует потому, что на его основе сейчас создается новая версия UEFI SCT, без которой невозможно проверить конкретную реализацию UEFI-совместимой прошивки на совместимость с конкретной версией спецификации.
В BIOS Setup дата-центра действительно захожу удаленно, через IPMI и RedFish.
Мое мнение: старый текстовый интерфейс сильно лучше, чем все эти новомодные тормозящие чудеса в решете (он в текстовую консоль почти без потерь перенаправляется, к примеру, и программировать его проще, т.е. ошибок допустят меньше), но людям нравятся блестки, и потому рано или поздно без блесток не останется ничего.
2) Так и есть, и это действительно связано с тем, что некоторые UEFI OROMы сильно быстрее своих legacy-собратьев, которые вынуждены переключаться в 16-битный реальный режим и сегменты там яростно переключать, и чем больше устройств в массиве — тем заметнее разница. По честному, без бенчмарков это все — так себе аргументация, но я достаточно не люблю CSM, чтобы видеть после его отключения ускорение, пусть даже это ускорение только у меня в голове происходит.