Blog

이번 주 LWN.net 위클리 에디션 주요 내용이다. Debian이 LLM 사용 정책을 두고 8개 선택지를 놓고 투표에 들어갔고, 커널 7.2가 릴리스되면서 역대 두 번째로 많은 커밋과 사상 최다 신규 기여자 기록이 함께 나왔다. Fedora 45는 AF_ALG를 제한하는 방향으로 가고, Arm은 72PB로도 모자랄 때를 대비한 128비트 페이지 테이블을 준비 중이다. 여기에 BPF 테스트 인프라 현황, 부트스트랩 가능한 빌드, 파이썬 pathlib 이야기까지 다룬다.

• Debian weighs eight options in vote on LLM usage — 전면 금지부터 명시적 허용까지, 8개 제안이 올라간 Debian 총회 결의
• Representing Python paths using pathlib — 파일 경로를 문자열로 다루는 관행을 그만두자는 PyCon US 2026 발표
• Bootstrappable builds: how and why — 256바이트 씨앗에서 현대 리눅스 유저스페이스 전체를 빌드하기
• Fedora prepares for the end of AF_ALG — 커널 Crypto API의 사용자 공간 인터페이스를 단계적으로 걷어내는 절차
• 128-Bit page tables for Arm — PTE를 128비트로 늘리는 패치 시리즈, 그런데 누가 이득을 보는가
• BPF, continuous testing, and stable kernels — BPF CI에 들어온 LLM 리뷰와 stable 커널 셀프테스트 현황
• Development statistics for the 7.2 kernel — 커밋 16,418개, 기여자 2,652명, 신규 기여자 613명의 개발 사이클
• 짧은 소식: AMD 메모리 컨트롤러 bank swizzle을 이용한 메모리 보호 우회 PoC, 커널 7.2 릴리스, 보안 수정 33건이 들어간 rsync 3.5.0, Go 1.27, Firefox 154, Mark Wielaard 공로상

Debian, LLM 사용 정책을 8개 선택지로 투표에 부치다

Debian 프로젝트가 LLM을 이용한 기여를 어떻게 다룰지 총회 결의(GR, general resolution) 투표에 들어갔다. 7월 말 Matthias Geiger가 “LLM이나 생성형 AI 도구로 만든 기여를 일절 금지하자”는 제안을 사회 계약(Social Contract) 개정안으로 올린 것이 발단이었고, 그 뒤로 대안 제안이 쏟아져 최종 투표지에는 8개 선택지에 “위 어느 것도 아님”까지 올라갔다.

Debian은 이 주제를 여러 해 미뤄왔다. 2024년 Tiago Bortoletto Vaz가 의견을 모았다가 “합의와 거리가 멀다”고 판단해 GR을 포기했고, 2026년 2월 Lucas Nussbaum이 AI 보조 기여를 허용하자고 제안했을 때도 논의는 원만했지만 GR까지는 가지 않았다. Fedora와 Gentoo가 이미 정책을 정리한 것과 대비된다.

Spreemann의 안은 GCC 프로젝트와 rust-lang/rust의 AI 정책을 참고했다. Debian은 Condorcet 방식을 쓰므로 투표자는 하나만 고르는 대신 선호 순서를 매긴다. Geiger의 안만 사회 계약을 건드리기 때문에 3:1 다수를 요구한다.

저작권, 품질, 기후

논쟁의 축은 셋이었다. 저작권 쪽에서 Geiger는 LLM 출력물의 저작권 상태가 “거대한 불확실성”이며 학습 데이터에서 오는 라이선스 의무를 100% 배제할 수 없으니 DFSG를 만족할 수 없다고 봤다. Russ Allbery는 커널을 포함한 상당수 상위 프로젝트가 이미 “이 문제들을 무시하기로 했다”며 배는 떠났다고 응수했고, Ted Ts’o는 Stack Overflow에서 예제를 찾아 코드를 쓰는 사람보다 LLM 출력이 특별히 더 불확실하지 않다고 주장했다.

품질 논쟁에서 Bécue는 자신도 LLM을 매일 쓰지만 “도구가 자동화되고 빨라질수록 안전망이 더 필요하다”는 입장이었다. Haber가 “어차피 형편없는 결과물을 낼 사람이라면 보조를 받아서 내도 되지 않느냐”고 하자, Bécue는 그러면 “10배 많은 쓰레기가 10배 빨리” 들어와 프로젝트에 부담이 된다고 반박했다. 반대로 Matthias Urlichs는 LLM에 패키징을 맡긴 뒤 자기 결과물이 훨씬 나아졌다며, 재현 가능 빌드 실패 추적이나 ITP 버그 필터링, NEW 큐 스캔, Rust/Go/Python/Node 패키지 최신화처럼 지루한 작업에 즉시 쓸 데가 있다고 했다.

