[Paper Review] Efficient Use-After-Free Prevention with Opportunistic Page-Level Sweeping

글쓴이 /
저자Chanyoung Park, Hyungon Moon
연도2024
게재처NDSS
유형garbage collection, one-time allocate
URLhttps://www.ndss-symposium.org/ndss-paper/efficient-use-after-free-prevention-with-opportunistic-page-level-sweeping/

Introduction

이전에도 UAF를 막기 위한 연구가 존재했다.

  • Delaying the reuse of free chunks → MarkUs, MineSweeper
    • garbage collection과 비슷하게, 객체를 가리키는 포인터가 없는 안전한 상태에서만 재사용이 가능할 수 있게 함
    • 할당 작업이 많은 벤치마크에서는 큰 slow-down을 보임
  • never reusing the freed chunks (one-time allocate) → Oscar, FFmalloc (+ DangZero, BUDAlloc)
    • 한번 할당했던 chunk를 재사용하지 않음
    • slow-down은 크지 않으나, 메모리 오버헤드가 큼

 

이 논문에서는 HushVac이라는 allocator를 제안한다. 간단히 정리하자면, HushVac은 OTA와 같이 항상 새로운(사용된 적 없는) heap chunk, 혹은 dangling pointer가 남아있지 않은 heap chunk를 할당한다. 즉, 기본적으로는 OTA 기법을 사용하면서 garbage collection 기능을 덧붙인 셈이라고 볼 수 있다.

 

HushVac의 디자인을 정리하면 다음과 같다.

  1. FFmalloc 기반 → FFmalloc은 OTA 기법을 사용하는데, 성능 오버헤드가 거의 없는 편이기 때문
  2. page level에서는 메모리를 재사용하긴 한다. 그런데 가상 주소 공간만 재사용하고, 물리 주소 공간의 재사용은 OS 커널에게 맡긴다. 리눅스 커널에서 가상 페이지를 unmap하지 않으면서 물리 페이지와 분리시킬 수 있는 (mmap with MAP_FIXED) 기능이 존재하기에 가능하다.
  3. 프로세스에서 더 이상 힙 청크를 할당하기 어려워지면, 가상 주소 공간을 재사용하기 위해 mark-sweep을 실행한다. 이때, 이전 연구에서는 실제 물리 공간을 재사용을 위해 waitlist에 추가했다면, HushVac에서는 가상 페이지(물리 공간으로부터 분리한) 만을 waitlist에 추가하고 이들의 메타데이터만을 관리하기 때문에 이로 인한 메모리 오버헤드가 적다.
  4. sub-page reuse → 특정 경우에는 어떤 페이지가 완전히 안전하다고(dangling pointer가 존재하지 않는다고) 판단되지 않는 경우더라도 힙 청크를 재사용하기도 함, potential fragmentation 완화 가능
  5. malloc, new와 같이 할당된 객체 뿐만 아니라 시스템콜(mmap)을 통해 직접 할당된 메모리 페이지까지 포괄적으로 스캔함 → dangling pointer로부터 더욱 안전

 

오버헤드 평가 시, SPEC CPU2006/2017, BBench in Firefox, PARSEC 3.0 등의 벤치마크 실행 결과 이전 mark-sweep 논문 MarkUs에 비해 낮은 성능 오버헤드를 보였고, 이전 one-time allocator 논문 FFmalloc보다 낮은 메모리 오버헤드를 보였다.

 

CVE, HardsHeap 기반 공격을 대상으로 모든 UAF 공격을 방지하면서 안전성을 검증하였다.

 

Background

A. Use-after-Free

heap과 같이 동적 할당된 메모리 공간에서 발생할 수 있는 취약점.

해제된 공간을 가리키고 있는 dangling pointer를 통해 해당 공간에 접근하여 privilege escalation, information leakage 등과 같은 공격으로 이어질 수 있는 취약점이다.

B. Existing Approaches Delaying the Reuse

어떤 객체를 해제하고자 할 때, 해당 객체를 가리키는 포인터가 없는 상태에서만 해제시켜주는 기법

Mark & Sweep 과정을 거쳐서 quarantine list에 있는 객체를 free list로 해제시켜 준다. Mark 과정에서는 stop-the-world를 통해 메모리에 존재하는 (BSS, data, heap, stack, registers) 모든 데이터가 각각 가리키는 곳을 마킹함으로써 heap 객체를 가리키는 포인터의 유무를 저장한다. Sweep과정에서 마킹되지 않은 heap 객체 중 quarantine list에 있는 객체를 free list로 옮기고 재사용할 수 있게 해준다.

