[논문리뷰]Milkomeda: Safeguarding the Mobile GPU Interface Using WebGL’s Security Checks

GPU

web browser도 webgl에 비슷한 문제에 직면해있다.

그래서 web browser는 security check를 webGL에 한다.

webgl security check를 도입해 mobile interface에 적용한다.

check-gen : 자동으로 바꿔주는 도구

multi process architecture가 없고 inter process communication과 shared memory transfer data가 필요없다.

대신 security check를 통해 integrity를 확보한다.

intro

mobile에도 GPU많이 쓰임 ㅇㅇ

그런데 크기는 크면서 취약함

desktop 게임은 유명한 회사에서 만든 게임들이어서 괜찮았음

모바일앱은 위험함

sandbox : os 시스템인데 java virtual machine 만큼 유명함

모바일 앱은 샌드박스에서 돌아가는데 나머지 시스템이랑 독립되어 있음

그런데 GPU에 access하는 것은 위험함 그래도 어쩔 수 없음 성능때문에

webgl도 같은 문제가 있다. web app은 javascript로 쓰임

webgl은 security check를 하는데 webgl call을 해서 state across를 한다.

interposition layer가 있는 것 만으로도 webgl의 보안성을 크게 높인다.

결국 webgl을 mobile향으로 바꾸겠다는 얘기

두가지 challenge가 존재하는데 바꾸는데 최소한의 노력이 들게하는 것과 퍼포먼스를 유지시키는 것

1. check gen을 tool로 사용했는데 자동으로 모바일향으로 바꿔주는 것이다.

2. webgl은 multi process architecture를 사용했다. communication은 GPU porcess를 통해서 했다.

그래서 이 architecture은 IPC(inter process commmunication)를 요구하고 shared memory data copying을 요구한다.

근데 이 환경이 overhead를 많이 발생시킨다. milkomeda는 ****novel in-process shield space design에 주목했다.

이것은 security check를 app process안에서 일어나게 한다. 

이 space는 code와 data를 untrusted process와 독립시켜 놓는다.

이러면 shield space에 있는 thread만 GPU device driver에 system call을 할 수 있다.

untrusted thread는 shield를 지정된 gate를  통해서만 들어올 수 있다. 그래서 security check는 ***circumvented될 수 없다.

shield안에 있는 code와 data는 간섭받지 않는다.

port : 복사하다 라는 뜻도 있다.

vet : 조사하다 라는 뜻도 있다.

collectively : 집합적으로

Android에서 실행됐고 chrome browser webgl을 사용했다. 

앞으로 나올 내용 : 

1. 제대로 webgl에서 milkomeda로 됐는지

2. 최소한의 노력을 통해 됐는지

3. high performance를 유지하면서 제대로 security check를 하는 지

2 background and morivation

2.1 current graphics stack in mobile devices

mobile app은 openGL ES를 이용했고 GPU device driver와 system call을 이용하여 통신했다.

android에서는 GPU device file을 열고 system call을 하는 방식으로 device file에 system call을 한다.

ioctl이랑 mmap이 명령어이다.

이게 취약한 이유가 두 가지 있다.

첫 번째로 좋은 app은 open gl library를  통신하는데만 사용하지만, gpu device driver로 직접 접근하는 것을 막을 것이 없다.

이는 os가 app에 device file에 직접적으로 접근할 수 있는 권한을 줬기 때문인데 이는 opengl es frame work를 app에서 가능하게 하기 위해서다.

그래서 어떤 코드도 device driver kernel에 접근할 수 있다. ioctl은 3만2천줄이나 되는데 40개의 func에 노출되어 있다.

두번째로 그렇게 opengl es api를 통해서 간접적으로 통신하더라도 안전하지 않는데 api가 보안에 큰 중요성을 두고있지 않기 때문이다.

이런 webgl interface의 공격이 많은 security check를 만들어내고  webgl interface를 어렵게 만든다.

하지만 모바일에서는 framework가 부족하다.

2.2 mobile graphics vulnerabilities

NVD에서 android와 gpu관련 오류들을 찾아봤다.

64개중 47개가 previlege escalations CVE, 13개가 unauthorized moemory accesses, 3개는 memory corruption 하나는 Denial of Service이다.

73%가 심각레벨이다. 이는 GPU driver 가 kernel 모드에서 돌아가고 권한없는 앱에서 실행되기 때문이다.

이는 권한없는 앱과 GPU driver를 보호해야한다는 필요성을 보여준다.

aforementioned : 앞서 언급한

reproducing the vulnerabilities : 무슨 의미인지 모르겠다.

2.3 Graphics Stack in Web Browsers

webgl은 opengl ES같은 api를 web에서 적용한다. webgl은 보안에 신경을 많이 썼다.

app을 system과 독립시켜놔야한다. app이 너무 위험하기 때문에.

webgl은 그래서 security check runtime이 있다.

web app이 webgl api를 call하면 call의 parameter들이 GPU에 들어가기 전에 조사된다.

만약 취약점이 발견되면 새로운 check이 다음 에 추가된다. 하지만 모든 attack을 이렇게 막을 순 없다.

그리고 이건 performance loss가 생긴다. app이 gpu device friver에 접근하기 위해서는 multi process를 통과해야한다.