“LLM에 의존하면 코딩 능력이 퇴화한다”는 우려에 대해 Ts’o는 계산기가 암산 능력을, 컴파일러가 어셈블리 실력을 줄인 것과 같은 이야기라고 봤다. Adrian Bunk은 debhelper를 예로 들어 이미 Debian 개발자 사이에 패키지 빌드 내부 지식이 부족해 문제를 디버깅하지 못하는 일이 흔하다고 지적했는데, 둘 다 이를 LLM 사용에 찬성하는 근거로 제시했다.

환경 영향은 논의를 지배한 주제였다. Bas Wijnen은 LLM이 생태계를 파괴한다는 데 동의하면서도 그것이 결정적 문제는 아니라고 결론짓는 태도를 이해할 수 없다고 했고, Nussbaum은 LLM만 콕 집는 것은 “AI 때리기”로 들린다며 패키지 빌드 축소나 DebConf 여행으로 인한 CO2 감축 같은 다른 선택지를 들었다. Ts’o가 환경 논거를 “이미 다른 이유로 내린 결론을 정당화하는 핑계”라고 하자 Didier ‘OdyX’ Raboud는 그 주장이 “잘못된 판단이거나 악의적”이라며, 문제는 질의 한 건당 영향이 아니라 AI 산업 전체가 전력·수자원 인프라에 가하는 부담이라고 응수했다.

투표는 8월 15일 시작해 8월 28일까지 진행된다. 기사 작성 시점에 유권자 1,000명 이상 중 130여 명이 투표했다. LWN은 2014년과 2019년의 init 시스템 논쟁을 예로 들며, 그때도 감정이 격했지만 결과적으로 프로젝트에 큰 해를 끼치지 않았다는 점을 상기시킨다.

pathlib로 파이썬 경로 다루기

PyCon US 2026에서 Trey Hunner는 파이썬 개발자들이 파일 경로를 문자열로 표현하는 것을 그만두게 하는 것이 발표의 목표라고 밝혔다. 문자열 경로는 지금도 동작하고 앞으로도 동작하겠지만, “대체로” 동작한다는 점이 문제라는 것이다.

첫 번째 문제는 표준 라이브러리의 경로 함수들이 os, os.path, glob, shutil 네 모듈에 흩어져 있다는 점이다. Hunner는 os와 sys를 파이썬 표준 라이브러리의 “잡동사니 서랍” 두 개라고 불렀는데, os에만 200개 가까운 함수가 있어 경로 관련 함수를 찾기가 쉽지 않다.

Django 프로젝트에서 형제 templates 디렉터리 경로를 구하는 코드를 세 가지로 비교했다.

# os.path 버전
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
TEMPLATES_DIR = os.path.join(BASE_DIR, "templates")

# 문자열 조작 버전 - 윈도우 경로 구분자에서 깨진다
BASE_DIR = os.path.abspath(__file__).rsplit("/", maxsplit=2)[0]
TEMPLATES_DIR = BASE_DIR + "/templates"

# os.sep을 써도 가독성이 나아지지 않는다
BASE_DIR = os.path.abspath(__file__).rsplit(os.sep, maxsplit=2)[0]
TEMPLATES_DIR = BASE_DIR + os.sep + "templates"

os.path 버전의 첫 줄은 오른쪽에서 왼쪽으로 읽어야 의미가 잡힌다. Path는 같은 동작을 체이닝으로 표현한다.

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent
TEMPLATES_DIR = BASE_DIR / "templates"

두 번째 문제로 Hunner는 “stringly typed code”를 들었다. 더 적합한 타입이 있는데도 데이터를 문자열로 넘기는 코드다. 날짜를 "2025-09-25" 문자열로 두고 target[:4] == "2025"로 비교하는 코드는 동작하지만 그 문자열이 실제로 유효한 날짜라는 보장이 없다. datetime.strptime()을 거치면 형식이 틀렸을 때 ValueError가 나므로 검증이 함께 따라온다. 경로도 마찬가지라는 논리다. 타입 힌트를 쓰는 코드라면 타입 체커가 문자열과 경로가 뒤섞인 지점을 잡아준다는 이점도 붙는다.

Path()는 운영체제에 따라 PosixPath 또는 WindowsPath를 돌려주는데, 둘은 같은 연산을 지원하고 경로 정규화 방식만 다르므로 사용자가 구분할 필요는 없다. 전체 속성·메서드는 70개가 넘지만 실제로 자주 쓰는 것은 메서드 20여 개, 속성 6개, 클래스 메서드 2개(Path.cwd(), Path.home()) 정도다.

