BPF에서 직접 패킷 보내기

이 기사는 LWN 구독자들이 후원합니다 LWN.net의 구독자들은 이 기사와 그 주변의 모든 것을 가능하게 만들었습니다. 우리의 콘텐츠가 마음에 드신다면, 구독을 구매해 주세요. 그러면 다음 기사들도 가능해집니다.

Tetragon은 BPF 기반 보안 모니터링 도구로, 실행 중인 커널의 다양한 측면을 BPF로 모니터링하고 사용자가 지정한 정책을 강제합니다. 하지만 이 도구는 데이터를 사용자 공간 프로세스로 보내고, 그 프로세스가 다시 네트워크 어딘가의 중앙 모니터링 서비스로 데이터를 전달합니다. 이것은 취약 지점을 만듭니다. 공격자가 Tetragon의 사용자 공간 에이전트를 죽일 수 있다면, 상황을 제대로 보고할 수 없게 됩니다. Song Liu, Mahé Tardy, Liam Wiseheart는 2026년 Linux Storage, Filesystem, Memory-Management, and BPF Summit에서 사용자 공간 에이전트의 필요를 없애는 작업에 대해 발표했습니다.

Wiseheart는 자신이 Tetragon이 아니라 Meta에서 일한다고 분명히 했지만, 어떤 사용자 공간 구성 요소와도 완전히 분리된 상태로 BPF 프로그램이 실행되도록 하는 같은 문제를 해결하는 데 관심이 있다고 말했습니다. 현재 Meta는 시스템 부팅 시점에 프로그램을 pinning하는 접근법을 사용하고 있으며, 적어도 사용자 공간 구성 요소가 죽더라도 프로그램이 제거되는 것은 막을 수 있지만, 문제를 완전히 피하지는 못합니다.

Tardy의 설명에 따르면, Tetragon이 사용자 공간과 통신하는 방식은 ring buffer를 통하는 것입니다. 사용자 공간 구성 요소는 주로 그 ring buffer에서 메시지를 읽고, 이를 원격 서버로 보내고, 응답을 받은 뒤, 다시 그 응답을 ring buffer에 넣는 역할을 맡습니다. BPF 프로그램이 원격 서버와 직접 통신할 수 있다면 훨씬 더 효율적일 것입니다. BPF 프로그램은 이미 들어오는 네트워크 패킷을 가로챌 수 있습니다. 부족한 부분은 BPF에서 직접 데이터를 보내는 능력입니다.

2025년에 Tardy와 동료들은 splice()를 사용하는 해결책을 발표했지만, 그 해결책은 인기가 없었습니다. 당시 Andrii Nakryiko는 동기식 선택지가 아마도 BPF에 잘 맞지 않을 것이라고 보았습니다. 그 세션에 있던 커널 개발자들은 netconsole 코드를 사용할 것을 제안했습니다. 이것은 원래 직렬 포트로 갈 로그 메시지를 대신 원격 위치로 커널이 보낼 수 있게 해주는 코드입니다.

"우리는 그걸 시도했습니다"라고 Tardy는 말했고, 작동하는 것으로 보인다고 했습니다. Netpoll은 netconsole 뒤에 있는 커널 인프라로, 커널 코드가 어떤 컨텍스트에서든 패킷을 보내게 해주고 일반적인 네트워킹 스택을 우회하므로 유용합니다. 그래서 이들은 kfunc를 작성했고, 이를 위한 패치셋을 보냈으며, 그해 후반에는 업데이트된 버전도 내놓았습니다. 이를 사용하려면 사용자 공간 로딩 프로그램이 네트워크 주소 정보를 BPF 프로그램에 전달하고, BPF 프로그램은 bpf_netpoll_create()를 호출해 netpoll 컨텍스트를 생성합니다. 그 다음 임의 데이터를 담은 UDP 패킷을 보내기 위해 bpf_netpoll_send_udp()를 사용합니다.

이어서 Tardy는 간단한 데모를 보여주었습니다. 그는 가상 머신을 부팅하고, 호스트 머신으로 가끔 ping을 보내는 BPF 프로그램을 설치하는 데모 에이전트를 시작한 뒤, 별도 터미널에서 그 메시지들이 들어오는 모습을 보여주었습니다. 그 다음 사용자 공간 에이전트를 죽였고, 그래도 ping이 계속 도착하는 것을 보여주었습니다. 그는 새로운 패킷 전송 함수들을 커널의 기존 암호화 API와 결합해 암호화된 패킷을 보낼 수도 있다고 덧붙였습니다. 현재 그의 데모는 단순한 대칭 키를 사용하지만, 더 복잡한 방식도 사용할 수 있습니다.

