20160125

1. [ASPLOS’02] Mondrian Memory Protection 읽기 (paper, slides)
– Mondrian memory protection은 fine-grained한 메모리 보호 기법이다. MMP를 사용하면 유연하게 서로 다른 도메인 간 메모리와 서비스의 공유가 가능하다.
– 운영체제는 프로세스 사이에 보호 메커니즘을 제공해야 한다. 초기에는 segment를 사용해 메모리 보호 기법을 적용했음. 하지만 이러한 방식은 효율적으로 구현하기 힘들었음. 현대의 아키텍쳐와 운영체제는 선형 주소를 사용하고, demand-paging 기법을 사용한다. 이러한 기법을 사용함으로써 쓰레드는 각각 다른 보호 도메인을 가지며, 공유는 페이지 단위로만 이루어지게 됨. 페이지 기반의 보호는 한계점이 분명하며, 더 유연한, fine-grained한 메모리 보호 기법이 필요함.
– 페이지 기반의 메모리 보호 기법을 사용하기 때문에 문제가 되는 경우가 많음. 웹 브라우저의 경우에는 플러그인을 사용하게 되는데, 플러그인이 브라우저와 메모리 주소 공간을 공유하는 경우가 많음. 메모리 주소 공간을 공유함으로써 더 빠르고 쉬운 구현이 가능하기 때문. 하지만 fine-grained하게 메모리 보호가 이루어지지 않으므로, 플러그인의 취약성은 브라우저의 취약성으로 연결됨.
– Mondrian memory protection (MMP)에서는 fine-grained한 메모리 보호 기법을 제공하는 동시에, 공간적인 오버헤드를 줄이고자 노력함.
– 메모리 보호 기법에 대한 세 가지 요구 사항을 언급하고, 기존의 메모리 보호 기법은 적합하지 않다는 설명을 하고 있음. 1) different, 2) small, 3) revoke를 세 가지 요구사항으로 들고 있음.
1) different: 서로 다른 도메인은 동일한 메모리 영역에 대해 다른 권한을 가질 수 있어야 함.
2) small: 최소 공유 단위는 페이지보다 작은 단위어야 함.
3) revoke: 도메인은 메모리의 일부 영역을 소유하며, 다른 도메인에게 권한을 부여하거나 빼앗을 수 있다.
– Conventional linear, demand-paged 메모리 보호 기법은 different는 만족하지만 small은 만족하지 못함. 쓰레드를 각기 다른 주소 영역에 두기 때문에 different는 만족하지만, 페이지 기반으로 공유하기 때문에 small을 만족하지 못함. Page-group system은 different, small 모두를 만족하지 못함. Page-group에 접근 권한이 있는 모든 도메인이 내용을 공유하기 때문. Domain-page system은 small을 만족하지 못함. 페이지 단위로 권한을 관리하기 때문. Capability system은 different를 만족하지 못함. 자료구조 공유에 포인터를 사용하는데, 포인터를 가지면 모두 같은 권한을 갖기 때문이다.
– MMP는 세 가지 요건 모두를 충족시키기 위한 메모리 시스템을 설계함 (figure from paper).
mondrian memory protection architecture.PNG
– MMP는 단일 주소 공간 상에 여러 개의 보호 도메인을 제공함. 사용자 쓰레드는 주소 영역에 대해 권한을 변경할 수 있음. 주소 영역을 user segment라고 부름. User segment는 시작 주소, 길이, 권한 값으로 이루어진다. 권한은 두 비트로 구성됨.
– CPU는 현재 domain ID를 유지하는 레지스터를 가지며, 도메인별로 permissions table을 가짐. Permissions table은 해당 도메인이 특정 주소에 대해 어떤 권한을 갖는지 정보를 유지한다. 모든 메모리 접근은 적절한 권한으로 수행되는지 확인되며, 정보 캐싱을 위해 permissions lookaside buffer(PLB)를 사용한다. 성능의 추가적인 개선을 위해 레지스터마다 sidecar register를 갖는다. Sidecar register는 해당 레지스터가 최근에 접근한 segment에 대한 정보를 갖는다.
– Permissions table은 가장 단순하게 구현하자면 sorted segment table로 구현할 수 있을 것. 하지만 이렇게 구현했을 때에는 공간 오버헤드가 크다. 그리고 공유 단위도 커진다는 문제가 있다. 이를 해결하고자 multi-level permission table을 구성한다. Permission vector entries, min-SST entries의 두 가지 대안을 보여주고, 공간 오버헤드가 더 작은 mini-SST entries를 선택한다.
슬라이드에 MMP가 왜 새로운지, 왜 좋은지에 대한 내용이 있었음.
MMP is a new solution.PNG
MMP there is no free lunch.PNG
– 그 외 기억해두어야 할 슬라이드 정리.
MMP sidecars.PNGMMP related work.PNG