도입 초기에는 open(str(path), ...)처럼 문자열로 되돌려야 하는 경우가 많았지만, 지금은 “파일 경로를 받는 파이썬 유틸리티는 거의 전부” Path 객체를 받는다. os.path.join()이나 os.mkdir()처럼 문자열 경로를 전제로 만들어진 함수들도 Path를 그대로 받으므로, 레거시 코드를 한 번에 고치지 않아도 점진적 전환이 가능하다. Django, pandas, pytest 같은 서드파티 패키지도 대부분 지원한다.

Bootstrappable builds: 씨앗 256바이트에서 시작하기

FOSSY 2026에서 Timothy Sample이 부트스트랩 가능한 빌드(bootstrappable build)를 발표했다. 아주 작은 프로그램이 조금 더 큰 프로그램을 빌드하고, 그것이 또 다음 것을 빌드하는 식으로 현대 리눅스 유저스페이스 전체를 작은 씨앗에서 만들어내는 것이 목표다. 결과물은 출처가 완전히 파악된 코드가 된다.

Guix와 Nix는 모든 소프트웨어를 파생 그래프(derivation graph)로 표현한다. 파이썬 프로그램을 돌리려면 파이썬이 필요하고, 파이썬은 C 프로그램이므로 C 컴파일러가 필요하고, 그 C 컴파일러도 어떤 언어로 쓰였으니 그 언어의 컴파일러가 필요하다. “내 컴파일러의 컴파일러의 컴파일러는 누가 컴파일했고 어디서 멈추는가”라는 질문이 여기서 나온다. Debian에서는 누군가 저장소에 올린 C 컴파일러 바이너리에서 멈추고, Guix도 원래는 250MB짜리 정적 링크 GNU 유저스페이스 블롭에서 멈췄다.

재현 가능 빌드(reproducible build)와 목적이 겹쳐 보이지만 막는 실패 유형이 다르다. 재현 가능 빌드는 바이너리를 준 사람이 거짓말을 하거나 착각한 경우를 잡는다. 부트스트랩 가능한 빌드는 Ken Thompson이 튜링상 수상 강연 “Reflections on Trusting Trust”에서 제시한 유형의 공격을 막는다. C 컴파일러 소스에서 "\n"의 정의를 찾으면 "\n"이라는 순환 정의만 나오고, 실제로 ASCII 10으로 바꾸는 지식은 컴파일러 바이너리에 들어있다. 같은 방식으로 login 프로그램용 백도어도 숨길 수 있다.

이것이 이론상의 이야기만은 아니다. Sample은 발표 준비 중 알게 된 논문(“Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation”)을 소개했는데, 연구자들은 NixOS의 strip 프로그램에 백도어를 심었다. strip은 시스템에서 빌드되는 거의 모든 바이너리에 실행되므로, 소스 코드 분석으로는 전혀 보이지 않는 방식으로 시스템 전체 프로그램에 백도어를 넣을 수 있었다.

고고학적 발굴과 전용 도구

가장 좋은 방법은 사전 예방이다. 컴파일러가 자기 자신으로 빌드되기 전에는 보통 다른 언어로 작성돼 있는데, 그 코드를 보존하고 함께 유지보수하면 된다. GNU Guile은 부트스트랩용 C 구현을 아직 유지하고 있고, GNU Make는 makefile 외에 make가 없을 때 쓰는 셸 스크립트도 함께 둔다.

가장 성공적인 사례는 둘을 섞는다. Rust는 C++로 작성된 mrustc로 1.54나 1.56을 빌드한 뒤 현재 버전(1.97)까지 거의 모든 중간 버전을 차례로 빌드한다. Guix 시스템을 재빌드할 때 “이 Rust 컴파일 체인에 걸리면 정말 우울해진다”고 했고, 청중 한 명은 Arm 노트북에서 사흘이 걸렸다고 답했다. mrustc가 이제 Rust 1.90까지 빌드할 수 있지만 아직 Guix에 통합되지는 않았다.

Guix의 씨앗은 이제 250MB 블롭이 아니라 256바이트 남짓의 hex0 프로그램이다. 16진수 텍스트를 해당 바이트의 바이너리로 바꿔주는 도구로, 여기서 hex1, hex2를 거쳐 GCC 2, GCC 4, 현대 GCC와 Guile까지 올라간다. 다만 Sample은 아직 정적 링크된 Guile을 여러 곳에서 쓰고 있다는 점을 “명백한 반칙”이라고 인정했다.

남은 한계도 분명하다. Guix는 커널의 존재를 전제하며 유저스페이스만 부트스트랩한다. 관련 프로젝트인 live-bootstrap은 Fiwix 커널로 커널 부트스트랩까지 탐색하고 configure 같은 기계 생성 파일도 다시 만들어내지만, 그 대가로 절차가 182단계에 이를 만큼 복잡하다. 그마저도 Rust나 Go는 빠진 “현대 GNU/리눅스 기본 시스템”까지의 경로다.

