모니터링 기간: 2026-11-04 08:00 ~ 2026-11-05 08:00 (베이징 시간, 24시간)

출처: RT-Thread 공식 뉴스 인터페이스 및 공식 웹사이트 뉴스 목록, GitHub 메인 저장소 commits / PR / Issue / releases / tags, RT-Thread org 저장소 푸시 목록, GitHub 저장소 검색(topic:rt-thread 및 rt-thread 키워드), Google News 중영문 5개 쿼리(프록시 경유), HN Algolia, EE Times China RT-Thread 공식 칼럼, Espressif 공식 발표자료, club.rt-thread.org 포럼(이번 기간에도 여전히 사이트 WAF 제한 적용)

이번 호 인덱스

    1. 커널 및 버전 동향
      • 버전 번호 부여 및 릴리스 프로세스 최초 문서화: Z 버전은 월 단위, Y 버전은 3~6개월 (11-04)
      • 시리얼 TIOCGWINSZ를 디바이스에 직접 질의하도록 변경: 더 이상 tshell을 통해 문자를 읽지 않음 (11-04)
      • GPT 파티션 시작/끝 반전 검증 추가: 언더플로된 거대 파티션 더 이상 등록되지 않음 (11-04)
    1. 보안 후속 조치 및 병합 대기 큐
      • MSI-X 테이블의 BIR과 오프셋 미검증, 악성 PCIe 디바이스가 프로빙 단계에서 임의 물리 주소에 기록 (11-05)
      • 보고 후 6시간 만에 수정 제안: 5개 검증 항목 일괄 보완 (11-05)
      • 큐: 블록 디바이스 파티션 패치 추가 업데이트, 4건 계속 대기 중 (11-05)
    1. 공식 및 커뮤니티 활동
      • Ruìqíng RK3576 데스크톱 펫: 보드는 듣기와 말하기 담당, PC는 생각 담당 (11-04)
      • 공식 뉴스 인터페이스는 여전히 6월에 멈춰 있음, 미디어 칼럼이 유일한 안정적 출구 (11-05)
    1. 생태계 및 벤더 적응
      • ESP32-S31에서 RT-Thread를 ESP-IDF에 이식: 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, 이슈 #11956

751줄 추가, 14개 파일, 전부 문서: 중영문 두 가지 버전의 《버전 번호 부여 제정 및 실시 세칙》과 《버전 릴리스 프로세스》, 6장의 흐름도 포함, Doxygen 인덱스에 등록되어 문서 센터와 함께 배포됨. 작성자 kurisaW, 10월 30일 제안, 이번 모니터링 기간 초에 병합. 문서 자체에 버전 1.0, 날짜 2026-10-27 표기.

규칙의 핵심은 버전 리듬을 숫자로 명시한 것: Z 수정 버전은 원칙적으로 월 1회, Y 마이너 버전은 기능 축적과 유지보수 리소스에 따라 3~6개월에 1회, 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에 명시해야 함. 함께 제공되는 《버전 릴리스 프로세스》는 한 번의 릴리스를 6단계로 나눔 — 버전 준비, 다음 버전 초기 목표 수립, 개발 준비, 개발, 프리릴리스, 릴리스. 프리릴리스 부분은 기능 수렴, 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 세 파일을 수정했으며, 커밋 4개, 메인테이너 BernardXiong이 직접 제출했고, 10월 18일에 시작되어 이번 기간에 머지되었다.

기존 구현에는 두 가지 문제가 있었다. 첫째, tshell 스레드에서만 사용할 수 있었다. finsh_getchar()로 터미널의 CSI 응답 패킷을 읽었기 때문에 tshell이 아닌 스레드에서 호출하면 그냥 80x24를 반환했다. 둘째, 입력을 삼킨다. 응답 패킷이 셸의 입력 채널로 들어오기 때문에 사용자가 입력 중인 문자를 삼킬 수 있었다. 또한 termios는 설정할 때마다 무조건 ops->configure를 호출했고, 순수 소프트웨어 파라미터 변경만으로도 UART의 FIFO가 초기화되었다.

