(Part 3) Memory Wall: 왜 당신의 Enclave가 느린가 그리고 해결 방법

Source: Dev.to

메모리 벽

Part 2에서 실행 중인 Enclave를 얻었지만, “Hello World”를 넘어 (예: 이미지 처리 알고리즘이나 작은 데이터베이스) 로 이동하면 곧 문자 그대로 하드웨어에 코딩된 벽, 즉 Memory Wall에 부딪히게 됩니다.

메모리 벽이란?

• 전통적인 애플리케이션에서는 RAM을 무한한 바다처럼 취급합니다—malloc으로 1 GB를 할당하면 OS가 보통 “괜찮아요”라고 대답합니다.
• SGX에서는 CPU가 Enclave를 위해 Enclave Page Cache (EPC) 라는 특별하고 격리된 RAM 영역을 예약합니다.
  • 구형 머신 (Ice Lake 이전)에서는 EPC가 128 MiB 로 제한됩니다.
  • 관리 오버헤드가 포함된 후 실제로 코드, 스택, 힙에 사용할 수 있는 것은 약 90 MiB 정도입니다.

“90 MiB? 내 Node.js 앱이 깨우는 것만으로도 그 정도는 쓰는데!”
바로 그거죠. SGX는 Confidential Computing을 위해 설계된 것이지 Lazy Computing을 위해 만든 것이 아닙니다.

SGX에서의 페이징

EPC 한도를 초과하면 하드웨어가 충돌하는 것이 아니라 페이징을 시작합니다:

1. Enclave 페이지가 암호화되어 일반 RAM으로 이동합니다.
2. 다시 필요해지면 페이지를 끌어와 복호화하고 무결성 해시를 검증합니다.

이 SGX 페이징은 일반 OS 페이징보다 10배~100배 느립니다. 이는 지속적인 암/복호화 오버헤드 때문입니다. 따라서 128 MiB 한계를 넘으면 성능이 급격히 떨어집니다.

90 MiB 박스 안에서 살아남기

메모리 관리 규칙

1. 한 번 할당하고 영원히 재사용 – malloc/free는 비용이 많이 들고 메모리를 파편화시킬 수 있습니다. 1 MiB 버퍼가 필요하면 시작 시 할당하고 계속 재사용하세요.
2. 큰 데이터 세트를 Enclave에 로드하지 않기 – 500 MiB 데이터베이스 같은 큰 파일은 신뢰되지 않는 RAM에 두세요. 데이터를 청크(예: 64 KiB) 단위로 가져와 처리하고, 결과는 OCALL을 통해 반환합니다. Enclave를 저장 창고가 아니라 처리 공장으로 생각하세요.
3. Enclave 설정 튜닝 – 기본 Enclave.config.xml 값이 성능을 크게 저해할 수 있습니다.

  0
  0
  0x4000000   
  0x40000   
  0x1000000 

Max의 황금 규칙

머신의 EPC 하드웨어 한계 바로 아래로 힙 크기를 설정하면 페이징 함정을 피할 수 있습니다.

실습: 고통을 느껴보라

SGX용 코딩을 배우는 것은 64 KB RAM을 가진 1980년대 게임 콘솔에 프로그래밍하는 것과 같습니다.
이는 데이터 지역성, 버퍼 관리, 오버헤드에 대해 생각하게 만듭니다. 개발자들이 RAM을 문제 해결에 쏟아붓는 세상에서 90 MiB 안에 보안 머신러닝 모델을 맞추는 사람은 보안 업계의 유니콘이라 할 수 있습니다.

다음은?

우리는 메모리를 정복했습니다. 다음 과제는 우리의 Enclave가 실제 하드웨어에서 실행되고 있으며 변조되지 않았음을 증명하는 것입니다.

다가오는 주제: 원격 인증

Remote Attestation은 신뢰의 디지털 핸드쉐이크로, 원격 파티를 신뢰하지 않더라도 인터넷을 통해 Enclave의 정체성을 증명할 수 있게 해줍니다.