Fedora 45, AF_ALG 제한을 준비하다

커널 Crypto API의 사용자 공간 인터페이스인 AF_ALG는 Copy Fail을 비롯한 최근의 고위험 보안 문제들과 엮여 있고, 올해 초 deprecated로 표시됐다. Eric Biggers를 비롯한 커널 개발자들이 제거 작업을 진행 중인 가운데, Fedora가 다음 릴리스에서 사용을 제한해 남은 사용자들이 미리 대비하도록 하려 한다.

AF_ALG는 2010년 Herbert Xu가 하드웨어 암호 가속기를 사용자 공간에서 쓰게 할 목적으로 넣었다. 당시에도 Christoph Hellwig 등은 “커널 소비자를 위해 반드시 필요한 경우가 아니면 커널 공간에 있을 이유가 없는 계산 집약적 코드”라며 반대했고, CPU가 암호화용 명령어를 갖춰가는 중이라 사용자 공간 API의 효용이 더 줄어든다고 봤다. 결과적으로 이들의 예측은 맞았지만 이유는 달랐다. 제거의 실제 동인은 성능이 아니라 취약점이다. Biggers는 deprecation 패치에서 이렇게 적었다.

AF_ALG는 거의 완전히 불필요하면서도, 현대적인 취약점 발견 도구를 버텨내지 못하는 거대한 공격 표면을 노출한다. […] 이것은 지속 가능하지 않으며, LLM이 취약점 유입 속도를 가속하면서 더욱 그렇다. 실제로 이 인터페이스를 쓰는 소수의 프로그램에 비해 여기 들어가는 노력이 지나치게 크고, 그 프로그램들도 사용자 공간 코드를 쓰는 편이 낫다.

Fedora 45의 “Disable in Kernel Crypto Userspace API (Phase 1)” 변경 제안은 Justin Forbes와 Peter Robinson이 올렸고 FESCo가 찬성 5, 반대 0으로 승인했다. 근거가 되는 상위 패치는 Biggers가 6월 22일 올려 7월 5일 Xu가 적용한 것으로, af_alg_restrict sysctl 노브를 추가한다.

기본값 1에서는 iwd, bluez, iproute2 같은 비특권 프로세스용 알고리즘 허용 목록이 적용되고, 특권 프로세스에는 더 긴 목록이 적용된다. Fedora에서 파악된 사용자는 cryptsetup, iwd, dracut이 쓰는 libkcapi 정도이며 제안서는 이들이 영향을 받지 않는다고 본다. 이번 단계의 목적은 파악되지 않은 제3자 패키지를 미리 찾아내는 데 있다.

Fedora devel 메일링 리스트 논의에서 Ondrej Kozina는 대체재 없이 끄는 것에 반대하며 cryptsetup이 일부 암호를 쓰려면 CAP_SYS_ADMIN이 필요해지고 TrueCrypt/VeraCrypt 컨테이너 지원이 제한된다고 지적했다. Robinson은 그 사용 사례 상당수가 Fedora 자체에는 없다고 답하며, AF_ALG는 “우리가 원하든 아니든” 사라지므로 릴리스 경계에서 미리 대비하게 하려는 것이라고 설명했다. Fedora 45는 7.2 커널로 출시된 뒤 7.3으로 올라가는데, 릴리스 도중에 갑자기 깨지는 상황을 피하겠다는 것이다.

실사용자 영향도 이미 드러났다. Barry Scott은 라즈베리파이 4의 LUKS2 볼트를 “인터넷의 조언에 따라” 설정했는데 그 암호가 제한 대상이었다. Robinson은 “인터넷이 전적으로 옳지는 않았다”며 언젠가는 옮겨야 하지만 Fedora 45 때문은 아니라고 답했다. cryptsetup 쪽은 2.8.7 릴리스 노트에서 이미 deprecation을 알리며, 사용자 공간 암호 라이브러리에 없는 Serpent와 Twofish 같은 알고리즘에서 호환성 문제가 생길 수 있다고 경고했다.

Arm 128비트 페이지 테이블

페이지 테이블 엔트리(PTE)의 크기는 프로세서가 접근할 수 있는 물리 메모리 양을 직접 제한한다. 32비트 시절 한계는 4GB였고, 64비트로 넘어오며 Arm은 56비트를 써서 72PB까지 접근할 수 있게 됐다. 그런데 Anshuman Khandual의 패치 세트는 PTE를 128비트로 늘린다. LWN이 던지는 질문은 누가 이 기능으로 이득을 보느냐다.

비용은 명확하다. PTE 크기가 두 배가 되면 페이지 테이블 크기도 두 배가 되고, 페이지 하나에 담기는 PTE 수가 절반이 되므로 huge page 크기가 줄어든다.

