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

출처: RT-Thread 공식 뉴스 API 및 공식 웹사이트 뉴스 목록, GitHub 메인 저장소 commits / PR / Issue / releases / tags, RT-Thread org 13개 중점 저장소 Atom 커밋 피드, GitHub 저장소 검색 (rt-thread 키워드 및 topic:rt-thread), Google News 중영문 6개 쿼리 (프록시 경유), HN Algolia, EE Times China RT-Thread 공식 칼럼, 세계인터넷대회 공식 웹사이트 및 국가인터넷정보판공실 보도자료, Phoenix Net 비즈니스 뉴스, club.rt-thread.org 포럼 (이번 호도 사이트 WAF 제한 적용)

이번 호 인덱스

    1. 커널 및 버전 동향
      • getaddrinfo 중첩 사용자 포인터 강화 머지: 스냅샷 1회로 계층 검증 대체 (11-03)
      • DM365의 SPI 분주기 0으로 나누기, max_hz에 0 전달 시 트리거 (11-03)
      • mailbox 테스트 케이스 두 번째 실행 시 반드시 실패: 완료 플래그 4개가 초기화되지 않음 (11-03)
      • 매크로 주석은 행 끝에 쓸지 위에 쓸지: 코딩 규범에 판단 기준 1절 추가 (11-03)
    1. 보안 후속 및 머지 대기 큐
      • timerfd 임의 fd 허용: 시스템 콜 2개로 커널 PC 제어 획득 (11-04)
      • POSIX timer의 id 미검증, RT-Smart에서 콘솔 디바이스 수정 가능 (11-03)
      • 블록 디바이스 파티션 ioctl의 임의 커널 쓰기, 제안 도착 (11-03)
      • 큐: pipe 패치 여전히 수정 중, 기존 5건 계속 대기 (11-03)
    1. 공식 및 커뮤니티 활동
      • 우전 “신광”: AIOS 기반 선정, 가상화 혼합 배포 발표 (11-02 ~ 11-03)
      • 오픈소스 AIOS 연맹, 소형 임베디드 AI 논의, RT-Thread 3가지 Agent 방안 발표 (11-03)
      • 공식 뉴스 API 여전히 6월에 정체, 발표 채널은 계속 미디어 칼럼 (11-04)
    1. 생태계 및 벤더 적응
      • Wildfire HPM6750 BTB의 Studio BSP GitHub에 업로드, 설치 절차 5단계로 정리 (11-04)
      • Nuvoton N9H30 커뮤니티 BSP: HMI 플랫폼의 ARM926EJ-S 노장 (11-03)
      • 듀얼 MCU 방역 장치: M7은 모션, M3는 분사 담당, 양쪽 모두 RT-Thread 구동 (11-03)
    1. 산업 응용
      • RV32IM 듀얼 이슈 FPGA CPU, RT-Thread Nano를 CoreMark 검증 체인에 연결 (11-03)
    1. 이번 호 트렌드 및 요약
      • 트렌드: 보안 측은 보고에서 제안으로, 테스트 측은 목록에서 코드로
      • 한계 및 중복 제거 설명

1. 커널 및 버전 동향

1.1 getaddrinfo 중첩 사용자 포인터 강화 머지: 스냅샷 1회로 계층 검증 대체 (11-03)

날짜: 2026-11-03 09:04 (머지 시간)　출처: 제안 #11977

지난 호에 보도된 메인테이너 재작업 건으로, 모니터링 기간 초에 머지되었으며 57줄 추가, 17줄 삭제로 네트워크 시스템 콜 디렉토리의 syscall_netdb.c 파일 하나만 수정했다.

기존 구현의 취약점은 계층 검증에 있었다. 사용자가 전달한 최상위 res 버퍼만 검사한 후, res->ai_addr이라는 사용자 제어 가능한 중첩 포인터를 통해 파싱된 socket 주소를 기록했으며, Smart/MMU 빌드에서는 getaddrinfo() 한 번이 임의 커널 쓰기로 변환되었다. hints의 필드는 최상위 검증 통과 후에도 사용자 메모리에서 직접 읽어 중간에 TOCTOU 윈도우가 존재했다. servname 복사 반환값 판단도 잘못 작성되어 size_t를 0과 비교했으므로 항상 거짓이었다.

수정 방식은 lwp_get_from_user()로 res와 hints를 한 번에 커널 임시 구조체로 복사하고, 이후 모든 중첩 포인터는 이 검증된 스냅샷에서 가져오는 것이다. 중첩 sockaddr과 외부 addrinfo는 일괄적으로 lwp_put_to_user()로 기록하며, 대상 주소 범위는 기존 helper가 검증하므로 커널은 미검사 사용자 포인터를 더 이상 역참조하지 않는다. 덧붙여 sizeof(*k_hints)에 따라 커널 addrinfo를 할당하고, 새로 추가된 오류 경로에서 k_res를 해제한다.

이 변경의 가치는 줄 수가 아니라 하나의 작성 방식을 보여준다는 데 있다. 중첩 사용자 포인터에 대해 계층 검증은 본질적으로 TOCTOU 공백이 있으며, 일회성 스냅샷이야말로 증명 가능하게 안전한 경로다. 작성자는 제안에서 검증이 K230의 RT-Smart 구성에서 syscall_netdb.o 컴파일 통과만 확인했으며 전체 빌드는 CI에 맡겼고, 사용자 영역 권한 상승 재현은 없다고 명시했다.

1.2 DM365의 SPI 분주기 0으로 나누기, max_hz에 0 전달 시 트리거 (11-03)

날짜: 2026-11-03 13:11 (머지 시간)　출처: 제안 #11957, 결함 #11950

6줄 추가, bsp/dm365/drivers/spi-davinci.c만 수정했으며 이번 모니터링 기간에서 가장 작은 변경입니다.

davinci_spi_setup_transfer()는 cfg->max_hz를 그대로 davinci_spi_get_prescale()에 전달하고, 후자는 DIV_ROUND_UP(clk_get_rate(dspi->clk), max_speed_hz)를 수행합니다. 설정에서 max_hz가 0이고 데이터 폭이 유효하면 이 나눗셈이 0으로 나누어져 곧바로 예외가 발생합니다. 수정 방식은 프리스케일러를 계산하기 전에 max_hz == 0을 판정하여 -RT_EINVAL을 반환하는 것이며, 0이 아닌 속도 경로는 건드리지 않습니다.

검증 조건은 솔직하게 기록했습니다. DM365 하드웨어가 없어 두 가지만 수행했습니다. arm-none-eabi-gcc로 bsp/dm365/drivers/spi-davinci.c를 컴파일하여 새로운 경고가 없음을 확인했고, 호스트 측에서 폭 검사와 프리스케일러 두 부분의 로직을 복제하여 data_width = 9, max_hz = 0일 때 수정 전에는 SIGFPE가 발생하고 수정 후에는 -RT_EINVAL을 반환하며, 1 MHz의 프리스케일러 결과는 수정 전과 동일함을 확인했습니다. DM365는 TI의 ARM9 구형 플랫폼으로 이런 BSP는 평소 테스트 커버리지가 거의 없어, 0으로 나누기 판정을 보강한 것만으로도 순이익입니다.

1.3 mailbox 테스트 케이스 두 번째 실행 시 반드시 실패: 네 개의 완료 플래그가 초기화되지 않음 (11-03)

날짜: 2026-11-03 10:53 (머지 시간)　출처: 제안 #11963, 결함 #6565

11줄 추가, src/utest/mailbox_tc.c만 수정했습니다.

증상은 동일한 부팅 내에서 두 번째로 core.ipc_mailbox를 실행하면 반드시 실패하는 것입니다. 첫 번째는 통과하지만, 두 번째는 수신 스레드에서 rt_object_get_type(...) == RT_Object_Class_MailBox 어서션이 실패하며 위치는 _rt_mb_recv() 2884행입니다. 근본 원인은 네 개의 *_thread_finish 플래그가 워커 스레드에 의해 1로 설정되기만 하고 한 번도 초기화되지 않기 때문입니다. 두 번째 실행 시 테스트 본체의 대기 루프 while (static_mb_recv_thread_finish != 1 || ...)가 즉시 통과하여, rt_mb_detach()가 이번 라운드에 시작되어 아직 rt_mb_recv()에서 블로킹 중인 워커 스레드가 종료되기 전에 호출되고, 스레드는 이후 오류로 복구되어 이미 detach된 mailbox를 계속 사용합니다. 동적 mailbox 쪽도 같은 형태이지만 별도로 트리거되지는 않았습니다.

수정 방식은 utest_tc_init()에서 초기화하는 것이며, 이 훅은 utest 프레임워크가 매 테스트 케이스 실행 전에 호출합니다. 결함 #6565는 2021년에 열린 오래된 이슈로, 이번 수정은 그 나머지 절반을 해결한 것입니다.

1.4 매크로 주석을 행 끝에 쓸지 위에 쓸지: 코딩 규범에 판정 기준 한 절 추가 (11-03)

날짜: 2026-11-03 09:48 (머지 시간)　출처: 제안 #11973, 결함 #10097

72줄 추가, 전부 문서에 해당합니다. coding_style_cn.md에 32줄, coding_style_en.md에 40줄을 추가하고, 제8절에 각각 「매크로 주석」 절을 보충했으며 코드는 한 줄도 변경하지 않았습니다.

기존 규범은 「문장 주석은 코드 위 또는 오른쪽에만 작성한다」고만 명시했을 뿐, 매크로에 어느 쪽을 선택해야 하는지, 그 근거가 무엇인지는 말하지 않아 같은 저장소에 두 가지 표기가 공존했습니다. 작성자는 먼저 현황을 통계한 뒤 규칙을 정했습니다. include/ 아래 135곳의 매크로 주석이 행 끝 /**<를 사용하며, 그중 87곳(64.4%)이 80열을 초과하고 kerrno.h 24행은 95열입니다. 그룹화된 상수 매크로는 의도적으로 열 정렬을 유지하며 초과를 감수합니다. 따라서 판정 기준은 행 길이가 아니라 「얼마나 설명이 필요한가」입니다. 한 줄 주석으로 설명할 수 있으면 행 끝에 두고, 한 단락이 필요하면(매개변수가 있는 매크로로 입출력, 확장 결과, 사용 제한을 설명해야 하는 경우) 위에 두고 @def를 추가합니다.

문서는 실천상의 차이도 한 가지 보충했습니다. MACRO_EXPANSION을 활성화하면 행 끝 /**<는 매크로의 확장 지점에 붙어, 같은 매크로가 여러 곳에서 확장될 때 주석 위치가 예상과 다를 수 있습니다. 위쪽 블록 주석은 항상 정의 위치에 바인딩됩니다. 따라서 자주 확장되는 매크로는 위쪽 블록 주석을 우선 사용합니다. 예시는 모두 저장소의 실제 코드(kerrno.h의 오류 코드 그룹, rtdef.h의 RT_ALIGN)에서 가져왔으며 지어낸 것이 아닙니다.

2. 보안 후속 조치 및 머지 대기 큐

2.1 timerfd가 임의 fd를 허용: 두 번의 시스템 호출로 커널 PC 제어 획득 (11-04)

날짜: 2026-11-04 01:08 (보고 시간)　출처: 결함 #11984

보고자 XueDugu, 기준선은 master 5d1fb66d13(v5.4.0-dev)입니다. 영향 범위를 명시하면: v5.0.2부터 영향을 받으며, 결함은 2023-09-23의 7c2f807a(즉 #8067의 timerfd 시스템 콜 병합)에 의해 도입되었습니다.

문제 자체는 매우 짧습니다: timerfd_do_settime()과 timerfd_do_gettime()은 프로세스 fd 테이블에서 임의의 디스크립터를 가져온 뒤, df->vnode->data를 곧바로 struct rt_timerfd *로 강제 형변환하며, 해당 파일이 실제로 timerfd인지 검증하지 않습니다. Linux는 같은 위치에서 file->f_op != &timerfd_fops이면 -EINVAL을 반환하지만, RT-Thread에는 대응하는 검사가 없습니다. 따라서 사용자가 접근할 수 있는 임의의 fd 객체의 vnode->data가 timerfd로 취급됩니다: 커널은 외래 객체 안에서 위조된 뮤텍스를 획득 및 해제하고, 공격자가 제공한 itimerspec을 기록한 뒤 tfd->timer를 역참조합니다(임의의 qword에서 리스트 제거와 rt_free를 한 번 수행).

진짜 치명적인 것은 음수인 it_value.tv_sec입니다: 이 값은 timerfd_timeout(tfd)을 동기적으로 실행하게 만들고, 첫 번째 문장 rt_wqueue_wakeup(&tfd->timerfd_queue, POLLIN)은 혼동된 객체에서 읽어낸 대기 큐 헤드를 따라 순회하며 entry->wakeup(entry, key)를 호출합니다 — 함수 포인터 간접 호출 한 번으로, 포인터와 r0가 전부 공격자가 선택한 메모리에서 나옵니다.

보고서는 전체 경로를 제시했습니다: 32비트 RT-Thread에서 signalfd는 완벽한 혼동 객체이며, 그 컨텍스트의 처음 128바이트가 바로 sigset_t sigmask로, signalfd()가 사용자 포인터에서 그대로 복사합니다(NUL 바이트 허용). 이는 위조된 timerfd 헤더를 덮기에 충분하며, rt_mutex의 type 바이트를 뮤텍스 타입으로 설정하고, owner를 0으로 남겨 take가 즉시 성공하게 하며, timerfd_queue.waiting_list.next를 설정하는 것까지 포함합니다. RT-Smart 커널은 사용자와 페이지 테이블을 공유하고 사용자 매핑을 직접 역참조하므로, 위조된 대기 큐 노드는 공격자 자신의 사용자 메모리에 놓입니다.

재현 환경은 qemu-vexpress-a9에 RT_USING_SMART 기본 빌드(timerfd와 signalfd는 Smart에서 기본 활성화)이며, libc 없는 사용자 모드 ELF를 /sbin/init으로 실행합니다. 대조군은 실제 timerfd 호출이 0을 반환하고 커널이 살아있었으며, 공격군은 signalfd(-1, mask, 0)에 timerfd_settime(sfd, 0, {it_value.tv_sec = -1})를 더해 커널 prefetch abort를 얻었고, PC는 완전히 제어 가능하며, 세 번의 실행이 바이트 단위로 일치했고, 레지스터에서 r00:0x10000을 볼 수 있었습니다. 결론은: 비특권이며 둘 다 공식 POSIX 스타일 인터페이스인 두 시스템 콜만으로 커널 제어 흐름 탈취가 가능하다는 것입니다.

2.2 POSIX timer의 id를 검증하지 않아 RT-Smart에서 콘솔 장치를 덮어쓸 수 있음 (11-03)

날짜: 2026-11-03 12:35(보고 시간)　출처: 결함 #11980

같은 보고자가 같은 날 이른 시각에 제출했습니다. timer_gettime()과 timer_settime()은 사용자가 준 timer_t를 그대로 인덱스로 사용합니다: timer = _g_timerid[(rt_ubase_t)timerid]이며, timerid < TIMER_ID_MAX 검사가 없습니다. 형제 함수 timer_delete()에는 이 검사가 있으므로, 이는 설계상의 선택이 아니라 누락입니다.

일반 MCU 빌드에서는 범위를 벗어난 읽기지만, RT-Smart에서는 그 이상입니다 — 공격자는 _g_timerid 옆 주소에 존재하는 포인터를 골라 대상 커널 객체를 struct timer_obj로 재해석할 수 있습니다. 보고서가 QEMU 이미지에서 찾은 구체적 별칭은 인덱스 0x35a5(13733)가 _console_device를 가리키는 것이었습니다: timer_settime()은 이어서 공격자가 제어하는 itimerspec으로 이 살아있는 UART 장치의 필드를 덮어쓰며, rx_indicate와 ops를 포함하므로, UART가 수신 바이트를 하나 받기만 하면 제어 흐름이 공격자가 지정한 주소로 점프하고, EL1에서 실행됩니다.

하드웨어 측에서도 검증했습니다: Pico 2 W(RP2350)에서 원본 ctime.c와 resource_id.c로 빌드하여, 디스어셈블리로 timer_settime() 진입점이 바로 ldr.w r6, [r5, r0, lsl #2]임을 확인했고, timer_oob에 0x20000000을 전달하면 주소가 0xa000202c로 계산되어, 매핑되지 않아, 결함 후 USB CDC 연결이 사라지거나 shell이 멈췄습니다. 소프트웨어 기준선은 동일하게 v5.4.0-dev이며, 도입 커밋은 077e9841, 최초 영향 버전은 v5.0.2입니다.

2.3 블록 디바이스 파티션 ioctl의 임의 커널 쓰기 등에 대한 제안 도착 (11-03)

날짜: 2026-11-03 15:51 (제안 시간)　출처: 제안 #11981, 결함 #11952

19줄 추가, 5줄 삭제, 파일 하나만 수정, 작성자 liangzhan5, 제안 상태는 자체적으로 초안으로 표시.

문제는 RT_DEVICE_CTRL_BLK_PARTITION에 있습니다: 이 명령은 사용자 공간에서 전달된 원시 포인터를 그대로 rt_memcpy의 목적지 주소로 사용하므로, 비특권 프로세스가 이를 통해 임의 커널 쓰기를 수행할 수 있습니다. 또 하나의 부수적 문제는 rt_memcpy 실행이 끝난 후 err를 갱신하지 않기 때문에, ioctl이 최종적으로 -1을 반환하더라도 대상 주소의 내용은 이미 변경된 상태이며 오류 코드가 실제 상황과 일치하지 않습니다. 작성자는 동시에 RT_DEVICE_CTRL_BLK_GETGEOME 등의 명령에도 같은 종류의 문제가 있을 수 있다고 지적했습니다.

수정 방법은 두 가지 경로로 나뉩니다: RT_USING_LWP 아래에서 lwp_self()를 사용해 현재 사용자 공간 컨텍스트인지 판단하고, 사용자 공간이면 먼저 파티션 데이터를 커널 스택 임시 변수에 복사한 다음 lwp_put_to_user()로 안전하게 다시 복사하며, 포인터가 유효하지 않으면 -EFAULT를 반환하고 어떠한 쓰기도 수행하지 않습니다. 비사용자 공간(커널 내부 호출)은 기존 rt_memcpy 경로를 유지하고 err = RT_EOK를 추가합니다. 검증은 qemu-vexpress-a9의 컴파일과 수동 검토까지만 진행되었습니다.

대응 결함 #11952는 10월 29일에 동일한 보고자가 제기했으며, 보고부터 제안까지 5일이 걸렸습니다.

2.4 큐: pipe 패치 여전히 수정 중, 다섯 건의 오래된 안건 계속 대기 (11-03)

날짜: 2026-11-03 (제안 업데이트 시간)　출처: 제안 #11971, 제안 #11954, 제안 #11911, 제안 #11918, 제안 #11947, 제안 #11935

지난 호에서 보도한 pipe FIONREAD 패치(#11971)는 11-03 16:13에 다시 업데이트되었으나 여전히 병합되지 않았습니다. 수정 방법은 변함없습니다: 먼저 링 버퍼의 데이터 길이 또는 남은 공간을 스택의 int에 계산하고, MMU 빌드에서는 lwp_put_to_user()로 사용자 주소에 다시 복사하며, 비MMU 빌드에서는 직접 쓰기를 유지합니다. 아울러 pipe와 pipe->fifo의 널 검사를 추가하고, lwp_user_mm.h의 include를 ARCH_MM_MMU로 감쌉니다.

큐에 있는 나머지 다섯 건의 상태: cromfs 디렉터리 이름 경계(#11911), poll 및 epoll 카운트 곱셈 오버플로(#11954), 9pfs 클라이언트가 서버 길이를 신뢰(#11918), DHCP 주소 풀 고갈 후 무한 검색(#11947), signalfd 종료 시 리스너 제거(#11935) 모두 이번 기간에 병합되지 않았습니다. 어제 병합된 #11978(GPT 파티션 처음과 끝 반전)은 종료되었습니다.

3. 공식 및 커뮤니티 활동

3.1 우전 「신광」: AIOS 기반 선정, 주제는 가상화 혼합 배포 (11-02 ~ 11-03)

날짜: 2026-11-02 (박람회 개막) / 2026-11-03 14:30 (공식 칼럼 게시)　출처: EE Times China: RT-Thread 우전 정상회의 참석, 세계인터넷대회: 박람회 우전 개막, CAC 보도자료

2026년 세계인터넷대회 우전 정상회의는 11월 2일부터 5일까지 저장성 우전에서 개최되며, 동시에 「인터넷의 빛」 박람회가 11월 2일 오전에 개막했습니다. 공식 발표: 54개 국가 및 지역의 671개 중외 기업과 기관이 참가하여 1000여 개의 신기술 신제품을 전시 및 발표하고, 35개의 「신광」 제품과 20개의 「신요」 시나리오를 선정 및 추천합니다.

RT-Thread RuiyAI가 이번 정상회의에서 얻은 위치는 「신광」 제품 추천 명단으로, 선정된 것은 회사가 자주 혁신한 「RT-Thread 이기종 통합 엣지 지능 AIOS 기반」입니다. 생태계 총괄 리옌은 박람회 현장에서 《가상화 혼합 배포 구현 지능 솔루션·AI Kit》이라는 제목으로 기조연설을 했습니다.

베이스의 기술 주장은 명확하게 서술되어 있다. 하이브리드 배포 아키텍처는 AI 추론을 Linux 측에, 실시간 제어를 RT-Thread 측에 배치하여 양측이 독립적으로 실행되고 서로 간섭하지 않으며, AI 측에 이상이 발생하더라도 제어 측은 안정적으로 실행될 수 있다고 한다. 공식 측은 제어 정밀도가 마이크로초 수준에 이를 수 있다고 밝혔다. 함께 제공되는 AI Kit는 추론 엔진, 모델 최적화, 하드웨어 적응 및 디버깅 환경을 하나의 툴체인으로 묶었으며, 판매 포인트는 개발자가 “특정 칩, 특정 프레임워크에 정통할” 필요 없이 하나의 도구 세트로 전체 프로세스를 완주할 수 있게 하는 것이다.

이 항목에서 주목할 만한 점은 내러티브의 변화이다. 과거 RT-Thread가 외부에 내세운 것은 “실시간 제어 베이스”, “설치 수량이 가장 많은 국산 임베디드 운영체제”였으나, 이번에 선정된 주체는 엔드사이드 지능형 운영체제이며, 착점은 로봇의 “두뇌”와 “소뇌”의 협업에 있다. 공식 보도자료의 “실시간 제어 베이스에서 엔드사이드 지능형 운영체제로의 핵심 도약”이라는 문구가 이 내러티브의 공식 버전이다. 수치 측면에서 원고가 제시한 커뮤니티 규모는 약 30만 개발자로, 기존 기준과 일치한다.

3.2 오픈소스 AIOS 얼라이언스, 소형 구현지능 논의, RT-Thread는 세 가지 Agent 방안 발표 (11-03)

날짜: 2026-11-03 17:14 (보도 시각) / 2026-10-23 (행사 시각)　출처: 凤凰网: 오픈소스 AIOS 얼라이언스, WTCC 2026 결집

11-03에야 발송된 비즈니스 보도자료로, 10월 23일 상하이 서안 국제 테크놀로지 소비 카니발(WTCC 2026) 기간의 “Jishu 창커팡: 소형 구현지능 방안 세미나”를 다루고 있다. 주최 측은 ARM China 산하 Jishu 커뮤니티이며, 같은 무대에 “오픈소스 AIOS 얼라이언스” 세 파트너가 참여했다: Rockchip, Radxa Computer, RT-Thread.

ARM China는 올해 7월 이 얼라이언스를 발족하여 지속적 인지, 자율 실행, 장기 기억 등의 역량에 집중했으며, 동시에 JishuFriends와 JishuBuddy 두 가지 실현 성과를 출시했다. 전자의 첫 프로토타입 Puppy는 로봇 개를 매개체로 환경 인지, 음성·시각 상호작용 및 자율 이동을 융합하고, 후자는 Agentic AI를 위한 하드웨어 개발 도구로 자연어를 진입점으로 삼아 Arm 아키텍처 임베디드 기기를 지원하며 시뮬레이션 환경을 기반으로 실제 구현기기와 연동할 수 있다.

RT-Thread 측에서는 AI 시니어 엔지니어 정웨이가 등장하여 로봇 개, HyperCar, Codex 오케스트레이션 세 가지 Agent 방안을 발표했으며, 착점은 지능체를 “대화”에서 “실행”으로 밀어내고 RT-Thread가 구현지능 프로젝트를 중점으로 하여 ARM China와 협력해 Agent 역량을 실제 응용에 연결하겠다는 것을 명확히 한 것이다. 세 파트너의 분업도 이 원고에서 비교적 명확하다: Rockchip은 메인 SoC와 AI 코프로세서의 연산-제어 디커플링을, Radxa는 ZERO 3W 같은 오픈소스 하드웨어로 프로토타입에서 양산 납품까지를, RT-Thread는 시스템 측의 Agent 스케줄링과 실행을 담당한다.

주의할 점은 시각 관계이다. 행사는 10월 23일이었고 보도는 11월 3일에야 나왔으며, 이번 호에 수록한 이유는 이 기사가 처음으로 얼라이언스 내 RT-Thread의 구체적 기술 분업을 제시했기 때문이지, 당일 새로 발생한 사건이 아니다.

3.3 공식 뉴스 인터페이스는 여전히 6월에 멈춰, 발표 출구는 계속 미디어 칼럼에 (11-04)

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

공식 뉴스 인터페이스 getList?type=rt_org가 반환하는 최신 항목은 여전히 2026-06-17의 “睿赛德科技, 2026 아부다비 투자 포럼에 초청받아 참석”이며, 공식 웹사이트 첫 페이지 뉴스 영역도 6월에 멈춰 있어 이번 호에는 신규 항목이 없다. 공식 웹사이트 뉴스 모듈 자체가 로딩에 실패했으며(페이지에서 “앗, 로딩 실패” 오류 표시), 목록 페이지는 인터페이스로만 확인할 수 있었다.

실제 발표 출구는 미디어 칼럼에 있다: 이번 호 EE Times China의 RT-Thread 공식 칼럼이 한 편(11-03의 우전 “신광” 원고)을 업데이트했으며, 이전 11-01의 광군제 프로모션 원고는 홍보 콘텐츠로 수록하지 않았다. 포럼 club.rt-thread.org는 여전히 468을 반환하며 WAF 챌린지 페이지가 선행되어, 게시글 목록과 본문을 직접 읽을 수 없으며, 커뮤니티 토론 측은 GitHub와 미디어 칼럼 교차 검증에만 의존할 수 있다.

4. 생태계와 벤더 적응

4.1 야훠 HPM6750 BTB의 Studio BSP, GitHub에 공개, 설치 절차를 다섯 단계로 정리 (11-04)

날짜: 2026-11-04 03:47 (저장소 생성)　출처: 저장소: rt-thread-bsp-hpm6750-fire-btb

개인이 유지보수하는 RT-Thread Studio 보드 지원 패키지로, 대상 보드는 야훠의 HPM6750 BTB 개발 보드이다. README의 파라미터 표는 매우 완비되어 있다: BSP 버전 1.0.19, MCU는 HPM6750IVM2(듀얼코어 32비트 RISC-V, 최대 816 MHz), RT-Thread Full / Latest(실측상 5.4.0에서 실행), 툴체인 RISC-V GCC 11.1.0, 콘솔은 UART0의 PY06/PY07(115200 8N1), 디버깅은 외장 JTAG 사용(본 보드는 SWD 미지원임을 명시).

설치 절차는 다섯 단계로 작성되었다: Releases에서 BSP ZIP을 다운로드하고, Studio의 SDK 관리자에서 리소스 패키지를 설치하고, 새 프로젝트 생성 시 HPM6750-FIRE-BTB를 선택하고, RT-Thread Settings에서 외부 장치를 체크하고, 컴파일 후 USB, DAPLink 또는 J-Link를 통해 다운로드한다. 이 방식은 HPMicro 공식 BSP 저장소들과 동일한 패턴이며, 다만 유지보수자가 칩 원제조사에서 개인으로 바뀌었을 뿐이다.

주목할 점은 이러한 저장소의 등장 빈도이다. 어제 HPMicro가 13분 만에 12개의 공식 BSP를 v1.13.0으로 푸시했다고 보도했는데, 오늘은 서드파티 보드에서도 동일한 프로젝트 구조로 보완하는 사례가 확인되었다 — BSP를 독립 저장소로 분리하고 Studio 프로젝트 기준으로 유지보수하는 이 관례는 이미 원제조사에서 커뮤니티로 확산되어 사실상 표준이 되었다.

4.2 Nuvoton N9H30의 커뮤니티 BSP: HMI 플랫폼의 ARM926EJ-S 노장 (11-03)

날짜: 2026-11-03 20:13 (푸시 시간)　출처: 저장소: sdk-bsp-nk-n9h30

Nuvoton N9H 시리즈의 커뮤니티 BSP로, 대상 칩은 N9H30F61IEC 또는 N9H30F63IEC이다. ARM926EJ-S 코어에 최대 300 MHz, 내장 TFT LCD 컨트롤러와 2D 그래픽 가속, 병렬 인터페이스는 1024x768, 24비트 컬러까지 구동 가능하며, 온칩 64 MB DDR, 패키지는 LQFP216 MCP이다.

N9H는 전형적인 인간-기계 인터페이스 플랫폼이다: 연산 성능은 높지 않지만 디스플레이와 외부 장치 인터페이스가 완비되어 있고 BOM이 저렴하여 산업용 HMI, 출입통제 및 가전 패널에 적합하다. RT-Thread의 이러한 MPU용 BSP는 줄곧 커뮤니티에서 유지보수해 왔으며, Nuvoton 공식 지원은 MCU 라인만큼 밀도가 높지 않기 때문에 구동되는 각 저장소는 선정에 참고 가치가 있다.

4.3 듀얼 MCU 소독 장치: M7은 운동, M3는 분사, 양쪽 모두 RT-Thread 구동 (11-03)

날짜: 2026-11-03 14:02 (푸시 시간)　출처: 저장소: GD32

“정순위사”라는 이름의 참가 프로젝트로, 교실, 복도, 공공 좌석과 같은 중소형 공공 구역을 위한 지능형 소독 이동 장치이다. 아키텍처는 듀얼 MCU: GD32H759IMT6(Cortex-M7)가 운동 주 제어를, STM32F103C8T6(Cortex-M3)가 분사 제어를 담당하며, 양쪽 모두 RT-Thread 4.1.1을 구동한다.

기능면은 4륜 차동 이동, 로봇팔 분무 분사, HX711 무게 측정을 통한 잔량 모니터링, 원격 제어, 예약 소독, 상태 보고 및 영상 회수를 포함한다. 저장소 구조는 대부분의 참가 프로젝트보다 정돈되어 있다: docs/ 아래에 하드웨어 설명, 통신 프로토콜, 코드 스타일 및 커밋 문서가 있고, scripts/ 아래에 Keil 빌드와 저장소 자체 점검 스크립트가 있으며, clang-format 설정도 포함되어 있다.

이러한 프로젝트의 관점은 기술적 난이도가 아니라 “M7 하나로 부족하여 M3 하나를 추가해 분담”하는 엔지니어링 선택이다: 운동 제어는 실시간성이 필요하고, 분사와 잔량 모니터링은 느린 변수이므로, 분리하면 두 칩 각각에 여유를 확보할 수 있고 통신 비용은 시리얼 프로토콜 하나로 충분하다.

5. 산업 응용

5.1 RV32IM 듀얼 발행 FPGA CPU가 RT-Thread Nano를 CoreMark 검증 체인에 연결 (11-03)

날짜: 2026-11-03 20:58 (푸시 시간)　출처: 저장소: RISC-V-CPU

Xilinx Kintex-7을 대상으로 하는 RV32IM 파이프라인 CPU 프로젝트로, 최근 푸시에서 실험 진입점이 업데이트되었다. CPU 측: RV32IM 명령어 세트, 머신 모드 CSR 및 타이머 인터럽트, 주 실행 채널에 정수 보조 채널을 추가하여 조건에 맞는 듀얼 명령 페어링을 지원하며, 프런트엔드에는 BTB, RAS 및 간접 점프 예측이, 메모리 액세스 측에는 듀얼 채널 포워딩, load/store 페어링 및 캐시 히트 바이패스가 있다.

소프트웨어 측이 바로 RT-Thread의 접점이다: RT-Thread Nano v3.1.5를 구동하며, UART 커맨드 라인과 CoreMark 1.0을 갖추고, 선택적 cmcrc16 사용자 정의 명령어가 있다. 대상 소자 xc7k325tffg900-2, Vivado 2023.2.

검증 데이터는 일반 아마추어 프로젝트보다 상세하다: timingopt15에 256행 DCache, 180 MHz 이상적 클럭에서 CoreMark 100회 동작 시뮬레이션을 수행하여, 31,445,017 CPU 사이클, 30,605,777 은퇴 명령어, CPI 1.027421, 최종 CRC는 0x988c, 7개 지향 회귀 통과. 부족한 점도 명시되어 있다: 180 MHz 배선 후 WNS는 -1.371 ns, WHS는 +0.013 ns로 타이밍이 수렴되지 않았고 아직 bitstream이 생성되지 않았으며, 100회 시뮬레이션은 기능과 CPI 비교에만 사용되며 보드 상 주파수는 구현 보고서를 기준으로 한다.

RT-Thread에게 이 소식의 의미는 Nano가 다시 한번 CPU 검증을 위한 최소 실행 가능 소프트웨어 스택으로 사용되었다는 점이다 — 베어메탈 테스트보다 인터럽트, 컨텍스트 스위치 및 타이머 경로의 문제를 더 잘 드러낼 수 있다.

6. 이번 호 동향과 요약

6.1 동향: 보안 측은 보고서에서 제안으로, 테스트 측은 목록에서 코드로

이번 24시간 동안 메인 저장소에 4건이 머지되었고(#11977, #11973, #11963, #11957), 신규 제안 4건(#11979, #11981, #11982, #11983)과 신규 결함 2건(#11980, #11984)이 접수되었습니다. 수량은 지난 기간과 같지만 구조가 달라졌습니다. 지난 기간은 적체 해소였고, 이번 기간은 신규 항목 개시에 더해 인프라 보강입니다.

첫 번째 축은 보안 측면의 신규 보고 2건으로, 형태가 매우 유사합니다. 둘 다 「설명자 또는 식별자에 대한 타입 검증 부재」입니다. timerfd는 fd가 timerfd인지 확인하지 않고, POSIX timer는 id가 범위를 벗어났는지 확인하지 않으며, 두 진입점 모두 사용자가 준 값을 커널 객체를 가리키는 진입점으로 그대로 사용합니다. 여기에 지난 기간의 그래픽 음수 오프셋(사용자가 준 오프셋의 부호 미검증)과 pipe(사용자 포인터 미검증)를 더하면 네 건은 동일한 부류로 묶을 수 있습니다. RT-Smart의 시스템 콜 계층이 「값 → 객체」 단계에서 통합 검증을 갖추지 못한 것입니다. 이런 결함의 수정 방식은 복잡하지 않으며, 어려운 점은 모든 진입점을 찾아내는 것입니다.

두 번째 축은 응답 속도가 빨라지고 있다는 점입니다. #11952는 10월 29일에 보고된 블록 디바이스 파티션 임의 쓰기이며, 11월 3일에 제안 #11981이 나왔습니다. 어제의 getaddrinfo 재작업(#11977)은 오늘 머지되었고, pipe 패치는 큐에서 계속 업데이트되고 있습니다. 보고, 제안, 메인테이너 재작업, 머지의 네 단계가 이제 며칠 안에 완료될 수 있으며, 이는 지난 기간의 「보고는 많고 패치는 적다」는 판단과 비교할 때 명확한 변화입니다. 대가는 리뷰 부담이 메인테이너 쪽으로 옮겨간 것입니다. 큐에는 여전히 다섯 건이 리뷰 중이며, 각 건마다 누군가 재현 절차를 이해해야 합니다.

세 번째 축은 Z 버전 테스트 목록이 코드 산출을 시작했다는 점입니다. 지난 기간에 보고된 #11972는 「Z 버전을 출시할 수 있는가」를 프레임워크별 QEMU 및 utest 목록으로 분해했으며, 이번 기간에는 이를 직접 인용한 제안 세 건이 등장했습니다. SPI의 펌웨어 내 가상 루프백 버스(#11979), I2C 프레임워크의 시뮬레이션 버스 utest(#11982), 그리고 자동 실행에 루프와 메모리 샘플링을 추가하는 #11983(#11963의 후속으로, 「한 번만 실행하면 메모리 누수를 발견할 수 없다」는 문제를 해결)입니다. 오늘 머지된 mailbox 테스트 케이스의 반복 실행 가능성과 함께, CI 측 테스트 기반은 「반복 가능, 관측 가능」 방향으로 나아가고 있습니다.

생태계 측면에서 반대 방향의 두 움직임 모두 주목할 만합니다. 한쪽은 칩 원제조사가 BSP 저장소를 스크립트화하여 일괄 배포하는 것이고(선지Xianji의 어제 12개 저장소 동일 버전), 다른 한쪽은 개인 개발자가 예화Yehuo HPM6750 BTB 같은 서드파티 보드용 Studio BSP를 보강하고 신탕Xintang N9H30 같은 구형 플랫폼용 커뮤니티 BSP를 보강하는 것입니다. 제조사가 보드 간 일관성을 보장하고 커뮤니티가 롱테일 커버리지를 채우며, 이 두 축이 합쳐져야 RT-Thread의 보드 레벨 생태계 전모가 됩니다.

활동 측면에서 우전Wuzhen 「신광Xinguang」은 이번 기간 가장 비중 있는 항목입니다. 국가급 플랫폼이 「이기종 융합 단말 측 지능 AIOS 기반」을 35개 추천 제품에 포함시켰으며, 내러티브가 「실시간 제어 기반」에서 「단말 측 지능 운영체제」로 전환되었고, 착점은 로봇의 「대뇌」와 「소뇌」 협동입니다. 같은 날 등장한 WTCC 연맹 기고문은 바로 이 내러티브를 구체적 시나리오에 적용한 버전입니다. 세 가지 Agent 방안, Arm Technology와의 분업, 구체 지능 중심점 등입니다. 홍보와 엔지니어링이 같은 선상에 있는 것은 기존 활동 기고문에서는 드문 일입니다.

6.2 한계 및 중복 제거 설명

포럼 club.rt-thread.org는 이번 기간에도 468을 반환하며 WAF 챌린지 페이지가 앞에 있어, 게시글 목록과 본문을 읽을 수 없었습니다. 커뮤니티 논의 측면의 정보 공백은 GitHub와 미디어 칼럼으로 보완했습니다. 공식 뉴스 API와 공식 웹사이트 뉴스 목록은 모두 6월 17일에 멈춰 있으며, 공식 웹사이트 뉴스 모듈 자체가 로드에 실패합니다.

GitHub 익명 API 한도(시간당 60회)가 수집 후반부에 소진되어, 조직 레벨 전체 푸시는 13개 중점 저장소의 Atom 커밋 피드 조회(packages, env, rtthread-nano, sdk, smart-build, UtestRunner, userapps 등)로 전환했으며, 모니터링 기간 내 커밋은 없었고 메인 저장소에만 푸시가 있었습니다. 결함 #11950은 제목과 요약만 확보했고 본문은 읽지 않았습니다. #11984와 #11980의 PoC 세부 내용은 모두 보고서 본문에서 인용했으며 독립 재현은 하지 않았고, 보고서에는 원문에 따라 한정 조건(QEMU 모델, 베이스라인 커밋, 영향 버전)을 명시했습니다.

Google News 중국어 측은 3일 내 5건이 검색되었고 2건을 수록했습니다(우전Wuzhen 「신광Xinguang」, WTCC 연맹 기고문). 광군절 프로모션 기고문은 홍보성이며 기간을 벗어나 미수록했고, 상하이Shanghai 오픈소스 대회 기고문은 지난 기간에 이미 보도했습니다. 영어 측 두组 쿼리는 제로 히트였습니다. HN Algolia 기간 내 5건은 모두 Thread 네트워킹 프로토콜, 채용 게시판, Mbed TLS 유지보수로 본 주제와 무관하여 제외했습니다.

중복 제거: 어제 보도한 #11977 제안은 이번 기간에 머지되었으므로 「진행」으로 처리하여 1건으로 기록했습니다. #11971, #11954, #11911, #11918, #11947, #11935는 지난 기간에 이미 나열되었으므로 이번 기간에는 상태 변화만 기록하고 항목으로 중복 생성하지 않았습니다. #11978은 어제 종결되었으므로 이번 기간에는 더 이상 다루지 않습니다.

부록: 출처核查表 및 출처 목록

출처核查表

출처 검증 결과
공식 뉴스 인터페이스(rt_org) 24시간 내 신규 없음, 최신 항목은 2026-06-17에 멈춤
공식 웹사이트 뉴스 목록 첫 페이지 뉴스 영역은 여전히 6월, 뉴스 모듈 로딩 실패
커뮤니티 포럼 전면 WAF 챌린지 페이지(HTTP 468), 목록과 본문 읽기 불가
메인 저장소 commits 모니터링 기간 내 4건, 11-03 09:04 ~ 13:11에 집중
메인 저장소 PR 머지 4건(#11977, #11973, #11963, #11957), 신규 4건(#11979, #11981, #11982, #11983)
메인 저장소 Issue 신규 2건(#11980, #11984), 모두 RT-Smart 보안 문제
메인 저장소 releases 및 tags 신규 없음, 최신은 여전히 v5.3.0(2026-09-10)
RT-Thread org 주요 저장소 13개 저장소 Atom 검증, 모니터링 기간 내 모두 커밋 없음
GitHub 저장소 검색 RT-Thread 관련 저장소 2개 신규(HPM6750 BTB BSP, N9H30 BSP), topic 일치 3개
Google News 중국어 3일 내 5건, 수집 2건(우전 신광, WTCC 연맹 기사)
Google News 영어 일치 없음
HN Algolia 5건 모두 Thread 프로토콜 또는 채용 내용, 본 주제 아님
EE Times China 공식 칼럼 11-03 우전 기사 1건, 수집 완료
세계인터넷대회 공식 웹사이트 / 국가인터넷정보판공실 박람회 개막 및 35개 「신광」 기준, 공식 기사 대조용

전체 출처 목록