2. [ISCA’14] The CHERI capability model Revisiting RISC in an age of risk 읽기 (paper, slides)
– CHERI 논문은 2016/01/22에 한 번 확인한 적이 있음. Capability model에 대한 배경 지식이 부족해 이해하기 힘들었음. Mondrian memory protection을 읽고, 이 논문을 여러 번 보니 이 논문에서 하려는 것이 어느 정도는 파악됨. 하지만 어려운 것은 여전함. 간단히 CHERI에서 하려는 것이 무엇인지만 정리하겠음.
– CHERI는 RISC의 장점을 버리지 않으면서도 capability model을 구현하려는 시도이다. RISC 구조위에 capability model을 더하려는 시도. CHERI를 이해하려면 capability model을 이해해야 함. 여전히 capability model이 무엇인지는 정확히 이해하기 어려움. Mondrian memory protection을 보고, 발표 영상까지 보고 나니 대강은 이해가 됨. 시스템에 메모리 객체들이 여러 개 있을 때, 각 객체에 대한 접근 권한을 도메인별로 설정할 수 있도록 하는 시스템이 capability system인 듯 하다. 발표 영상에서는 capability를 unforgeable token of authority라고 정의하고 있음. 쉬운 정의는 아니다.
CHERI capability
– 현대의 시스템에 capability model을 도입하려 하는 이유는 보안이 중요한 이슈가 되었기 때문이다. 그리고 현재의 메모리 보호 기법은 취약하기 때문이다. 현재 시스템에서는 성능 상의 목적으로 demand-paging을 사용하고 있는데, demand-paging은 page 단위의 접근 권한밖에 설정할 수 없음. 그리고 thread간 분리는 이루어지고 있으나, 아키텍쳐 수준에서 permission을 강제할 수는 없음. 이러한 motivation은 Mondrian memory protection에서 잘 설명되어 있었으며, 선행 연구를 더 읽어보면 motivation에 대해서 충분히 이해할 수 있을 것이라 생각함. 더 읽어봐야 함.
CHERI address validation and pointer safety
– Paged memory와 capability model 모두 장단점이 있음. CHERI는 이 두 가지 장점 모두를 택하고자 하는 시스템.
– CHERI는 coprocessor로 구현되어 있으며, MIPS pipeline이 명령어를 capability coprocessor에 제공함으로써 capability 위반 여부를 확인한다. CHERI는 32개의 capability register를 가지며, capability register들이 capability를 강제한다. Conventional code들은 암묵적으로 capability register C0를 사용한다. 그리고 메모리 상에서 capability 정보의 여부를 확인하고, 변조를 방지하기 위해 메모리에 1bit tag를 붙임.
capability register file implicittags to protect capabilities in memory
– Background 관련 논문을 읽고 읽어도 여전히 어려움. Capability model 자체가 생소하기도 하고, CHERI가 너무 많은 세부 사항을 갖고 있기에 그런 것 같기도 함. 실제로 FPGA에 구현했으므로 논문에 포함되기 어려울 정도로 많은 내용이 있을 듯.


