Олег Артамонов olartamonov

Привет, Хабр!

Некоторое время тому назад рабочая группа Сколтеха по Интернету вещей опубликовала проект национального стандарта узкополосной связи для IoT под названием «OpenUNB», полный текст которого можно найти здесь. С одной стороны, явление безусловно положительное – если в области стандартов широкополосных существует de facto открытый к применению всеми желающими LoRaWAN, то узкополосные стандарты до сего дня были исключительно проприетарными (Sigfox, XNB компании «Стриж», NB-Fi компании «Вавиот» — хотя последний также опубликован в виде проекта национального стандарта, в нём не открыты существенные для реализации сторонними лицами части).

При этом узкополосные и широкополосные системы имеют каждая свои плюсы и минусы, так что говорить «зачем вам что-то ещё, когда есть LoRaWAN» – не совсем верно. То есть, открытый стандарт на UNB-связь необходим.

Однако, необходимость – это лишь одно из двух условий. Второе – достаточность. Ок, то, что опубликовал Сколтех, необходимо, но достаточно ли оно для практического применения?



Мы ответим на это в формате, похожем на интервью – под катом цитаты из проекта стандарта OpenUNB и комментарии к ним, данные Александром Шептовецким (AS), техническим директором компании GoodWAN, и Олегом Артамоновым (OA), техническим директором компании Unwired Devices.

Итак, поехали. Стилистика, орфография и пунктуация авторов сохранены.

Привет, Хабр.

Мне хотелось бы в очередной раз поговорить о том, как обеспечивается базовый (читай: минимально необходимый) уровень безопасности данных в беспроводных сетях, используемых в IoT-устройствах, на примере LoRaWAN.

Почему именно LoRaWAN? Во-первых, потому, что это хорошо описанный и хорошо проработанный стандарт, на который стоит ориентироваться как на референс, если вы разрабатываете какой-то свой беспроводной протокол. Во-вторых, потому, что это — очень родное и типовое для IoT решение; можно, конечно, разбирать обеспечение безопасности в Wi-Fi или LTE, но для большинства разработчиков это будет бесполезный разбор: вряд ли у вас возникнет необходимость писать свою реализацию Wi-Fi. В-третьих, именно маломощные IoT-устройства, в которых разработчики экономят каждый байт, часто оказываются наиболее дырявыми — и здесь LoRaWAN даёт хорошее представление, как и байты экономить, и под атаки не подставляться. В-четвёртых, наконец, потому что буквально за последние несколько дней несколько наших клиентов попросили рассказать им подробнее про защиту данных в LoRaWAN, и этой статьёй я убиваю двух зайцев.


Обмен сообщениями в сети LoRaWAN между сервером и устройством

Хотя схема обмена сообщениями в LoRaWAN на картинке выглядит довольно простой — эта простота обманчива: за ней стоит много работы, и ни один пиксель в ней не является лишним. Сейчас вы поймёте, почему.

Разбирать будем на примере LoRaWAN 1.0.2 и плясать от возможных угроз — ибо хороший разработчик всегда должен думать не о том, как его система защищена, а о том, как её могут сломать. Иначе за него об этом подумает кто-то другой.

Итак, какие основные угрозы есть в беспроводной сети — и как от них защищаться?

Привет, Хабр.

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

Навела меня на эту мысль фраза в сегодняшней статье — «Под катом многабукав, но будет инженерненько»; к сожалению, не только под катом не было инженерненько, но и вообще в очень большом проценте статей по теме «как я сделал девайс», публикуемых в последнее время на Хабре, нет ничего инженерного.

Почему?

Потому, что у любого инженера — как и у программиста, врача, юриста и вообще любого профессионала — есть базовая методология работы, без соблюдения которой деятельность из профессиональной превращается в бессистемные метания. Точнее, даже не методология — к методологии мы можем отнести аджайл, ТРИЗ и вот это вот всё, оно у каждого своё — а грубая стратегия, которую можно записать в несколько шагов.

Итак, что же это применительно к электронике?

Привет, Хабр!

В прошлой статье и я сам упоминал, и в комментариях спрашивали — ок, хорошо, методом научного тыка мы подобрали размер стека, вроде ничего не падает, а можно как-то надёжнее оценить, чему он равен и кто вообще столько сожрал?

Отвечаем коротко: да, но нет.

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

Ответ немного длиннее — под катом.