새 구현은 조회 명령을 시리얼 장치에 직접 기록하고(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를 설치하여 응답 패킷이 원시 수신 큐에 남아 입력으로 변하지 않도록 한다. 기존 ioctl에 있던 ENOSYS만 처리하던 switch도 함께 삭제되었다.

검증 조건은 명확하게 작성되었다. BSP는 bsp/k230과 bsp/qemu-virt64-aarch64를 사용하며, 작성자는 로컬에서 실행하지 않았고, 그 이유는 환경에 RISC-V musleabi 툴체인이 없어 CI 컴파일에 맡겼기 때문이다. 이런 “한 아키텍처에서만 정리하고 CI에 의존하는” 커밋은 시리얼 계층에서 드물지 않지만, 변경 방향은 옳다. 터미널 크기는 장치 속성이지 특정 셸 스레드의 존재에 의존해서는 안 된다.

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보다 작지 않은지는 확인하지 않았다. CRC 검증이 유효한 GPT 이미지를 구성하면 efi_partition()의 size = ending_lba - starting_lba + 1에서 부호 없는 하위 언더플로가 발생하여 천문학적인 파티션 크기가 되고, 논리 파티션으로 시스템에 등록된다. 수정 방법은 두 단계다. is_pte_valid()에 end가 start보다 작다는 판정 기준을 추가하여 직접 거부하고, start와 size 계산을 유효성 검사 이후로 옮겨 검증된 start로 size를 도출하여 근본적으로 언더플로 표현식이 평가되지 않도록 한다.

한 가지 정정이 필요하다. 지난 호 리포트에서 제안 상태에 따라 #11978을 “종료됨”으로 작성했지만, 실제 머지 타임스탬프는 11-04 21:30(베이징 시간)으로 이번 기간 내에 해당하므로 이번 호에서 머지로 추가 기록한다. 동일한 수정에 대응하는 결함 #11271은 3월 19일에 시작되어 결함에서 머지까지 7개월 이상 걸렸다.

2. 보안 추적 및 머지 대기 큐

2.1 MSI-X 테이블의 BIR과 오프셋 미검증, 악성 PCIe 장치가 프로브 단계에서 임의 물리 주소에 기록 (11-05)

날짜: 2026-11-05 01:12 (보고 시간)　출처: 결함 #11985

보고자는 여전히 XueDugu이며, 기준 master 5d1fb66d(v5.4.0-dev, 2026-10-15), 영향 범위는 v5.2.0부터로 명시되어 있으며, 2024-05-30의 2168ed8e7(PCI/PCIe 버스 프레임워크 최초 머지)에 의해 도입되었다.

문제는 msix_table_remap()에 있습니다. 이 함수는 장치 측의 읽기 전용 레지스터인 MSI-X Table Offset을 읽어 하위 3비트를 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을 AND 연산)이 오히려 통과되어, table_base_phys = 0에 오프셋을 더한 값이 되어 완전히 장치가 결정하는 절대 물리 주소가 되며, 29비트 폭으로 참조 보드의 전체 메모리를 덮을 수 있습니다.

또한 두 가지 검증이 빠져 있습니다. table_offset은 최대 0xFFFFFFF8까지 가능한데 BAR의 size와 비교한 적이 없으며, entries_nr은 MSI-X Control 레지스터를 또 한 번 읽어서 얻는데, 장치가 두 번의 읽기에서 다른 값을 주면 각 테이블 항목에 0x80000000을 쓰는 마지막 루프가 매핑 영역을 벗어나 최대 2048개 항목, 32 KB까지 실행될 수 있습니다. 더 중요한 것은 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을 OR한 값입니다. 부팅 시 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줄 삭제, PCI의 MSI-X 핵심 파일인 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 제안까지 6시간 9분으로, 이 주제에서 지금까지 가장 빠른 “보고에서 패치까지”입니다.

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 데스크톱 펫: 보드는 듣고 말하고, PC는 생각한다 (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 기술 라이브 방송에서 실기 시연을 진행했다.

역할 분담은 명확하다. 보드는 듣고 말하고, PC는 생각한다. 보드 측은 RK3576에 ES8388 사운드 카드를 조합하고, 녹음은 arecord, 재생은 aplay를 사용하며 모두 hw:0,0을 통한다. 표정은 GPU를 쓰지 않았고 Qt나 LVGL도 실행하지 않으며, mmap으로 /dev/fb0를 열어 픽셀을 직접 기록한다. 인격, 기억, 도구, 모델은 모두 PC의 DSH Desktop에 있고, 보드는 API Key를 저장하지 않으며 추론도 하지 않는다. PC가 꺼져 있으면 보드는 벙어리가 된다.

한 번의 대화는 일곱 단계로 나뉜다. evdev가 KEY5를 읽으면 알림음을 재생하고 녹음을 시작한다. arecord가 16 kHz, S16_LE, 2채널로 WAV를 녹음한다. 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 디바이스 독점, 시작 시 /proc의 fd를 기준으로 고아 프로세스 정리이며, 셋 중 하나만 빠져도 재현된다. 둘째, 스트리밍 TTS가 잘린다. 코드의 DSH_VOICE_TTS_SSE 스위치는 기본적으로 꺼져 있고, 주석에 often truncates라고 직접 적혀 있다. 초기에는 첫 세그먼트를 받자마자 합성해 한 문장이 10 KB에 불과했고, 「연속 여러 차례 폴링해 내용이 변하지 않고 낭독이 최소 두 한자 이상」일 때 합성하도록 바꾸자 용량이 115 KB에 이르렀다. 셋째, 표정은 두 단계 우선순위로 나뉘며 idle, listening, speaking은 0, 감정은 1이다. 1이 잠겨 있을 때 0의 요청은 무시되며, 잠금이 만료되면 반드시 자동으로 idle로 돌아가야 한다. 그렇지 않으면 confused 재생이 끝난 뒤 마지막 프레임에 멈춘다.

이 글의 가치는 「실시간 IO는 보드 측에 두고 추론은 연산력이 더 강한 쪽에 둔다」는 원칙을 재현 가능한 일곱 단계 체인으로 정리했다는 데 있다. 우전 「신광」 기사에서 AI는 Linux 측, 제어는 RT-Thread 측에 두는 분업과 같은 사고이며, 이번에는 추론이 PC로 옮겨졌을 뿐이다. 향후 계획은 LVGL 인터페이스, 인터럽트 메커니즘, 대형 모델의 하드웨어 제어다.

3.2 공식 뉴스 인터페이스는 여전히 6월에 정지, 미디어 칼럼이 유일한 안정적 출구 (11-05)

날짜: 2026-11-05 (확인)　출처: RT-Thread 공식 뉴스 목록

공식 뉴스 인터페이스 getList?type=rt_org가 반환하는 최신 항목은 여전히 2026-06-17의 「RT-Thread Ruisaide Technology, 2026 아부다비 투자 포럼에 초청 참석」이며, 공식 홈페이지 첫 화면 뉴스 영역도 6월에 멈춰 있어 이번 회차 신규 항목은 없다. 공식 홈페이지 뉴스 모듈의 목록 영역은 여전히 인터페이스로 대조해야 전체를 읽을 수 있다.

이미 실제 배포 경로는 미디어 칼럼에서 안정화되었습니다: 이번 기간 EE Times China의 RT-Thread 계정에 Ruiqing 데스크톱 펫 관련 원고 한 편이 업데이트되어 수록되었습니다. 포럼 club.rt-thread.org는 여전히 468을 반환하며 앞단에 WAF 챌린지 페이지가 있어, 게시글 목록과 본문을 직접 읽을 수 없고, 커뮤니티 논의 측면은 GitHub와 칼럼을 교차 검증하는 방식에만 의존할 수 있습니다.

4. 생태계와 벤더 적응

4.1 ESP32-S31에서 RT-Thread를 ESP-IDF에 밀어 넣기: 자체 점검 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/는 esp-idf/components/rtthread에 그대로 drop-in되어 FreeRTOS 커널을 대체하고, patches/는 git apply로 IDF 자체의 10개 파일, 약 440줄을 수정하는데 여기에는 freertos의 Kconfig와 CMakeLists, 부팅 흐름, 링커 스크립트의 인터럽트 스택과 힙 세그먼트 정의, 그리고 새로 추가된 RISC-V 트랩 진입점과 flash 크로스코어 훅이 포함됩니다; project/에는 예제 애플리케이션만 둡니다. RT-Thread 소스는 무수정 상태로 유지되며, 스크립트가 고정 커밋 9e6dec3b 기준으로 5.4.0을 가져옵니다.

기능 목록은 매우 구체적입니다: 스케줄링, 스레드, 세마포어, 뮤텍스, 이벤트, 메일박스, 메시지 큐, 소프트웨어 타이머, 동적·정적 객체가 모두 갖춰져 있고; SMP 듀얼코어 스케줄링(코어별 독립 tick, 독립 인터럽트 스택, IPI), CLIC 인터럽트와 하드웨어 중첩, 인터럽트 워치독, FinSH의 22개 명령, 내부 DRAM과 16 MB PSRAM 힙이 모두 사용 가능합니다. 주변장치 측면에서는 UART, GPIO와 핀 인터럽트, 3채널 I2C, SPI(폴링, 완전한 버스 프레임워크는 아님), 2채널 17비트 ADC, 8채널 LEDC PWM, MCPWM 상보 출력과 데드타임, 4채널 GPTimer, PCNT, RMT, TWAI가 모두 연결되었고; 무선 측면에서는 Wi-Fi 2.4 GHz가 연결되어 IP를 획득하고 스캔할 수 있으며, BLE 컨트롤러와 NimBLE도 사용 가능합니다; 이식되지 않은 것은 I2S, SD/MMC, LCD, 카메라, 터치, 이더넷, 하드웨어 암호화와 저전력입니다.

보드 테스트 결과는 자체 점검 36개 전부 통과, 0 실패이며, 두 코어 모두 스레드를 실행 중이고 Wi-Fi는 듀얼코어가 켜진 상태에서도 연결되어 IP를 획득합니다. 글에서 언급된 세 가지 비자명한 설계 포인트는 기록할 만합니다: CONFIG_FREERTOS_UNICORE=y와 「듀얼코어」는 모순되지 않으며, 이 두 매크로는 FreeRTOS가 멀티코어에서 스케줄링하는지를 기술하는데 y로 설정하면 IDF가 start_other_core를 호출하지 않고 두 번째 코어는 RT-Thread가 스스로 시작하도록 남겨두며, n으로 설정하면 오히려 entry()가 아예 호출되지 않게 됩니다; CPU1은 반드시 먼저 mstatus.FS를 3으로 설정해야 하는데, 트랩 진입점이 부동소수점 폭이 32일 때 무조건 f0부터 f31까지 저장하고, 스레드 스택 프레임 구성 시 FS는 3이지만 CPU1 전원 인가 시에는 0이므로, 이 처리를 보충하지 않으면 첫 번째 부동소수점 저장에서 오류가 발생합니다.

배경은 Espressif가 2026년 3월 26일 발표한 ESP32-S31입니다: 듀얼코어 32비트 RISC-V, 최대 320 MHz, Wi-Fi 6, 블루투스 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

작성자 DeguiLiu가 만든 C++17 기반 액티브 객체 및 계층형 상태 머신 프레임워크로, 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의 중첩 사용자 포인터, pipe의 ioctl 포인터, timerfd의 임의 fd 수용, POSIX timer의 id 범위 초과, 블록 디바이스 파티션의 원시 포인터. 이러한 결함의 전제는 모두 ‘비특권 프로세스가 존재한다’는 것이었다. 이번 MSI-X 결함의 전제는 ‘악성 디바이스가 삽입된다’로 바뀌었다: 디바이스 펌웨어가 제공하는 읽기 전용 구성 레지스터를 커널이 신뢰 입력으로 간주하고, BIR이 한 비트 범위를 초과하면 rom 멤버로 별칭되어 매핑 기저 주소가 임의 물리 주소로 변한다. 따라서 CVSS는 6.8에 불과하지만 결과는 마찬가지로 부팅 단계의 커널 임의 쓰기이다. RT-Smart 외에도 PCI 프레임워크는 MCU에서도 동일하게 영향을 받으며, 이는 디바이스 측 입력 검증이 시스템 호출보다 검토가 적은 영역임을 보여준다.

두 번째 축은 대응 속도이다. 01:12 보고, 07:21 제안, 6시간; 지난 기간의 블록 디바이스 파티션은 10월 29일 보고, 11월 3일 제안으로 5일이었다. 보고자가 PoC, GDB 로그, 버전 추적이 포함된 완전한 자료를 제공하여 유지관리자가 받자마자 직접 수정할 수 있었으며, 이는 어떤 프로세스 규정보다도 수정 시간을 단축시킨다. 대가는 리뷰 부담이 계속 뒤로 밀리는 것이며, 대기열에는 여전히 4건이 심사 대기 중이다.

세 번째 축은 버전 거버넌스가 처음으로 문서로 정착된 것이다. 751행의 버전 번호와 릴리스 프로세스는 Z를 월 단위, Y를 3~6개월, X를 비정기로 못박고, Z는 새로운 공개 API를 도입할 수 없으며 릴리스 후 원래 Tag를 변경할 수 없고, Y의 주기는 버전 목표에 명시해야 한다고 규정했다. 다운스트림 배포판과 상용 버전에게 이는 한 번의 업그레이드를 따라갈지, 마이그레이션 비용이 얼마인지를 판단하는 직접적 근거이며, 릴리스 노트의 구두 약속보다 신뢰할 수 있다.

생태계 측면에서 방향이 반대인 두 가지 움직임 모두 주목할 만하다: 한쪽은 커뮤니티가 RT-Thread를 FreeRTOS만 제공하는 신규 칩(ESP32-S31)에 탑재하여 컴포넌트 형태로 커널을 교체하고 벤더 무선 스택을 유지하는 것이고; 다른 쪽은 coact 같은 C++ 프레임워크가 액티브 객체와 계층적 상태 머신의 성숙한 패러다임을 RT-Thread 애플리케이션 계층에 도입하는 것이다. 하나는 커널의 플러그 가능성을 검증하고, 다른 하나는 애플리케이션 계층의 방법론을 보완한다. 활동 측면에서 Ruiqing 데스크톱 펫은 ‘보드 측 실시간 IO와 PC 측 추론’의 최소 재현 가능한 샘플을 제공하며, Wuzhen ‘New Light’ 기고문의 혼합 배포 서사와 같은 맥락이다.

5.2 한계와 중복 제거 설명

포럼 club.rt-thread.org는 이번 기간에도 468을 반환하고 WAF 챌린지 페이지가 앞에 붙어 있어, 게시글 목록과 본문을 읽을 수 없었으며, 커뮤니티 논의 측 정보 공백은 GitHub와 미디어 칼럼으로 보완했다. 공식 뉴스 인터페이스와 공식 웹사이트 뉴스 목록은 모두 6월 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 메인라인의 완전한 포크로 독립적인 애플리케이션 코드가 없어 생태계 항목으로 수록하지 않았다; 10월 30일의 광군제 프로모션 기고문은 홍보성 콘텐츠이며 이미 모니터링 기간을 벗어났다.

부록: 출처 검증표 및 출처 목록

출처 검증표

출처 검증 결과
공식 뉴스 인터페이스(rt_org) 24시간 동안 신규 없음, 최신 항목은 2026-06-17에 멈춤
공식 웹사이트 뉴스 목록 홈페이지 뉴스 영역은 여전히 6월, 신규 없음
커뮤니티 포럼 전면 WAF 챌린지 페이지(HTTP 468), 목록과 본문 읽기 불가
메인 저장소 commits 모니터링 기간 내 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 org 저장소 35개 저장소 검증, 메인 저장소만 모니터링 기간 내 푸시 있음
GitHub 저장소 검색 topic:rt-thread 8개, 2개 수집(ESP32-S31 포팅, coact)
Google News 중국어 3일 내 3건 모두 모니터링 기간 전 보도 또는 홍보, 7일 조회에서 Ruiqing 데스크톱 펫 1건 확인, 수집 완료
Google News 영어 유효 조회 제로, 무관한 HackerNoon 기사 1건만 있음
HN Algolia 7건 모두 Thread 네트워킹 프로토콜, 채용 또는 무관한 내용, 제외 완료
EE Times China 공식 칼럼 11-04 Ruiqing 데스크톱 펫 기사 1건, 수집 완료
Espressif 공식 발표문 ESP32-S31 사양과 발표 시점 확인용

전체 출처 목록