PUD 레벨이 4분의 1로 줄어드는 것은 그 페이지에서 생략되는 페이지 테이블 레벨이 두 단계이기 때문이다. multi-size THP로 병합 가능한 크기도 비슷한 비율로 줄어드는데, huge page 성능에 크게 의존하는 워크로드에는 뼈아플 수 있다.

그럼 얻는 것은 무엇인가. 새 포맷의 주소 필드는 비트 12~55로 44비트에 불과해, 오프셋 12비트를 더해도 56비트다. 물리 주소 범위 확장이 이번 변경의 직접적 목표는 아니라는 뜻이다. 다만 최상위 주소 비트 위로 예약 비트가 35개 남아 있어 향후 확장 여지는 넉넉하다. 실제로 얻는 것은 소프트웨어 전용 비트가 5개에서 10개로 늘어난 것, 그리고 SKL(skip level) 필드다.

SKL은 비트 109~110에 있으며 모든 페이지 테이블 레벨에 존재한다. 기존에는 huge page일 때만 마지막 단계의 레벨이 생략됐지만, SKL은 이 메커니즘을 일반화해 조회 과정의 다음 단계가 최종 단계가 아닌 중간 레벨이더라도 huge page임을 표시할 수 있다. 페이지 테이블 자체를 huge page로 두어 주소 변환을 빠르게 하고 TLB 사용을 줄이는 길이 열린다.

READ_ONCE()가 128비트를 못 다루는 문제

커널 쪽 변경은 대부분 필드와 비트 위치를 기술하는 매크로 정의라 크지 않다. 가장 성가신 부분은 페이지 테이블 조작이다. 각 레벨의 엔트리를 읽을 때는 엔트리 전체가 일관되도록 원자적으로 읽어야 하는데, 지금은 READ_ONCE()가 그 역할을 한다. 패치 시리즈는 ptval_get()/ptval_set() 한 쌍을 새로 만들어 기본값은 READ_ONCE()/WRITE_ONCE()로 두되 아키텍처가 재정의할 수 있게 하고, 128비트 PTE 빌드에서는 ldp/stp 명령으로 구현한다.

기사 본문의 “Arm CPU에 128비트 원자적 연산이 없다”는 설명은 댓글에서 곧바로 지적을 받았다. Arm에는 casp가 있고 ldp/stp도 쓰이는데 무슨 뜻이냐는 질문에 Jonathan Corbet은 “READ_ONCE()가 그것들과 함께 동작하지 않는다는 뜻”이라고 답했다. pm215가 인용한 패치 2의 커밋 메시지가 더 정확하다.

ldp/stp는 FEAT_LSE128이 지원될 때만 single copy atomic이다(FEAT_D128을 지원하면 필수다). 현재 128비트 페이지 테이블은 컴파일 타임 결정이므로 그 설정에서만 READ_ONCE()/WRITE_ONCE()가 128비트를 허용하게 확장할 수도 있었다. 하지만 그것은 범용 API라 다른 사용자가 128비트를 기대하고 들어왔다가 다른 설정에서 컴파일에 실패할 수 있다는 우려가 있었다. 더 나쁜 것은, D128을 부팅 시점 옵션으로 만드는 것을 검토 중인데 그렇게 되면 READ_ONCE()가 컴파일 타임에 항상 128비트를 허용해야 하고 런타임에 조용히 tearing이 날 수 있다.

패치 시리즈 저자 중 한 명인 Ryan Roberts는 기사의 주소 폭 설명도 정정했다. Arm의 64비트 PTE 포맷은 최대 물리 주소 폭이 52비트이고 128비트 포맷이 이를 56비트로 확장한다는 것이다. 다만 초기 시리즈는 선택한 PTE 포맷과 무관하게 52비트 제한을 유지한다고 덧붙였다.

배포판 입장에서 까다로운 제약도 남아 있다. 현재 구현에서는 커널을 128비트 PTE용으로 따로 빌드해야 하고, 그렇게 빌드한 커널은 해당 PTE 크기를 지원하지 않는 CPU에서 부팅하지 못한다. 배포판은 빌드하는 커널 수를 최소로 유지할 강한 동기가 있으므로, 부팅 시점 코드 패칭이 상당히 들어가기 전에는 이 기능을 켜지 않을 가능성이 높다.

BPF CI와 stable 커널 테스트

2026 LSFMM+BPF 서밋의 BPF 트랙 마지막 두 세션은 테스트가 주제였다. Ihor Solodrai는 BPF CI에 무엇이 달라졌는지를, Shung-Hsi Yu는 stable 커널의 BPF 변경을 어떻게 더 철저히 테스트할지를 발표했다.