대체로 적당한 오버헤드를 보였지만, 특정 오버헤드에서 심각한 성능 오버헤드를 보이는 문제점이 존재한다.

 

C. One-time Allocation

한번 할당했던 heap chunk를 재사용하지 않는다. 즉, 항상 새로운 virtual page로부터 새로운 heap chunk를 할당시켜준다. 대신, physical page는 재사용이 가능하다.

이전에 사용했던 가상 메모리를 다시 사용하지 않고 항상 새로운 가상 메모리를 사용하기 때문에 메모리 오버헤드가 높고, 해당 기법을 적용하면서 TLB pressure이 높아져 성능 오버헤드 역시 증가하게 된다.

 

 

Motivation

MarkUs와 같이 heap chunk의 reuse를 delay하는 기법은 힙 단편화를 발생하게 한다. 이는 spatial locality를 낮게 만들고, 캐시 미스의 증가로 이어져 실행 시간을 증가시킨다.

반면, FFmalloc의 경우 계속 새로운 가상 메모리만을 사용하기 때문에 spatial locality가 높아 캐시의 이점을 잘 활용하여 상대적으로 실행 시간이 적어진다.

위의 그림은 할당 작업이 많은 xalancbmk를 실행했을 때 heap chunk 간의 평균 거리, 실행 시간을 비교한 것이다. 먼저 average distance는 할당된 청크를 기준으로 이전/이후에 할당된 10개의 인접한 청크와의 물리 주소 거리 차이를 측정해서 평균낸 값이다. 이때 MarkUs는 200MB가 넘을 정도로 거리가 멀었고, FFmalloc은 4MB로 거리가 상대적으로 가까웠음을 확인할 수 있었다.

이로 인해 캐시 미스가 발생하여 실행 시간이 상대적으로 길게 측정된다. 따라서 HushVac에서는 이를 완화하기 위해 FFmalloc을 기반으로 다른 최적화 기법을 도입하였다.

 

Threat Model

이전 연구와 마찬가지로, UAF 취약점을 가지고 있으며 공격자가 실제로 UAF를 발생시킬 수 있는 상황을 가정. UAF 이외의 spatial safety violation (heap overflow 등)은 방어 대상 X.

 

Design

A. Overview

HushVac의 디자인 overview는 다음과 같다.

  1. 어플리케이션의 malloc 요청을 받으면, HushVac Runtime은 Heap Allocator(FFmalloc)으로부터 힙 청크를 받아서 이를 전해준다.
  2. Page Metadata를 확인했을 때, 재사용 가능한 청크가 페이지에 존재한다면, 해당 페이지로부터 청크를 할당하여 전해준다. (Sub-page Reuse)
  3. 어플리케이션의 free 요청을 받으면, 실제로 청크를 해제시켜주고 Page Metadata에 해당 청크를 해제된 상태로 업데이트 해준다.
  4. HushVac의 Marker 스레드는 어플리케이션의 메모리를 확인하면서 마킹을 진행한다.
  5. 마킹의 결과를 Page Metadata에 기록한다.
  6. HushVac의 Sweeper 스레드는 Page Metadata를 바탕으로, 어떠한 가상 페이지가 재사용될 수 있는지 확인한다.
  7. 재사용 가능한 가상 페이지를 Heap Allocator에게 전달한다.

 

B. Mark-Sweep For Virtual Pages

FFmalloc의 경우, page unmap 시에 특정 수의 연속된 페이지가 unmap될 때까지 기다렸다가 한번에 unmap해주는, 즉 unmap을 batching하는 방법을 도입하였다. 이는 시스템콜로 인한 오버헤드는 줄일 수 있었지만, 메모리가 바로 unmap되지 못해 심각한 메모리 오버헤드를 초래하였다.

또한, 잦은 page unmap은 in-kernel VMA(virtual memory area) struct의 파편화를 초래하게 되고, 이는 또한 메모리 오버헤드로 이어지게 된다.

 