netpoll 해결책이 작동하기는 하지만, "UDP는 악이다라는 피드백도 받았습니다"라고 Liu는 말했습니다. 우선 netpoll이 보내는 패킷은 일반적인 네트워킹 스택을 우회하기 때문에, BPF 프로그램이 너무 많은 트래픽을 보내면 다른 프로세스의 대역폭을 빼앗을 수 있고, 경쟁을 제한할 현실적인 방법도 없습니다. 한 청중은 어떤 커널 컨텍스트에서든 보낼 수 있는 netpoll의 능력을 사용할 필요는 없다고 제안했습니다. BPF 인터페이스가 커널 스레드를 생성하고 그 스레드로 정상적인 방식으로 패킷을 보내게 하면, 네트워킹 코드가 그 트래픽에 모든 일반 네트워킹 설정을 적용할 수 있다는 것입니다.

발표 10시간 전 시점을 기준으로, Liu는 이들이 UDP 대신 TCP 트래픽을 보내는 버전도 실험했다고 말했습니다. 네트워킹 쪽 사람들은 그것을 더 편하게 받아들였지만, 그렇게 하면 kfunc를 atomic 컨텍스트에서 사용할 수 없게 됩니다. 이는 커널 스레드 기반 해결책과 마찬가지입니다. 이 대목에서 UDP와 TCP의 장점에 대한 긴 토론이 이어졌고, 모인 사람들 대부분은 UDP 쪽에 더 우호적인 듯했습니다. Alexei Starovoitov는 netpoll이 이미 존재하고 커널에서 사용되고 있다는 점을 고려하면, 굳이 TCP를 선호할 이유를 보지 못했습니다. John Fastabend는 Tetragon의 사용 사례에는 UDP로 충분하다고 생각했습니다. Wiseheart는 netpoll이 일반 네트워킹 스택을 우회하기 때문에, 망가진 보안 모듈 훅이나 비슷한 문제가 netpoll 기반 로깅을 방해하기가 더 어렵다고 지적했습니다.

Starovoitov는 그런 견고함이 실제로 드러난 사례를 하나 공유했습니다. 그는 한때 네트워크 인터페이스 카드(NIC)가 부분적으로 고장 나서 패킷을 받을 수 없게 되었고, 그 때문에 전체 네트워킹 스택이 망가진 상황을 본 적이 있다고 했습니다. 하지만 그 장치로 보내는 데에는 netpoll 코드가 여전히 동작했습니다. 다른 한 사람은 netpoll 기반 해결책의 유일한 진짜 문제는 호스트에서의 대역폭 관리뿐이라고 반박했지만, 그것은 심각한 문제이기도 하다고 말했습니다. Starovoitov는 netpoll이 NIC에서 단 하나의 큐만 사용한다고 말하며, 그것만으로 문제가 생기리라고는 생각하지 않는다고 했습니다. Liu는 이러한 관점을 네트워킹 유지관리자들에게 설득하는 데 Starovoitov의 도움을 요청했고, 그는 돕겠다고 약속했습니다.

Daniel Borkmann은 얼마나 많은 NIC 드라이버가 실제로 netpoll을 지원하는지, 또는 그것이 모든 드라이버에서 동작하는 일반적인 유틸리티인지 물었습니다. Starovoitov는 대략 90%의 드라이버가 netpoll을 지원하지 않는다고 생각했습니다. 의도적으로 그렇거나, 아니면 그냥 고장 나 있기 때문이라는 것입니다. 그가 말하기로, Meta에서 정기적으로 사용하는 드라이버들만은 확실히 이를 올바르게 처리합니다.

이 점에 대해 반대하는 사람은 없어 보였고, 그래서 netpoll이 정말로 최선의 접근법인지가 오히려 불분명해졌습니다. 불행히도 그 시점에서 세션 시간이 다 되었습니다. 회의 이후에도 Tardy와 동료들은 이 문제를 계속 다루었고, 7월 6일에는 netpoll 대신 BPF 프로그램이 UDP 커널 소켓을 생성하고 사용할 수 있도록 하는 새 패치셋을 올렸습니다.

---