Окно мониторинга: 2026-11-04 08:00 ~ 2026-11-05 08:00 (пекинское время, 24 часа)

Источники: официальный новостной интерфейс RT-Thread и список новостей на официальном сайте, коммиты / PR / Issue / releases / tags основного репозитория GitHub, список пушей репозиториев организации RT-Thread, поиск по репозиториям GitHub (topic:rt-thread и ключевое слово rt-thread), пять групп запросов Google News на китайском и английском (через прокси), HN Algolia, официальная колонка RT-Thread в EE Times China, официальные пресс-релизы Espressif, форум club.rt-thread.org (в этом выпуске по-прежнему ограничен WAF сайта)

Индекс выпуска

    1. Динамика ядра и версий
      • Нумерация версий и процесс релиза впервые задокументированы: Z-версии ежемесячно, Y-версии каждые 3–6 месяцев (11-04)
      • TIOCGWINSZ последовательного порта переведён на прямой запрос к устройству: больше не читает символы через tshell (11-04)
      • Добавлена проверка перепутанных начала и конца GPT-раздела: гигантские разделы с переполнением снизу больше не регистрируются (11-04)
    1. Сопровождение безопасности и очередь на слияние
      • BIR и смещение в таблице MSI-X не проверяются, вредоносное PCIe-устройство на этапе обнаружения пишет по произвольным физическим адресам (11-05)
      • Предложение об исправлении через 6 часов после отчёта: пять проверок добавлены разом (11-05)
      • Очередь: очередное обновление патчей разделов блочных устройств, четыре коммита по-прежнему висят (11-05)
    1. Официальные и общественные мероприятия
      • Настольный питомец Ruiiing RK3576: плата отвечает за слух и речь, ПК — за мышление (11-04)
      • Официальный новостной интерфейс по-прежнему стоит на июне, медийная колонка — единственный стабильный канал (11-05)
    1. Экосистема и адаптация производителей
      • RT-Thread встроен в ESP-IDF на ESP32-S31: все 36 самопроверок пройдены (11-04)
      • coact: один заголовочный файл одновременно подключает RT-Thread, FreeRTOS и Linux (11-04)
    1. Тренды выпуска и итоги
      • Тренд: поверхность атаки смещается с параметров системных вызовов к прошивкам устройств
      • Ограничения и пояснения по дедупликации

1. Динамика ядра и версий

1.1 Нумерация версий и процесс релиза впервые задокументированы: Z-версии ежемесячно, Y-версии каждые 3–6 месяцев (11-04)

Дата: 2026-11-04 10:44 (время слияния)　Источник: предложение #11955, issue #11956

751 добавленная строка, 14 файлов, всё — документация: двуязычные (китайская и английская) «Правила нумерации версий и инструкция по реализации» и «Процесс выпуска версий», с 6 блок-схемами, зарегистрированные в индексе Doxygen и публикуемые вместе с документационным центром. Автор kurisaW, предложено 30 октября, слито в начале этого окна. Сами документы помечены версией 1.0, датой 2026-10-27.

Ядро правил — числовая фиксация ритма версий: Z-ревизии в принципе ежемесячно, Y-минорные версии по мере накопления функциональности и с учётом ресурсов сопровождения каждые 3–6 месяцев, X-мажорные версии выпускаются без фиксированного цикла. Номер версии — vX.Y.Z, и он должен совпадать с RT_VERSION_MAJOR/MINOR/PATCH в исходном коде, Git Tag, Release и именами артефактов; повседневные коммиты номер версии не повышают, снимки разработки могут обозначаться только целевой версией плюс полный SHA.

Критерии разрядов расписаны детальнее, чем когда-либо ранее. Триггеры X: смена ядра, смена модели устройств или фреймворка драйверов, согласованное обновление нескольких ключевых подсистем, а также изменения API, ABI, Kconfig или процесса загрузки, требующие миграции существующих проектов. Для Y требуется «новый API ядра или компонента, новый набор BSP, образующих самостоятельную единицу поставки, несколько небольших функций, складывающихся в полный проверяемый набор», и явно указано: отдельная разрозненная функция, локальное расширение параметров или оптимизация одной реализации автоматически не запускают Y. Z охватывает только дефекты, безопасность, производительность, адаптацию отдельного BSP и документацию и не должен вводить новые публичные API, компоненты или фреймворки драйверов — если отдельный BSP приносит новый фреймворк драйверов, надо повышать до Y или X. При смешении нескольких категорий изменений в одной версии берётся высший уровень: X выше Y, Y выше Z, без оглядки на число коммитов, PR или строк кода.