HushVac에서는 이를 해결하기 위해 다음과 같은 방식을 도입하였다.

  • bitmap을 통해 각 페이지의 chunk 할당/해제 상태를 기록한다.
  • bitmap에서 특정 페이지의 모든 청크가 해제된 상태라면, 이를 바로 quarantine list에 넣어준다. (not batching)
  • quarantine list에 추가할 때, 해당 페이지를 unmap 시켜주는 대신 MAP_FIXED 플래그와 함께 mmap 시켜준다. (VMA sturcture 파편화 방지)
  • quarantine list에 있는 페이지 중, 해당 페이지를 가리키는 포인터가 없다면, 그 페이지는 안전하다고 판단하고 재사용할 수 있도록 Heap Allocator에 전달한다.

즉, HushVac은 batching 없이 mmap(with MAP_FIXED)을 호출함으로써 메모리 오버헤드를 줄였다.

 

 

이때, mmap with MAP_FIXED가 어떻게 VMA sturcture 파편화를 방지할까? (출처 : chatgpt)

VMA Fragmentation이 발생하는 이유

mmap과 munmap을 반복적으로 호출하면 VMA fragmentation이 발생하는 이유는 다음과 같음:

  1. VMA Split (분할)
    • mmap으로 새 영역을 할당한 후, munmap으로 해당 영역의 일부만 해제하면 기존 VMA가 분할됨.
    • 예를 들어, 기존 VMA가 [0x1000, 0x5000]이고 munmap(0x2000, 0x1000)을 호출하면: 
      