3. [ASPLOS’15] Architectural Support for Dynamic Linking 읽기 (paper, slides)
– 모든 소프트웨어는 라이브러리에 기반해 작성됨. 대부분의 라이브러리는 실행 중에 동적으로 링크되고 로드됨. 동적 라이브러리를 사용하는 것은 코드 재사용성, 업데이트 용이성, 메모리 관리 측면에서 도움이 된다. 하지만 동적 라이브러리는 정적 라이브러리에 비해 성능이 떨어진다. 동적 라이브러리 함수가 호출될 때마다 indirect 함수 호출이 발생하기 때문이다. 실제 함수를 호출하기 위해서는 lookup table 확인이 반드시 필요해, trampoline 코드가 매번 호출된다. 이 연구에서는 프로세서에 변경을 가해 trampoline을 건너뛰고자 한다.
Architectural Support for Dynamic Linking contribution.PNG
– 동적 라이브러리 함수에서의 성능 저하를 해결하고자 다양한 기법들이 제안되었음. 정적 라이브러리를 사용하거나, hardware memoization, 또는 profil-driven optimization을 사용할 수 있음. 그러나 여전히 이 기법들은 trampoline 코드를 온전히 제거하지는 못함.
– 동적 라이브러리를 사용하는 것은 flexibility, memory conservation, security 측면에서 이점이 있다. Trampoline 코드로 인해 명령어 캐시가 부담이 된다는 점, lookup table로 인해 데이터 캐시가 부담이 된다는 점, branch 정확도가 떨어진다는 점은 문제이다.
Architectural Support for Dynamic Linking trampoline overhead.PNG
– SW 수준에서 dynamic resolver를 사용할 수도 있겠지만, 여러 문제가 있음. 함수 호출 방식이 다양할 수도 있고, 이렇게 dynamic resolving을 사용하면 메모리 용량에 부담이 될 수 있음. CoW 방식으로 fork를 하고 있는데, fork된 이후에 dynamic resolving이 이루어지면 copy가 무수히 일어나 메모리 용량을 많이 잡아먹을 것. 그리고 한 프로그램 안에서 library function call이 많아서 이를 모두 resolve 할 수도 없다.
– 핵심 아이디어는 간단함. Trampoline 코드를 인식하면 이를 건너뛰고, 함수로 바로 건너뛰도록 한다. Branch predictor 부분에서 trampoline 코드를 인식한다. Branch predictor가 trampoline 코드를 인식하면 branch target buffer의 target address에 함수의 주소를 쓴다.
Architectural Support for Dynamic Linking baseline.PNGArchitectural Support for Dynamic Linking proposal.PNG
– 이를 위해 branch predictor에 alternate BTB (ABTB)를 추가한다. ABTB는 trampoline 코드의 주소와 실제 함수 주소의 map을 유지하고 있다. Back end가 branch 명령어의 target을 결정할 때, ABTB를 검색해 trampoline 코드인지 확인하고, 실제 함수의 주소로 바꾼다. ABTB는 어떻게 업데이트 하느냐 하면, trampoline 코드 특징인 명령어 패턴을 확인한다. Indirect branch 이후에 따라오는 call 명령어로 확인해 ABTB를 업데이트한다.
– 그 외에 추가적으로, 함수 주소가 바뀌면 어떻게 할 것인지, speculation이 틀리면 어떻게 할 것인지 등에 대해 기술하고 있음.


