인스토리지 컴퓨팅은 데이터를 호스트로 옮기기보다 SSD 내부에서 처리해 I/O 비용을 줄이는 방식이다. 그러나 사용자 프로그램이 SSD 내부에서 실행되면 다른 사용자의 데이터와 플래시 관리 기능을 보호해야 한다. IceClave는 이를 위한 경량 신뢰 실행 환경(TEE)을 제안한다.

기존 정리 원본

문제와 위협 모델

SSD는 여러 애플리케이션이 공유하는 자원이다. 신뢰할 수 없는 프로그램이 내부로 오프로드되면 호스트 운영체제의 보호만으로 장치 내부의 실행을 통제하기 어렵다. 메모리 취약점을 악용해 FTL의 매핑 테이블을 변경하거나 다른 프로그램의 데이터를 읽고 수정할 위험이 있다.

논문은 사용자 프로그램에 의한 소프트웨어 공격과 장치 내부 데이터에 대한 물리적 공격을 고려한다. 보호 대상은 플래시 관리 기능, 프로그램 사이의 데이터, 메모리와 데이터 경로의 기밀성·무결성이다. 이러한 범위를 넘어 모든 공격을 방어한다고 해석해서는 안 된다.

설계 개요

IceClave는 TrustZone을 활용한 실행 영역 분리와 메모리 암호화·무결성 검사를 결합한다. 완전한 운영체제나 하이퍼바이저를 추가하기보다 SSD 컨트롤러의 제한된 자원에 맞는 보호 계층을 구성하는 것이 목표다.

연구는 FPGA 기반 프로토타입으로 구현 가능성과 비용을 평가하고, 시뮬레이션으로 설계의 영향을 분석한다. 실행 영역 격리와 물리적 메모리 보호는 서로 다른 문제이므로 함께 살펴봐야 한다.

FTL 보호

FTL과 IceClave 런타임은 보안 영역에서 실행하고, 사용자 프로그램은 일반 영역에 배치한다. 사용자 프로그램이 FTL과 런타임의 코드·데이터를 임의로 수정하지 못하도록 접근 권한을 분리한다.

FTL은 논리 주소와 물리 주소를 연결하고 GC와 웨어 레벨링을 관리한다. 이 기능이 손상되면 사용자 데이터의 유출뿐 아니라 저장장치의 정상 동작에도 영향을 줄 수 있다. 따라서 사용자 연산을 허용하면서 관리 기능의 권한을 보호하는 것이 핵심이다.

SSD DRAM의 보호

메모리 암호화는 외부에서 메모리를 관찰할 때 코드와 데이터가 노출되는 것을 막기 위한 기능이다. 무결성 검사는 데이터가 변경되었는지를 확인한다. 암호화만으로 변조까지 탐지할 수 있는 것은 아니므로 두 기능을 구분해야 한다.

논문에서 설명하는 카운터 기반 방식은 쓰기 시점마다 다른 암호화 입력을 사용하도록 카운터를 관리한다. 카운터의 저장과 갱신, 검증 정보의 접근은 추가 메모리 트래픽과 지연을 발생시킬 수 있다. 보호 기능의 유무뿐 아니라 이 비용이 워크로드에 미치는 영향도 평가 대상이다.

실행 흐름과 API

실행 흐름은 코드 오프로드, TEE 생성, 데이터 접근, 결과 회수, TEE 종료로 나눌 수 있다.

  1. 호스트가 미리 컴파일한 코드와 필요한 데이터의 논리 페이지 주소(LPA)를 전달한다. 작업 ID는 해당 실행을 식별한다.
  2. 런타임이 TEE에 메모리를 할당하고 보안 영역에 메타데이터와 접근 권한을 관리한다.
  3. 프로그램은 허용된 매핑 정보를 통해 데이터의 물리 페이지 주소를 얻는다. 필요한 매핑이 캐시에 없으면 FTL에 주소 변환을 요청한다.
  4. 런타임이 보안 영역으로 전환해 누락된 매핑 정보를 준비하고 실행을 이어간다.
  5. 프로그램이 데이터를 처리하면 결과를 호스트에서 회수할 수 있도록 알리고 전달한다.
  6. 결과 전달과 자원 회수 이후 TEE를 종료한다.

이 흐름에서 사용자 프로그램이 매핑 정보에 접근할 수 있는 범위와 FTL의 관리 권한을 구분하는 것이 중요하다. API 호출 자체뿐 아니라 권한 확인과 실행 영역 전환이 데이터 경로의 비용에 포함된다.

구현과 실험 설정

위 표는 논문의 구현과 평가 환경을 보여준다. 아래 성능 수치는 해당 하드웨어와 워크로드에서 보고된 값이며, 일반적인 SSD에서 동일하게 나타나는 결과로 해석해서는 안 된다.

보호 기능의 비용

  • TEE 생성 시간은 95µs, 삭제 시간은 58µs다.
  • 보안 영역과 일반 영역 사이의 컨텍스트 전환 비용은 3.8µs다.
  • 메모리 암호화와 검증 시간은 각각 평균 102.6ns와 151.2ns다.
  • 암호화와 검증에 따른 추가 메모리 트래픽은 각각 평균 20.26%와 14.51%다.

이 결과는 보호 기능의 비용이 존재함을 보여준다. 개별 동작의 지연과 애플리케이션 전체 성능의 변화를 따로 평가해야 한다.

여러 프로그램을 함께 실행할 때의 성능

논문은 여러 IceClave 인스턴스를 동시에 실행해 자원 경쟁의 영향을 평가한다. TPC-C를 다른 워크로드와 함께 실행한 경우 성능이 6.1–15.7% 감소했고, 공존 인스턴스 수를 늘린 실험에서는 평균 21.4% 감소했다. 논문은 연산 자원의 경쟁과 매핑 테이블의 캐시 미스를 주요 원인으로 설명한다.

그럼에도 논문의 비교 조건에서는 호스트 기반 처리보다 인스토리지 처리의 이점을 유지했다. 이 결과는 보안 격리와 자원 경쟁이 서로 다른 문제임을 보여준다. 프로그램을 격리해도 공유 CPU와 메모리의 경쟁까지 없어지는 것은 아니다.

정리

IceClave의 핵심은 사용자 연산을 SSD 내부에서 실행하면서도 플래시 관리와 데이터 보호의 경계를 유지하는 것이다. 성능 평가에서는 데이터 이동을 줄여 얻은 이점과 격리·암호화·검증으로 추가된 비용을 함께 봐야 한다.