기존: [0x1000, 0x5000] (하나의 VMA)
해제 후: [0x1000, 0x2000] + [0x3000, 0x5000] (두 개의 VMA로 분할됨

       

    • mmap을 빈번하게 호출하면서 munmap을 수행하면, 이러한 VMA 분할이 계속 발생하여 VMA 리스트가 조각화(fragmentation)됨.
  2. VMA Merge 실패
    • 새로운 mmap 호출이 기존 VMA와 인접한 주소에서 발생하더라도, VMA 속성이 다르면 병합되지 않음.
    • 예를 들어, [0x1000, 0x2000] (PROT_READ) 와 [0x2000, 0x3000] (PROT_READ | PROT_WRITE)는 병합되지 않음.
    • 결과적으로 VMA 개수가 계속 증가하고, 커널이 이를 관리하는 비용이 증가함.

2. MAP_FIXED가 VMA Fragmentation을 방지하는 원리

논문에서 말하는 MAP_FIXED의 효과는, 새로운 VMA를 생성하지 않고 기존 VMA를 대체하는 방식 때문임.

  1. 기존 VMA를 Split하지 않고 Overwrite
    • MAP_FIXED를 사용하면 기존 VMA가 존재하더라도 mmap이 새로운 매핑을 강제로 덮어씀.
    • 기존 VMA가 여러 개로 분할될 필요 없이, 하나의 연속된 VMA로 유지됨.
    • 예를 들어, 기존 VMA [0x1000, 0x5000]이 있을 때: 
      
mmap(0x2000, 0x1000, PROT_READ, MAP_FIXED, fd, 0);

       

      • 일반 mmap의 경우: VMA가 [0x1000, 0x2000], [0x3000, 0x5000]로 분할됨.
      • MAP_FIXED의 경우: [0x2000, 0x3000]이 기존 VMA를 그대로 덮어씀 → VMA 분할 없음.
  2. Physical Page Detach가 가능해지는 이유
    • MAP_FIXED를 사용하여 기존 매핑을 덮어씌우면, 해당 영역에 연결된 물리 페이지 (physical page) 와의 매핑이 자동으로 해제됨.
    • 이 과정에서 커널은 기존 VMA에 할당된 물리 페이지를 zap_page_range 등을 사용해 detach (분리) 함.
    • 즉, 기존에 매핑된 가상 주소는 유지되지만, 물리 메모리와의 연결만 끊어짐.

 

 

C. Two-Staged Mark Phase

HushVac의 마킹 과정은 2가지로 나뉜다.

  • concurrent mark : 다른 어플리케이션의 실행 도중 동시에 마킹 진행
  • synchronous mark : concurrent mark 이후, 도중에 수정된 부분에 대해서 마킹 다시 진행 (stop-the-world)

 

concurrent mark 시작 전에 각 페이지의 dirty 비트를 0으로 만들어준다. 마킹 이후, 다시 dirty 비트를 확인했을 때 1로 되어있는 페이지는 마킹 도중에 수정이 발생한 부분이라고 볼 수 있으므로, 해당 페이지들만 다시 마킹을 진행한다. 이때는 정확한 마킹을 위해 stop-the-world, 즉 모든 어플리케이션의 실행을 멈춘 상태에서 진행한다.

이렇게 마킹 과정을 둘로 나눔으로써 stop-the-world 상태의 지속 시간을 최소화하였다.

 

 

D. Page-Level Sweeping

마킹 과정 이후, Sweeper 스레드는 quarantine list에 저장된 virtual page들을 확인한다. 정확히는, mark map을 확인하여 특정 페이지의 모든 객체가 dangling pointer가 없는 상태, 즉 mark bit가 0으로 설정되어 있는지 확인한다. 그러한 페이지들은 reuse batch list에 보내진다.

HushVac에서 heap을 확장하려고 하면, mmap 시스템 콜을 호출하기 전에 먼저 reuse batch list를 확인한다. 만약 해당 리스트에 virtual page가 존재한다면, 그 페이지를 사용하여 힙을 확장하게 된다.

이때 reuse batch list를 확인하는 과정이 추가되어 오버헤드가 증가한다고 볼 수도 있다. 하지만 reuse batch list에 있는 페이지는 이미 매핑되어 있는 상태이고 (unmap이 아니라 mmap with MAP_FIXED를 통해 물리 페이지와 분리시켰기 때문), 따라서 해당 페이지를 재사용할 때에는 mmap을 호출할 필요가 없기 때문에 위의 오버헤드를 상쇄시킬 수 있다.

 

 

E. Opportunistically Triggering the Mark-Sweep Procedure

이전 연구(MarkUs, MineSweeper)와 다르게, HushVac은 quarantine list에 가상 페이지 단위로 저장하게 된다. 이때 가상 페이지들은 물리 주소와 분리되어 있으며, 각각의 페이지에 대한 정보로는 가상 페이지 base 주소 + 데이터 구조로 총 16byte만 쓰인다. 따라서 quarantine list에 들어가는 메모리 오버헤드가 적기 때문에 많은 가상 페이지를 저장해도 문제가 없다.

 

HushVac은 mark-sweep 과정을 ‘기회주의적(opportunistically)’으로 실행시킨다. 만약 어플리케이션에서 할당 작업이 많이 일어나고 있다면, mark-sweep을 실행하지 않고 미룬다. 기본적으로 HushVac의 mark-sweep은 특정 간격마다 발생하게 된다. 매 할당 때마다 counter 값을 증가시키고, 만약 이번 간격의 counter 값이 평균 counter의 1.1x 이상이라면 mark-sweep을 실행하지 않는다. 이렇게 함으로써 할당 작업의 빈도가 높은 시기에는 mark-sweep을 미뤄서 어플리케이션의 성능을 향상시킨다.

 

 

F. Comprehensive Scanning of the Memory Space

HushVac은 마킹 과정에서 heap, stack 뿐만 아니라 어플리케이션에서 mmap을 직접 호출하여 할당한 메모리 공간까지 확인을 거친다. 이전 연구(MarkUs)의 경우, 사용자가 직접 mmap을 호출해서 할당한 공간까지는 마킹 과정에서 체크하지 않았는데, 위의 PoC(HardsHeap에서 생성)와 같은 경우에 mmap을 통해 할당한 공간에 존재하는 dangling pointer를 탐지하지 못하여 UAF가 발생할 수 있다. HushVac은 메모리 공간을 포괄적으로 확인함으로써 위와 같은 공격을 방지한다.

 

 

G. Sub-Page Reuse

HushVac의 page-level sweeping의 단점은 페이지의 모든 청크가 해제될 때까지 페이지를 재사용하지 못한다는 것이다. 이는 작은 청크 하나 때문에 전체 페이지를 재사용하지 못하는 등의 문제로도 이어질 수 있다.

이를 해결하기 위해, HushVac은 sub-page reuse라는 방안을 도입하였다. 이는 페이지 전체가 해제되기 전에, 페이지의 몇몇 청크를 재사용하는 것이다. 이렇게 함으로써 더 나은 spatial locality를 통해 성능 오버헤드를 감소시키고, 메모리를 재사용하여 메모리 오버헤드 역시 감소시킬 수 있다.

sub-page reuse의 구체적인 방법은 다음과 같다.

  1. dangling pointer가 존재하지 않는 청크가 하나라도 있다면, 해당 페이지를 sub-page reuse batch list에 추가한다.
  2. 새로운 할당 요청이 생기면, HushVac은 이 batch list로부터 힙 청크를 받아서 전달한다.
  3. 여전히 page-level sweeping이 가능하기 때문에, 모든 청크가 해제되면 reuse batch list에 추가되게 된다.

 

Evaluation

Experimental Setup

OS : Ubuntu 18.04, Linux 5.4.0-150-generic

CPU : AMD Ryzen 5 2600

Memory : 32GB

 

A. SPEC CPU 2006

SPEC CPU 2006를 3가지의 allocator를 대상으로 돌렸을 때의 결과이다. 런타임 오버헤드는 평균적으로 HushVac은 4.7%, MarkUs는 11.4%, FFmalloc은 -2.1%였다. HushVac은 stop-the-world가 발생하는 시간을 줄였기에 MarkUs보다 낮은 런타임 오버헤드를 가졌다.

할당/해제 작업이 많은 perlbench, gcc, omnetpp, xalacbmk만을 대상으로 평가했을 때, HushVac의 오버헤드는 35%, MarkUs의 오버헤드는 110%였다.

위의 그림은 MarkUs와 HushVac에서 발생한 stop-the-world의 시간을 비교한 결과이다. 평균적으로 HushVac은 3.03s, MarkUs는 28s의 지연 시간을 보였다.

 

 

위의 그림은 메모리 오버헤드를 나타내고 있다. 평균적으로 HushVac은 57.2%, FFmalloc은 115%, MarkUs는 25.1%의 메모리 오버헤드를 보였다. HushVac 역시 FFmalloc 기반으로 기본적으로 재사용보다 새로운 페이지를 할당하는 경우가 더 많기 때문에 MarkUs에 비해 높은 메모리 오버헤드를 보이고 있다.

 

B. SPEC CPU 2017

SPEC CPU 2006를 3가지의 allocator를 대상으로 돌렸을 때의 결과이다. 런타임 오버헤드는 평균적으로 HushVac은 7.3%, MarkUs는 12.6%, FFmalloc은 2.6%였다. 마찬가지로 HushVac은 stop-the-world가 발생하는 시간을 줄였기에 MarkUs보다 낮은 런타임 오버헤드를 가졌다.

할당/해제 작업이 많은 벤치마크 perlbench, gcc, omnetpp, xalancbmk를 대상으로 한 오버헤드는 HushVac의 경우 5.7%, 43%, 21%, 23%였고 Markus의 경우 9.1%, 60%, 67%, 59.1%였다.

 

SPEC CPU 2017에서도 마찬가지로 stop-the-world에 소요되는 시간이 HushVac이 MarkUs보다 적은 것을 확인할 수 있다.

메모리 오버헤드의 경우 HushVac은 48.9%, FFmalloc은 94.7%, MarkUs는 35.4%였다.

 

 

C. Mimalloc-bench

heap 할당 작업이 많은 mimalloc-bench를 통해 실험한 결과이다.

평균 런타임 오버헤드는 MarkUs 974%, FFmalloc 91.8%, HushVac 372%였다.

HushVac과 MarkUs의 stop-the-world 소요 시간이다.

평균 메모리 오버헤드는 각각 MarkUs는 65.8%, FFmalloc은 520%, HushVac은 257%였다.

 

D. Real-world Application

Firefox에서 BBench를 실행하면서 웹 페이지 렌더링 시간을 측정한 결과이다. (markus의 경우 실험이 불가능하여 논문에서 발표한 수치를 그대로 가져옴)

이 벤치마크에서는 markus보다 HushVac이 더 높은 오버헤드를 보였다. 하지만 HushVac에서 시스템콜 오버헤드를 줄이기 위해 이를 batching (여러개를 모았다가 한번에 실행)했더니 markus보다 낮은 오버헤드를 보였다.

위의 그림은 웹 페이지를 20번 연속으로 실행시켰을 때의 결과이다. 대부분의 웹이 20번의 반복실행에도 큰 차이를 보이지 않는 것을 확인할 수 있었다. 그러나 amazon의 4번째 실행, espn의 8번째 실행과 같이 한번씩 오버헤드가 크게 증가하는 것을 확인할 수 있다. 이는 Firefox에서 시스템콜을 상대적으로 많이 호출하고, 힙을 확장하는데 page fault가 발생하기 때문에 slow down이 발생한 것으로 볼 수 있다.

 

E. Multi-threaded Workloads

PARSEC 3.0을 실행시키면서 thread 개수의 변화에 따른 오버헤드의 변화를 측정하였다.

먼저 (a) 그래프를 살펴보면, 세 allocator 모두 스레드 개수가 증가할수록 시간이 증가하다가 스레드 32째에 다시 감소하는 것을 확인할 수 있다. 평균 오버헤드는 FFmalloc 21%, MarkUs 46%, HushVac 36%이다.

(b) 그래프는 메모리 오버헤드를 나타내고 있다. 이전 벤치마크들과 마찬가지로 MarkUs가 가장 낮은 11.9%, FFmalloc과 HushVac은 각각 42%, 41%의 오버헤드를 보였다.

 

 

F. Evaluating Design Choices

VPS(virtual page-level sweeping), TSM(two-stage mark phase), SPR(sub-page reuse)을 각각 적용했을 때의 오버헤드에 주는 영향을 확인한 그래프이다. 대부분의 벤치마크에서 VPS 통해 오버헤드를 줄일 수 있었으며, 몇몇 벤치마크에서는 TSM을 통해서 stop-the-world 시간을 줄여서 오버헤드를 더 감소시킬 수 있었다. 반면 SPR의 경우는 spatial locality를 감소시키기도 하여 오히려 오버헤드를 증가시키는 모습을 보였다.

위의 그래프는 각 기법을 적용하였을 때의 stop-the-world에 소요된 시간을 측정한 것이다. 확실히 TSM을 통해 stop-the-world에 소모되는 시간을 줄여서 성능 오버헤드를 줄일 수 있었음을 확인할 수 있다.

메모리 오버헤드의 경우 대부분의 벤치마크에서 별 차이를 보이지 않았지만, sphinx3의 경우 적은 수의 청크가 페이지를 차지하고 있는 경우가 많았기에, 해당 벤치마크에서 SPR을 적용했을 때 메모리 오버헤드가 눈에 띄게 감소했음을 확인할 수 있다.

 

마지막으로 xalancbmk를 실행하면서 VMA(Virtual Memory Area) 구조체의 개수 변화를 측정한 것이다. FFmalloc은 mmap, munmap 만을 활용하여 one-time allocate를 구현하였기에 VMA 파편화가 발생하여 그 수가 계속 증가하는 것을 확인할 수 있다.

그에 비해 HushVac의 경우 mmap with MAP_FIXED를 사용하여 가상 페이지를 물리 페이지로부터 분리하는 기법을 사용하였기에 VMA를 새로 생성하지 않고 그대로 덮어쓸 수 있었다.

 

 

G. Effectiveness

UAF를 활용하는 CVE를 대상으로 HushVac의 안전성을 검증한 결과, 4개의 CVE를 대상으로 했을 때 모두 UAF를 발생시키지 못하여(dangling pointer가 가리키는 힙 청크가 재사용되지 못하여) HushVac이 안전하게 막았음을 보였다.

 

Limitation

Memory overhead

HushVac은 one-time allocator(FFmalloc) 기반으로 만들어졌다. 추가로 page 단위의 mark-sweep 과정을 추가하여 안전하게 메모리를 재사용할 수 있게 하였다. 따라서 이전 연구인 MarkUs에 비해 낮은 성능 오버헤드를 보였다. 하지만 메모리 오버헤드 측면에서는 이전 연구인 FFmalloc보다는 향상된 결과를 보였지만, 여전히 높은 오버헤드를 보이고 있다.

 

 

Conclusion

이 논문은 HushVac이라는 새로운 allocator를 제안한다. 이전 연구에서 mark-sweep 기법과 one-time allocate 기법이 벤치마크에서 보인 오버헤드를 참고하여, one-time allocate 기법을 활용한 FFmalloc을 기반 할당자로 하면서 page-level sweeping을 통해 청크를 페이지 단위로 안전하게 재사용하도록 하였다. 이떄 page-level로 재사용하는 기법은 가상 페이지를 물리 페이지와 분리하여 quarantine list에 추가함으로써 FFmalloc의 문제였던 VMA 구조 파편화를 해결하였다. 평가 시에 mark-sweep을 활용한 이전 연구인 MarkUs에 비해 더 나은 성능 오버헤드를 보였지만, 여전히 높은 메모리 오버헤드를 보이고 있다.

관련 게시물

댓글 달기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

위로 스크롤