KR102365263B1 - 하드웨어 기반의 gpu 메모리 보호를 위한 효율적인 암호화 방법 및 장치 - Google Patents

Abstract

하드웨어 기반의 GPU 메모리 보호를 위한 효율적인 암호화 방법 및 장치가 제시된다. 일 실시예에 따른 컴퓨터 장치를 통해 수행되는 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 방법은, GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용하는 단계를 포함하고, 상기 공통 카운터는 다수 개의 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 매핑할 수 있다.

Description

하드웨어 기반의 GPU 메모리 보호를 위한 효율적인 암호화 방법 및 장치{Efficient Encryption Method and Apparatus for Hardware-based Secure GPU Memory}

아래의 본 발명의 실시예들은 하드웨어 기반 GPU 메모리를 보호하는 효율적인 암호화 기술에 관한 것이다.

Intel Software Guard Extension(SGX) 및 ARM TrustZone과 같은 하드웨어 기반 신뢰할 수 있는 실행 환경(Trusted Execution Environment, TEE)은 신뢰할 수 없는 원격 클라우드 서버에서 사용자 애플리케이션의 안전한 실행을 제공한다. 이러한 하드웨어 TEE는 손상된 운영 체제 및 물리적 공격으로부터 사용자 실행 환경을 분리하고 보호함으로써 신뢰할 수 있는 클라우드의 새로운 방향을 선도한다. 그럼에도 불구하고 현재 TEE 지원의 중요한 한계는 널리 사용되는 GPU 기반 연산에 대한 고려가 부족하다는 것이다. 머신러닝(Machine Learning, ML) 워크로드의 광범위한 배치와 함께 GPU 컴퓨팅은 컴퓨팅 시스템의 필수적인 부분이 되었으며, 특히 ML 기반 서비스를 제공하는 클라우드에서 그러했다. 필수 GPU 연산을 보호하려면 TEE의 범위를 GPU 연산으로 확장해야 한다.

GPU TEE의 부족을 해결하기 위해, 최근 연구에서는 그러한 GPU 실행 환경에 대한 하드웨어 기반 강화 기법을 제안했다. Graviton은 중요 GPU 관리 작업을 CPU 측 드라이버로부터 분리하고, 이를 GPU 측 명령 처리 장치에 격리하여 악의적 권한 소프트웨어로부터 중요한 GPU 작업을 보호한다(비특허문헌 1). GPU 내부에서 이와 같이 격리된 GPU 관리를 제공하기 위해 GPU 서브시스템을 변경할 필요가 있다. 또한 HIX는 권한 소프트웨어로부터 PCIe I/O 서브시스템을 보호하고 CPU TEE로 GPU 드라이버를 보호할 것을 제안했다(비특허문헌 2). HIX는 GPU를 변경할 필요가 없지만 HIX가 직접 물리적 공격으로부터 보호해 주지 않아 위협모델은 Graviton보다 약하다.

이전 연구에서는 신뢰할 수 있는 GPU 컴퓨팅에 대한 시스템 설계를 제안했지만, 중요하게 언급되지 않은 구성요소는 GPU에 대한 하드웨어 기반 메모리 보호이다. Graviton은 GPU용 3D 적층 DRAM의 가용성에 의존하고 있으며, 3D 적층 DRAM의 메모리 내용이 유출되거나 훼손될 수 없다고 가정한다. 그러나 많은 GPU 시스템이 여전히 GDDRx 메모리를 사용할 뿐만 아니라 통합형 GPU도 기존의 DDRx 메모리를 사용한다. GPU TEE에 대한 일반적인 지원을 제공하려면 GPU 메모리에도 하드웨어 메모리 보호 기능을 사용할 수 있어야 한다. 그러나 하드웨어 기반 보호에는 비용이 많이 드는 암호화 및 무결성 검증이 필요하다.

최근에는 CPU 워크로드에 대한 하드웨어 기반 메모리 보호가 상당히 개선되었다. 최첨단 메모리 암호화는 카운터 기반 암호화를 사용하며, 암호화 키, 주소, 카운터를 기반으로 OTP(1회용 암호)를 생성한다. 메모리의 각 캐시라인 유닛에는 데이터의 새로운 보장을 위해 업데이트 때마다 증가되는 별도의 암호화 카운터가 있다. 카운터는 카운터 캐시에 캐싱되며, 마지막 레벨 캐시(Last-Level Cache, LLC)에서 누락된 데이터에 대한 카운터가 온칩 카운터 캐시에 있는 한, 누락된 데이터에 대한 OTP는 데이터가 메모리에서 돌아오기 전에 준비할 수 있어 암호 해독을 위한 간단한 XOR 작업이 필요하다. 무결성 검증은 각 캐시라인 데이터(MAC)의 키 해시 값을 사용하며, 카운터 값의 검증은 카운터 트리를 사용한다.

도 1은 일반적인 신뢰할 수 있는 GPU 실행 흐름을 설명하기 위한 도면이다.

최근의 연구는 효과적인 CPU 메모리(10, 11) 암호화와 무결성 보호를 가능하게 했지만, GPU 메모리(20, 21)의 보호는 아직 조사되지 않았다.

도 1의 (a)를 참조하면, 스누핑 공격으로부터 안전한 것으로 알려진 스택 메모리가 장착된 GPU(20) 전용으로 설계된 Graviton의 신뢰할 수 있는 GPU 실행을 나타내고, (b)를 참조하면, 메모리 보호 기술은 보다 일반적인 시스템에서 신뢰할 수 없는 기존 GDDRx 메모리(31)에 대한 기밀성과 무결성을 나타낸다.

S. Volos, K. Vaswani, and R. Bruno, "Graviton: Trusted Execution Environments on GPUs," in Operating Systems Design and Implementation (OSDI), 2018. R. C. Moerkle, "Protocols for Public Key Cryptosystems," in IEEE Symposium on Security and privacy (S&P), 1980. G. Saileshwar, P. J. Nair, P. Ramrakhyani, W. Elsasser, J. A. Joao, and M. K. Qureshi, "Morphable Counters: Enabling Compact Integrity Trees For Low-Overhead Secure Memories," in International Symposium on Microarchitecture (MICRO), 2018. B. Rogers, S. Chhabra, M. Prvulovic, and Y. Solihin, "Using Address Independent Seed Encryption and Bonsai Merkle Trees to Make Secure Processors OS- and Performance-Friendly," in International Symposium on Microarchitecture (MICRO), 2007. C. Yan, D. Englender, M. Prvulovic, B. Rogers, and Y. Solihin, "Improving Cost, Performance, and Security of Memory Encryption and Authentication," in International Symposium on Computer Architecture (ISCA), 2006. G. Saileshwar, P. J. Nair, P. Ramrakhyani, W. Elsasser, and M. K. Qureshi, "Synergy: Rethinking secure-memory design for errorcorrecting memories," in International Symposium on High Performance Computer Architecture (HPCA), 2018. O. Villa, M. Stephenson, D. Nellans, and S. W. Keckler, "NVBit: A Dynamic Binary Instrumentation Framework for NVIDIA GPUs," in International Symposium on Microarchitecture (MICRO), 2019.

본 발명의 실시예들은 하드웨어 기반의 GPU 메모리 보호를 위한 효율적인 암호화 방법 및 장치에 관하여 기술하며, 보다 구체적으로 GPU 프로그램의 일정한 쓰기 패턴을 활용하여 CPU 기반의 최신 메모리 보호 기법보다 높은 효율성을 달성하는 기술을 제공한다.

일 실시예에 따른 컴퓨터 장치를 통해 수행되는 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 방법은, GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용하는 단계를 포함하고, 상기 공통 카운터는 다수 개의 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 매핑할 수 있다.

상기 공통 카운터를 통해 카운터 캐시 누락으로 인해 발생하는 성능 오버헤드를 제거할 수 있다.

상기 GPU는 각 컨텍스트에 대해 몇 개의 공통 카운터를 유지하여 카운터 캐시 누락을 피할 수 있다.

LLC(Last-Level Cache) 누락 시, 요청된 주소가 상기 공통 카운터 중 하나인 메모리 청크에 대한 주소인 경우 암호화 엔진은 누락 처리 요청에 대한 공통 카운터 값 중 하나를 사용함에 따라 요청된 카운터가 상기 공통 카운터에 제공되는 경우에는 카운터 캐시에 접속하지 않을 수 있다.

상기 카운터를 공통 카운터를 기반으로 사용하는 단계는, 각 컨텍스트에 별도의 메모리 암호화 키가 제공되는 단계를 포함하고, 상기 각 컨텍스트에 별도의 메모리 암호화 키가 제공되는 단계는, 상기 GPU가 컨텍스트를 생성하면, 새로운 컨텍스트에 대한 메모리 암호화 키가 생성되고, 메모리 암호화 엔진은 요청된 데이터의 주소의 컨텍스트에 따라 메모리 암호화 키를 변경할 수 있다.

상기 카운터를 공통 카운터를 기반으로 사용하는 단계는, 상기 GPU는 요청된 주소가 공통 카운터에 의해 제공될 수 있는지 여부를 암호화 엔진에 알려주는 공통 카운터 상태 맵(Common Counter Status Map, CCSM)이라는 상태 표를 유지할 수 있다.

상기 카운터를 공통 카운터를 기반으로 사용하는 단계는, 상기 GPU가 컨텍스트를 실행할 때, 빠른 액세스를 위해 공통 카운터 세트를 온칩 스토리지에 저장할 수 있다.

상기 카운터를 공통 카운터를 기반으로 사용하는 단계는, 호스트 메모리에서 새 데이터를 복사하면 CPU 애플리케이션과 상기 GPU 사이의 공유 키로 암호화된 암호문서로 상기 GPU에 도착하고, 상기 GPU는 암호화된 데이터를 해독하고 상기 GPU 메모리는 새 데이터로 업데이트되는 단계; 및 데이터 전송 후, 상기 공통 카운터는 업데이트된 메모리 청크의 실제 카운터 값을 스캔하여 식별하는 단계를 포함할 수 있다.

상기 카운터를 공통 카운터를 기반으로 사용하는 단계는, 커널 실행이 완료되면 커널에 의해 업데이트된 메모리 페이지의 모든 카운터 값을 체크하고, 카운터를 스캔하면 카운터가 같은 메모리 청크가 식별되며, 업데이트된 메모리에 액세스하는 다음 커널 실행에 대한 공통 카운트 상태 맵(CCSM)이 업데이트될 수 있다.

다른 실시예에 따른 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 장치는, GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용하는 공통 카운터 기반 암호화부를 포함하고, 상기 공통 카운터는 다수 개의 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 매핑할 수 있다.

상기 공통 카운터를 통해 카운터 캐시 누락으로 인해 발생하는 성능 오버헤드를 제거할 수 있다.

상기 GPU는 각 컨텍스트에 대해 몇 개의 공통 카운터를 유지하여 카운터 캐시 누락을 피할 수 있다.

LLC(Last-Level Cache) 누락 시, 요청된 주소가 상기 공통 카운터 중 하나인 메모리 청크에 대한 주소인 경우 암호화 엔진은 누락 처리 요청에 대한 공통 카운터 값 중 하나를 사용함에 따라 요청된 카운터가 상기 공통 카운터에 제공되는 경우에는 카운터 캐시에 접속하지 않을 수 있다.

상기 공통 카운터 기반 암호화부는, 각 컨텍스트에 별도의 메모리 암호화 키가 제공되고, 상기 GPU가 컨텍스트를 생성하면, 새로운 컨텍스트에 대한 메모리 암호화 키가 생성되고, 메모리 암호화 엔진은 요청된 데이터의 주소의 컨텍스트에 따라 메모리 암호화 키를 변경할 수 있다.

상기 공통 카운터 기반 암호화부는, 상기 GPU는 요청된 주소가 공통 카운터에 의해 제공될 수 있는지 여부를 암호화 엔진에 알려주는 공통 카운터 상태 맵(Common Counter Status Map, CCSM)이라는 상태 표를 유지할 수 있다.

본 발명의 실시예들에 따르면 이종 컴퓨팅 이종 컴퓨팅 환경(CPU-GPU)에서 데이터 보호를 통해 클라우드를 사용하는 사용자의 데이터를 안전하게 보호할 수 있다.

또한, 본 발명의 실시예들에 따르면 임베디드와 같이 내장 GPU를 사용하는 환경(Autonomous driving, drone, etc) 에서도 해당 기법을 적용할 수 있기 때문에 보안 수준 향상을 기대할 수 있다.

도 1은 일반적인 신뢰할 수 있는 GPU 실행 흐름을 설명하기 위한 도면이다.
도 2는 일반적인 카운터 모드 암호화를 설명하기 위한 도면이다.
도 3은 일반적인 재생 공격 보호를 위한 무결성 트리 구조를 나타내는 도면이다.
도 4는 일반적인 기준 비보안 GPU에 비해 SC 128 지원 GPU의 성능 저하를 나타내는 도면이다.
도 5는 기존의 카운터 캐시 누락률을 비교하여 나타내는 도면이다.
도 6은 일 실시예에 따른 GPU 벤치마크를 분석 결과를 나타내는 도면이다.
도 7은 일 실시예에 따른 전체 실행 후 균일하게 업데이트된 청크에 대한 구별되는 카운터 값의 수를 나타내는 도면이다.
도 8은 일 실시예에 따른 실제 GPU 애플리케이션에 대해 균일하게 업데이트 된 데이터 청크의 비율을 나타내는 도면이다.
도 9는 일 실시예에 따른 메모리 보안 GPU 구조를 나타내는 도면이다.
도 10은 일 실시예에 따른 공통 카운터 보호 방식의 실행 흐름을 나타내는 도면이다.
도 11은 일 실시예에 따른 LLC 누락 처리 흐름을 나타내는 도면이다.

이하, 첨부된 도면을 참조하여 본 발명의 실시예들을 설명한다. 그러나, 기술되는 실시예들은 여러 가지 다른 형태로 변형될 수 있으며, 본 발명의 범위가 이하 설명되는 실시예들에 의하여 한정되는 것은 아니다. 또한, 여러 실시예들은 당해 기술분야에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위해서 제공되는 것이다. 도면에서 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다.

하드웨어 기반의 신뢰할 수 있는 실행은 보안 클라우드 컴퓨팅을 제공할 수 있는 새로운 유망한 기회를 열었다. 그럼에도 불구하고, 현재의 신뢰할 수 있는 실행 환경은 전통적인 CPU 기반 계산에 한정되어 있는 반면, 머신러닝과 같은 점점 더 중요한 워크로드는 GPU를 사용해야 한다. 보안 GPU 컴퓨팅을 위해 최근 연구에서는 GPU에 대해 신뢰할 수 있는 실행을 제공하여 중요한 GPU 운영을 운영 체제에서 격리할 것을 제안했다. 그러나 이전 GPU 신뢰 실행에서 누락된 구성요소는 GPU의 하드웨어 기반 메모리 보호이다. CPU에 대한 최첨단 메모리 보호 기술은 카운터 모드 암호화를 사용하며, 여기서 블록별 카운터는 타임 패드 생성을 위한 타임스탬프로 사용된다. 카운터의 무결성은 카운터 트리에 의해 보호된다.

본 발명의 GPU에 대한 하드웨어 메모리 암호화를 조사하고 카운터 캐시 누락을 주요 성능 병목 현상으로 파악한다. 하드웨어 기반 보안 GPU 메모리의 오버헤드를 줄이기 위해, 효율적인 카운터 모드 암호화 및 카운터 무결성 트리를 위해 공통 카운터라고 불리는 기술을 제안한다. 제안된 기술은 일반적인 GPU 애플리케이션의 고유한 특성을 이용한다. GPU 애플리케이션에서 애플리케이션 메모리의 상당 부분은 CPU 메모리로부터의 초기 데이터 전송에 의해 한 번만 기록되며, GPU 애플리케이션이 주요 출력 데이터 구조에 대해 쓰는 횟수는 균일하게 되는 경향이 있다. 균일한 쓰기 속성에 따라 본 발명의 공통 카운터 표현을 사용하여 기존의 블록별 암호화 카운터를 보완할 것을 제안한다. 공통 카운터 표현을 통해 제안된 기법은 카운터 캐시 누락으로 인한 중요한 성능 오버헤드를 거의 제거할 수 있다.

아래의 본 발명의 실시예들은 Graviton(비특허문헌 1)이 제안한 GPU에 대한 신뢰할 수 있는 실행 모델을 바탕으로, GPU 메모리 보호의 성능 영향을 평가하고 성능 저하를 완화하기 위한 새로운 기법을 제안하는 첫 번째 연구이다. 조사에 따르면, 카운터 캐시 누락은 카운터 블록의 공간적 인접성이 낮은 GPU 애플리케이션의 성능 저하를 크게 초래할 수 있다. 고성능을 위해 GPU를 사용함에 따라 보안을 위한 성능 오버헤드가 GPU에 대한 신뢰할 수 있는 컴퓨팅의 빠르고 광범위한 채택을 지연시키고 있을 수 있다.

실시예들은 메모리 보호에 의한 성능 저하를 완화하기 위해 GPU 애플리케이션의 고유한 특성을 이용하여 공통 카운터라고 하는 GPU에 대한 새로운 카운터 표현 기법을 제안한다. GPU 애플리케이션의 경우 애플리케이션 메모리의 많은 부분이 CPU 메모리에서 초기 데이터 전송에 의해 한 번 기록된다. 또한, 많은 GPU 커널의 실행은 출력 데이터 구조의 각 요소에 대해 동일한 수의 쓰기를 생성하는 경향이 있으므로 커널 실행 후에는 데이터 구조에 속하는 각 메모리 블록의 카운터 값이 동일한 경향이 있다. 따라서 GPU 애플리케이션이 데이터 의존성을 가진 커널의 다중 실행으로 구성되는 경우, 카운터 값은 커널 실행 흐름 전체에서 균일하게 증가되는 경향이 있다.