«С опытом приходит стандартный, научный подход к вычислению правильного размера стека: взять случайное число и надеяться на лучшее»
— Jack Ganssle, «The Art of Designing Embedded Systems»

Привет, Хабр!

Как ни странно, но в абсолютном большинстве виденных мной «учебников для начинающих» по STM32 в частности и микроконтроллерам вообще нет, как правило, вообще ничего про такую вещь, как распределение памяти, размещение стека и, главное, недопущение переполнения памяти — в результате которого одна область перетирает другую и всё рушится, обычно с феерическими эффектами.

Отчасти это объясняется простотой учебных проектов, выполняемых при этом на отладочных платах с относительно жирными микроконтроллерами, на которых влететь в нехватку памяти, мигая светодиодом, довольно сложно — однако в последнее время даже у начинающих любителей мне всё чаще встречаются упоминания, например, контроллеров типа STM32F030F4P6, простых в монтаже, стоящих копейки, но и памяти имеющих единицы килобайт.

Такие контроллеры позволяют делать вполне себе серьёзные штуки (ну вот у нас, например, такая вполне себе годная измериловка сделана на STM32F042K6T6 с 6 КБ ОЗУ, от которых свободными остаются чуть больше 100 байт), но при обращении с памятью при работе с ними нужна определённая аккуратность.

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

— Шеф, у нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности...

Привет, Хабр!

В комментариях к предыдущему посту про InoThings++ высказали мнение, что в Интернете Вещей есть более важная для обсуждения область, нежели вмешательство государства — это область обеспечения безопасности устройств. Со всех точек зрения.

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

Почему вообще обеспечение безопасности в IoT рассматривают как что-то отдельное и специфическое, непохожее на обеспечение безопасности в классических ИТ-системах?

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

И, к сожалению, мы ещё многократно хлебнём горя с авторами продуктов, не понимающими разницы в подходе и проблемах.

Привет, Хабр

За последний год тема национальных стандартов, различных указаний госрегуляторов и прочих связанных вещей стала одной из самых обсуждаемых в российской IoT-сообществе — что, впрочем, совершенно неудивительно, достаточно посмотреть на краткий список свежих событий:

• принятие предварительного национального стандарта на протокол NB-Fi компании «Вавиот»
• рекомендация Минцифры (оно же Минсвязи) при дистанционном съёме показаний приборов учёта электроэнергии пользоваться только и исключительно протоколом XNB компании «Стриж»
• невнятные решения ГКРЧ, провозглашающие что-то непонятное об использовании базовых станций российского производства в LPWAN-сетях
• напоминание РКН и ГКРЧ о порядке регистрации этих базовых станций и самих сетей
• долгожданное и одновременно неожиданное расширение безлицензионных диапазопов

Все эти события довольно бурно обсуждались между непосредственно причастными к рынку людьми, но наружу выплёскивались лишь отдельные сжатые скептические комментарии профессионалов IoT-рынка и безудержно оптимистичные рассказы чиновников и иных людей, всегда готовых к импортозамещению в формате «пятилетка за три года».

Даже призванное быть публичным обсуждение проекта стандарта NB-Fi в Техническом комитете 194 Росстандарта по факту от публики оказалось полностью закрытым.

Мы бы хотели исправить это положение.



Итак, на InoThings++ 2019 (Москва, 4 апреля) пройдёт первое настоящее публичное обсуждение темы национальных стандартов, госрегулирования и господдержки в области Интернета вещей, в котором мы постараемся и представить все возможные точки зрения со стороны докладчиков, и дать возможность слушателям задать свои вопросы.

Привет, Хабр!

В конце прошлого года причастные к «интернету вещей» сайты, блоги и каналы всколыхнула новость — якобы ГКРЧ приняла решение, согласно которому базовые станции любых IoT-сетей LPWAN должны быть только российского производства, а при установке их в обязательном порядке необходимо регистрировать.


Базовая станция LoRaWAN российского производства

Хотя для самой популярной из открытых технологий — LoRaWAN — российские БС вполне себе существуют, это, например, новосбириская Вега БС-2, новость вызвала у многих серьёзное волнение. Во-первых, одной Вегой сыт не будешь, Kerlink, Multitech и даже Sagemcom тоже иногда хочется. Во-вторых, ну хорошо, сегодня все строят LoRaWAN, а завтра? Такое решение попросту закрыло бы путь на российский рынок для новых стандартов — зарубежное оборудование эксплуатировать нельзя, а в разработку аналогичного российского вкладываться никто не будет, пока не станет хоть как-то понятна окупаемость и перспективы.

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

