[Arm][AAPCS] 프로세스의 스택 사이즈를 점검하는게 중요

이에 못지 않게 점검해야 할 중요한 정보는 프로세스의 스택 사이즈입니다. 여러분이 작성한 코드가 실행되는 운영체제나 RTOS마다 프로세스에게 할당하는 스택 사이즈도 약간의 차이가 있기 때문입니다. 예를 들어 부트로더로 사용되는 LK(Little Kernel)은 4096(0x1000) 바이트만큼 프로세스의 스택을 설정하고, 범용 운영체제로 분류되는 리눅스 커널은 프로세스의 스택 사이즈를 0x2000(32비트 기준)로 설정합니다.

프로세스의 스택 사이즈를 상대적으로 크게 할당하는 운영체제에서 개발자는 지역 변수로 배열의 크기를 별 생각 없이 크게 잡습니다. 크게 잡아도 별 문제가 일어나지 않기 때문입니다. 그런데 같은 코드를 프로세스에게 작은 사이즈의 스택을 할당하는 RTOS에 적용하면 문제가 될 수 있습니다.

오픈 소스로 진행되는 프로젝트의 코드를 활용할 때도 유사한 상황을 겪습니다. 오픈 소스를 가져다가 여러분의 시스템에서 사용할 때 가끔 예상치 못한 에러를 만나는데, 그 중 대표적인 증상이 스택 오버플로우입니다.

예를 들면 다음 코드에서 10개 정도의 문자열을 복사하기 위해 배열의 크기를 256으로 설정합니다.

01 static void update_debug_string(void)
02 {
03 char data[256];
04
05 memset((void *)data, 0, sizeof(data));
06      strcpy(data, "trace start \n");
07 }

 

이런 코드는 프로세스마다 0x2000 바이트만큼 스택을 할당하는 리눅스 커널 드라이버에서는 별 문제 없이 동작할 것입니다. 하지만 프로세스마다 0x800 정도의 스택 공간을 할당하는 RTOS에서는 스택 오버플로우를 유발할 수 있습니다.

 

[정보]
필자도 유사한 사례를 겪은 적이 있습니다. 다른 운영체제에서는 제대로 동작하는 코드를 다른 RTOS에 적용했던 경우입니다. 스택 오버플로우가 발생 해 메모리 공간을 오염시켜, 다양한 버그가 유발된 적이 있습니다.