여기에서는 GPU 애플리케이션에서 바꿔 쓰기가 안되는 속성과 카운터 값의 균일한 진행률을 이용하여 공통적인 카운터 표현을 제안하며, 이는 기존의 캐시라인 단위 카운터 관리를 강화한다. 제안된 메커니즘은 커널 실행 또는 CPU 측 코드로부터의 데이터 전송 후 캐시라인 데이터 단위에 대해 동일한 카운터 값을 가지는 메모리 청크를 효율적으로 확인한다. 커널 실행 중, 캐시라인에 대한 카운터가 일련의 공통 카운터 값에서 제공될 수 있는 경우, 메커니즘은 카운터 캐시를 우회하여 공통 카운터 값을 제공한다. 대부분의 데이터 액세스의 경우, 대응하는 카운터 값은 몇 개의 공통 카운터 값에서 얻으므로 카운터 캐시 누락을 피한다.

이러한 공통 카운터를 활성화하려면 컨텍스트(context) 생성 중에 애플리케이션 메모리의 모든 카운터를 재설정해야 하므로, 각 애플리케이션의 GPU 컨텍스트는 다른 메모리 암호화 키를 사용해야 한다. 일단 신뢰할 수 있는 GPU 명령 프로세서에 의해 GPU 컨텍스트가 생성되면 컨텍스트에 대한 메모리 페이지는 컨텍스트별 암호화 키에 의해 암호화되고 컨텍스트에 할당된 메모리 블록에 대한 카운터 값은 재설정된다. 새 컨텍스트의 메모리 페이지는 새 키로 암호화되므로 이 카운터 리셋은 보안 요건을 위반하지 않는다.

GPGPU-Sim을 사용한 시뮬레이션을 기반으로 한 평가는 제안된 카운터 관리 기법이 카운터 캐시 누락에 의한 성능 오버헤드를 거의 제거할 수 있다는 것을 보여준다. GPU 애플리케이션 세트의 메모리 보호에 의한 성능 저하는 2.7%로 감소하는 반면, Morphable 카운터(비특허문헌 3)를 사용한 최신 개선은 11.9%의 성능 저하를 보일 수 있다.

하드웨어 기반 GPU 메모리 보호에 대한 첫 번째 연구로서 본 발명의 기여는 다음과 같다.

* 신뢰할 수 있는 GPU 실행 모델에 기존의 최신 CPU 기반 메모리 보호 기술을 적용한다. 이는 카운터 캐시 누락이 GPU 실행에서 성능 저하의 주요 원인임을 식별한다.

* GPU 애플리케이션에서 카운터 값의 고유한 동작이 변화하며, 여기서 카운터 값이 애플리케이션 내에서 몇 가지 공통 값으로 진행된다는 것을 식별한다.

* 공통 카운터를 식별하고 LLC(Last-Level Cache) 누락 처리를 위한 공통 카운터를 제공하여 카운터 캐시를 효과적으로 우회할 수 있는 효율적인 메커니즘을 제안한다.

GPU에 대한 신뢰할 수 있는 실행

CPU에 대한 신뢰할 수 있는 실행 환경(TEE)은 악의적 권한 소프트웨어 및 물리적 공격으로부터 보호되는 격리된 실행 환경을 제공한다. 인텔 Software Guard Extension(SGX)는 사용자 애플리케이션이 enclave라는 TEE를 만들 수 있도록 하며, 실행 환경과 메모리 페이지를 포함한 컨텍스트는 하드웨어 메커니즘에 의해 보호된다. TEE를 지원하기 위해 첫째, 액세스 격리 메커니즘은 권한 있거나 권한 없는 enclave가 아닌 코드가 enclave 실행 환경 및 페이지에 액세스하지 못하도록 방지한다. 둘째, 하드웨어 메모리 보호 메커니즘은 외부 DRAM에 대한 잠재적인 물리적 공격 하에서 외장 메모리 페이지의 기밀성과 무결성을 지원한다. 셋째, 증명 메커니즘은 원격 또는 로컬 사용자가 enclave에서 실행하는 TEE 환경 및 코드의 유효성을 확인할 수 있도록 한다.

GPU에 대한 TEE를 제공하기 위해, 최근의 두 연구는 절충을 통한 두 가지 다른 방법을 제안했다. 첫째, Graviton은 GPU를 시스템의 나머지 부분으로부터의 완전한 하드웨어 기반 격리를 제안하였다(비특허문헌 1). 각 GPU에는 자신을 식별할 수 있는 고유한 개인 키가 내장되어 있다. 또한, 컨텍스트 생성, 메모리 페이지 할당 등 중요한 GPU 관리 작업은 GPU 내부의 명령 프로세서에 의해 수행되어야 한다. GPU 내부에서 그러한 중요 작업을 수행함으로써 사용자 애플리케이션은 운영체제의 간섭을 우회하여 직접적이고 안전하게 GPU에 명령을 전송할 수 있다. 사용자 애플리케이션을 보호하기 위해 CPU 측 사용자 애플리케이션이 enclave에서 실행되며, CPU enclave와 GPU는 GPU 환경을 증명하고 공통 키를 공유하여 컨텍스트 생성 중에 신뢰를 구축한다.

다른 방법은 GPU 변경을 요구하지 않는 것이다. HIX는 상품 GPU를 변경하지 않고 GPU TEE를 제공할 것을 제안했다(비특허문헌 2). HIX는 고유 키를 내장하고 GPU 내에서 관리 작업을 수행하도록 GPU를 수정하도록 요구하는 대신 PCIe I/O 서브시스템을 확보할 것을 제안했다. GPU 드라이버는 특수한 GPU enclave에서 실행함으로써 운영체제로부터 격리되고 PCIe 라우팅 테이블은 잠겨 있어 손상된 운영체제가 GPU로 의도한 패킷을 임의로 재라우팅할 수 없다. HIX는 범용 GPU에 TEE를 허용하고 다른 PCIe 연결 가속기를 쉽게 지원할 수 있지만, PCIe 인터커넥트가 마더보드에 노출되기 때문에 물리적 공격에 대한 보호 기능을 제공하지는 않는다.

본 발명은 물리적 공격에 대한 GPU 메모리 보호를 제안하므로, Graviton(비특허문헌 1) GPU는 운영체제의 드라이버로부터 스스로를 격리시키기 위해 수정되는 접근법에 기초한다. 단, 이전 접근방식에서 누락된 TEE의 한 가지 중요한 구성요소는 GPU의 메모리를 보호하는 방법이다. CPU TEE의 경우, 외부 비보안 DRAM에 존재하는 메모리 데이터의 기밀성과 무결성을 제공하는 데 상당한 개선이 있었다. 그러나 Graviton은 HBM(고 대역폭 메모리)과 같은 3D 적층 DRAM이 GPU에 사용할 수 있으며, 3D 적층 DRAM의 데이터는 어떠한 물리적 공격에서도 항상 안전하다고 가정한다. 그러나 많은 일반 GPU는 여전히 물리적 공격에 취약한 훨씬 저렴한 GDDRx 메모리에 의존할 것이다. 또한, 내장된 GPU는 CPU와 동일한 DDRx 메모리를 공유한다. GDDRx의 광범위한 사용과 물리적 공격에 대한 취약성을 고려하여 GPU에 대한 하드웨어 기반 메모리 보호의 성능 시사점을 조사하는 것이 필수적이다.

위협 모델(Threat Model)

본 발명의 신뢰할 수 있는 컴퓨팅 기초(TCB)는 보안 GPU 칩과 그 칩에서 실행되는 GPU 소프트웨어이다. 또한, 이전 연구에서 가정된 바와 같이, GPU 애플리케이션을 시작하는 CPU 측 사용자 애플리케이션이 CPU enclave에서 실행되고 있다. 따라서 enclave에서 실행 중인 CPU 칩과 사용자 소프트웨어도 TCB에 포함된다. 본 발명은 공격자가 운영 체제와 기타 권한 소프트웨어를 완전히 제어할 수 있고 CPU 메모리 버스, PCIe 인터커넥트, GPU 메모리 인터커넥트 등 노출된 시스템 구성 요소에 대해 probing 버스와 같은 물리적 공격을 행사할 수 있다고 가정한다.

그러나 손상된 OS가 CPU 측 애플리케이션의 실행을 차단할 수 있기 때문에 GPU 계산의 가용성을 제공하지 않는다. 또한 GPU나 CPU에 대한 측면 채널 공격은 본 발명의 범위를 벗어난다. 본 발명의 위협 모델은 일반적으로 다음과 같다.

그러나 손상된 OS가 CPU 측 애플리케이션의 실행을 차단할 수 있기 때문에 본 발명에서는 GPU 계산의 가용성을 제공하지 않는다. 또한 GPU나 CPU에 대한 측면 채널 공격은 본 발명의 범위를 벗어난다. 본 발명의 위협 모델은 GPU GDDRx 메모리의 취약성을 제외하고 일반적으로 Graviton(비특허문헌 1)과 동일하다.

신뢰할 수 있는 실행을 위한 메모리 보호

메모리 보호는 신뢰할 수 없는 외부 DRAM에 상주하는 데이터의 기밀성과 무결성을 모두 지원해야 한다. 메모리 블록이 온칩 캐시에 들어오면 블록의 암호를 해독하고 무결성을 검증해야 한다. 수정된 캐시라인이 퇴출되면 메모리 블록이 암호화되고 암호화된 데이터와 함께 무결성 메타 데이터도 작성된다. 기밀성을 위한 일반적인 하드웨어 암호화는 1회용 암호(One Time Pad, OTP)를 사용한 카운터 기반 암호화를 사용한다.