Давайте разбираться.

Привет, Хабр!

Практически ровно год назад — в конце января 2018-го — мы попробовали провести первую профессиональную конференцию для разработчиков устройств, систем и проектов «Интернета вещей» InoThings++ 2018.

Помимо того, что она была первой для нас — если не считать небольших пробных секций по IoT на Highload++ и РИТ++ — мы постарались сделать её в достаточной степени выделяющейся и на фоне других IoT-конференций, который сейчас проходит весьма немало.



InoThings++ — это конференция для людей, делающих реальные проекты в IoT. У нас нет докладов с графиками Gartner и прогнозами роста рынка в миллиардах долларов, нет красивых презентаций о безмерной государственной поддержке и борьбе за статус самого умного города. Мы приглашаем выступать только тех, кто действительно работает руками — и может про это рассказать.

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



Под катом — рассказ о том, что было год назад (с видеозаписями всех докладов), а также что ожидать через полтора месяца — и главное, нужно ли вам идти на InoThings++ (конечно, нужно).

Привет, Хабр!

Почитал я некоторые ранее опубликованные статьи о том, как жить славному молодцу, перед которым встала задача спаять 10-50-100 устройств из резисторов и микросхем, и взгрустнул, ибо во всех в них советы были даны если не вредные, то и не сильно полезные.


А вот, например, совет держать включённый паяльник за ручку — полезный!

В связи с этим хочу рассказать, как можно легко решить задачу, совершенно типичную для пары-тройки собравшихся вместе индивидуальных разработчиков-фрилансеров, небольшой компании по разработке электроники или опытного отдела в компании покрупнее:

• регулярно надо делать 5-10-50-100 плат с SMD-компонентами
• по возможности быстро
• по возможности дёшево

Если вы можете позволить себе — что по срокам, что по деньгам — услуги «Резонита» или «Компэла» (сотрудничающего, впрочем, с «Резонитом») по сборке модулей под ключ, то текст ниже в общем и целом не для вас. Однако, на практике даже в достаточно крупных компаниях люди, занимающиеся опытными образцами, часто собирают их сами — потому что это занимает пару дней вместо недели, потому что всегда можно на ходу что-то подправить, потому что не надо бегать между начальством и бухгалтерией со счетами и актами… В мелких же вопрос упирается попросту в деньги.

Тем более, что в наше время базовое оборудование, позволяющее делать подобные вещи достаточно быстро и достаточно дёшево, доступно даже любителю-одиночке.

Привет, Хабр!

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


Одна из весьма полезных и при этом почему-то в готовом виде нигде не описанных возможностей на микроконтроллерах Cortex-M (всех) — это возможность проверки корректности адреса в памяти. С её помощью можно определять размеры флэша, ОЗУ и EEPROM, определять наличие на конкретном процессоре конкретной периферии и регистров, прибивать упавшие процессы при сохранении общей работоспособности ОС и т.п.

Привет, Хабр!

В сети довольно много статей про работу микроконтроллеров STM32 в энергоэффективных устройствах — как правило, это устройства на батарейном питании — однако среди них прискорбно мало разбирающих эту тему за пределами перечисления энергосберегающих режимов и команд SPL/HAL, их включающих (впрочем, та же претензия относится к подавляющему большинству статей про работу с STM32).

Тем временем, в связи с бурным развитием умных домов и всевозможного IoT тема становится всё более актуальной — в таких системах многие компоненты имеют батарейное питание, и при этом от них ожидаются годы непрерывной работы.

Восполнять данный пробел мы будем на примере STM32L1 — контроллера весьма популярного, достаточно экономичного и при этом имеющего некоторые специфические именно для этой серии проблемы. Практически всё сказанное будет также относиться к STM32L0 и STM32L4, ну и в части общих проблем и подходов — к другим контроллерам на ядрах Cortex-M.



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

Привет, Хабр!

После волны, поднятой моим предыдущим постом, довольно заметное число людей спрашивали меня (в фейсбуке, в личке и т.п.), на что, собственно, обращать внимание, чтобы вместо умной розетки на ардуино не получить очередной тазик-эвтаназик.


Тема это большая и сложная, но я постараюсь выделить основные моменты — не в последнюю очередь на основании ошибок, которые я видел во всевозможных реальных устройствах и проектах, в том числе публиковавшихся на Хабре. Я не буду долго и нудно перечислять ГОСТы, но перечислю совсем базовые вещи, которые необходимо понимать и соблюдать, чтобы не убить хотя бы себя (если вы планируете не убивать также и окружающих, то после завершения этой статьи не поленитесь пролистать и релевантные ГОСТы).

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

