THINK-PRO BLOG

pintos 운영체제에는 자체 내장되어 있는 테스트 프로그램이 있습니다. 

src/userprog/ 디렉토리에서 'make check' 쉘 명령어를 입력하면, 76개의 테스트를 실행하며, 마지막에 테스트의 결과를 알려줍니다.

76개의 테스트 중 (제가 봤을 때) 제일 디버깅이 어려운 테스트는 'multi-oom'테스트입니다.

multi-oom테스트의 목적은 pintos운영체제의 메모리 누수가 존재하는지를 확인합니다.

메모리 누수가 일어나는 곳을 찾아야 하는데 쉽지 않습니다. 

multi-oom 테스트를 해결해나가는 약간의 팁을 제공하자면,

1) malloc - free를 정확하게 사용해라. 

malloc함수는 힙영역에 새로운 메모리를 할당하는 함수입니다. 만약에 어떤 함수에서 메모리를 새로 할당한 이후, 그 함수가 종료되기 전까지 할당한 메모리가 사라지지 않는다면, 계속해서 쓸모없는 메모리가 남게 되어 메모리 누수가 발생합니다. 따라서, 함수 루틴 안에서 반드시 malloc을 사용한 경우에는 그에 대응하는 free를 해주기 바랍니다. 참고로, malloc을 한 이후, 그 메모리를 가리키는 포인터를 다음에도 계속 가지고 있다면, 즉시 free를 해줄 필요는 없습니다. 최종적으로 그 메모리가 필요없게 되었을 때 정확히 free를 해주는 것이 관건인 것이지요.

간단히 말하자면, 함수 내에서 임시적으로 사용하기 위해 할당한 메모리는 그 함수가 끝나는 시점에서 즉시 free로 메모리 해제를 해주어야 하고, 스레드 내에서 파일 디스크립터 테이블과 같이 스레드가 죽을 때까지 가지고 있어야 하는 정보에 대한 메모리는 스레드가 죽을 때, 메모리 해제를 해주면 되는 것이지요.

2) 1)과 같은 이유로, palloc_get_page에 대응하는 palloc_free_page를 철저하게 사용하라.

1)과 동일한 이유입니다. palloc_get_page도 메모리를 할당하는 함수이고, palloc_free_page도 메모리를 해제하는 함수입니다.

3) 문자열에 대한 메모리 누수를 정확하게 계산하라.

운영체제를 건축하는 일은 C언어의 메모리 사용을 '정확히' 알아야 합니다.

하지만, 제가 학부생으로서 다른 친구들을 보았을 때 C언어의 메모리(포인터) 사용을 정확하게 아는 사람은 정말 드물어요.

아마 4학년 졸업한 후에도 10명 중 1명이 채 안될 겁니다. 정말 세밀한 부분까지 완벽하게 이해한 사람은 거의 없습니다.

물론 저도 아직 부족한 부분이 많고, 운영체제를 건축해보면서 더더욱 부족한 부분을 알게 되고 수정해나가네요.

그런 부분에서 큰 성장을 하는 것 같아 기분이 좋습니다. :) 

| 보안 이슈와 포인터의 남용 개요

  모든 어플리케이션에서 보안과 신뢰성은 주요한 관심 요소이다. 잦은 비도로 나타나는 보안 사고와 어플리케이션의 비정상 동작 떄문에 보안과 신뢰성에 대한 관심이 더욱 강화되고 있다. 애플리케이션의 보안에 대한 책임은 대부분 그 개발자에게 있다. 

  C로 안전한 어플리케이션을 작성하는 것은 언어에 고유한 몇 가지 속성 떄문에 쉽지 않다. 예를 들어, C는 프로그래머가 배열의 영역을 넘어선 영역에 데이터를 기록하는 것을 막지 않는다. 이러한 접근은 메모리가 손상되어 보안에 잠재적인 취약점이 될 수 있다. 또한, 포인터의 부적절한 사용은 종종 많은 보안 문제의 근본적인 원인이 되기도 한다.

  어플리케이션이 예상하지 못한 방식으로 동작한다고 해도 최소한 인가되지 않은(unauthorized) 접근이 발생하지 않는다는 점에서 보면, 보안 문제로 보이지 않을 수도 있다. 하지만 이런 비정상적인 동작을 이용해서 애플리케이션의 서비스를 거부하여 침해를 당할 수도 있다. 

  CERT(http://www.cert.org/)에서는 C와 다른 언어에서의 보안 이슈를 포괄적으로 다루고 있다. 이 조직은 인터넷 보안 취약점에 대해 연구한다. 포인터의 사용에 관한 보안 이슈에 대해 집중해 살펴보도록 하자. CERT 조직의 보안 이슈 중 많은 부분이 포인터의 부적절한 사용에 기인한다. 포인터와 그 적절한 사용 방법에 대한 이해는 안전하고 신뢰할 수 있는 애플리케이션을 개발하는 데 매우 중요한 역할을 한다. 

  운영체제의 보안은 많이 개선됐다. 그런 개선 사항 중의 일부는 메모리의 사용 방법에 반영되었다. 일반적으로 운영체제의 개선 사항은 개발자의 통제 범위를 벗어나 있긴 하지만 애플리케이션에도 영향을 준다. 이런 이슈를 이해해야만 애플리케이션의 동작에 대해 설명할 수 있다. 주소 영역 배치 랜덤화(Address Space Layout Randomization)와 데이터 실행 방지(Data Execution Prevention)에 대해 집중적으로 살펴보고자 한다.

  주소 영역 배치 랜덤화(ASLR) 절차는 메모리 내 애플리케이션의 데이터 영역을 랜덤하게 배치한다. 데이터 영역은 코드, 스택, 힙을 포함한다. 이 영역의 배치를 랜덤화하면 공격자가 메모리가 어디에 위치할지 예측하기 어려우므로 데이터 영역에 접근하기 힘들다. return-to-libc같은 특정한 종류의 공격은 스택 일부를 덮어쓴 후, 제어를 이 영역으로 넘긴다. 이 영역은 보통 공유 C 라이브러리인 libc이다. 스택과 libc의 위치가 알려지지 않는다면, 이런 공격은 성공하기 어려울 것이다.

  데이터 실행 방지(DEP) 기법은 코드가 메모리의 실행 불가능한 영역에 있을 때 실행을 차단한다. 몇몇 종류의 공격은 메모리의 영역을 악성 코드로 덮어쓴 후, 제어를 이 영역으로 넘긴다. 이 코드 영역이 스택이나 힙처럼 실행 불가능한 영역일 경우 실행되지 않는다. 이 기법은 하드웨어나 소프트웨어로 구현할 수 있다.

앞으로 다음과 같은 몇 가지 측면에서 보안 이슈에 대해 알아보도록 하겠다. 

* 포인터의 선언과 초기화

* 부적절한 포인터 사용

* 메모리 해제 문제

※ 'Understanding and Using C Pointers' 책에서 일부 내용을 따온 것입니다.

그렇다면 한 번에 인접한 메모리를 할당하려고 한다면 어떻게 해야 할까?

이 포스트에서, C언어로 다차원 배열을 할당하는 경우 메모리를 인접하게 할당하는 방법에 대해서 다룰 것이다.

| 일반적인 코딩 방법

우리는 일반적으로 다차원 배열을 동적으로 할당할 때, 다음과 같이 코딩을 한다.

 int rows = 2;
 int columns = 5;
 int i=0, j=0;

 int ** matrix = (int**) malloc(rows*sizeof(int*));

 for(i=0; i<rows; i++){
         matrix[i] = (int*)malloc(columns * sizeof(int));
 }

그런데, 이렇게 해버리면 다음과 같이 결과가 나타난다.

▲ [0][4] 원소와 [1][0] 원소 사이에 16바이트 갭이 생겼다.

첫 번째 행의 마지막 원소와 두 번째 행의 첫번쨰 원소의 주소가 int 변수의 크기인 4 byte만큼 차이가 나는 것이 아니라 16 byte가 차이난다. (위 숫자들은 전부 16진수임을 알기를 바란다. 40에서 50으로 갔음은 10바이트가 아니라 16바이트가 차이났음을 의미한다.)

이제, 해결책에 대해서 알아보자.

2차원 배열에 인접한 메모리를 할당하는 두 가지 접근 방법이 있다. 첫 번째 기법은 '바깥쪽' 배열을 먼저 할당한 후 전체 열에 대한 메모리를 할당하는 방법이고, 두 번째 기법은 모든 메모리를 한 번에 할당하는 방법이다. 

| 첫 번째 방법

첫 번째 기법을 다음 예제 코드에서 설명하고 있다. 첫 번째 malloc 함수 호출로 정수에 대한 포인터의 배열을 할당한다. 각 요소는 열에 대한 포인터를 가지게 된다. 두 번째 malloc 함수 호출은 우리가 선언할 다차원 배열의 제일 첫 번째 원소의 주소에 모든 요소에 대한 메모리를 할당하게 된다. (말이 어렵다면, 그냥 배열의 이름에다가 이후에 저장할 모든 메모리의 크기를 한 번에 할당한다고 생각하자.) 그리고 for 루프는 첫 번째 배열의 각 요소에 두 번째 malloc에서 할당한 메모리의 일부분을 지정한다.

int rows = 2;
int columns = 5;
int i=0, j=0;

int ** matrix = (int**)malloc(rows*sizeof(int*));
matrix[0] = (int*)malloc(rows*columns*sizeof(int));
for(i=1; i<rows; i++)
        matrix[i] = matrix[0] + i*columns;

엄밀히 따지면, 첫 번째 배열의 메모리는 배열의 '본체(body)' 부분과 떨어져 있을 수도 있다. 하지만 배열의 본체 부분에서는 메모리의 인접한 영역이 할당된다. 

▲ 배열의 모든 요소들이 인접하게 나열됬다.

| 두 번째 방법

다음 예제 코드에서는 두 번째 기법을 설명하고 있다. 

int * matrix = (int*)malloc(rows*columns*sizeof(int));

결과는 다음과 같다.

나중에 코드 안에서 이 배열을 참조할 때는 배열 첨자를 사용할 수 없다. 대신, 다음 코드에서 설명하는 것처럼 배열에 대한 인덱스를 수동으로 계산해야 한다. 각 배열 요소는 그 인덱스의 곱으로 초기화한다. (컴파일러가 배열 첨자를 허용할 때 필요한 배열의 형태에 대한 정보가 없으므로 배열 첨자를 사용할 수 없기 때문에 배열 첨자를 사용할 수 없는 것이다.)

int i=0, j=0;

for(i=0; i<rows;i++){
        for(j=0; j<columns; j++){
                *(matrix+(i*columns)+j) = i*j;
        }       
} 

2차원 배열에 대한 인접한 메모리를 할당하는 두 가지 일반적인 접근 방법에 대해 설명했다. 어떤 방법을 이용할 것인지는 어플리케이션에 따라 다르다. 하지만 두 번째 접근 방법이 '전체'배열에 대한 단일 메모리 블록을 생성한다.

포인터의 사용법의 구문과 의미는 C 표준 문서(http://bit.ly/173cDxJ)에 매우 자세히 설명되어 있다. 그러나 표준 문서가 포인터의 동작을 명확히 정의하지 못하는 경우가 있다. 이러 떄 표준 문서는 포인터의 동작을 다음과 같이 정의한다.

- 구현 방법에 따라 정의된 행동(Implementation-defined behavior)

 동작에 대한 문서화된 구현을 제공한다. 구현 방법에 따라 정의된 행동의 예로, 정수에 대한 오른쪽 시피트 연산에서 상위 비트의 확장 방법이 있다.

- 명시되지 않은 행동(Unspecified behavior)

 동작에 대한 구현을 제공하지만 문서화하지 않는다. malloc함수에 인자로 0을 주고, 실핼할 때 메모리가 얼마나 할당되는가 하는 것이 명시되지 않은 행동의 예가 될 수 있다. 명시되지 않은 행동의 목록을 CERT Secure Coding Appendix DD에서 볼 수 있다.

- 정의되지 않은 행동(Undefined behavior)

 포인터의 동작에 대해 어떠한 것도 강요하지 않으므로 어떠한 동작도 발생할 수 있다. 이 경우의 예로, free 함수에 의해 해제된 포인터의 값이 있다. (C 표준은 해제된 포인터에 어떤 값이 들어 있는지 정의하지 않는다.) 정의되지 않은 행동의 목록은 CERT Secure Coding Appendix CC(http://bit.ly/16msOVK)에서 찾을 수 있다.

포인터가 여전히 해제된 메모리 영역을 가리키고 있다면, 이러한 포인터를 댕글링 포인터(Dangling Pointer)라고 한다. 댕글링 포인터가 가리키는 메모리는 더는 유효하지 않다. 댕글링 포인터는 premature free(조숙한 해제, 너무 급한 해제)라고 부르기도 한다.

댕글링 포인터의 사용은 아래 목록에 나열된 문제를 포함한 다양한 문제를 야기한다.

- 메모리 접근시 예측 불가능한 동작

- 메모리 접근 불가 시 Segmentation fault

- 잠재적인 보안 위험

이러한 유형의 문제는 다음과 같은 동작의 결과로 발생한다.

- 메모리 해제 후, 해제된 메모리에 접근

- 함수 호출에서 자동 변수를 가리키는 포인터의 반환

< 댕글링 포인터 예제 >

int * pi = (int * )malloc(sizeof(int)); *pi = 5;  printf("*pi: %d\n", *pi); free(pi);

free 함수로 메모리를 해제한 후에도 변수 pi는 여전히 메모리의 주소를 가리키고 있다. 그러나 이 메모리는 힙 관리자에 의해 재사용되거나 기존의 정수가 아닌 다른 타입으로도 사용될 수 있다. free 함수를 호출하면 원래 pi 포인터가 가리키고 있던 주소에 위치한 메모리는 해제되며 다시는 사용할 수 없다. 그러나 대부분의 런타임 시스템에서 해제 뒤에 발생하는 메모리의 접근이나 변경을 막지 않는다. 아래 코드에서 보듯이 여전히 해당 메모리에 접근하여 쓰기를 시도할 수 있으며, 이러한 시도의 결과는 예측할 수 없다.

free(pi); *pi = 10; 

하나 이상의 포인터가 같은 메모리 영역을 가리키고 그 중 하나가 해제된 경우에는 좀 더 복잡하다. 아래 코드처럼 변수 p1과 p2는 둘 다 같은 메모리 영역을 가리키고 있으며, 이러한 상황을 포인터 에일리어싱(Aliasing)이라고 한다. 그런데, p1이 해제되었다.

int * p1 = (int *)malloc(sizeof(int)); *pi = 5; ... int * p2; p2 = p1; ... free(p1); ... *p2 = 10;          // p2는 댕글링 포인터이다. 

또 다른 예제가 있다. 아래 코드와 같이 블록 구문을 사용할 때도 다른 미묘한 문제가 발생한다. 변수 pi에는 tmp의 주소가 할당되며, 변수 pi는 전역 변수이거나 로컬 변수이다. 그러나 변수 tmp는 블록 안에서 선언되고 블록 구문이 닫힐 때 스택에서 제거되며, tmp의 주소는 더는 유효하지 않다.

int *pi; ... {     int tmp = 5;     pi = &tmp; } // 이 위치에서 pi는 댕글링 포인터가 된다. foo(); 

대부분 컴파일러는 블록 구문을 스택 프레임으로 다룬다. 변수 tmp는 블록 안의 스택 프레임에 할당되며, 이어서 블록 구문이 종료되면서 스택 프레임이 제거된다. 블록의 스택 프레임으로 사용된 메모리 영역은 나중에 다른 방식으로 재사용(예제에는 foo함수가 호출되므로 foo함수에 의해 재사용)되며, 변수 pi는 여전히 그 위치를 가리키고 있게 된다.

< 댕글링 포인터 다루기 >

포인터가 원인인 문제들의 디버깅은 떄로 해결하기 어려울 때가 있다. 댕글링 포인터 문제를 처리하기 위한 몇 가지 접근 방법을 아래에 나열하였다.

- 메모리 해제 후 포인터를 NULL로 설정하여라.

NULL로 설정한 포인터를 그 이후에 사용하면 애플리케이션이 종료할 것이다. 그러나 해당 포인터에 대한 다수의 복사본이 존재할 경우 문제는 여전히 발생한다. 포인터에 NULL을 설정하는 일은 많은 포인터 복사본 중에 단 하나의 포인터에만 영향을 미치기 때문이다. 이와 비슷한 문제를 앞 절 "이중 해제"에서 언급한 적이 있다.

- free 함수를 대체할 새로운 함수를 작성하여라.

- 몇몇 런타임 시스템이나 디버깅 시스템은 해제된 메모리를 특별한 값으로 덮어쓴다.

(예를 들어, 0xDEADBEEF - Visual Studio는 해제된 메모리의 종류에 따라 0xCC, 0xCD, 0xDD 값을 사용하여 덮어쓴다). 예외가 발생하지 않은 상황이라도 프로그래머는 예상치 못한 곳에 이러한 값이 포함된 것을 보고 프로그램이 해제된 메모리에 접근한 것을 알 수 있다.

- 댕글링 포인터와 다른 문제들을 발견하기 위해 서드파티 도구들을 사용하라.

< 메모리 누수 탐지 기능 >

마이크로소프트는 동적으로 할당된 메모리를 덮어쓰는 문제와 메모리 누수 문제를 해결하기 위한 기술을 제공하며, 이 접근 방식은 프로그램의 디버그 버전에서 아래에 나열된 특별한 메모리 관리 기술을 사용한다.

- 힙의 무결성 검사

- 메모리 누수 검사

- 힙 메모리가 부족한 상황 재현

마이크로소프트는 메모리 할당을 관리하기 위한 특별한 데이터 구조체를 사용한다. 그리고 이 구조체의 사용으로 위와 같은 메모리 관리 기술을 제공한다. 이 구조체는 malloc 함수가 호출된 파일명과 줄 번호와 같은 디버그 정보를 관리한다. 게다가, 메모리를 덮어쓴느 문제를 찾기 위해 메모리 할당 전후로 버퍼가 할당된다. 이 기술에 대한 추가적인 정보는 Microsoft Developer Network(http://bit.ly/12SftWV)에서 찾을 수 있다.

Mudflap 라이브러리(http://bit.ly/YilPI1) 사용하면 GCC에 비슷한 기능을 사용할 수 있다. Mudflap의 런타임 라이브러리는 수많은 기능을 제공하며 그중에서도 특히 메모리 누수 탐지 기능이 제공된다. 이 메모리 누수 탐지 기능은 포인터 역참조 연산들을 계산하고 측정하는 방식으로 수행된다.

/// 이 글의 출처는 "Understanding and Using C Pointers(리처드 리스 지음)"입니다.

This post is some part from the book called "Understanding and Using C Pointers".