도 2는 일반적인 카운터 모드 암호화를 설명하기 위한 도면이다.

도 2에 도시된 바와 같이, 암호화는 (1) 암호화 키(201), 주소(203) 및 카운터(203) 값에서 OTP(220)를 생성하고, (2) 제거된 캐시라인으로 OTP(220)를 XOR로 설정하여 수행한다. AES(210)와 같은 대칭 블록 암호는 OTP(220)를 생성하는 데 사용된다. 메모리 블록의 각 캐시라인 단위에 대해서는 별도의 카운터(203)를 유지해야 하며, 온칩 캐시에서 쓰기 축출에 의해 메모리 블록이 업데이트될 때마다 카운터(203) 값이 증가한다. 각 블록별 카운터(203)는 동일한 암호화 키(201)를 사용하더라도 암호화된 데이터(240)의 새로움을 보장한다.

무결성 검증은 데이터의 손상을 감지한다. 무결성 검증을 위해 이전 연구와 상업적 프로세서에 Merkle 트리 변형을 채택한다. 간단한 설계는 전체 메모리 블록에서 해시 값의 트리를 만든다. 트리의 루트는 보안 프로세서를 떠나지 않지만 나머지 해시 트리 노드는 비보안 메모리에 존재할 수 있다. 성능을 위해 해시 트리의 일부를 프로세서 내부의 해시 캐시에 저장할 수 있다. LLC 누락에 의해 프로세서에 메모리 블록이 들어오면, 트리의 저장된 해시 값에 대해 메모리 블록의 계산된 해시 값이 검증된다. 해당 해시 값이 해시 캐시에 존재하지 않는 경우 해시 노드를 메모리에서 읽고 해시 값의 상위 노드에서 먼저 검증해야 한다.

해시 트리와 카운터 모드 암호화를 결합하여 무결성 트리에 대한 개선 사항을 조사하였다. 데이터 메모리 영역 전체를 트리의 리프 노드로 덮어야 하므로 원래 Merkle 트리의 높이는 높을 수 있다. 개선된 Bonsai Merkle 트리(BMT)는 메모리 블록의 카운터 값만으로 해시 트리를 생성한다(비특허문헌 4). 각 메모리 블록에 대해 무결성 확인을 위해 키 해시 값 또는 메시지 인증 코드(MAC)가 생성된다. 또한, 카운터(Bonsai Merkle 트리)의 무결성 트리는 잠재적인 재생 공격을 방지하기 위해 카운터의 새로움를 보장한다. BMT는 카운터만을 위한 작은 메모리 영역을 포괄하기 때문에 높이가 훨씬 낮다.

도 3은 일반적인 재생 공격 보호를 위한 무결성 트리 구조를 나타내는 도면이다.

도 3에 도시된 바와 같이, 중간 트리 노드의 단일 블록에서 더 많은 카운터를 압축하기 위해 BMT가 개선되었다. 카운터 블록은 데이터 캐시라인과 동일한 크기로 구성되는 경우가 많다. 단일 카운터 블록에 더 많은 카운터를 저장할 수 있어 카운터 캐시의 효율성이 향상될 뿐만 아니라 카운터 무결성 트리의 높이도 낮아진다. 분할 카운터(비특허문헌 5)는 카운터 값을 마이너 카운터와 메이저 카운터로 분해하는 기법을 제안한다. 카운터 블록 내에서 각 카운터에는 마이너 카운터가 있으며, 동일한 카운터 블록에 있는 모든 카운터는 하나의 메이저 카운터를 공유한다. 마이너 카운터가 한계에 도달하면 메이저 카운터가 증가한다. VAULT는 카운터의 소형 표현과 마이너 카운터 오버플로우에 의한 재암호화 비용 사이의 균형을 유지하도록 트리의 각 레벨에 대해 다른 arity를 채택하여 카운터 무결성 트리를 개선한다. 형태 변환 가능한 카운터는 카운터 블록당 128개의 카운터를 패킹하여 카운터를 더욱 소형화할 것을 제안했다(비특허문헌 3). 애플리케이션의 카운터 변경 동작에 맞추어 카운터 표현을 동적으로 변경한다.

보안 GPU 메모리의 성능 영향

앞에서 논의된 세 가지 기존 메모리 보호 기법은 GPU 시뮬레이터를 모델로 한다. 여기에서는 기준으로서 보안 기능이 없는 vanilla GPU와 비교하여 메모리 보안 GPU의 성능 특성을 수행한다. 평가된 메모리 보호 기술은 (1) Bonsai Merkle 트리(BMT)(비특허문헌 4), (2) 캐시라인당 128개의 카운터가 있는 분할 카운터(비특허문헌 5), (3) Morphable 카운터(비특허문헌 3)이다. 메모리 보안 GPU 3종 모두 16KB 카운터 캐시를 탑재해 각 캐시라인당 BMT와 SC 128팩 128개 암호화 카운터를 탑재한 반면, Morphable은 256개 카운터를 탑재한다.

카운터 기반 메모리 보호 기법이 GPU에 미치는 성능 영향을 설명한다. 성능 저하 요인을 보다 잘 이해하기 위해 먼저 SC 128 지원 GPU를 살펴보고 성능 저하를 가져오는 것이 무엇인지 살펴본다.

도 4는 일반적인 기준 비보안 GPU에 비해 SC 128 지원 GPU의 성능 저하를 나타내는 도면이다.

도 4를 참조하면, 접두사 Ideal은 카운터 및 MAC 검색으로 인한 성능 오버헤드가 존재하지 않는 가상의 경우를 나타낸다. vanilla SC 128을 어떤 것에 idealizing 하지 않고 GPU에 구현하면 GPU는 ges, atax, mvt, bicg, lib, sc, bfs 등 메모리 집약적인 벤치마크에서 lib에서의 34.7%에서 ges의 75.6%에 이르기까지 상당한 성능 손실을 경험한다. 그러나 nn, sto, ray, nqu를 포함한 계산 집약적인 벤치마크는 성능 저하를 거의 경험하지 않는다. 결과는 카운터와 MAC에 대한 메모리 액세스가 성능 손실의 주요 원인임을 보여준다. 카운터 캐시 크기가 무한하고 GPU가 카운터 캐시 누락(즉, Ideal Ctr + MAC)을 경험하지 않는다고 가정할 때, 카운터 읽기 및 암호 해독이 임계 경로에 있고 성능에 큰 영향을 미치기 때문에 상당한 성능 향상을 관찰한다. 마지막으로, MAC 읽기 때문에 대역폭 손실이 없는 또 다른 이상적인 경우를 가정하면 성능이 더욱 향상된다. 최근 선행 연구인 Synergy(비특허문헌 6)는 데이터와 MAC의 병렬 읽기를 가능하게 하는 ECC 칩을 사용하여 MAC를 운반할 것을 제안하고, MAC에 의한 성능 오버헤드를 효과적으로 제거한다. 그러나 대부분의 벤치마크의 경우, 카운터로 인한 오버헤드를 제거함으로써 유입된 성과이익에 비해 상대적으로 개선폭이 작다.

도 5는 기존의 카운터 캐시 누락률을 비교하여 나타내는 도면이다.

이러한 경향은 이전 연구에서 제안된 다른 카운터 기반 메모리 보호 기법과 유사하다. 도 5를 참조하면, 이전 세 작업의 카운터 캐시 누락률을 비교한다. BMT와 SC 128의 카운터 arity는 128과 동일하기 때문에, 카운터 캐시 누락률은 대략 동일하므로 유사한 성능 영향을 야기한다. Morphabe은 arity가 256이기 때문에 카운터 캐시 누락으로 인한 어려움을 덜 겪는다. 그러나, 그 성능은 여전히 많은 영향을 받는다.

GPU 애플리케이션의 쓰기 특성

본 발명의 주요 목적은 카운터 캐시 누락으로 인해 발생하는 성능 오버헤드를 줄이는 것이다. 이 목표를 달성하기 위해 메모리 쓰기에 GPU 애플리케이션의 고유한 속성을 활용하고, 보안 GPU를 위한 효율적인 암호화 엔진을 제공한다. GPU가 일반적으로 스트리밍 방식으로 데이터를 이동하는 속성은 성능 SI를 훼손하지 않고 메모리 보안 GPU 아키텍처용 GPU 애플리케이션의 고유한 속성을 식별하도록 동기를 부여했다. GPU 애플리케이션은 상당히 균일한 방식으로 할당된 메모리 영역에 대한 메모리 쓰기를 생성하는 경향이 있다. GPU 컨텍스트에서 할당된 영역의 대부분은 (1) 호스트로부터의 초기 메모리 복사본에 대해 한 번 또는 (2) 애플리케이션이 할당된 메모리를 휩쓸면서 데이터를 쓰는 경우 두 번 이상 동일한 수의 쓰기를 수신하는 경우가 많다.