4. [ASPLOS’00] Architectural support for copy and tamper resistant software 읽기 (paper, slides)
– SW piracy는 심각한 경제적 문제를 일으키고 있음. 이러한 SW piracy를 막기 위한 여러 시도가 있었음. 하지만 신뢰할 수 있는 SW only method는 없는 상황이다. 이 논문에서는 SW piracy를 막기 위해, 실행만 가능한(execute-only) 아키텍쳐인 XOM을 제안한다. 명령어들이 메모리에 암호화된 코드로 올라오며, 이러한 코드들은 실행 시점에 프로세서에 의해 복호화된다. 이처럼 모든 데이터가 실행 시점에만 복호화되기 때문에 사용자가 명령어를 직접 보거나, 변조할 수 없다. 이 논문에서는 이러한 XOM 보호 모델을 실제로 구현할 수 있도록 설계한다. 소프트웨어를 격리하기 위해 compartment라는 것을 제안한다. Compartment는 session key로부터 생성된다. 프로그램은 compartment 내에 격리되며, compartment 밖으로 나갈 때에는 모든 데이터가 compartment의 session key로 암호화된다. 암호화되지 않은 일반적인 코드는 unprotected, null compartment에서 실행된다. 프로그램의 보호는 비대칭키와 대칭키를 조합해 이루어진다. 프로그램을 변조하거나 복사하지 못하도록 암호화해야 하는데, 비대칭키를 사용하면 느리므로 비대칭키와 대칭키를 조합해 사용한다. 프로그램 전체를 대칭키로 암호화하고, 대칭키를 비대칭키로 암호화해 저장한다. 이렇게 하면 빠른 속도로 암/복호화하면서도 배포에 용이하다. 대칭키는 프로그램에 고유하므로, 이를 compartment 생성에 사용한다. Compartment에는 XOM ID가 부여되며, 해당 compartment에서 생성한 데이터는 모두 XOM ID 태그가 붙여진다. 프로세서는 XOM ID 태그가 일치하는 데이터만 캐시로부터 읽어들일 수 있다. 그리고 데이터를 읽어들일 때에는 XOM ID 태그와 일치하는 compartment의 session key로 복호화해서 데이터를 읽어들인다. XOM ID에 사용되는 비트의 수는 동시에 실행 가능한 compartment의 수에 따른다.
– XOM의 구현을 위해서는 몇 가지 명령어가 추가되어야 한다. enter_xom과 exit_xom은 XOM 모드로 들어오고 나가는 명령어이다. enter_xom 명령어를 사용해 session key를 준비하고, XOM 모드로 전환할 수 있다. XOM 모드에서는 모든 명령어가 compartment의 session id로 복호화되어 실행된다. exit_xom 명령어를 사용하면 XOM 모드에서 벗어날 수 있다.
– XOM은 추가로 mv_to_null, mv_from_null 명령어를 요구한다. 데이터의 태그 변경을 하는 명령어이다.
– XOM이 제공하는 네 가지 기능으로는, 1) 비대칭키를 사용해 대칭키를 복호화하는 기능, 2) 복호화된 세션 키를 사용하여 프로그램을 복호화하는 기능, 3)XOM mode에 들어가고 나오는 기능, 4) XOM ID가 일치하는 경우에만 데이터를 접근하게 하는 보호 기능이 있다.
– 한편, XOM에서는 프로세서만 신뢰하고 메모리는 신뢰하지 않는다. 메모리를 신뢰하지 않으므로, 메모리 수준에서공격이 가능하다. 메모리에 데이터를 저장할 때와 불러올 때 hash 값도 함께 저장하고 불러와 메모리 변조를 탐지해낸다. 이 때 사용하기 위한 명령어를 추가한다.
– Interrupt가 발생할 때, 신뢰할 수 없는 운영체제가 레지스터를 조작하게 된다. 이 때문에 데이터 유출이 발생할 수 있는데, 이를 방지하기 위해 암호화해 저장하는 save_secure, restore_secure 명령어를 추가한다.
– 프로세서 구조 변경을 최소화한 simple XOM machine과 하드웨어를 자유롭게 변경한 full XOM machine을 제안하고 있음 (figures from paper). 그리고 마지막으로 암복호화, 해싱에서 사용되는 하드웨어 오버헤드를 분석하고 있다. 여러가지 대안이 있고, 이 중에서 어떤 것이 가장 효율적인지 결론내며 구체적인 수치를 포함한다.
simple XOM machine.PNGfull XOM machine.PNG
– 한편, 대칭키와 비대칭키를 동시에 사용해 암호화하는 기법은 [HPCA’05] SENSS security enhancement to symmetric shared memory multiprocessors에서도 사용했던 기법이다.

Advertisements
Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in 1) Memo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

누적 방문자 수
  • 88,328 hits
%d bloggers like this: