이번 글은 USENIX Security 2025 논문 BlueGuard: Accelerated Host and Guest Introspection Using DPUs에 대한 논문 리뷰다. 핵심 질문은 단순하다. “보안 감시를 공격 대상 시스템 안에서 돌리지 않고, CPU와 어느 정도 분리된 장치에서 빠르게 실행할 수 없을까?”

BlueGuard의 답은 DPU(Data Processing Unit), 흔히 SmartNIC이라고도 부르는 장치다. 기존 NIC보다 훨씬 많은 기능을 가진 DPU 위에서 VM과 하이퍼바이저, 심지어 bare metal 호스트까지 감시한다. 이 감시는 VMI(Virtual Machine Introspection)의 확장된 형태인 HGI(Host and Guest Introspection)에 가깝다.

논문 링크: USENIX Security 2025 - BlueGuard

왜 DPU인가

VMI의 오래된 매력은 “안에서 보지 않고 밖에서 본다”는 점이다. 악성코드가 VM 내부에서 프로세스 목록을 조작하거나 보안 도구를 속여도, VM 바깥에서 메모리를 읽어 프로세스, 커널 모듈, credential 구조체 등을 재구성하면 다른 관찰 지점을 얻을 수 있다.

문제는 기존 방식들이 각각 아쉬운 균형점을 가진다는 것이다.

Host-based VMI는 하이퍼바이저나 호스트 CPU 쪽에서 실행되므로 성능 자원을 VM과 경쟁한다. 공격자가 하이퍼바이저나 호스트 쪽을 장악하면 감시자 자체의 신뢰도도 흔들릴 수 있다. 반대로 외부 co-processor나 RDMA 기반 방식은 격리는 좋아지지만, 메모리 획득 지연이나 네트워크 노출, 확장성 문제가 남는다.

BlueGuard가 DPU를 선택한 이유는 세 가지로 정리된다.

1. DPU는 호스트 CPU와 물리적으로 분리되어 있어 감시자의 격리성이 좋아진다.
2. DPU는 DMA, hashing, regex 같은 하드웨어 엔진을 가지고 있어 메모리 읽기와 패턴 매칭을 빠르게 처리할 수 있다.
3. DPU는 네트워크 경로에 있으므로 감염된 VM을 발견했을 때 VLAN이나 virtual switch 정책으로 격리할 수 있다.

즉 BlueGuard는 “감시”, “가속”, “격리 대응”을 같은 장치 위에 묶으려는 시도다.

BlueGuard의 구조

BlueGuard는 NVIDIA BlueField-2 DPU 위에 구현되었다. DPU의 SR-IOV 기능을 이용해 VM이나 하이퍼바이저에 vDPU를 연결하고, 각 대상에 대해 VMI context를 만든다. 이 context는 DMA, SHA, regex 엔진의 큐, completion queue, 주소 변환 캐시, kernel symbol 정보 등을 가진다.

VMI 애플리케이션은 DPU의 세부 큐를 직접 만지지 않는다. 대신 BlueGuard가 제공하는 인터페이스를 통해 “어떤 주소에서 얼마만큼 읽고, 어떤 연산을 적용할지”를 job 형태로 제출한다. 예를 들어 pslist는 Linux의 task_struct 연결 리스트를 따라가며 프로세스 목록을 재구성하고, modules는 커널 모듈 목록을 읽고, check_creds는 여러 프로세스가 같은 credential 구조체를 공유하는지 확인한다.

흥미로운 점은 BlueGuard가 단순히 DPU에 프로그램을 올린 것이 아니라, DPU라는 제한된 컴퓨팅 환경에 맞춰 런타임을 설계했다는 점이다. DPU의 general-purpose core는 강력한 서버 CPU가 아니다. 그래서 BlueGuard는 메모리 접근이 완료될 때까지 바쁘게 기다리지 않고, non-blocking 방식으로 요청을 던진 뒤 다른 VMI 애플리케이션으로 전환한다. 논문은 이를 C++ coroutine 기반의 N:M threading 모델로 구현했다고 설명한다.

이 설계가 중요한 이유는 VMI 애플리케이션이 기본적으로 pointer chasing을 많이 하기 때문이다. 한 주소를 읽고, 그 결과로 다음 주소를 계산하고, 다시 읽는다. 매번 blocking하면 DPU core가 놀거나 context switch 비용을 크게 낸다. BlueGuard는 이 대기 시간을 다른 introspection 작업으로 겹쳐서 숨긴다.

주소 변환이라는 현실적인 난점

밖에서 메모리를 읽는 시스템은 항상 같은 벽을 만난다. 보안 분석가는 task_struct 같은 커널 객체를 보고 싶지만, 하드웨어가 실제로 읽는 것은 physical address다. VM이면 guest virtual address, guest physical address, host physical address가 얽힌다.

BlueGuard는 x86 4-level page table을 software walk로 따라가며 VA를 PA로 바꾼다. CR3 같은 CPU 내부 레지스터는 DPU에서 직접 읽을 수 없으므로, kernel symbol과 알려진 메모리 내용을 이용해 kernel root page table을 찾는다. VM의 GPA-HPA 변환은 IOMMU에 맡길 수 있고, 하이퍼바이저나 bare metal introspection에서는 PA를 더 직접적으로 사용할 수 있다.