여기에서는 실제 GPU를 사용하여 실험을 수행한다. NVBit(비특허문헌 7)를 사용하여 GPU 애플리케이션의 이진 계측을 수행하고 메모리 흔적을 수집한다. NVBit는 모든 로드 및 저장 메모리 액세스를 캡처하고 액세스한 가상 주소를 기록할 수 있도록 허용한다. 그러나 NVBit에는 (1) 캐시에서 액세스가 누락되는지 여부를 프로파일링하는 기능과 (2) 액세스가 누락될 때 라이트 백이 필요한지 여부를 식별하는 기능이 부족하다. 따라서, LLC 누락 흔적이 아닌 GPU 코어의 메모리 액세스 흔적으로 쓰기 동작을 분석한다.

메모리 액세스 카운트에 얼마나 많은 균일성이 있는지 조사하기 위해 컨텍스트에 대한 메모리 공간을 고정 크기 데이터 청크 세트로 나누고, 각 청크에 대해 청크의 모든 캐시라인이 어떻게 업데이트되는지 추적한다. 청크의 캐시라인이 균일한 방식으로 업데이트되는 경우 청크는 균일하게 업데이트된 청크로 표시된다. 여기에서는 총 메모리 크기에 대해 균일하게 업데이트된 청크의 비율을 분석한다.

본 실시예들은 두 가지 유형의 시나리오를 사용한다. 첫째, GPU 벤치마크 분석은 본 발명의 주요 평가에 사용된 벤치마크 세트를 사용한다. 여기에서는 시뮬레이터를 사용하는 대신 실제 시스템에서 실행한다. 둘째, 더 복잡한 설정을 위해 7개의 실제 애플리케이션을 평가한다.

도 6은 일 실시예에 따른 GPU 벤치마크를 분석 결과를 나타내는 도면이다.

도 6을 참조하면, 청크 크기를 32KB에서 2MB로 변경하여 총 청크 수에 대해 균일하게 업데이트된 청크의 비율을 보고한다. 각 막대는 두 범주로 분해된다. (1) 읽기 전용(실선)은 호스트의 초기 쓰기 동안만 업데이트된 메모리 청크를 나타내며, (2) None 읽기 전용(점선)은 청크에서 각 캐시라인에 대해 두 개 이상의 쓰기가 있는 청크를 보여준다. 평균적으로 32KB 청크 크기를 사용할 때 전체 청크의 60.9%가 균일하게 업데이트된 청크이다. 2MB 청크 크기를 사용할 경우 청크의 27.5%가 균일하게 업데이트된다. 청크 크기가 증가하면 청크가 캐시라인 수를 더 많이 커버하고 커널 실행 중에 분산될 가능성이 높기 때문에 동일한 카운터 값을 갖는 청크 내의 모든 캐시라인의 가능성이 감소한다. 균일하게 업데이트된 청크의 상당 부분은 읽기 전용 데이터이다. 그러나 몇 가지 벤치마크 애플리케이션(fdtd-2d, sssp, pr, lib, hotspot, srad v2)의 경우 메모리 청크의 상당 부분이 두 번 이상 업데이트된다. 읽기 전용이 아닌 것(점선)은 청크에서 각 캐시라인에 대해 두 개 이상의 쓰기가 있는 청크를 보여준다. 평균적으로 32KB 청크 크기를 사용할 때 전체 청크의 60.9%가 균일하게 업데이트된 청크이다. 2MB 청크 크기를 사용할 경우 청크의 27.5%가 균일하게 업데이트된다. 청크 크기가 증가하면 청크가 캐시라인 수를 더 많이 커버하고 커널 실행 중에 분산될 가능성이 높기 때문에 동일한 카운터 값을 갖는 청크 내의 모든 캐시라인의 가능성이 감소한다. 균일하게 업데이트된 청크의 상당 부분은 읽기 전용 데이터이다. 그러나 몇 가지 벤치마크 애플리케이션(fdtd-2d, sssp, pr, lib, hotspot, srad v2)의 경우 메모리 청크의 중요한 부분이 몇 번이고 업데이트된다.

도 7은 일 실시예에 따른 전체 실행 후 균일하게 업데이트된 청크에 대한 구별되는 카운터 값의 수를 나타내는 도면이다.

도 7을 참조하면, 읽기 전용 데이터가 있는 벤치마크 애플리케이션의 경우, 균일하게 업데이트된 청크가 한 번 작성되기 때문에 구별되는 카운터 값의 수는 1이다. 그러나 읽기 전용 데이터가 없는 벤치마크의 경우 구별되는 카운터 값의 수는 2와 3이 될 수 있다. 벤치마크에 따라 실제 카운터 값이 크게 다르다는 점에 유의한다. 결과는 균일하게 업데이트된 청크가 존재한다면, 이들의 업데이트 수는 크게 달라지지 않는다는 것을 보여준다.

실제 애플리케이션 분석 결과는 다음과 같다. 이진 계측을 엄청나게 오랜 시간 실행하지 않고 더 큰 GPU 애플리케이션의 속성 보유를 입증하기 위해, 7개의 완전한 GPU 애플리케이션을 선택한다. (1) GoogLeNet 및 ResNet-50, (2) ScratchGAN용 DNN 교육의 반복 실행, (3) 최단 경로를 찾기 위한 Dijkstra 알고리즘, (4) CUDA 동적 병렬 처리를 활용한 2D-맵에서 Quadtree로의 전환, (5) 에지 감지를 위한 Sobel-filter 알고리즘, (6) fat 클라우드(FS FatCloud)용 3D Fluid 시뮬레이션이다.

도 8은 일 실시예에 따른 실제 GPU 애플리케이션에 대해 균일하게 업데이트 된 데이터 청크의 비율을 나타내는 도면이다.

도 8을 참조하면, 데이터 청크 크기를 32KB에서 2MB로 늘림에 따라 128B 크기의 캐시라인 모두가 단일 카운터 값을 공유하는 데이터 청크의 비율을 보여준다. 애플리케이션은 GPU 벤치마크에 비해 균일하게 업데이트된 데이터 청크의 비율이 낮은 경향이 있지만, 데이터 청크의 상당 부분은 여전히 균일한 쓰기 속성을 나타낸다. GoogLeNet은 청크 크기에 따라 카운터 값이 같은 데이터 청크가 34.5%~84.4%에 이른다. ResNet-50 및 ScratchGAN은 GoogLeNet보다 더 복잡한 모델 구조를 가지고 있어서 균일하게 쓰여진 메모리 청크의 수가 적다. 평균적으로 32KB 청크 크기를 사용할 때 전체 청크의 59.6%가 균일하게 업데이트된다. 2MB 청크 크기를 사용할 경우 29.3%가 균일하게 업데이트된다. GoogLeNet, ResNet-50, ScratchGAN, Dijkstra, Sobel-filter는 대부분 읽기 전용이지만 Quadtree와 FS Fatcloud는 읽기 전용이 아니다.

아래에서는 본 발명의 구조에 대해 설명한다.

일 실시예에 따른 컴퓨터 장치를 통해 수행되는 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 방법은, GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용하는 단계를 포함할 수 있다.

일 실실시예에 따른 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 방법은 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 장치를 예를 들어 설명할 수 있다. 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 장치는 공통 카운터 기반 암호화부를 포함하여 이루어질 수 있다.

공통 카운터 기반 암호화부는 GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용할 수 있다. 여기서, 공통 카운터는 다수 개의 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 매핑할 수 있다. 이러한 공통 카운터를 통해 카운터 캐시 누락으로 인해 발생하는 성능 오버헤드를 제거할 수 있다.

GPU는 각 컨텍스트에 대해 몇 개의 공통 카운터를 유지하여 카운터 캐시 누락을 피할 수 있다. 공통 카운터 기반 암호화부는, LLC(Last-Level Cache) 누락 시, 요청된 주소가 공통 카운터 중 하나인 메모리 청크에 대한 주소인 경우 암호화 엔진은 누락 처리 요청에 대한 공통 카운터 값 중 하나를 사용함에 따라 요청된 카운터가 공통 카운터에 제공되는 경우에는 카운터 캐시에 접속하지 않을 수 있다.

공통 카운터 기반 암호화부는 각 컨텍스트에 별도의 메모리 암호화 키가 제공되고, GPU가 컨텍스트를 생성하면, 새로운 컨텍스트에 대한 메모리 암호화 키가 생성되고, 메모리 암호화 엔진은 요청된 데이터의 주소의 컨텍스트에 따라 메모리 암호화 키를 변경할 수 있다. 또한, 공통 카운터 기반 암호화부는 GPU는 요청된 주소가 공통 카운터에 의해 제공될 수 있는지 여부를 암호화 엔진에 알려주는 공통 카운터 상태 맵(Common Counter Status Map, CCSM)이라는 상태 표를 유지할 수 있다. 공통 카운터 기반 암호화부는 GPU가 컨텍스트를 실행할 때, 빠른 액세스를 위해 공통 카운터 세트를 온칩 스토리지에 저장할 수 있다.

공통 카운터 기반 암호화부는 호스트 메모리에서 새 데이터를 복사하면 CPU 애플리케이션과 GPU 사이의 공유 키로 암호화된 암호문서로 GPU에 도착하고, GPU는 암호화된 데이터를 해독하고 GPU 메모리는 새 데이터로 업데이트되는 단계; 및 데이터 전송 후, 공통 카운터는 업데이트된 메모리 청크의 실제 카운터 값을 스캔하여 식별하는 단계를 포함할 수 있다.

또한, 공통 카운터 기반 암호화부는 커널 실행이 완료되면 커널에 의해 업데이트된 메모리 페이지의 모든 카운터 값을 체크하고, 카운터를 스캔하면 카운터가 같은 메모리 청크가 식별되며, 업데이트된 메모리에 액세스하는 다음 커널 실행에 대한 공통 카운트 상태 맵(CCSM)이 업데이트될 수 있다.

실시예들은 하드웨어 기반 GPU 메모리를 보호하는 효율적인 암호화 기술을 통해 GPU 프로그램의 균일한 쓰기 패턴을 활용하여 CPU 기반의 최신 메모리 보호 기법보다 높은 효율성을 달성할 수 있다. 특히, 메모리 쓰기 패턴에 따라 암호화 과정에 사용하는 카운터를 달리 사용함으로써 성능 저하를 최소화할 수 있다.

실시예들에 따르면 이종 컴퓨팅을 사용하는 환경에서 CPU 및 GPU 데이터를 보호하고, 악의적인 시스템 소프트웨어 및 DRAM에 대한 물리적 공격으로부터 데이터를 보호할 수 있다. 또한, 기존의 CPU 기반의 메모리 보호기법 보다 GPU 프로그램의 특성을 활용하여, 낮은 성능 오버헤드로 GPU 메모리에 존재하는 데이터를 보호할 수 있다.

아래에서 일 실시예에 따른 컴퓨터 장치를 통해 수행되는 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 방법 및 장치에 대해 보다 상세히 설명한다.

GPU에서 카운터 캐시 누락에 의한 성능 손실을 줄이기 위해, 본 발명은 앞에서 논의한 공통 GPU 애플리케이션의 통일된 메모리 쓰기 동작을 활용한다. GPU 애플리케이션 메모리의 대부분은 애플리케이션 초기화 중에 애플리케이션의 카운터가 재설정되는 경우 가능한 몇 가지 카운터 값 중 하나를 가진다. 공통 카운터(COMMONCOUNTER)라고 불리는 제안된 기술은 많은 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 효율적으로 매핑하는 것을 제공한다. GPU는 각 컨텍스트에 대해 몇 개의 공통 카운터(공통 카운터 세트(set))를 유지한다. LLC(Last-Level Cache) 누락의 경우, 요청된 주소가 공통 카운터 중 하나인 메모리 청크에 대한 주소인 경우 암호화 엔진은 누락 처리 요청에 대한 공통 카운터 값 중 하나를 사용할 수 있다. 따라서 요청된 카운터가 공통 카운터에 제공될 수 있는 경우에는 카운터 캐시에 접속하지 않는다.

도 9는 일 실시예에 따른 메모리 보안 GPU 구조를 나타내는 도면이다.

많은 메모리 청크에 대해 이러한 공유 공통 카운터를 지원하려면 몇 가지 변경이 필요하다. 공통 카운터에 필요한 하드웨어 수정사항은 도 9에 기술되어 있다. 예를 들어, GPU(910)에 키 생성(911), 암호화 엔진(912), 무결성 엔진(913), 해시 캐시(914), 카운트 캐시(915) 및 CCSM 캐시의 구성이 추가될 수 있다. 여기서 GPU(910)는 기존의 연산 엔진(917) 및 공유 L2 캐시(918)을 포함할 수 있다. 또한, 신뢰할 수 없는 GPU 메모리(920)는 암호화 데이터(921, 922), 트리 노드(923), 데이터 MAC(924), Enc 카운트(925), CCSM 엔트리(926) 및 업데이트 메모리 영역 맵(927)을 포함할 수 있다.

첫째, 각 컨텍스트에는 별도의 메모리 암호화 키가 있어야 한다. 보안 GPU 명령 프로세서가 컨텍스트에 대해 새 페이지를 할당하면 프로세서는 키로 메모리 페이지를 다시 암호화하여 카운터 값을 0으로 재설정한다. 둘째, GPU 하드웨어는 요청된 주소가 공통 카운터에 의해 제공될 수 있는지 여부를 암호화 엔진에 알려주는 공통 카운터 상태 맵(CCSM)이라는 상태 표를 유지한다.

공통 카운터 표현은 기존 캐시라인별 암호화 카운터를 보완하며, 암호화 카운터 및 카운터 무결성 트리는 여전히 유지되어야 한다는 점에 유의한다. 공통 카운터는 많은 페이지가 동일한 카운터 값을 가질 때, 매우 작은 카운터 표현으로 메모리 블록의 카운터 값을 반환하기만 하면 된다. 따라서 GPU 커널이 메모리 블록을 업데이트하면 메모리 청크의 카운터 값이 순간에서 벗어나기 때문에 해당 메모리 청크는 더 이상 공통 카운터와 함께 제공될 수 없다. 따라서 업데이트된 데이터가 있는 LLC 제거의 경우 원래 카운터 값도 업데이트해야 한다. 또한, CCSM은 메모리 청크가 더 이상 공통 카운터를 사용할 수 없음을 표시한다.

도 10은 일 실시예에 따른 공통 카운터 보호 방식의 실행 흐름을 나타내는 도면이다.

도 10을 참조하면, 공통 카운터는 두 가지 이벤트에서 식별된다. 첫 번째 이벤트는 호스트 메모리로부터의 초기 데이터 전송(1010)이다. 호스트 메모리에서 새 데이터를 복사하면 CPU 애플리케이션과 GPU 사이의 공유 키로 암호화된 암호문서로 GPU에 도착한다. GPU는 암호화된 데이터를 해독하고 GPU 메모리는 새 데이터로 업데이트(1020)된다. GPU 애플리케이션의 많은 메모리 페이지는 초기 업데이트 후에 더 이상 업데이트되지 않을 수 있으며, 여기서 이것을 초기 한 번 쓰기(initial write once)라고 언급할 수 있다. 데이터 전송 후, 공통 카운터는 업데이트된 메모리 청크의 실제 카운터 값을 스캔하여 식별(1030)한다. 이러한 경우, 메모리 복사본은 메모리 페이지를 한 번만 업데이트하므로 카운터 값은 일반적으로 모두 1씩 증가된다. 두 번째, 커널 실행이 완료되면 커널에 의해 업데이트된 메모리 페이지의 모든 카운터 값을 체크한다. 카운터를 스캔하면 카운터가 같은 메모리 청크가 식별되며, 업데이트된 메모리에 액세스하는 다음 커널 실행에 대한 공통 카운트 상태 맵(CCSM)이 업데이트된다.

공통 카운터를 사용하는 것은 메모리 보호의 기밀성과 무결성에 영향을 미치지 않는다. 카운터 기반 암호화 및 무결성 트리 유지보수는 기존의 메커니즘과 동일한 방식으로 수행된다. 공통 카운터는 기존 메커니즘에 의해 설정된 공통 카운터 값만 찾아 압축된 표현을 제공한다. 각각의 새로운 컨텍스트에 대해 카운터를 재설정해야 한다. 카운터 리셋에 의한 잠재적 누출을 방지하기 위해 각 리셋에 새 암호화 키를 사용한다.

대부분의 메모리 페이지에 대해 이러한 공유 공통 카운터를 지원하려면 다음과 같은 추가 메타 데이터가 필요하다.

* 컨텍스트별 암호화 키. 새로운 GPU 응용프로그램이 컨텍스트를 생성하면, 새로운 컨텍스트에 대한 메모리 암호화 키가 생성된다. 하드웨어 메모리 암호화 엔진은 요청된 데이터의 주소의 컨텍스트에 따라 메모리 암호화 키를 변경한다.

* GPU-wide 공통 카운터 상태 맵(CCSM). 메모리 청크의 경우 상태 맵은 메모리 청크가 공통 카운터를 사용하는지 여부를 추적한다. 본 발명의 나머지의 경우 CCSM에서 관리하는 매핑 단위를 세그먼트로 표시한다. 세그먼트 크기는 가상 메모리 지원을 위해 페이지 크기와 일치할 필요가 없다는 점에 유의한다. 이 매핑 테이블은 실제 주소로 처리된다. 본 발명에서는 128KB 세그먼트 크기, CCSM의 세그먼트당 4 비트를 사용한다. CCSM 엔트리(entry) 값이 유효하지 않은 경우(invalid) 세그먼트는 공통 카운터를 사용하지 않는다.

* 컨텍스트별 공통 카운터 세트. 각 컨텍스트에 대해 일련의 공통 카운터 값이 유지된다. 스토리지(저장소) 오버헤드를 최소화하기 위해 15개의 공통 카운터만 사용한다. GPU가 컨텍스트를 실행할 때, 빠른 액세스를 위해 공통 카운터 세트를 온칩 스토리지에 로드해야 한다. CCSM 엔트리 값은 컨텍스트에 대한 공통 카운터 세트에 대한 지수이다.

* 업데이트된 메모리 영역 맵. 업데이트된 메모리 영역 맵은 CPU 또는 커널 실행에서 데이터를 전송하는 동안 업데이트된 메모리 영역을 기록한다. 단순히 데이터 전송이나 커널 실행 후 카운터 값의 검색 오버헤드를 줄이는 것이다. 여기서, 2MB 영역당 1 비트를 사용하여 coarse-grained 맵을 채택했다.

신뢰할 수 있는 GPU 실행

본 발명의 실시예에 따른 신뢰할 수 있는 GPU 모델은 Graviton(비특허문헌 1)에서 제안한 것과 동일한 설계를 따르지만, 모델은 취약한 외부 DRAM을 가정한다. 신뢰할 수 있는 GPU 모델에서는 CPUside 사용자 애플리케이션이 SGX enclave에서 실행되어 GPU와 신뢰를 설정하고, 초기화 중에 사용자 애플리케이션은 원격 CA로 GPU가 사용하는 서명을 확인하여 GPU 자체를 증명한다. 증명이 완료되면 사용자 enclave와 GPU는 공통 키를 공유한다. 공용 키는 사용자 enclave와 GPU 사이의 후속 암호화된 통신에 사용되며, GPUside 명령어 프로세서는 중요한 관리 작업을 수행할 책임이 있으며, TCB(신뢰할 수 있는 컴퓨팅 기초)의 일부분이다. GPU 메모리(숨겨진 메모리)의 일부는 보안 메타 데이터를 위해 예약되어 있으며, 보안 명령 프로세서와 암호화 및 무결성 엔진에 의해서만 볼 수 있고 액세스할 수 있다.

먼저, 컨텍스트를 초기화한다. 초기 설정 후 사용자 enclave는 안전하게 새 GPU 컨텍스트 생성을 요청할 수 있다. GPU 측 명령 프로세서가 컨텍스트를 생성하고 초기화한다. GPU 측 명령 프로세서는 운영 체제를 포함한 모든 권한 있는 CPU 소프트웨어와 독립적으로 작동한다는 점에 유의한다. 따라서 운영체제는 악의적으로 운영에 개입할 수 없다. 메모리 할당을 위해 GPU 명령 프로세서는 GPU 페이지 테이블을 업데이트한다. 페이지 테이블 업데이트 중에 명령 프로세서는 다른 컨텍스트가 물리적 페이지를 공유하지 않도록 하여 컨텍스트 간에 메모리 분리를 시행한다.

메모리 보호를 위해서는 추가적인 단계가 필요하다. 컨텍스트 생성을 위해 새 메모리 암호화 키가 생성된다. 컨텍스트가 GPU에서 실행되도록 예약되어 있는 경우, 해당 메모리는 암호화하고 키로 해독해야 한다. 컨텍스트에 대해 메모리 페이지가 할당되면 새 키로 메모리가 다시 암호화된다. 단, 현재의 GPU에서도 새로 할당된 페이지의 메모리 내용을 스크럽(scrubbed)하여 보안을 유지해야 하기 때문에 이 초기 재암호화 단계에는 추가 비용이 들지 않는다. 실시예에 따른 계획에서 스크러빙 단계는 하드웨어 엔진에 의해 암호화된 0의 값으로 동일한 메모리 쓰기를 생성한다. 또한, 새로 할당된 페이지에 대응하는 CCSM 엔트리는 공통 카운터를 사용하지 않도록 재설정된다.

공통 카운터 상태 업데이트

공통 카운터를 활성화하려면 응용 프로그램 메모리에 사용되는 공통 값을 식별해야 한다. 단계 중에 CCSM과 공통 카운터 세트를 업데이트해야 한다. 명령어 프로세서는 (1) CPU에서 GPU 메모리로의 데이터 전송 완료, (2) 커널 실행 완료의 두 가지 이벤트에 대한 공통 카운터 업데이트 작업을 개시한다. 두 가지 유형의 이벤트에 대해 업데이트된 메모리 세그먼트의 카운터 값이 스캔된다. 단계 중에 발견된 새 공통 카운터의 경우 공통 카운터 세트가 업데이트되어 대응하는 엔트리(entry)를 삽입하거나 수정한다. 또한 세그먼트가 새로운 세그먼트를 가리키도록 CCSM이 업데이트된다.

업데이트된 메모리 영역을 추적한다. 전체 카운터 블록을 전체 물리적 메모리에 대해 스캔하면 상당한 오버헤드가 발생하므로, 데이터 전송 또는 커널 실행은 2MB 영역당 1 비트로 coarse-grained 업데이트된 메모리 맵을 유지한다. 32GB 메모리의 경우 16KB 메모리만 사용되며, 메모리의 작은 부분만 업데이트되기 때문에 공간적 인접성이 매우 높다. 그것들은 마지막 단계의 캐시에 저장된다. 업데이트된 메모리 영역에 대한 더 최적화된 추적을 채택할 수 있지만, 본 실시예는 중요한 오버헤드를 유발하지 않기 때문에 이러한 순수한 접근법을 사용한다.

카운터 블록의 스캔 단계 중에 업데이트된 메모리 영역이 먼저 점검된다. 영역이 업데이트된 경우에만 해당 카운터 블록을 검색하여 공통 카운터를 찾는다. 세그먼트에서 모든 카운터 값이 동일한 경우, 해당 CCSM 엔트리가 새로운 공통 카운터 값을 가리키도록 업데이트된다. 새 값은 공통 카운터 세트에 존재하지 않으며, 새 값이 추가된다.

공통 카운터 사용

여기에서는 LLC 누락에 대해 공통 카운터를 사용하는 방법과 쓰기 처리 방법에 대해 설명한다. CCSM에 대한 빠른 접근을 위해 작은 캐시가 GPU에 추가된다.

먼저, CCSM 캐시에 대해 설명한다. 공통 카운터 상태 맵(Common Counter Status Map, CCSM)은 GPU의 물리적 메모리 전체를 커버해야 하므로 전체 맵은 온칩 스토리지에 저장할 수 없다. 대신에 제안된 기술은 CCSM 데이터 전용 캐시를 사용한다. 카운터 캐시에 비해 CCSM 캐시의 효율은 규모 순으로 높다. 카운터 캐시의 경우, 128-ary 및 256-ary 카운터 방식을 각각 사용할 때 128B 카운터 캐시 블록은 16KB 및 32KB 데이터 메모리를 커버한다. 그러나 128B CCSM 캐시 블록은 32MB의 데이터 메모리를 커버하므로 캐싱 효율이 2,048배 향상된다. 제안된 공통 카운터에 의한 개선은 이러한 저장 효율성에서 기인한다. 여기에서는 크기가 1KB인 작은 CCSM 캐시를 사용한다. 그러나 CCSM 캐시는 카운터 캐시와 병합할 수 있다.

다음으로, 누락 처리 흐름에 대해 설명한다.

도 11은 일 실시예에 따른 LLC 누락 처리 흐름을 나타내는 도면이다.

도 11을 참조하면, LLC 누락(1101) 시, 데이터 요청(1102)은 메모리 컨트롤러(1103)로 전송되며, 동시에 카운터 요청(1105)는 CCSM 캐시(1106)로 전송되고, CCSM 캐시(1106)에서 누락된 주소를 먼저 확인하여 CCSM 상태를 확인한다. CCSM 캐시(1106)에 상응하는 CCSM 엔트리가 없을 경우 GPU의 숨겨진 메모리(1107)에서 CCSM 엔트리를 검색해야 하지만, 매핑 효율성이 높아 CCSM 캐시의 누락은 드물다. CCSM 엔트리가 확인되면, 누락 처리기는 주소에 대해 공통 카운터를 사용할 수 있는지 여부를 확인(1108)한다.

CCSM 엔트리가 컨텍스트의 공통 카운터 세트에 대한 유효한 인덱스(valid index)를 가지고 있는 경우, 공통 카운터 값이 카운터 블록의 실제 카운터 값과 동일하다고 보장되기 때문에, 세트의 공통 카운터 값이 사용된다. 또한, CCSM 엔트리가 해당 세그먼트를 무효(모두 1)로 표시하면, 카운터 캐시(1109)에 액세스하여 상응하는 카운터 엔트리를 찾는다. 카운터 캐시 누락이 발생하면 기본 메모리 암호화 엔진처럼 처리해야 한다. 카운터 값이 공통 카운터 세트(1113) 또는 카운터 캐시(1109)에서 사용 가능해지면 OTP 생성기(1114)에 의해 누락에 대한 OTP(1115)가 생성된다. 데이터(1104)가 메모리에서 도착하면 데이터는 생성된 OTP(1115)로 해독된다.

다음으로 쓰기 처리를 설명한다. 다른 쓰기 정책이 지원될 수 있지만, 실시예들은 라이트백/쓰기 할당 LLC를 가정하여 쓰기 흐름에 대해 논의한다. 쓰기의 경우, 2개의 메타 데이터 업데이트가 필요하다. (1) 먼저, 기존의 카운터 모드 암호화와 유사하게, 대응하는 카운터 엔트리(corresponding counter entry)를 업데이트해야 하며, 이때 dirty 캐시라인이 결국 캐쉬에서 메모리로 제거된다. 공통 카운터는 카운터 값의 손쉬운 방법이지만, 각 메모리 블록에 대한 실제 카운터는 여전히 유지된다. (2) 둘째, CCSM 엔트리는 현재 유효하지 않은 것으로 업데이트되어, 카운터 값이 현재 증가하므로, 동일한 주소로 이어지는 모든 읽기/쓰기에서는 공통 카운터를 사용할 수 없다. 앞에서 설명한 바와 같이, 커널 실행이 완료되고 공통 카운터 상태 업데이트 절차가 세그먼트에 대한 동일한 카운터 값을 찾으면 업데이트된 메모리 세그먼트에 대한 CCSM 엔트리가 공통 카운터로 재설정된다는 점에 유의한다.

하드웨어 오버헤드

CCSM은 다른 보안 메타 데이터와 함께 GPU 메모리의 고정 위치에 할당되어야 한다. CCSM의 크기는 GPU 메모리 크기, 컨텍스트당 공통 카운터 수, 세그먼트 크기에 따라 달라진다. 평가의 경우, 세그먼트 크기는 128KB로 설정되며, 컨텍스트당 공통 카운터 수는 16개로 세그먼트당 4 비트가 필요하다. 각 1GB GPU 메모리에 대해 4KB의 CCSM 용량이 필요하다.

공통 카운터 세트는 컨텍스트당 공통 카운터 수가 16개일 때 30x4 비트가 필요하다. GPU에서 여러 컨텍스트를 동시에 실행할 수 있는 경우, 온칩 저장소에 여러 개의 공통 카운터 세트를 추가해야 한다. 두 컨텍스트가 동시에 실행되지 않는 한 공통 카운터 세트는 컨텍스트 메타 데이터 메모리에 저장되고 GPU 스케줄러에 의해 복원된다.

제안된 아키텍처에는 1KB CCSM 캐시, 16KB 카운터 캐시, 16KB 해시 캐시를 포함한 추가 온칩 캐시가 필요하다. 카운터 캐시와 해시 캐시는 SC 128이나 Morphable 카운터 같은 이전 메모리 보호 기술에도 포함되어 있다는 점에 유의한다. 추가 온칩 캐시의 면적과 전력 오버헤드를 추정하면, 모든 온칩 캐시는 0.11mm² 면적에 해당하고, 이는 RTX 2060 die 면적의 0.024%에 불과하며, 누설 전력 소비량은 11.28mW이다.

최근 딥러닝, 그래프 처리와 같은 수많은 데이터에 대해 병렬적인 연산을 요구하는 애플리케이션은 GPU를 이용하여 효율적으로 가속할 수 있다. 따라서, 클라우드 환경에서도 GPU를 서비스 형태로 지원하고 있으며, 이에 대한 수요는 점점 증가하고 있다. 이에 따라 원격의 GPU로 전송되는 사용자의 데이터는 보호되어야 한다. 이상에서 설명한 본 발명은 이러한 시장의 수요를 충족시킬 수 있는 기술이다.

실시예들에 따르면 이종 컴퓨팅 환경(CPU-GPU)에서 데이터 보호를 통해 클라우드를 사용하는 사용자의 데이터를 안전하게 보호할 수 있다. 또한 실시예들에 따르면 임베디드와 같이 내장 GPU를 사용하는 환경(Autonomous driving, drone, etc) 에서도 해당 기법을 적용할 수 있기 때문에 보안 수준 향상을 기대할 수 있다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 컨트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPA(field programmable array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 컨트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (15)

1. 컴퓨터 장치를 통해 수행되는 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 방법에 있어서,
   GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용하는 단계
   를 포함하고,
   상기 공통 카운터는 다수 개의 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 매핑하는 것을 특징으로 하는, 암호화 방법.
2. 제1항에 있어서,
   상기 공통 카운터를 통해 카운터 캐시 누락으로 인해 발생하는 성능 오버헤드를 제거하는 것
   을 특징으로 하는, 암호화 방법.
3. 제1항에 있어서,
   상기 GPU는 각 컨텍스트에 대해 공통 카운터 세트를 사용하는 것
   을 특징으로 하는, 암호화 방법.
4. 제1항에 있어서,
   LLC(Last-Level Cache) 누락 시, 요청된 주소가 상기 공통 카운터 중 하나인 메모리 청크에 대한 주소인 경우 암호화 엔진은 누락 처리 요청에 대한 공통 카운터 값 중 하나를 사용함에 따라 요청된 카운터가 상기 공통 카운터에 제공되는 경우에는 카운터 캐시에 접속하지 않는 것
   을 특징으로 하는, 암호화 방법.
5. 제1항에 있어서,
   상기 카운터를 공통 카운터를 기반으로 사용하는 단계는,
   각 컨텍스트에 별도의 메모리 암호화 키가 제공되는 단계
   를 포함하고,
   상기 각 컨텍스트에 별도의 메모리 암호화 키가 제공되는 단계는,
   상기 GPU가 컨텍스트를 생성하면, 새로운 컨텍스트에 대한 메모리 암호화 키가 생성되고, 메모리 암호화 엔진은 요청된 데이터의 주소의 컨텍스트에 따라 메모리 암호화 키를 변경하는 것
   을 특징으로 하는, 암호화 방법.
6. 제1항에 있어서,
   상기 카운터를 공통 카운터를 기반으로 사용하는 단계는,
   상기 GPU는 요청된 주소가 공통 카운터에 의해 제공될 수 있는지 여부를 암호화 엔진에 알려주는 공통 카운터 상태 맵(Common Counter Status Map, CCSM)이라는 상태 표를 유지하는 것
   을 특징으로 하는, 암호화 방법.
7. 제1항에 있어서,
   상기 카운터를 공통 카운터를 기반으로 사용하는 단계는,
   상기 GPU가 컨텍스트를 실행할 때, 빠른 액세스를 위해 공통 카운터 세트를 온칩 스토리지에 저장하는 것
   을 특징으로 하는, 암호화 방법.
8. 제1항에 있어서,
   상기 카운터를 공통 카운터를 기반으로 사용하는 단계는,
   호스트 메모리에서 새 데이터를 복사하면 CPU 애플리케이션과 상기 GPU 사이의 공유 키로 암호화된 암호문서로 상기 GPU에 도착하고, 상기 GPU는 암호화된 데이터를 해독하고 상기 GPU 메모리는 새 데이터로 업데이트되는 단계; 및
   데이터 전송 후, 상기 공통 카운터는 업데이트된 메모리 청크의 실제 카운터 값을 스캔하여 식별하는 단계
   를 포함하는, 암호화 방법.
9. 제1항에 있어서,
   상기 카운터를 공통 카운터를 기반으로 사용하는 단계는,
   커널 실행이 완료되면 커널에 의해 업데이트된 메모리 페이지의 모든 카운터 값을 체크하고, 카운터를 스캔하면 카운터가 같은 메모리 청크가 식별되며, 업데이트된 메모리에 액세스하는 다음 커널 실행에 대한 공통 카운트 상태 맵(CCSM)이 업데이트되는 것
   을 특징으로 하는, 암호화 방법.
10. 하드웨어 기반의 GPU 메모리 보호를 위한 암호화 장치에 있어서,
    GPU가 사용하는 GPU 메모리의 쓰기 패턴에 따라 암호화 과정에서 사용하는 카운터를 공통 카운터를 기반으로 사용하는 공통 카운터 기반 암호화부
    를 포함하고,
    상기 공통 카운터는 다수 개의 메모리 청크가 공유하는 공통 카운터 값에 메모리 주소를 매핑하는 것을 특징으로 하는, 암호화 장치.
11. 제10항에 있어서,
    상기 공통 카운터를 통해 카운터 캐시 누락으로 인해 발생하는 성능 오버헤드를 제거하는 것
    을 특징으로 하는, 암호화 장치.
12. 제10항에 있어서,
    상기 GPU는 각 컨텍스트에 대해 공통 카운터 세트를 사용하는 것
    을 특징으로 하는, 암호화 장치.
13. 제10항에 있어서,
    LLC(Last-Level Cache) 누락 시, 요청된 주소가 상기 공통 카운터 중 하나인 메모리 청크에 대한 주소인 경우 암호화 엔진은 누락 처리 요청에 대한 공통 카운터 값 중 하나를 사용함에 따라 요청된 카운터가 상기 공통 카운터에 제공되는 경우에는 카운터 캐시에 접속하지 않는 것
    을 특징으로 하는, 암호화 장치.
14. 제10항에 있어서,
    상기 공통 카운터 기반 암호화부는,
    각 컨텍스트에 별도의 메모리 암호화 키가 제공되고, 상기 GPU가 컨텍스트를 생성하면, 새로운 컨텍스트에 대한 메모리 암호화 키가 생성되고, 메모리 암호화 엔진은 요청된 데이터의 주소의 컨텍스트에 따라 메모리 암호화 키를 변경하는 것
    을 특징으로 하는, 암호화 장치.
15. 제10항에 있어서,
    상기 공통 카운터 기반 암호화부는,
    상기 GPU는 요청된 주소가 공통 카운터에 의해 제공될 수 있는지 여부를 암호화 엔진에 알려주는 공통 카운터 상태 맵(Common Counter Status Map, CCSM)이라는 상태 표를 유지하는 것
    을 특징으로 하는, 암호화 장치.

Images