Fuzz тестирование, закон сохранения энергии, RTOS и… прагматизм IoT (а также о событиях)

Для объёмов статьи материала не то, чтобы мало, но тематика настолько специфическая, что ограничусь пусть немаленькой, но всё же цепочкой записей в блоге. Это частично будет интересно только программистам, причём далеко не всем, потому что речь будет идти в том числе и о конкретном инструменте, имеющем ограниченную применимость. Но и общий принцип тоже придётся «захватить». Чтобы «разбавить» специфику, позволю себе пространные отступления.

Даже не буду пытаться переводить термин «fuzz» («fuzzing»), сразу обращусь к точному определению, благо, оно есть в названии единственной полноценной тематической книги – «обнаружение уязвимостей методом грубой силы» (Brute Force Vulnerability Discovery). Даже не вдаваясь в детали, просто из «Brute Force» в названии, понятно, что речь идёт о несложных на смысловом уровне, но очень ресурсоёмких задачах. И, само собой, об эвристиках, сокращающих эту ресурсоёмкость.

Классический исторический пример fuzz-тестирования, как ни странно, хорошо вписывается в реалии IoT-систем. Потому что копеечные встраиваемые вычислители «доросли» до характеристик того самого знаменитого Macintosh, который был моноблоком с монохромным экраном. У того Macintosh было 128 KB оперативной памяти (кило-, не мега-), из которых 16KB отдавалось системе и 22KB – экранному буферу. Единичная (не в партиях) однокристальная полноценная 32-битовая машина с таким объёмом ОЗУ (с долговременной памятью, портами ввода-вывода и кучей всего «в нагрузку») сегодня доступна примерно за $6 (процессор MIPS-архитектуры), и эта цифра уже считается разработчиками массовой продукции очень немаленькой. Но вернёмся к истории fuzz-тестирования Macintosh. В 1983 году Стив Каппс, занимавшийся в команде Apple демонстрационными программами для MacWrite и MacPaint (ключевые приложения Macintosh), написал крохотную программку (код помещался в 256 байтов), имитирующую стаю быстрых обезьян, случайно нажимающих «на всё» и перемещающих указатель мыши. «The Monkey» использовалась в тестировании всей системы в целом. И, по воспоминаниям разработчиков, первые запуски программы «заваливали» систему буквально через несколько минут, выявляя совершенно очевидные, но не замеченные ошибки. То, что делала The Monkey, и есть «грубая сила для выявления уязвимостей». К большому сожалению, выявляемые в реальных системах совершенно невероятные ошибки даже не реализации, а проектирования на всех уровнях, показывают, что обстоятельные, очень долгие массированные атаки «грубой силой» остаются небесполезными. Чего стоит только феерическая «однобитовая уязвимость» всех версий Windows (включая 10), позволяющая реально обойти все многоступенчатые системы защиты ОС модификацией единственного бита в user space. Это смехотворное и леденящее душу уже быстренько закрыли очередным security update, но сколько такого ещё в системе, где на защищённом уровне ядра ОС реализуются какие-то «бегунки» пользовательского интерфейса?

Единственный пример «из старины» приведен сугубо для иллюстрации факта – инструментальные средства fuzz-тестирования не новинка. Их было много, и есть немало. Есть и чёткие категории их классификации по объектам тестирования – для «белых ящиков» (white box), то есть, для программ, доступных на уровне исходного кода, для «чёрных ящиков», тестирование на бинарном, исполняемом уровне, игнорирующее внутреннюю реализацию, и, наконец, для «серых ящиков» – бинарное fuzz-тестирование с учётом знаний о реализации.

Из сути fuzzy-тестирования очевидно следует, что идеальный его вариант – полный перебор всего пространства состояний тестируемого программного объекта. А из этого не менее очевидным является астрономический масштаб задачи, как относящейся к классу «грубой силы». Естественно, всё самое интересное в fuzzy-тестировании происходит именно в области результативного сокращения пространства поиска (на деле мы действительно говорим о задаче поиска такой комбинации параметров, например, при которой тестируемой программе «становится плохо»). Но короткую конкретику надо предварить кое-чем не менее очевидным, и даже не особо умалчиваемым, просто выпадающим из поля зрения «общетехнической журналистики».

IoT, как очередная эволюционная фаза M2M (взаимодействия машин), в мире взрослых людей – явление очень прагматичное. Стоимость, производительность, энергопотребление, габариты и сложность на уровне «чёрного ящика» встраиваемых вычислителей дошли возможности встраивания их «во всё», надёжность и доступность радиоканалов позволяют существенно экономить на физических проводных сетях, максимальная автономность «умных узлов» позволяет экономить на их эксплуатации во всём их жизненном цикле – было бы удивительно, если бы при таких предпосылках IoT (в том числе и неизбежный hype-период) не случился бы. Но есть некоторые «но». Встраиваемый вычислитель с радиоканалом подчиняется физическим законам при любом реализованном уровне «интеллекта». Чем чаще и больше он задействует радиоканал, например, тем больше энергии источника питания он расходует, а это означает снижение срока автономной работы. Чем более сложно и менее качественно (не будем вдаваться в детали определения качества, они интуитивно понятны) реализовано ПО такого вычислителя, тем чаще требуются его обновления, тем больше надо задействовать доступные каналы связи (или вообще отказаться от понятия автономности – кто-то должен приехать-прийти к вычислителю и, например, обновить ему firmware). Первое очевидное утверждение определяет специфику всех беспроводных каналов M2M и IoT – пакеты с минимальной «перегрузкой» служебной информацией, с маленькой «полезной нагрузкой» (payload), редкий обмен ими (только когда это надо, никакого принудительного опроса, поллинга, с предустановленным интервалом времени). Второе, не менее очевидное, с учётом первого превращает задачу, например, обновления firmware, в трудно реализуемую, а в многохоповых меш-сетях беспроводных датчиков (WSN, Wireless Sensor Network) ещё и в «задачу массового поражения источников питания узлов сети» (потому что прямой связи между узлом и пограничным роутером в таких сетях нет, а передача через множество узлов сети 128KB образа firmware, разбитого на 512 256-байтовых пакетов, может оказаться непозволительной роскошью). Это чистейшая инженерная прагматика. И из-за неё требования к ПО IoT вычислителей в идеале очевидно жёстче даже по сравнению с mission-critical приложениями: идеальный IoT-вычислитель не должен требовать обслуживания и обновлений хотя бы в период работоспособности от автономного источника питания, а этот период должен быть максимально продолжительным, речь идёт о годах. Иначе большие сети (IoT или M2M 2.0, как кому больше нравится) превратятся в огромную обузу.

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

Иллюстрацией к предыдущему абзацу приведу вчерашнюю (11.02.2015) новость – французский IoT-«стартап» Sigfox получил инвестиции в размере 100 миллионов евро, и эта цифра сама по себе является событием в мире стартапов. Но ещё интереснее инвесторы, о таких мечтают любые серьёзные большие компании, например, о NTT Docomo Ventures. Что же такого предлагает миру Sigfox? По большому счёту трудно сказать, что нечто «очень особенное». Речь идёт об очень дешёвых компактных встраиваемых модемах, реализующих интересный собственный защищённый патентами сверхузкополосный (Ultra Narrow Band) радиоканал в не требующих лицензирования диапазонах частот 868 или 915 MHz. «Скорострельность» этого канала на удивление низкая – 100 бит в секунду (не опечатка). Модемы Sigfox поддерживаются базовыми станциями (шлюзами) разработки компании и программным сервисом. Низкая скорость передачи радиоканала и его специфика (сверхузкополосность) – не прихоть, а вполне логичная основа большой дальности передачи, которая нужна для освобождения системы в целом от потребности в многохоповой архитектуре на уровне радиоканала. Заявленная дальность – 3-10 км для городских условий, 30-50 км для загородных, – позволяет уменьшить расходы на развёртывание сети базовых станций. Модемы Sigfox могут работать как в только передающем (12 байтов полезной нагрузки в одном пакете), так и в принимающем (8 байтов полезной нагрузки) режимах, но приём информации возможен только после инициализации передачей конечным устройством, так устроен протокол Sigfox, и это ограничение в какой-то мере понятно, оно – следствие соблюдения требований к высокой автономности, в то же время оно ограничивает возможности всей системы в передаче экстренной информации о критических событиях (фактически разработчики из Sigfox переложили ответственность за это на создателей конечных устройств). Автономность модемов очень высока, в Sigfox заявляют, что при принятых во всей системе ограничениях (передача до 140 пакетов в сутки для одного модема) срок работы от батареи с емкостью 2,5А/ч может достигать 20 лет. Ко всему этому удовольствию «привязаны» собственные облачные сервисы Sigfox. Принцип монетизации предельно прост - пользователи платят до 1 одного евро в месяц за 1 модем (цифра уменьшается при увеличении числа модемов). Использованное в начале абзаца в кавычках слово «стартап» было призвано подчеркнуть «небольшой» важный факт – на сегодняшний день сеть Sigfox покрывает базовыми станциями Францию, Испанию, Голландию и 10 крупнейших городов Великобритании. Вот такая иллюстрация одного фрагмента того, чего в реальности хочет мир. В контексте это иллюстрирует одну очень важную деталь – удалённое обновление firmware (прошивок) модемов Sigfox де-факто невозможно (совершенно нестрашный объём, 128KB, пакетами по 12 байтов при допустимых 140 пакетах в сутки будет обновляться примерно 78 суток если модем и «что-то там подключенное к нему» больше ничем вообще заниматься не будет. То есть, разработчики Sigfox гарантируют стабильную работу своего firmware на протяжении как минимум жизненного цикла заряда батареи, а это десяток лет. Надеюсь, понятно, какой уровень качества реализации встраиваемого ПО требуется, и как этот уровень оценивает мир (и серьёзные инвесторы).

Продолжение следует

Откланиваюсь

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365