Привет, Хабр. Под этим пафосным заголовком я бы хотел поговорить о том, что такое «инженерная наука», в чём состоит главная обязанность инженера и что бывает, если он с ней не справляется — мне кажется, в последнее время эта тема становится всё более актуальной, при этом её публичного обсуждения я не вижу.

Сподвигла меня на это разразившаяся (при моём активном участии) в минувшие выходные история с «нейроинтерфейсами» компании Bitronics Lab — детскими учебными наборами для снятия ЭЭГ и мышечной активности, которые при ближайшем рассмотрении оказались попросту небезопасны в использовании из-за несоблюдения их производителем базовых требований к электробезопасности медицинского оборудования.

История это очень показательна в том, что она демонстрирует, как по мере роста сложности система, составленная из кажущихся её авторам безопасными компонентов, становится опасной — причём на примере системы простой, бытовой и интуитивно понятной, а не атомного реактора или реактивного лайнера, которые любят брать в качестве примеров авторы книг вроде моей любимой "Inviting Disaster".

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

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



Казалось бы, что может пойти не так?

Короткая, но важная для причастных к IoT новость: ГКРЧ официально расширила безлицензионный диапазон 868 МГц, в котором традиционно живут такие сети, как LoRaWAN, Стриж/Вавиот, Sigfox и другие.

Официально это называется «неспециализированные устройства малого радиуса общего применения», а закреплены изменения в Приложении 12 к Решению ГКРЧ № 18-46-03-1 от 11 сентября 2018 года.

Было:

• 864,0 — 865,0 МГц — мощность до 25 мВт, рабочий цикл до 0,1 % или LBT*, запрещено использование на территории аэропортов
• 868,7 — 869,2 МГц — мощность до 25 мВт, рабочий цикл без ограничений, использование без ограничений

Стало (жирным выделены изменения):

• 864,0 — 865,0 МГц — мощность до 25 мВт, рабочий цикл до 0,1 % или LBT*, запрещено использование на территории аэропортов
• 866,0 — 868,0 МГц — мощность до 25 мВт, рабочий цикл до 1 % или LBT*, запрещено использование на территории аэропортов, спектральная плотность мощности до 1000 мВт/МГц
• 868,7 — 869,2 МГц — мощность до 100 мВт, рабочий цикл до 10 % или LBT*, использование без ограничений

* Listen Before Talk. Что это означает, правда, никто не знает, так как в российских НПА техническая суть LBT нигде не расшифровывается. Да и, собственно, никто его и не использует.

Что это означает конкретно для сетей LoRaWAN?

Привет, Хабр.

Традиционным уникальным преимуществом платформы Arduino называлось (да и сейчас иногда называется, хотя это уже неверно — и мы поговорим, почему) опускание порога входа в микроконтроллерную разработку до уровня базовых знаний C/C++ и электроники в маштабе «подключить светодиод в нужной полярности».

Спросите примерно у любого активного сторонника Arduino — и вам быстро объяснят, что можно, конечно, писать под STM32 или nRF52, но выгоды в том реальной никакой, зато вас ждут бессонные ночи над сотнями страниц даташитов и бесконечные простыни функций с длинными непонятными названиями.

Заслуги Arduino в снижении порога вхождения действительно трудно переоценить — эта платформа появилась на свет в середине нулевых годов, а после 2010 завоевала серьёзную популярность среди любителей. Особых альтернатив на тот момент ей не было — процессоры на ядрах Cortex-M только появились, по сравнению с AVR они были довольно сложны даже для профессиональных разработчиков, а отладочные платы у большинства вендоров стоили от сотни долларов и выше (и в общем в индустрии ценник за отладку на 5-долларовом контроллере в $500 никого сильно не удивлял).

Однако большая проблема Arduino в том, что её развитие за минувшие 10+ лет более всего напоминает некоторые модели АвтоВАЗа:


Так как дальше я планирую длинное вступление, то сейчас, чтобы вы представляли, в чём будет заключаться практическая часть, я приведу полный текст программы, включающий инициализацию процессора STM32 и мигание светодиодом. Программа написана для ОС ARM Mbed:

#include "mbed.h"
DigitalOut myled(LED1);