Несколько пунктов инструкции наиболее полезны для нижестоящих потребителей: как только период Y зафиксирован, он должен быть записан в цели версии, а функции, не прошедшие проверку в срок, переносятся; примерно за месяц до релиза Z начинается стабилизация исправлений, примерно за месяц до релиза Y начинается функциональная стабилизация и заморозка X.Y; после официального релиза при обнаружении проблем допускается только выпуск X.Y.Z+1, изменять исходный Tag, содержимое исходного Release или исходные артефакты запрещено; Y- и Z-версии, меняющие поведение по умолчанию или потребление ресурсов, обязаны указать это в Release. Сопутствующий «Процесс выпуска версий» разбивает один релиз на шесть этапов — подготовка версии, определение предварительных целей следующей версии, подготовка к разработке, разработка, предрелиз, релиз; в предрелизной части — стабилизация функций, регрессия BUG и шаблоны тест-кейсов с группировкой по архитектурам и BSP.

Примечательно, что примеры в документах единообразно записаны как v6.0.0, v6.1.0, v6.1.1, а следующая основная линия планируется по серии 6. Ранее интервал между 5.2 и 5.3 и ритм Z-версий существовали лишь в практике; это первый раз, когда ритм, критерии и правило о неизменяемости Tag после релиза оформлены как официальный документ внутри репозитория, что даёт непосредственно применимую основу для оценки стоимости обновления нижестоящим дистрибутивам и коммерческим версиям.

1.2 TIOCGWINSZ последовательного порта переведён на прямой запрос к устройству: больше не читает символы через tshell (11-04)

Дата: 2026-11-04 21:33 (время слияния)　Источник: Предложение #11891

Добавлено 136 строк, удалено 153 строки, изменены три файла: dev_serial.c, dev_serial_v2.c и serial_tty.c, четыре коммита, предложено самим мейнтейнером BernardXiong, открыто 18 октября, в этом выпуске слито.

У старой реализации было две проблемы. Во-первых, она работала только в потоке tshell: читала CSI-ответ терминала через finsh_getchar(), а при вызове из потока, отличного от tshell, просто возвращала 80x24. Во-вторых, она съедала ввод — ответ приходил по входному каналу shell и мог проглатывать символы, которые пользователь в этот момент набирал. Кроме того, termios при каждой установке безусловно вызывал ops->configure, и даже чисто программное изменение параметров сбрасывало FIFO UART.

В новой реализации команда запроса пишется напрямую в последовательное устройство (записываются четыре байта CSI 18 t), ответ читается побайтово, общее ожидание 200 миллисекунд, чтение завершается по достижении ‘t’; ответ должен строго соответствовать форме CSI 8;rows;cols t, строки и столбцы ограничены диапазоном от 1 до 999, при несоответствии на любом шаге сохраняется значение по умолчанию 80x24, без произвольного разбора через atoi. В версии v2 есть дополнительный шаг: на время запроса RX-таймаут временно меняется на RT_WAITING_NO, чтобы чтение не блокировалось навсегда при отсутствии ответа терминала, а после чтения восстанавливается.

Со стороны termios сделано «сначала сравнить, потом настраивать»: если новая конфигурация побайтово совпадает с serial->config, ops->configure не вызывается; со стороны tty при открытии последовательного порта определяется, является ли он консолью, и если да, то сначала один раз запрашивается размер окна, а затем устанавливается bypass, так что ответ остаётся в исходной очереди приёма и не превращается во ввод. Заодно удалён прежний switch в ioctl, который делал только ENOSYS.

Условия проверки изложены прямо: BSP использует bsp/k230 и bsp/qemu-virt64-aarch64, автор локально не запускал, причина — отсутствие в окружении инструментальной цепочки RISC-V musleabi, компиляция передана CI. Подобные коммиты, «продуманные только на одной архитектуре и полагающиеся на подстраховку CI», в последовательном слое встречаются нередко, но направление изменений верное: размер терминала — это свойство устройства, и он не должен зависеть от существования некоего потока shell.

1.3 В GPT-разделе перепутаны начало и конец, добавлена проверка: гигантские разделы из-за нижнего переполнения больше не регистрируются (11-04)