여기에는 중요한 신뢰 가정이 붙는다. BlueGuard는 초기화 시점의 VM, 하이퍼바이저, DPU를 신뢰한다. 초기화가 끝난 뒤 공격자가 root 권한을 얻는 상황을 주로 다룬다. 또한 하이퍼바이저가 IOMMU를 악의적으로 조작하는 공격이나 address translation redirection 계열은 논문에서 범위 밖으로 둔다. 이 부분은 BlueGuard만의 약점이라기보다 많은 out-of-band introspection 시스템이 공유하는 어려움이다.

Delta introspection: 매번 전체를 다시 보지 않기

논문에서 가장 실용적으로 마음에 든 아이디어는 delta introspection이다.

VMI 애플리케이션은 결국 메모리에서 특정 주소들을 읽고, 읽은 값으로 결과를 만든다. 그렇다면 첫 실행 때 어떤 주소와 크기를 읽었는지 기록해두고, 다음 번에는 그 주소들만 batch DMA로 다시 읽어 값이 바뀌었는지 확인할 수 있다. 바뀌지 않았다면 전체 VMI 애플리케이션을 다시 돌릴 필요가 없다. 바뀌었다면 그때 전체 플러그인을 실행해 새 상태를 재구성한다.

이 방식은 stealthy malware를 다룰 때 특히 중요하다. 어떤 악성 프로세스나 커널 모듈은 아주 짧은 시간만 흔적을 남기고 사라질 수 있다. 전체 introspection latency가 길면 그 짧은 창을 놓친다. BlueGuard는 delta check를 빠르게 반복하고, 변화가 보일 때만 무거운 플러그인을 실행하는 식으로 탐지 확률을 높인다.

논문은 100% 탐지를 위해 필요한 시간 창을 2 * delta latency + VMI app latency로 설명한다. 예를 들어 modules에서 delta introspection 평균 latency는 108.2 microseconds, plugin latency는 1.38 milliseconds로 측정되었다. 이 경우 흔적이 약 1.59 milliseconds 이상 남아 있으면 모델상 100% 탐지를 기대할 수 있다.

평가 결과

논문은 BlueField-2 DPU가 장착된 서버에서 BlueGuard를 평가했다. 호스트는 Intel Xeon Gold 6130 두 개, 204GB RAM, KVM/QEMU 기반 VM 환경이고, VM은 16개까지 실제 실행했다. 그 이상은 VMI context를 늘려 64 VM까지의 확장성을 시뮬레이션했다.

핵심 수치는 다음과 같다.

1. 메모리 접근 latency에서 BlueGuard는 LibVMI보다 작은 버퍼 기준 약 3배 빠르고, 1MB 또는 2MB 같은 큰 버퍼에서는 약 27배에서 33배 빠르게 측정되었다.
2. 전체 VM 메모리를 2MB 단위로 읽는 실험에서는 약 53Gbps의 introspection bandwidth를 보였다. 논문이 비교한 기존 HGI 시스템의 최고 보고 수치인 250MB/s보다 약 27배 높다.
3. RDMI와 비교한 check_creds 시나리오에서 100% 탐지를 위한 latency 기준으로 BlueGuard는 2.08ms, RDMI는 8.94ms로 계산되어 약 4.3배 빠르다.
4. modules_integrity는 DPU hashing engine을 사용해 software hashing 대비 약 12배 빨라졌다.
5. regex_scan은 DPU regex engine을 사용했을 때 software implementation 대비 두 자릿수 수준이 아니라 “two orders of magnitude” 수준의 개선을 보였다.
6. 64개의 VM context까지 VMI 애플리케이션을 실행해도 급격한 붕괴가 아니라 graceful degradation을 보였다.

성능보다 더 눈에 띈 부분은 VM workload 영향이다. SPEC CPU2017과 IOzone 실험에서 BlueGuard가 CPU나 I/O workload에 큰 영향을 주지 않는 것으로 보고된다. Redis 실험에서는 LibVMI 기반 pslist가 Redis와 같은 CPU에 묶였을 때 throughput을 크게 떨어뜨리지만, BlueGuard는 CPU 밖에서 실행되기 때문에 성능 격리가 유지된다.

이 결과는 BlueGuard의 주장과 잘 맞아 떨어진다. “더 빠른 감시”도 중요하지만, 클라우드 사업자 관점에서는 “테넌트가 쓰는 CPU를 빼앗지 않는 감시”가 더 큰 장점일 수 있다.

악성코드 탐지와 격리

논문은 rootkit과 실제 malware family를 대상으로 한 평가도 포함한다. Diamorphine과 Reptile 같은 Linux kernel module 기반 rootkit은 로딩 직후 자신을 숨기는 기능을 가진다. BlueGuard는 modules VMI 애플리케이션과 delta introspection을 사용해 모듈 목록 변화를 빠르게 감지한다.

결과는 Reptile 100%, Diamorphine 91% 탐지였다. Diamorphine은 이론 모델상으로는 더 높게 나올 법했지만, 논문은 P90 latency나 실제 흔적 유지 시간이 평균보다 짧았을 가능성을 언급한다. 이 대목은 오히려 현실적인 평가로 보인다. 평균 latency만 보면 충분해 보여도, 짧게 나타나는 artifact는 tail latency에 민감하다.

실제 malware family 평가에서는 Cl0p, Gafgyt, Mirai, XMRig, DinodasRAT, AresRAT, Babuk, Kaiji가 등장한다. BlueGuard는 regex_scan으로 onion address 같은 indicator를 찾고, pslist로 의심스러운 parent/child relationship을 본다. sh child process는 132개 중 108개를 감지했고, onion address는 실행한 malware에서 모두 확인했다고 보고한다.

격리 실험도 흥미롭다. BlueGuard가 의심 프로세스를 발견하면 DPU의 OVS 설정을 바꿔 VM을 containment VLAN으로 옮긴다. ping을 악성 프로세스처럼 사용한 실험에서 평균 27.7ms 후 네트워크 격리가 이루어졌다. 최소는 12.19ms, 최대는 83.04ms였다.

내가 보는 장점

이 논문의 가장 큰 장점은 DPU를 “빠른 NIC”가 아니라 “클라우드 보안 control point”로 본다는 점이다. DPU는 메모리 접근, inline computation, 네트워크 정책 집행이라는 세 가지 위치에 동시에 걸쳐 있다. BlueGuard는 이 위치를 잘 활용한다.

또 하나 좋은 점은 기존 VMI 애플리케이션 모델과의 연결을 포기하지 않았다는 것이다. 논문은 Volatility 같은 도구와의 통합 가능성도 언급한다. BlueGuard가 제공하는 read interface가 충분히 맞춰지면 기존 플러그인을 큰 폭으로 재사용할 수 있다는 관점이다. 실제 제품화에서 중요한 부분은 언제나 “새 탐지 로직을 얼마나 쉽게 올릴 수 있는가”인데, 논문은 그 점을 꽤 의식하고 있다.

마지막으로 delta introspection은 논문 밖에서도 응용할 수 있는 패턴처럼 보인다. 보안 감시뿐 아니라, 외부 관찰자가 고비용 분석을 반복해야 하는 시스템에서는 “처음에는 전체 실행, 이후에는 입력 집합의 변화만 확인”하는 구조가 꽤 유용하다.

조심해서 봐야 할 점

BlueGuard는 만능 감시자가 아니다. 논문의 threat model을 읽으면 몇 가지 선이 분명하다.

첫째, DPU와 그 위에서 실행되는 BlueGuard는 trusted computing base 안에 있다. DPU firmware나 DPU software가 깨지는 상황은 다루지 않는다.

둘째, 초기화 시점은 신뢰한다. VM이나 하이퍼바이저가 부팅 후 BlueGuard에 메모리 접근 권한을 세팅하고, 그 이후 공격자가 침투하는 모델이다. 부팅 전부터 이미 악성 상태라면 이야기가 복잡해진다.

셋째, CPU 내부 상태는 볼 수 없다. DPU는 메모리는 읽을 수 있지만, register나 TLB 같은 내부 상태까지 완전히 introspect하지 못한다. 이 때문에 CR3 조작이나 translation redirection 계열의 공격은 여전히 어려운 문제다.

넷째, consistency 문제가 남는다. VM을 멈추지 않고 메모리를 읽으면 읽는 동안 상태가 변할 수 있다. 논문은 VM pause 방식이 성능에 너무 큰 비용을 낸다고 보고 non-cooperative design을 택한다. KPTI 때문에 CR3 변경을 trap하는 방식이 Redis throughput을 15배 낮췄다는 설명은 이 선택의 이유를 잘 보여준다.

결론

BlueGuard는 “보안 감시를 어디에서 실행해야 하는가”라는 질문에 대한 꽤 설득력 있는 답이다. CPU 안에서 보안 도구를 돌리면 공격자와 같은 자원을 공유하고, 외부 장치에서 돌리면 느리거나 운영이 어렵다. DPU는 그 중간 어딘가에 있다. 호스트와 물리적으로 분리되어 있으면서도, 메모리와 네트워크에 충분히 가까운 위치다.

논문이 특히 설득력 있는 지점은 단순히 “DPU에 올렸더니 빨랐다”가 아니라, DPU의 약점까지 반영해 런타임을 설계했다는 것이다. non-blocking scheduler, batching, address translation cache, delta introspection, inline accelerator abstraction이 모두 같은 목표를 향한다. 제한된 DPU 자원 위에서 많은 VM을 계속 감시하는 것.

개인적으로는 BlueGuard가 앞으로의 cloud security architecture를 보여주는 작은 예고편처럼 느껴진다. 보안 기능이 점점 더 host OS 바깥, hypervisor 바깥, 그리고 네트워크와 가속기가 만나는 지점으로 이동하고 있다. DPU가 단순한 offload 장치가 아니라 독립된 보안 평면이 될 수 있다는 점에서, 이 논문은 꽤 오래 기억해둘 만하다.