int main() {
    while(1) {
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

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

Конспект первой лекции по программированию современных микроконтроллеров на примере STM32 и операционной системы RIOT. Лекции читаются в Институте информационных технологий МИРЭА по субботам, с 12:50 в актовом зале на 4 этаже корпуса Д. В занятиях отводится 1,5 часа на саму лекцию и 3 часа на практические занятия в лаборатории IoT Академии Samsung по теме лекции.

Привет, Гиктаймс! Как мы и обещали, начинаем публикацию конспектов лекций, которые сейчас читаются в Институте ИТ МИРЭА. По результатам первой, вводной лекции мы решили немного изменить структуру курса — вместо планировавшихся двух потоков по 5 занятий будет один поток на 7 занятий. Это позволит в более спокойном темпе разобрать ряд вспомогательных вопросов, а также статьи с конспектом будут появляться на GT каждую неделю в течение всего марта и апреля, а не через неделю, как планировалось раньше.

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

Курс рассчитан на студентов второго и третьего курсов, знакомых с языком C и базовыми понятиями электроники и электротехники. Предварительное знакомство с микроконтроллерами не требуется.

Цель курса — освоение навыков, позволяющих свободно работать с микроконтроллерами на ядре ARM Cortex-M на современном уровне и, при наличии такого желания, двигаться в сторону дальнейшего углубления своих знаний.



Сегодняшняя лекция — первая, поэтому на ней будут разбираться общие понятия: что такое вообще микроконтроллер и зачем он нужен, что такое прошивка и как она получается, зачем нам нужна операционная система, и наконец — как работать с git. Результат практического занятия — собственный репозитарий на GitHub с исходными кодами ОС, а также успешно настроенная среда сборки на локальном компьютере.

Привет, Гиктаймс! Этим полукреслом мастер Гамбс… Этим постом мы — проект IoT Академия Samsung и компания Unwired Devices — начинаем цикл публикаций по мотивам нового практического курса по программированию микроконтроллеров на ядре Cortex-M3, который с завтрашнего дня будет читаться в Институте Информационных Технологий Московского Технологического Университета (также известного как МИРЭА).

Цель курса — познакомить студентов с современными микроконтроллерами на ядре Cortex-M3 и дать им базовые навыки программирования под них на языке C под операционной системой. Требования к слушателям — знакомство с языком C (не обязательно на микроконтроллерах) и базовое понимание электроники (на уровне умения подключить светодиод).



Изначально программа IoT Академии задумывалась как достаточно высокоуровневая — студенты должны работать с готовыми модулями передачи данных для сетей LoRa и 6LoWPAN, в которые уже были загружены прошивки с поддержкой нужных датчиков и необходимой логикой работы с ними. Фактически, курс заключается в настройке этих модулей и написании высокоуровневого ПО для обработки приходящих данных на платформе Samsung Artik + Tizen.

Однако, как показала практика, многим студентам интересно более серьёзно углубиться в то, что происходит внутри микроконтроллеров. При этом на данный момент с обучающими курсами по контроллерам Cortex-M в паре с операционными системами всё обстоит достаточно плохо: по сути, девять из десяти таких курсов посвящены написанию несложного приложения с использованием StdPeriphLib и/или CubeMX, причём половина текста приходится на вопросы инициализации контроллера и его периферии.

Часть первая: Meltdown
Часть вторая: Spectre

Одним из самых интересных вопросов, возникших в дискуссиях об аппаратных уязвимостях Meltdown и Spectre (см. ссылки выше) был вопрос о том, сделал ли нам Дед Мороз этот подарок в связи с тем, что в 2017 году мы вели себя плохо — или, наоборот, хорошо.



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

Часть первая: Meltdown.

Несмотря на всю мощь уязвимости Meltdown, принесённое этим Новым годом счастье не было бы полным, если бы не вторая часть открытия, не ограничивающаяся процессорами Intel — Spectre.

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

Строго говоря, Spectre не является одной уязвимостью — уже на старте заявлены два различных механизма (CVE-2017-5753 и CVE-2017-5715), а авторы отмечают, что может быть ещё и много менее очевидных вариантов.

В основе своей Spectre похожа на Meltdown, так как также базируется на том факте, что в ходе спекулятивного выполнения кода процессор может выполнить инструкции, которые он не стал бы выполнять при условии строго последовательного (неспекулятивного) вычисления, и, хотя в дальнейшем результат их выполнения отбрасывается, его отпечаток остаётся в процессорном кэше и может быть использован.