Дата: 2026-11-04 21:30 (время слияния)　Источник: Предложение #11978, Дефект #11271

Добавлено 11 строк, удалено 5 строк, изменён только один файл efi.c разбора разделов блочного устройства. Это переделка уже просроченного предложения #11275.

is_pte_valid() ранее требовала лишь, чтобы и starting_lba, и ending_lba попадали в пределы диска, но не проверяла, что ending_lba не меньше starting_lba. Достаточно было сконструировать GPT-образ с корректной CRC, чтобы в efi_partition() выражение size = ending_lba - starting_lba + 1 испытало беззнаковое нижнее переполнение, дав астрономический размер раздела, который регистрировался в системе как логический раздел. Исправление в два шага: в is_pte_valid() добавлен критерий отклонения при end меньше start; вычисление start и size перенесено после проверки корректности, size выводится из уже проверенного start, чтобы выражение с переполнением не вычислялось в принципе.

Нужно одно уточнение: в прошлом выпуске отчёта по статусу предложения #11978 было записано как «закрыто», фактическая метка времени слияния — 11-04 21:30 (пекинское время), что попадает в окно текущего выпуска, поэтому здесь оно дописано как слитое. Дефект #11271, соответствующий тому же исправлению, был открыт 19 марта, от дефекта до слияния прошло более семи месяцев.

2. Сопровождение безопасности и очередь на слияние

2.1 BIR и смещение таблицы MSI-X не проверяются, вредоносное устройство PCIe на этапе обнаружения пишет по произвольным физическим адресам (11-05)

Дата: 2026-11-05 01:12 (время отчёта)　Источник: Дефект #11985

Докладчик по-прежнему XueDugu, базовая ветка master 5d1fb66d (v5.4.0-dev, 2026-10-15), область влияния указана начиная с v5.2.0, внесено коммитом 2168ed8e7 от 2024-05-30 (первое слияние каркаса шины PCI/PCIe).

Проблема в msix_table_remap(): функция читает регистр MSI-X Table Offset, доступный только для чтения со стороны устройства, интерпретирует младшие три бита как BIR и напрямую использует их для индексации pdev->resource[]. Однако этот массив содержит всего 6 элементов, а BIR маскируется по 0x7, поэтому могут получиться значения 6 и 7. При значении 6 происходит алиасинг на расположенный в структуре сразу за массивом pdev->rom — для устройств без option ROM этот член равен {base:0, size:0, flags:0}. Поскольку значение PCI_BUS_REGION_F_MEM равно 0, проверка на «невыделенный BAR» (flags & F_NONE) наоборот проходит, и тогда table_base_phys = 0 плюс смещение превращается в абсолютный физический адрес, полностью определяемый устройством, шириной 29 бит, чего достаточно для покрытия всей памяти референсной платы.

Кроме того, отсутствуют ещё две проверки: table_offset может достигать 0xFFFFFFF8 и никогда не сравнивается с size BAR; entries_nr берётся из ещё одного чтения регистра MSI-X Control, и если устройство при двух чтениях вернёт разные значения, последний цикл, записывающий 0x80000000 в каждую запись таблицы, сможет выйти за пределы области отображения — максимум 2048 записей, 32 КБ. Что ещё важнее, rt_ioremap() сам по себе не выполняет проверку допустимости физического адреса, поэтому поддельное отображение будет успешным.

Цепочка воспроизведения полная: официальная конфигурация qemu-virt64-aarch64 по умолчанию (RT_USING_PCI, RT_PCI_MSI, RT_PCI_ECAM, RT_NVME_PCI, RT_PIC_ARM_GIC_V2M все включены), с помощью локально пропатченной модели QEMU nvme регистр MSI-X Table Offset на стороне устройства подделывается как 0x4023f06e, то есть адрес rt_interrupt_enter_hook 0x4023f068 с BIR 6. При загрузке pci_nvme_probe последовательно доходит до msix_capability_init и msix_table_remap, после чего ядро записывает значение MSI doorbell 0x08020040 по этому физическому адресу; при следующем срабатывании прерывания EPC в журнале исключения оказывается 0x08020040, и система входит в бесконечный цикл. В отчёте приведены точка наблюдения GDB, журнал консоли и сравнение памяти до и после; результаты трёх запусков атакующей группы совпадают побайтно.

Оценка сформулирована сдержанно: CVSS 3.1 равен 6.8 (AV:P), оценка снижена из-за предпосылки физического доступа или цепочки поставок периферии, но техническое последствие — произвольное чтение и запись физической памяти ядра на этапе загрузки. Предпосылкой атаки является вредоносное или скомпрометированное устройство PCIe (NVMe-диск с вредоносной прошивкой, подменённая периферия, открытый слот M.2), не требующее никаких программных привилегий или взаимодействия с пользователем. Связаны CWE-787, CWE-129 и CWE-20; уязвимость подтверждена для v5.2.0–v5.3.0 и master. Автор отчёта также отмечает, что каркас PCI ранее не покрывался никаким аудитом безопасности, и эта находка не пересекается с существующими отчётами.

2.2 Через 6 часов после отчёта — предложение об исправлении: пять проверок добавлены разом (11-05)

Дата: 2026-11-05 07:21 (время предложения)　Источник: Предложение #11986

47 добавленных строк, 5 удалённых, изменён только основной файл MSI-X в PCI — msi.c; предложено мейнтейнером BernardXiong, статус по-прежнему «ожидает рассмотрения».

Пять проверок соответствуют трём пробелам и двум деталям из отчёта: BIR больше или равен длине массива resource — немедленный отказ; BAR помечен как невыделенный или size равен 0 — немедленный отказ; table_offset плюс entries_nr умножить на 16 должно полностью укладываться в BAR (заодно table_offset приводится в порядок маской PCIM_MSIX_TABLE_OFFSET); проверяется возвращаемое значение чтения конфигурационного регистра, при ошибке чтения выполнение не продолжается; при превышении nvec над table_size — отказ, чтобы защититься от несогласованных размеров таблицы при двух чтениях устройства. В вычислениях table_base_phys и table_bytes переведены в 64 бита, чтобы избежать переполнения сложения в 32 битах.

Проверка ограничена компиляцией: bsp/qemu-virt64-aarch64, с включёнными RT_USING_PCI и RT_PCI_MSI, xPack aarch64-none-elf-gcc 13.2.1 проходит, воспроизведение атаки не выполнялось. От отчёта в 01:12 до предложения в 07:21 — шесть часов девять минут; это самый быстрый в данной теме цикл «от отчёта до патча».

2.3 Очередь: снова обновлён патч разметки блочных устройств, четыре предложения продолжают висеть (11-05)

Дата: 2026-11-05 (время обновления предложения)　Источник: Предложение #11981, Предложение #11954, Предложение #11971, Предложение #11983

Обновление по уже упоминавшемуся в прошлом выпуске усилению защиты пользовательских указателей в разделах блочных устройств (#11981, соответствует произвольной записи в ядро из дефекта #11952) появилось снова 11-05 в 07:34, по-прежнему не смержено, способ исправления не изменился: в пользовательском контексте данные раздела сначала копируются в стек ядра, затем копируются обратно через lwp_put_to_user(), при недопустимом указателе возвращается -EFAULT без записи.

Статус остальных трёх позиций в очереди: переполнение при умножении счётчиков poll и epoll (#11954) обновлено 11-05 в 00:04; усиление защиты пользовательских указателей в pipe ioctl (#11971) обновлено 11-04 в 14:57; предложение utest с добавлением цикла и сэмплирования памяти для автозапуска (#11983) обновлено 11-04 в 12:44, все три ожидают рассмотрения. Смерженный в прошлом выпуске #11978 закрыт в этом выпуске, #11977, #11973, #11963, #11957 также закрыты, накопление не продолжает расти.

3. Официальные и общественные мероприятия

3.1 Настольный питомец Ruiqing RK3576: плата отвечает за слух и речь, ПК — за мышление (11-04)

Дата: 2026-11-04 13:54 (время публикации колонки) / 2026-11-04 20:00 (время трансляции)　Источник: EE Times China: платформа Ruiqing — выращиваем синего кита на RK3576

Официальная колонка RT-Thread 11-04 опубликовала инженерный разбор того, как синий кит из DeepSeek Harness был перенесён на RK3576 с небольшим экраном: нажимаешь KEY5, говоришь фразу, он издаёт «diii», через несколько секунд отвечает тоном толстой рыбы, глаза на экране при этом двигаются. В тот же день в 20:00 в техническом лайв-канале Ruiqing была проведена демонстрация на реальном устройстве.

Разделение обязанностей описано чётко: плата отвечает за слух и речь, ПК — за мышление. На стороне платы — RK3576 со звуковой картой ES8388, запись через arecord, воспроизведение через aplay, всё через hw:0,0; для эмоций не задействован GPU, не запускаются Qt или LVGL, пиксели пишутся напрямую через mmap в /dev/fb0. Персонаж, память, инструменты и модель находятся на ПК в DSH Desktop, плата не хранит API Key и не выполняет инференс — без включённого ПК она нема.

Один цикл диалога разбит на семь шагов: evdev считывает KEY5, затем воспроизводится подсказка и начинается запись; arecord записывает WAV с 16 kHz, S16_LE, два канала; voice-once отправляет файл multipart POST в /v1/voice-turn промежуточного сервиса; server.mjs отрезает заголовок WAV, преобразует в f32 PCM и отправляет в ASR; session.prompt отвечает лишь «принято», а основной текст опрашивается из session.history до стабилизации; spokenForTts выбирает только символы внутри 【】 и передаёт их в Edge TTS для синтеза mp3; на стороне платы mpg123 преобразует в WAV, sox пересэмплирует до 48 kHz, aplay воспроизводит звук, одновременно по метке эмоции в заголовке ответа переключаются кадры.

Почему между ними нужен промежуточный мост, статья приводит две конкретные причины: api.deepseek.com имеет только текстовый интерфейс, без серии эндпоинтов /v1/audio/, и прямое подключение с платы не позволяет собрать голосовую цепочку; непрерывность сессии требует фиксированного DSH_SESSION_ID, а если голос открывает новую сессию, персонаж и контекст полностью меняются. Мост блокирующий, на стороне платы curl с таймаутом 180 секунд, висит от нажатия кнопки до возврата аудио.

Три подводных камня описаны ценнее, чем выводы. Во-первых, одно нажатие кнопки запускало два цикла диалога — при убийстве демона дочерний процесс не обязательно умирает вместе с ним, два процесса одновременно читают один и тот же event7; решение — flock для единственного экземпляра, EVIOCGRAB для эксклюзивного захвата устройства, очистка осиротевших процессов по fd в /proc при запуске, без любого из трёх воспроизводится. Во-вторых, потоковый TTS обрезает, переключатель DSH_VOICE_TTS_SSE в коде по умолчанию выключен, в комментарии прямо написано often truncates, на раннем этапе синтез запускался при получении первого фрагмента, одна фраза составляла всего 10 KB; после изменения на «синтез, когда содержимое при нескольких последовательных опросах не меняется и озвучиваемый текст содержит как минимум два китайских иероглифа» объём достиг 115 KB. В-третьих, у эмоций два уровня приоритета: idle, listening, speaking имеют 0, эмоции — 1, когда 1 заблокирован, запросы с 0 просто игнорируются, по истечении блокировки необходимо автоматически вернуться в idle, иначе после воспроизведения confused останется на последнем кадре.

Ценность этой статьи в том, что она описывает «реальный ввод-вывод остаётся на плате, инференс переносится на сторону с большей вычислительной мощностью» как воспроизводимую семишаговую цепочку, что совпадает по подходу с разделением из материала Wuzhen «Xinguang», где AI на стороне Linux, а управление на стороне RT-Thread, только здесь инференс перенесён на ПК. Дальнейшие планы — интерфейс LVGL, механизм прерывания и управление аппаратным обеспечением большой моделью.

3.2 Официальный новостной интерфейс по-прежнему на июне, колонки СМИ — единственный стабильный выход (11-05)

Дата: 2026-11-05 (проверка)　Источник: Официальный список новостей RT-Thread

Последняя запись, возвращаемая официальным новостным интерфейсом getList?type=rt_org, по-прежнему — от 2026-06-17 «RT-Thread RuisaiDe Technology приглашена на инвестиционный форум Абу-Даби 2026», новостной раздел главной страницы официального сайта также застыл на июне, в этом выпуске новых нет; список новостного модуля официального сайта по-прежнему можно прочитать полностью только сверяясь с интерфейсом.

Фактический канал публикации уже стабильно закрепился в медиа-колонке: в этом выпуске аккаунт RT-Thread в EE Times China обновил материал о настольном питомце Ruiqing, он включён в подборку. Форум club.rt-thread.org по-прежнему возвращает 468 и предваряется страницей WAF-проверки, список тем и текст сообщений напрямую прочитать нельзя, поэтому со стороны обсуждений в сообществе остаётся лишь перекрёстная сверка через GitHub и колонку.

4. Экосистема и адаптация у производителей

4.1 RT-Thread внутри ESP-IDF на ESP32-S31: все 36 самотестов пройдены (11-04)

Дата: 2026-11-04 20:56 (время публикации)　Источники: репозиторий: esp32s31-rtthread, Espressif: анонс ESP32-S31

Репозиторий, портирующий RT-Thread 5.4.0 на ESP32-S31, по форме не обычный BSP, а оформление себя как компонента ESP-IDF v6.1: component/ напрямую drop-in в esp-idf/components/rtthread, заменяя ядро FreeRTOS; patches/ через git apply правит 10 файлов самого IDF, около 440 строк, включая Kconfig и CMakeLists для freertos, процесс загрузки, определения стеков прерываний и сегментов кучи в скрипте компоновки, а также добавленные точки входа RISC-V-ловушек и межъядерные хуки для flash; project/ содержит только пример приложения. Исходники RT-Thread остаются без изменений, скрипт извлекает 5.4.0 по фиксированному коммиту 9e6dec3b.

Список возможностей дан предметно: планировщик, потоки, семафоры, мьютексы, события, почтовые ящики, очереди сообщений, программные таймеры, динамические и статические объекты — всё на месте; SMP-планирование на двух ядрах (независимый tick на каждом ядре, независимые стеки прерываний, IPI), прерывания CLIC и аппаратная вложенность, сторожевой таймер прерываний, 22 команды FinSH, куча во внутренней DRAM плюс 16 MB PSRAM — всё доступно. На периферии подключены UART, GPIO и прерывания по пинам, три канала I2C, SPI (опросный режим, не полный шинный фреймворк), два 17-битных АЦП, восемь каналов LEDC PWM, комплементарный MCPWM с мёртвым временем, четыре канала GPTimer, PCNT, RMT, TWAI; по беспроводной части Wi-Fi 2.4 GHz умеет подключаться и получать IP, умеет сканировать, контроллер BLE плюс NimBLE работоспособны; не портированы I2S, SD/MMC, LCD, камера, сенсорный ввод, Ethernet, аппаратное шифрование и энергосбережение.

Результат на плате: все 36 самотестов пройдены, 0 сбоев, оба ядра гоняют потоки, Wi-Fi при включённых двух ядрах подключается и получает IP. В статье стоит запомнить три неочевидных момента проектирования: CONFIG_FREERTOS_UNICORE=y и «два ядра» не противоречат друг другу — эти два макроса описывают, планирует ли FreeRTOS на нескольких ядрах; при значении y IDF не вызывает start_other_core, второе ядро остаётся для собственного запуска RT-Thread, а при значении n entry() вообще не будет вызван; CPU1 должен сначала установить mstatus.FS в 3, потому что точка входа ловушек при ширине float 32 безусловно сохраняет f0–f31, при формировании стекового фрейма потока FS равен 3, а при включении CPU1 он равен 0, и без этой правки первое же сохранение float даёт ошибку.

Контекст — выпущенный Espressif 26 марта 2026 года ESP32-S31: двухъядерный 32-битный RISC-V, до 320 MHz, Wi-Fi 6, Bluetooth 5.4, 802.15.4, официальный программный стек — ESP-IDF плюс FreeRTOS. Этот проект заменяет ядро, сохраняя беспроводную прошивку и драйверы IDF, то есть на чипе, для которого производитель предлагает только одну RTOS, проверяет подключаемость другого ядра. Позиционирование описано честно: host- и мультиархитектурные порты служат лишь тестовым референсом, продуктовая цель по-прежнему — одноядерный MCU.

4.2 coact: один заголовочный файл одновременно для RT-Thread, FreeRTOS и Linux (11-04)

Дата: 2026-11-04 22:35 (время публикации)　Источники: репозиторий: coact

Фреймворк активных объектов и иерархических конечных автоматов на C++17, автор DeguiLiu, лицензия MIT, в это окно мониторинга продвинулся до 98 звёзд. Модель следует подходу QP/C++: события вместо потоков, поведение описывается иерархическими конечными автоматами, таблицы переходов constexpr, никаких аллокаций во время выполнения; один и тот же набор заголовочных файлов работает на RT-Thread и FreeRTOS, а также компилируется на Linux и Windows через PAL, host служит только тестовым референсом.

Он формулирует три свойства как структурные ограничения, а не как лозунги. Ограниченность: каждая очередь, пул памяти и размер пакета — это константы времени компиляции, нет кучи, нет new и delete, нет динамической регистрации, наихудшее потребление flash и RAM можно определить на этапе компоновки, в репозитории есть скрипт измерения потребления под Renode. Обнаружимость: результат коммита возвращается через код SubmitResult, дополнительно есть счётчики Monitor, Breaker::level() и обработка fatal_assert, при сбое видно прямо в месте возникновения, какому активному объекту и какому разделу он принадлежит. Восстановление: каждому активному объекту сопоставлен конечный автомат автоматического выключателя с пятью состояниями Normal, BrokenL1, BrokenL2, Safe, Recovering, условия восстановления явно заданы как время охлаждения, устойчиво низкий уровень, успешное зондирование, непрерывное окно здоровья, в примере приведена полная реализация супервизора безопасности.

Значение для RT-Thread — в методологии прикладного уровня. В экосистеме большинство проектов строят логику напрямую на потоках и очередях сообщений, конечные автоматы часто пишут вручную через switch, не хватает фреймворка, который совместно ограничивает ограниченность, наблюдаемость и восстанавливаемость; данная реализация делает критическую секцию инъекционным интерфейсом, на стороне RT-Thread используется отключение прерываний, на стороне FreeRTOS — критическая секция задачи плюс маскирование ISR, путь ISR не берёт блокировок и не зависит от libatomic, одноядерный MCU — это явная точка проектирования.

5. Тенденции текущего выпуска и итоги

5.1 Тенденция: поверхность атаки смещается от параметров системных вызовов к прошивке устройств

За текущие 24 часа в основной репозиторий влито 3 коммита (#11955, #11978, #11891), создано 1 предложение (#11986), создан 1 дефект (#11985). Количество меньше, чем в прошлом выпуске, но по каждой из трёх линий есть содержательные изменения.

Первая линия — на стороне безопасности сменилась поверхность атаки. В последних выпусках сообщалось об отсутствии проверки «значение — объект» на уровне системных вызовов: вложенные пользовательские указатели getaddrinfo, указатель ioctl у pipe, timerfd принимает произвольный fd, выход id за границы у POSIX timer, сырой указатель раздела блочного устройства. Предпосылкой всех этих дефектов было «наличие непривилегированного процесса». Предпосылка дефекта MSI-X в этом выпуске сменилась на «вставлено вредоносное устройство»: предоставляемый прошивкой устройства регистр конфигурации только для чтения ядро считает доверенным вводом, выход BIR за границу на один бит даёт алиасинг на член rom, и далее базовый адрес отображения становится произвольным физическим адресом. Поэтому CVSS всего 6.8, но последствие то же — произвольная запись в ядро на этапе загрузки. Помимо RT-Smart, фреймворк PCI на MCU также подвержен влиянию, что показывает: проверка ввода со стороны устройства — менее scrutinized участок, чем системные вызовы.

Вторая линия — скорость реакции. Отчёт в 01:12, предложение в 07:21, шесть часов; в прошлом выпуске раздел блочного устройства: отчёт 29 октября, предложение 3 ноября, пять дней. Докладчик предоставил полный материал с PoC, с логами GDB, с прослеживанием версий, и мейнтейнер, получив его, может сразу править, это сокращает время исправления лучше любых процедурных предписаний. Цена — давление рецензирования продолжает смещаться назад: в очереди по-прежнему четыре ожидающих рассмотрения.

Третья линия — управление версиями впервые закреплено в документе. Документ из 751 строки о нумерации версий и процессе выпуска жёстко фиксирует Z как месячный, Y как три-шесть месяцев, X как нерегулярный, а также устанавливает, что Z не должен вводить новые публичные API, после выпуска нельзя менять исходный Tag, цикл Y должен быть записан в цели версии. Для нижестоящих дистрибутивов и коммерческих версий это прямой критерий того, стоит ли следовать за обновлением и сколько миграционных издержек оно потребует, что надёжнее устных обещаний в примечаниях к выпуску.

На стороне экосистемы заслуживают внимания два противоположно направленных действия: с одной стороны, сообщество встраивает RT-Thread в новые чипы, предоставляющие только FreeRTOS (ESP32-S31), заменяя ядро в виде компонента и сохраняя вендорский беспроводной стек; с другой стороны, такой C++ фреймворк, как coact, приносит на прикладной уровень RT-Thread зрелую парадигму активных объектов и иерархических конечных автоматов. Один проверяет подключаемость ядра, другой восполняет методологию прикладного уровня. На событийной стороне настольный питомец Ruiqing даёт минимально воспроизводимый образец «реального IO на плате плюс инференс на стороне PC», это та же линия, что и нарратив гибридного развёртывания в материале «Новый свет» из Учжэня.

5.2 Ограничения и пояснения по дедупликации

Форум club.rt-thread.org в этом выпуске по-прежнему возвращает 468 с предварительной страницей вызова WAF, список тем и текст не читаются, пробел в информации со стороны обсуждений сообщества восполнен GitHub и колонками медиа. Официальный интерфейс новостей и список новостей на официальном сайте застыли на 17 июня, в этом выпуске новых нет. Прямое подключение к агрегирующей странице колонки EE Times China истекло по таймауту, материал о настольном питомце Ruiqing был сверен путём попадания заголовка через Google News с последующим извлечением оригинальной страницы статьи, время публикации и текст взяты с исходной страницы.

На стороне GitHub квота анонимного интерфейса в этом выпуске достаточная, проверка на уровне организации охватила 35 репозиториев, в окне мониторинга推送 были только в основном репозитории, в ключевых репозиториях packages, env, rtthread-nano, sdk, smart-build, UtestRunner коммитов не было. Поиск по репозиториям topic:rt-thread дал 8 попаданий, включено 2 (порт ESP32-S31, coact), остальные — универсальные GUI-проекты или личные форки.

Дедупликация: #11978 в прошлом выпуске был записан как закрытый по статусу предложения, в этом выпуске дополнен по фактическому времени слияния с деталями корневой причины; #11981, #11954, #11971, #11983 были перечислены в прошлом выпуске, в этом фиксируются только изменения статуса без повторного раскрытия; #11985 и #11986 — это новая полная цепочка текущего выпуска, дефект и предложение записаны двумя отдельными пунктами. Не включено:推送 zlgopen/awtk относится к универсальным улучшениям GUI и не имеет специального отношения к RT-Thread; WorkerHMan/imx6ull_rt-thread и JiaVerso/myPilot_board по проверке оказались полными форками основной линии RT-Thread без независимого прикладного кода и не рассматриваются как записи экосистемы; материал о распродаже 11.11 от 30 октября является рекламным содержанием и уже вышел за окно мониторинга.

Приложение: контрольная таблица источников и перечень источников

Контрольная таблица источников

Источник Результат проверки
Официальный новостной интерфейс (rt_org) За 24 часа новых записей нет, последняя запись от 2026-06-17
Список новостей на официальном сайте Новостной раздел на главной странице по-прежнему за июнь, новых записей нет
Фóрум сообщества Страница проверки WAF (HTTP 468), список и содержимое недоступны для чтения
Коммиты основного репозитория 3 в окне мониторинга, сосредоточены 11-04 в 10:44 и с 21:30 по 21:33
PR основного репозитория Слито 3 (#11955, #11978, #11891); создан 1 (#11986)
Issue основного репозитория Создан 1 (#11985), вход со стороны устройства PCI MSI-X не валидируется
Releases и tags основного репозитория Новых нет, последний по-прежнему v5.3.0 (2026-09-10)
Репозитории организации RT-Thread Проверено 35 репозиториев, отправка в окне мониторинга только в основном репозитории
Поиск по репозиториям GitHub topic:rt-thread — 8, включено 2 (порт ESP32-S31, coact)
Google News на китайском 3 за 3 дня — все уже освещены до окна мониторинга или являются продвижением; запрос за 7 дней дал 1 совпадение — настольный питомец Ruiqing, включено
Google News на английском Ноль действительных совпадений, лишь одна не относящаяся к теме статья HackerNoon
HN Algolia Все 7 — протоколы сетевого взаимодействия Thread, вакансии или нерелевантный контент, исключены
Официальная колонка EE Times China 11-04 одна статья о настольном питомце Ruiqing, включена
Официальный пресс-релиз Espressif Используется для сверки спецификаций и даты выпуска ESP32-S31

Полный перечень источников