Solodrai가 먼저 꺼낸 것은 LLM 리뷰였다. Sashiko가 가능성을 보여주기 전부터 살펴보던 아이디어였고, 결국 독자 구현을 만들었다. Chris Mason의 리뷰 프롬프트, 시맨틱 검색, Lore 메일링 리스트 아카이브, 커널 소스 트리를 조합해 BPF 변경에 대한 리뷰를 생성한다. GitHub 미러에 풀 리퀘스트를 올리면 GitHub Actions가 돌아 잠시 후 리뷰 코멘트가 달린다. Sashiko 쪽이 전담 개발팀을 두고 있어 더 강력하므로 BPF CI의 LLM 리뷰를 끌까 고민했지만, LLM 제공자가 달라(Sashiko는 Google, 이쪽은 Anthropic) 리뷰의 결이 다르다는 이유로 당분간 유지하기로 했다. 논의에서도 BPF 개발자들은 독립적인 리뷰가 여러 개 있는 편이 미묘한 문제를 잡는 데 도움이 된다고 봤다.

컴파일러 버전 업그레이드는 언급할 가치도 없을 만큼 사소했으면 좋겠지만 실제로는 상당한 작업이었다고 한다. Solodrai의 불만은 다른 데 있었다. 예전에는 CI 실패가 대개 자기 잘못이었는데 이제는 Anthropic, GitHub, Ubuntu 저장소, 심지어 git.kernel.org까지 외부 서비스가 내려앉는 것이 원인이라는 것이다. “요즘 소프트웨어는 덜 안정적인데 왜 그런지 모르겠다. 이 회사들에 영향력이 있는 분은 좀 더 안정적으로 만들어 달라”고 했다.

stable 트리에서 셀프테스트 돌리기

Yu가 지적한 문제는 AUTOSEL이 BPF 셀프테스트를 돌리지 않는다는 점이다. 백포트 여부를 판단할 때 패치가 깨끗하게 적용되는지는 보지만, 그것만으로는 검증기가 의도대로 계속 동작한다고 확신할 수 없다. 작년에 이를 고치겠다고 제안했고 Solodrai가 기존 셀프테스트 접근 권한을 제공해, 지금은 여러 stable 트리를 대상으로 셀프테스트를 돌리고 있다.

실패 대부분은 노이즈였다. 백포트된 코드에 맞지 않는 테스트가 원인인데, 예컨대 6.6 커널에 없는 헬퍼를 쓰는 테스트가 추가돼 되돌린 사례가 세션 직전에 있었다. 좀 더 미묘한 것도 있다. 네트워크 MTU를 10바이트로 설정하는 백포트된 테스트가 있었는데, 네트워크 네임스페이스 안에서는 문제없지만 충분히 오래된 커널에서는 루트 네임스페이스에 영향을 줘 연쇄적으로 실패를 일으켰다. 진짜 성과도 있었다. struct_ops 구조체의 포인터가 유효하다고 잘못 가정해 생긴 커널 패닉을 찾아냈다.

Yu는 stable 트리 3개를 테스트하며 한 달에 한 번쯤 무언가 깨지는 것을 본다고 답했다. 그가 꼽은 가장 확실한 방법은 변경을 백포트할 때 테스트도 함께 백포트하는 것이다. 테스트는 매일 아침 자동으로 돌아 그가 일어나면 결과를 볼 수 있게 해두었고, Greg Kroah-Hartman이 stable 릴리스 후보를 내기 전에 전체 실행이 끝나는 편이다. Daniel Borkmann이 메인 BPF CI에 통합할 여지를 물었지만, Yu는 자신의 방식이 메일링 리스트를 감시하는 대신 실행 시점의 stable 트리를 그냥 가져오는 방식이라 분리해두는 편이 유용하다고 봤다.

커널 7.2 개발 통계

리누스 토발즈가 8월 17일 7.2 커널을 릴리스했다. 마지막 주에 들어온 수정이 “바라던 것보다 많았다”고 했는데, 실제로 7.2는 커널 역사상 가장 바쁜 개발 사이클 중 하나로 60만 줄 가까운 코드가 추가됐다.

커밋 수로 역대 1위는 여전히 6.7이지만, 그때는 bcachefs 개발 히스토리 병합이 대부분을 차지했다. 7.2의 물량은 훨씬 넓게 퍼져 있다. 커밋 수 1위는 드라이버 서브시스템 정리 작업을 한 Uwe Kleine-König(151개), 2위는 아키텍처·드라이버·네트워킹·crypto 등 전방위로 LLM이 작성한 버그 수정을 낸 Rosen Penev(146개)였다. 변경 줄 수 1위 Matthew Stewart(83,587줄)는 기계 생성 amdgpu 헤더 파일을 대량 추가하는 오랜 전통을 따랐고, Miguel Ojeda는 Rust zerocopy 크레이트를 커널 소스로 들여왔다.