app은 webgl frontend framework를 사용하는데 이건 IPC(inter process communication)와 &&&shared memory를 사용한다.

backend는 security check를 api call에 대해 수행하는데 app process 결과를 app에 되돌려준다.

2.4 WebGL Security Checks

webgl review하는 부분

deprecate : 반대하다

어떤 코드들은 hard-coded되어있다(직접적으로 코드를 써놨다는 말인듯) - conditional statement로 수행된다.

나머지는 validator로 다뤄진다. validator는 자동적으로 python script로 만들어지는데 opengl es으로부터 만들어진다.

상태를 보고 api call의 적합성을 따지기도 한다.

GPU사용하는 acceleration은 shader코드를 사용한다. 이 코드를 쓰지 않으면 거른다.

webgl api를 쓰는 parameter는 포인터가 많다. tocttou attack을 막기위해 shadow copy가 이 포인터에게 가르키도록 만든다.

오로지 중요한 데이터만 그렇다.

workaround : 대응책

대응책을 마련해둔다. 

3. threat model

library는 믿지않는다. 왜냐하면 app이 직접 접근할 수 있기 때문에

kernel은 믿는다.

4. MILKOMEDA's design

layer를 새롭게 만든다. 결국 1-c그림이 핵심이고 isolation이 주된 목적인 듯

그러면 퍼포먼스에 영향이 있다. 이건 탈락인듯

앱에서 직접 check를 하는 것이 다른 방법이 있는데 이러면 check가 안될 수 있다.

우선 직접 device driver에 call하고 나중에 check하는 방식인듯

여기에 필요한 보증

1. device driver에 직접 접근 불가

2. control flow는 보존된다.

3. data integrity of security check와 중간 단계도 보존

4. security check 는 퍼포먼스를 떨어뜨리지 않는다.

중간 layer이름을 vetting layer라고 부른다.

novel shield space를 쓰는데 이건 security check를 위해 필요

os는(device driver는)shield space에 있는 thread와만 통신한다.

app이 수행되면 thread는 enrty point에 들어가고 security check가 수행되어야 pass된다.

그래서 app이 다른 장소로 점프하지 못한다.(포인터로 가르키지 못한다.)

memory page는 app의 다른 부분에서 접근불가하게 막는다.

5. shield space

이건 gpu device driver에 app이 접근하는 것을 막고 opengl es와 interact하게 둔다.

opengl es api를 수행시키려면 shield call을 해야한다. 그래야 trusted가 된다.

shield design에는 두가지 구성요소가 필요하다.

1. protected shield space memory - shield의 code와 data보호를 위해

2. effective syscall filtering - shield에서 수행되는 thread제한을 위해

5.1 protected shield space memory

이 space는 shield call을 통해서만 들어갈 수 있다.

page table이 두개의 set으로 나뉘는데 하나는 shield space 밖에서 사용되는 thread를 위한 것 다른 하나는 안에서 사용되는 것을 위한 것이다.

두개는 거의 동일한데 일정부분의 주소를 untrusted는 접근하지 못한다.

virtual address도 각각 하나씩 가지고 있다.

모든 thread는 당연히 untrusted page table을 사용한다.

shield call을 보내서 trusted page table을 사용할 수 있다.

만약 사용하게되면 cpu에서 사용하는 page table을 바꾼다.

stack을 교체하고 지정된 call gate에서 다시 실행한다.

그리고 thread는 argument를 call gate에 넘겨준다. (최대 5개)

shield안에 있는 코드가 처리하고 다른 syscall을 이용하여 shield space를 나간다.

나간다는것은 shield를 들어오기 전으로 바꾸고 TLB를 flush하고 결과값을 return하는 것이다.

어차피 untrusted에서는 접근할 수 없기 때문에 flush 할 필요가 없다.

5.2 Effective syscall filtering

gpu driver가 오로지 shield space에게만 허가되어야 한다.

커널 안에 있는 device driver의 entry point체크로 달성 가능

state를 살펴서 trusted인지 아닌지 판별한다.

device driver안에 있는 handler의 수가 제한되기 때문에  가벼운 체크만 다수 진행한다.

처음에는 다른 filtering machanism을 사용했는데 퍼포먼스가 줄고 복잡해져서 포기함

5.3 satisfying the required guarentees

6. resusing webgl security checks for mobile graphics

webgl을 재활용해서 최소한의 engineering effort를 만드는 것이 목표이다.

webgl이 아직 업데이틑 되는중 그래서 checkgen이라는 tool을 만들었다.

이건 자동으로 webgl check를 mobile향으로 바꿔준다.

webgl을 알아야 이 부분을 잘 이해할 수 있을 것 같다. 

7. implementation

7.1 shield imtegration

필요할때만 메모리를 할당한다

address space는 1기가

다른 app과는 data와 code가 떨어져 있어야 한다.

그래서 library도 복사해서 따로 가지고 있는다. untrusted에 하나 shield에 하나 가지고 있는다.

global variables이랑 dynamic allocation도 각자 가지고 있다.

하지만 그러면 overhead가 생긴다.

나중에는 이름으로 이전에 안전이 확보된 app을 판별한다.

serialization하는 이유

security check할 때 conditional branch처럼 먼저 수행하고 security check를 한다는건가 는 안되려나