Статья написана в дополнение к предыдущей по просьбе сообщества.

В этой статье разберемся с магией чисел в децимальных номерах. И рассмотрим нумерацию не только принятую в ЕСКД (Единая система конструкторской документации), а также в ЕСПД (Единая система программной документации) и КСАС (Комплекс стандартов на автоматизированные системы), так как Харб в большей степени состоит из ИТ специалистов.

В соответствии с требованиями стандартов ЕСКД, ЕСПД и КСАС каждому изделию (программе, системе) должно быть присвоено обозначение — децимальный номер.

Обозначение присваивается в соответствии с установленными в стандартах правилами. Это придумано людьми в древние времена для унификации и упрощения идентификации изделий и документации, ведения учёта и архива.

Разберемся в простой процедуре присвоения децимального номера, чтобы она не казалось древним ритуалом, а присваиваемые номера — магическими числами.

Для каждого комплекта стандартов рассматривать порядок действий будем по отдельности.

Примерно в каждой второй теме на Хабре, касающейся космонавтики или электроники, всплывает тема радиационной стойкости. Через новости об отечественной космонавтике красной нитью проходит тематика импортозамещения радстойкой элементной базы, но в то же самое время Элон Маск использует дешевые обычные чипы и гордится этим. А изральтяне в «Берешите» использовали радстойкий процессор и тоже гордятся этим. Да и в принципе микроэлектронная отрасль в России живет по большей части за счет госзаказа с соответствующими требованиями. Наблюдение за регулярными спорами насчет того, как надо правильно строить спутники, показывает, что подготовка участников обычно невысока, а их аргументация отягощена стереотипами, случайно услышанными вырванными из контекста фактами и знаниями, устаревшими много лет назад. Я подумал, что читать это больше нет сил, поэтому, дорогие аналитики, устраивайтесь поудобнее на своих диванах, и я начну небольшой (на самом деле большой) рассказ о самых популярных заблуждениях на тему того, что такое радиационная стойкость интегральных микросхем.


Рисунок 1. Непременная красивая картинка про космическое излучение и хрупкую Землю.

Самый первый транзистор был биполярным и германиевым, но подавляющее большинство современных интегральных микросхем сделаны из кремния по технологии КМОП (комплементарный металл-оксид-полупроводник). Как вышло, что кремний стал главным из многих известных полупроводников? Почему именно КМОП-технология стала почти монопольной? Были ли процессоры на других технологиях? Что ждет нас в ближайшем будущем, ведь физический предел миниатюризации МОП-транзисторов фактически достигнут?


Если вы хотите узнать ответы на все эти вопросы — добро пожаловать под кат. По просьбам читателей предыдущих статей предупреждаю: там много текста, на полчаса.

В данной статье речь пойдет про SMT-решатели. Так сложилось, что в исследовательских материалах, посвященных данной теме, появилась хорошая традиция. Уже несколько раз в качестве подопытного алгоритма для SMT-решателей разные исследователи выбирали один и тот же пример – крякми, придуманное некогда человеком с ником kao. Что ж, продолжим эту традицию и попробуем использовать для решения этого крякми еще один инструмент для символьных вычислений – Triton.

Всем привет!

Сегодня мы хотели бы поделиться своим списком материалов по тематике reverse engineering (RE). Перечень этот очень обширный, ведь наш исследовательский отдел в первую очередь занимается задачами RE. На наш взгляд, подборка материалов по теме хороша для старта, при этом она может быть актуальной в течение продолжительного времени.

Данный список ссылок, ресурсов, книг мы уже лет пять рассылаем людям, которые хотели бы попасть в наш исследовательский отдел, но не проходят пока по уровню знаний или только начинают свой путь в сфере информационной безопасности. Естественно, этому перечню, как и большинству материалов/подборок, через некоторая время потребуется обновление и актуализация.

Забавный факт: нам показывали, как некоторые компании рассылают наш список материалов от себя, но только в очень старой редакции. И вот после этой публикации они, наконец, смогут использовать его обновленную версию с чистой совестью ;)

Итак, перейдем к списку материалов!

English version of this article.

Введение

Прошивки современных материнских плат компьютера работают по спецификации UEFI, и с 2013 года поддерживают технологию проверки подлинности загружаемых программ и драйверов Secure Boot, призванную защитить компьютер от буткитов. Secure Boot блокирует выполнение неподписанного или недоверенного программного кода: .efi-файлов программ и загрузчиков операционных систем, прошивок дополнительного оборудования (OPROM видеокарт, сетевых адаптеров).
Secure Boot можно отключить на любой магазинной материнской плате, но обязательное требование для изменения его настроек — физическое присутствие за компьютером. Необходимо зайти в настройки UEFI при загрузке компьютера, и только тогда получится отключить технологию или изменить её настройки.

Большинство материнских плат поставляется только с ключами Microsoft в качестве доверенных, из-за чего создатели загрузочного ПО вынуждены обращаться в Microsoft за подписью загрузчиков, проходить процедуру аудита, и обосновывать необходимость глобальной подписи их файла, если они хотят, чтобы диск или флешка запускались без необходимости отключения Secure Boot или добавления их ключа вручную на каждом компьютере.
Подписывать загрузчики у Microsoft приходится разработчикам дистрибутивов Linux, гипервизоров, загрузочных дисков антивирусов и программ для восстановления компьютера.

Мне хотелось сделать загрузочную флешку с различным ПО для восстановления компьютера, которая бы грузилась без отключения Secure Boot. Посмотрим, как это можно реализовать.

У нас в Phusion работает простой многопоточный HTTP-прокси на Ruby (раздаёт пакеты DEB и RPM). Я видел на нём потребление памяти 1,3 ГБ. Но это безумие для stateless-процесса…


Вопрос: Что это? Ответ: Использование памяти процессом Ruby с течением времени!

Оказывается, я не одинок в этой проблеме. Приложения Ruby могут использовать много памяти. Но почему? Согласно Heroku и Нейту Беркопеку, в основном раздутие связано с фрагментацией памяти и чрезмерным распределением по кучам.

Современные микроэлектронные технологии — как «Десять негритят». Стоимость разработки и оборудования так велика, что с каждым новым шагом вперёд кто-то отваливается. После новости об отказе GlobalFoundries от разработки 7 нм их осталось трое: TSMC, Intel и Samsung. А что такое, собственно “проектные нормы” и где там тот самый заветный размер 7 нм? И есть ли он там вообще?


Рисунок 1. Транзистор Fairchild FI-100, 1964 год.

Самые первые серийные МОП-транзисторы вышли на рынок в 1964 году и, как могут увидеть из рисунка искушенные читатели, они почти ничем не отличались от более-менее современных — кроме размера (посмотрите на проволоку для масштаба).

Не так давно я прочёл фантастический роман «Задача трёх тел» Лю Цысиня. В нём у одних инопланетян была проблема — они не умели, с достаточной для них точностью, вычислять траекторию своей родной планеты. В отличии от нас, они жили в системе из трёх звёзд, и от их взаимного расположения сильно зависела «погода» на планете — от испепеляющей жары до леденящего мороза. И я решил проверить, можем ли мы решать подобные задачи.

При модернизации архитектуры вычислений в многоядерную и многоузловую в полный рост стал вопрос о способах перемещения данных между вычислительными ресурсами, особенно гетерогенными. То и дело возникали узкие места, тормозящие всю систему в целом, и придумывались новые технологии, которые в какой-то степени решали проблему, но, с другой стороны, своим многообразием ее усложняли. Индустрии требовался стандарт интерконнекта, разработанный с учетом накопленного опыта и поддерживаемый консорциумом ведущих игроков. Теперь, усилиями Intel, таковой имеется.

Введение

Умножение матриц — это один из базовых алгоритмов, который широко применяется в различных численных методах, и в частности в алгоритмах машинного обучения. Многие реализации прямого и обратного распространения сигнала в сверточных слоях неронной сети базируются на этой операции. Так порой до 90-95% всего времени, затрачиваемого на машинное обучение, приходится именно на эту операцию. Почему так происходит? Ответ кроется в очень эффективной реализации этого алгоритма для процессоров, графических ускорителей (а в последнее время и специальных ускорителей матричного умножения). Матричное умножение — один из немногих алгоритмов, которые позволяет эффективно задействовать все вычислительные ресурсы современных процессоров и графических ускорителей. Поэтому не удивительно, что многие алгоритмы стараются свести к матричному умножению — дополнительная расходы, связанные с подготовкой данных, как правило с лихвой окупаются общим ускорением алгоритмов.

Так как реализован алгоритм матричного умножения? Хотя сейчас существуют множество реализаций данного алгоритма, в том числе и в открытых исходных кодах. Но к сожалению, код данных реализаций (большей частью на ассемблере) весьма сложен. Существует хорошая англоязычная статья, подробно описывающая эти алгоритмы. К моему удивлению, я не обнаружил аналогов на Хабре. Как по мне, этого повода вполне достаточно, чтобы написать собственную статью. С целью ограничить объем изложения, я ограничился описанием однопоточного алгоритма для обычных процессоров. Тема многопоточности и алгоритмов для графических ускорителей явно заслуживает отдельной статьи.

Процесс изложения будет вестись ввиде шагов с примерами по последовательному ускорению алгоритма. Я старался писать максимально упрощая задачу, но не более того. Надеюсь у меня получилось…

Учимся дебажить с perf — целых 18 страниц про основные подкоманды, фичи и устройство инструмента. Джулия рекомендует; “Я даже использовала его несколько раз для профилирования Ruby программ!”

Уровень сложности — для суперпродвинутого администратора.

Когда нужно отыскать причину сбоя, не имея доступа к исходным кодам. Все логи уже просмотрены, все debug и verbose-ключи включены, а причина проблем так и не обнаружена — используйте perf. Потребуется навык кодинга на языках типа Си.

(ИЛИ каламбур типизации, неопределенное поведение и выравнивание, о мой Бог!)

Друзья, до запуска нового потока по курсу «Разработчик С++», остается совсем немного времени. Пришло время опубликовать перевод второй части материала, в которой рассказывается о том, что такое каламбур типизации.

Что такое каламбур типизации?

Мы дошли до того момента, когда мы можем задаться вопросом, зачем нам вообще могут понадобиться псевдонимы? Обычно для реализации каламбуров типизации, т.к. зачастую используемые методы нарушают правила строгого алиасинга.



Иногда мы хотим обойти систему типов и интерпретировать объект как другой тип. Переинтерпретация сегмента памяти в качестве другого типа называется каламбуром типизации (type punning). Каламбуры типизации полезны для задач, которым требуется доступ к базовому представлению объекта для просмотра, транспортировки или манипулирования предоставленными данными. Типичные области, в которых мы можем встретить использование каламбуров типизации: компиляторы, сериализация, сетевой код и т.д.

Производительность диска зависит от температуры

Осенью прошлого года стало известно, что твердотельный накопитель Samsung 840 Evo теряет скорость при чтении старых данных. Записанную более месяца назад информацию можно было прочесть лишь с падением производительности, и компания Samsung вскоре выпустила патч с обновлением прошивки, который был призван решить эту проблему. Тогда было указано, что напряжения для ячеек со старыми данными были откалиброваны неправильно. Как выяснилось позднее, проблема всё равно оставалась, и решить её должно второе обновление, которое периодически перезаписывает старые данные в фоне. Пер Ханссон выяснил, что проблеме деградации подвержены и другие диски Samsung с памятью TLC NAND.

На днях прошла встреча международного комитета по стандартизации C++ в американском городе Кона. Это была не просто встреча, а feature freeze! Никакие серьёзные новые идеи больше не могут просачиваться в стандарт, остаётся лишь пара встреч на добавление предварительно одобренных вещей, исправление недочётов и устранение шероховатостей.

Ожидать ли Модули и Корутины в C++20, будет ли там быстрая библиотека для форматирования вывода, сможет ли она работать с календарями, добавили ли std::stacktrace, начнёт ли компилятор сам вызывать std::move в ряде случаев, приняли ли std::flat_map? Всё это и многое другое ожидает вас под катом.

В этой статье вас ждёт десять лучших докладов от Андрея Александреску, Дэвида Вандервурда, Джона Калба и многих других.

Фичи компилятора C++, асинхронность, многопоточность, параллелизм, модель памяти, алгоритмы и STL, метапрограммирование и рефлекшен, огромное множество тем.

Всё это — записи с конференции C++ Russia, самой большой в истории. Восемь сотен участников, немаленький зал, спикеры с мировым именем. Прошёл год, но большинство докладов ничуть не утратило своей актуальности. Впрочем, и неудивительно — именно такие доклады и попадают в топ по оценке участников.

Формат таков:

• Обязательное видео на YouTube
• Слайды, если есть
• Подробное описание доклада на русском языке
• Краткая биография докладчика

Плюс у вас есть комментарии Хабра, чтобы обсудить увиденное. Реклама на ютубе отключена, никто не будет мешать. Есть всё, чтобы начать смотреть прямо сейчас.

«В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки» — сообщает нам Википедия. Сами будучи поклонниками Linux, мы регулярно сталкиваемся с вопросом, какими именно инструментами её лучше осуществлять. И хотим поделиться переводом статьи программиста Хонгли Лая, который рекомендует bpftrace. Забегая вперёд, скажу, что заканчивается статья лаконично: «bpftrace — это будущее». Так чем же он так впечатлил коллегу Лая? Развёрнутый ответ под катом.

Давайте поговорим об экосистеме приложений свободных приложений с открытым исходным кодом на Android. Попробуем установить MicroG — свободную реализацию сервисов Google на Android. Посмотрим, как и зачем со всем этим жить.

Несколько причин, почему стоит об этом задуматься

Google Play далеко "не торт"

Далеко ходить не нужно, в соседних постах можно найти множество примеров того, как разработчиков выгоняют из Google Play по тем или иным причинам, заставляя общаться с ботами без возможности реальной аппеляции. Некоторые типы приложений теперь принципиально невозможно распространять (например, блокировщики рекламы, да и в принципе приложения обхода любых ограничений).

Мне, как параноику, не нравится, что у стороннего лица появляется практически полный доступ к моему устройству. Google способен как минимум удалить с моего телефона любое приложение в любой момент и собрать с него произвольные данные. Более того, google play service — это огромное (стандартная поставка — 600Мб, минимальная — 95Мб) количество постоянно обновляющегося кода, часть которая работает с системными привилегиями. Для сравнения, дистрибутив MicroG может весить всего 4Мб.

Согласно Википедии, трагедия — это «форма драмы, основанная на человеческих страданиях, которая вызывает в аудитории сопутствующий катарсис или удовольствие». Из этого определения почерпнул вдохновение Бенно Райс в своём выступлении на конференции 2019 linux.conf.au. Его доклад посвящён истории systemd, в которой немало страданий. А аудитория точно получила удовольствие, так что всё сходится. В целом, это сочувственный и тонкий взгляд на одну бурную главу в истории системы Linux.

Райса также вдохновила статья Ауринна Шоу о так называемой «культуре презрения». По словам Шоу, люди проявляют презрение (например, к разработчикам, которые используют другой язык программирования) в качестве социального знака, способа показать, что они принадлежат к правильной группе.

Безусловно, в этой истории есть такая культура: большие группы сообща проявляют общее презрения к systemd и к тем, кто использует эту систему. Отсюда вытекает концепция изменения или сопротивления. Да, знакомые вещи удобны. Но они не обязательно хороши, особенно если ничего не меняется уже много лет.

Размеры транзисторов в современных микросхемах неумолимо уменьшаются — несмотря на то, что о смерти закона Мура говорят уже несколько лет, а физический предел миниатюризации уже близок (точнее, в некоторых местах его уже успешно обошли). Тем не менее, это уменьшение не приходит даром, а аппетиты пользователей растут быстрее, чем возможности разработчиков микросхем. Поэтому, кроме миниатюризации транзисторов, для создания современных микроэлектронных продуктов используются и другие, зачастую не менее продвинутые технологии.