고용주별로는 커밋 수 기준 (Unknown)이 16.7%로 1위, 그 뒤로 Intel 9.2%, Google 7.3%, Red Hat 5.3%, AMD 5.0% 순이다. 줄 수로는 AMD가 22.4%로 압도적이다. LWN이 이번에 가장 의미 있다고 본 변화는 소속 불명 개발자 비중의 증가인데, 신규 개발자 유입 급증과 무관하지 않다.

신규 기여자와 도구

가장 활발한 신규 개발자 Bryam Vargas는 input, NVMe, F2FS, AppArmor, Landlock, SELinux, NTFS, WiFi, ATA, SCSI, 네트워킹, Ceph, Thunderbolt 등에 걸쳐 43개 커밋을 냈다. LWN은 숙련된 커널 개발자라도 한 사이클에 이만큼 많은 서브시스템을 깊이 건드리기는 어렵다고 지적하면서, 처음 보는 개발자가 그렇게 한 것은 “잘 봐줘야 놀라운 일”이라고 적었다. Vargas의 패치에는 Assisted-by 태그가 없어 LLM 도움 없이 한 것으로 믿을 수밖에 없다는 문장이 이어진다.

Assisted-by 태그가 달린 커밋은 1,111개로 7.1의 301개에서 크게 늘었지만, LWN은 실제 LLM 보조 패치 수가 이보다 훨씬 많을 수밖에 없다고 본다. 많은 개발자가 규칙을 모르거나 태그를 달지 않고, 메인테이너는 LLM 사용 여부를 잘 묻지 않으며, 최소한 한 명의 메인테이너는 패치를 적용할 때 그 태그를 적극적으로 제거한다. 리뷰 쪽에서는 Sashiko 리뷰 시스템을 Reported-by로 명시한 패치가 252개, 체인지로그에서 Sashiko를 언급한 커밋이 568개다.

가장 흥미로운 숫자는 Fixes 태그다. 7.2에는 이전 커밋이 만든 버그를 고친다고 표시한 커밋이 4,830개 있다. 여러 릴리스 동안 대체로 평평했던 이 수치가 최근 급격히 올라갔는데, LWN은 이것이 많은 사람이 LLM으로 기존 소프트웨어의 버그를 찾기 시작했을 때 벌어지는 일이라고 해석한다. 버그 수가 무한할 수는 없으니 언젠가 이 곡선은 꺾여야 한다. 만약 꺾이지 않는다면, LLM 덕분에 예전 같으면 패치를 만들지 못했을 사람들이 패치를 만들고 있다는 뜻이고, 그중 상당수는 자기 패치가 무엇을 하는지 온전히 이해하지 못한다는 뜻이 된다. “아무도 제대로 이해한 적 없지만 앞으로 몇 년간 유지보수해야 하는 코드 더미”를 쌓고 있을 가능성을 LWN은 경계한다.

7.3용으로 linux-next에 대기 중인 non-merge 체인지셋은 이미 1만 4천 개에 육박하고 그중 1,100개 이상이 Assisted-by 태그를 달고 있다. 최근의 높은 활동 수준이 곧 끝날 조짐은 없다.

짧은 소식

• AMD 메모리 컨트롤러로 메모리 보호 우회: Christopher Domas가 AMD 메모리 컨트롤러의 bank swizzle 모드를 이용해 메모리 보호를 우회하고 임의 데이터를 읽고 쓰는 PoC를 공개했다. CPU 마이크로코드 정의와 플랫폼 보안 프로세서(PSP)에 속한 메모리까지 대상이 되며, 커널 수준에서 도는 코드가 프로세서 명령어의 의미를 직접 조작할 수 있어 메모리 암호화나 VM 격리 같은 방어를 무력화할 여지가 있다. bank swizzle 자체는 AMD 매뉴얼에 문서화된 동작이지만, 호스트를 죽이지 않고 불변이어야 할 펌웨어를 다시 쓸 수 있다는 점은 설계의 의도치 않은 부작용으로 보인다. 활성화에 커널 권한이 필요해 당장 급한 문제는 아니다.
• 커널 7.2 릴리스: 8월 16일 릴리스됐다. 주요 기능으로 bpf() 시스템 콜의 공통 속성 지원, CPU 스케줄러의 캐시 인지 로드 밸런싱, Btrfs의 large folio 지원, swap 서브시스템 개선, Landlock 개선, 인라인 암호화 하드웨어를 쓰는 블록 장치를 위한 dm-inlinecrypt 타깃 등이 들어갔다. 안정 업데이트로는 7.1.9, 6.18.45, 6.12.104, 6.6.152, 6.1.183, 5.15.216, 5.10.265가 8월 19일 나왔다.
• rsync 3.5.0: 보안 수정 33건이 한꺼번에 들어갔다. 경로 처리와 데몬 프로토콜을 집중 감사하고 데몬 프로토콜 퍼징을 병행한 결과이며, CVE ID는 VulnCheck가 할당했다. 각 권고에 “도입된 버전” 범위가 함께 붙는데 상당수는 “3.5.0 이전 전부”보다 훨씬 좁다. 모든 수정에 수정 전 트리에서 실패하는 회귀 테스트가 함께 들어갔다.
• Go 1.27: ML-DSA 포스트 양자 알고리즘 지원, 새 JSON 처리 패키지, 언어 업데이트 등이 포함됐다.
• Firefox 154.0: 로컬 네트워크 접근 보호를 WebSocket 연결까지 확대했고, 쿠키·데이터 삭제를 사이트별로 더 유연하게 설정할 수 있게 됐다.
• 그 외 릴리스: 바이너리 데이터 편집기 GNU poke 5.0, 페디버스 클라이언트 Tuba 0.11(Mastodon 컬렉션·인용 지원, 안드로이드 빌드 추가)이 나왔다. Python 패키징 협의회(PPC) 초대 선거는 5석에 17명이 출마했고 9월 1일부터 15일까지 투표한다.
• Mark J. Wielaard 공로상: Software Freedom Conservancy가 제2회 Distinguished Service Award in Software Freedom 수상자로 Mark J. Wielaard를 선정했다. 가장 오래된 FOSS 협업·개발 인프라 호스팅 사이트인 Sourceware를 유지보수하고 있으며, DWARF 디버깅 표준 위원회 위원이자 Valgrind와 elfutils의 메인테이너다.
• 금주의 커널 인용: Greg Kroah-Hartman이 LLM에 대해 “천 개의 태양만큼 뜨거운 열정으로 LLM이 나와 대부분의 오픈소스 프로젝트에 끼치는 고통을 증오하지만, 그것들이 엄청난 비용을 들여 3분의 1은 거짓말을 하면서도 진짜 보안 버그를 찾아 고치는 퍼지 도구를 만들어냈다는 사실을 무시할 수는 없다”고 적었다. 자신이 유지보수하는 일부 영역에서는 사용을 금지했지만, 퍼저와 마찬가지로 우리가 활용할 수 있는 도구라는 입장이다.

이번 주 핵심 요약

• LLM은 더 이상 개별 기사의 소재가 아니라 이번 에디션 전체를 관통하는 주제다. Debian은 정책을 투표에 부쳤고, 7.2 통계는 Fixes 태그 급증과 신규 기여자 613명이라는 형태로 그 효과를 수치로 보여줬으며, BPF CI는 LLM 리뷰를 상시 운영 중이고, AF_ALG 제거의 명분에도 “LLM이 취약점 유입 속도를 가속했다”는 문장이 들어갔다. Greg KH의 인용문이 현재 커널 커뮤니티의 양가감정을 가장 압축적으로 보여준다.
• Debian 투표의 8개 선택지는 사실상 세 덩어리다. 금지(Geiger, Jackson, Spreemann), 허용(Nussbaum, Bécue, Haber), 입장 표명만(Frost, Levsen). Condorcet 방식이라 비슷한 안들이 표를 나눠 먹는 문제는 덜하지만, 사회 계약을 건드리는 Geiger 안만 3:1 다수를 요구한다는 점이 결과를 크게 좌우할 것으로 보인다.
• Arm 128비트 PTE는 비용은 확실하고 이득은 아직 불확실한 드문 사례다. huge page가 절반에서 4분의 1로 줄어드는 대가로 얻는 것이 소프트웨어 비트 5개 추가와 SKL 필드인데, 정작 주소 폭 확장은 이번 시리즈 목표가 아니다. 예약 비트 35개가 남아 있으니 “미래를 위한 자리 확보”로 읽는 편이 정확하고, 배포판이 커널을 따로 빌드해야 하는 제약이 풀리기 전까지는 실사용도 제한적일 것이다.
• AF_ALG 제거 절차는 커널 인터페이스를 걷어낼 때의 교과서적 순서를 보여준다. 커널에 sysctl 노브를 넣어 단계적 제한을 가능하게 하고(7.3 기본값 1), 배포판이 릴리스 경계에서 이를 켜서 알려지지 않은 사용자를 미리 찾아낸다. Fedora 44는 7.2를 받되 제한 패치는 빼는 식으로 진행 중 릴리스 파손도 피한다.
• 부트스트랩 가능한 빌드는 NixOS strip 백도어 논문으로 위협 모델이 이론에서 실증으로 넘어왔다. 다만 Guix 씨앗이 256바이트로 줄었다는 성과에도 정적 링크 Guile 의존과 커널 부트스트랩 부재라는 큰 구멍이 남아 있어, “출처가 완전히 파악된 시스템”까지는 아직 거리가 있다.

원문: LWN.net Weekly Edition for August 20, 2026