Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
2000년대 후반, 미국 T사의 차량에서 발생한 급발진 사고는 수십 건의 인명 피해를 남기며 전 세계 자동차 산업에 큰 충격을 안겨주었습니다.
당시 이 사건은 기계적 결함인지, 운전자 실수인지에 대한 논쟁이 이어졌지만, 미국 법정에서 제시된 기술 분석 결과는 한 가지 놀라운 사실을 보여주었습니다.
그림 1. T사 급발진 차량 사고 사진
(출처 : https://www.korea-press.com/news/articleView.html?idxno=24831)
2013년 오클라호마주에서 열린 재판에서, 차량의 전자제어 스로틀 시스템(ETS) 내 소프트웨어 결함이 급발진의 원인으로 지목되었습니다.
임베디드 소프트웨어 전문가인 마이클 바(Michael Barr)는 법정에서 T사의 소스 코드를 분석한 결과, 스택 오버플로우로 인해 스로틀 제어 태스크가 중단되었고, 이로 인해 스로틀이 열린 상태로 고정되어 급발진이 발생했다고 증언하였습니다.
이러한 결함은 fail-safe 시스템이 제대로 작동하지 못하게 만들었으며, 이는 차량 제어 시스템의 치명적인 취약점을 드러낸 사례로 평가됩니다.
이 사건은 미션 크리티컬 시스템에서 스택 사용량 분석의 중요성을 강조하며, StackAnalyzer와 같은 스택 사용량 분석 도구의 필요성을 부각 시키는 계기가 되었습니다.
(참고 : https://www.edn.com/toyotas-killer-firmware-bad-design-and-its-consequences/)
스택 오버플로우란?
스택(Stack)은 함수 호출 시 지역 변수나 반환 주소 등을 임시로 저장하는 메모리 영역입니다.
하지만, 함수가 너무 깊게 중첩되거나 큰 지역 변수를 많이 할당할 경우, 이 스택이 할당된 범위를 초과해 인접한 메모리 영역을 침범하는 오버플로우가 발생할 수 있습니다.
이런 스택 오버플로우는 예기치 않은 동작, 시스템 재시작, 혹은 태스크 종료로 이어지며, 미션 크리티컬 시스템에서는 단 한 번의 예외만으로도 생명을 위협하는 사고로 직결될 수 있습니다.
왜 단순한 스택 계산으로는 충분하지 않을까?
많은 개발자들이 정적 분석 도구나 컴파일러 출력에 포함된 스택 사용량 추정만으로 충분하다고 생각할 수 있습니다.
그러나 이러한 단순 계산 도구는 다음과 같은 중대한 한계를 가집니다.
▶ 단일 경로 기준 계산만 수행하여 복잡한 조건 분기나 반복, 인터럽트는 무시
▶ 라이브러리 함수, 어셈블리 루틴, ISR 등은 분석 대상에 포함되지 않음
▶ 최악의 실행 경로 (Worst-Case Execution Path)를 고려하지 않기 때문에, 가장 위험한 상황에서의 스택 사용량을 놓치게 됨
이러한 한계로 인해 테스트나 간단한 정적 계산만으로는, 실제로 발생 가능한 스택 오버플로우를 사전에 발견할 수 없는 경우가 생깁니다.
T사는 스택 사용량을 검사하지 않았나?
T사의 급발진 사고에서 가장 충격적인 부분은, 세계적인 자동차 기업조차 스택 사용량을 체계적으로 검증하지 못했다는 점입니다.
마이클 바의 법정 증언에 따르면, 문제의 핵심은 스택 오버플로우로 인해 태스크가 비정상 종료되었음에도, 시스템이 이를 감지하거나 복구하지 못했다는 것입니다.
T사는 할당된 스택 공간의 41%만 사용되었다고 주장했지만, 조사 결과 94%에 가까운 스택 공간이 사용되고 있었습니다.
자체적인 유닛 테스트와 HIL 테스트를 수행했지만, 그 범위는 일반적인 실행 경로에 한정되어 있었고 모든 조건 분기, 인터럽트 처리, 재귀 함수 호출 등으로 발생 가능한 최악의 스택 사용량까지는 충분히 분석하지 못한 것으로 보입니다.
이런 사례는 다음과 같은 중요한 교훈을 주었습니다.
▶▶▶ 단순한 코드 리뷰나 테스트만으로는 스택 오버플로우를 막을 수 없음
▶▶▶ 분석 도구를 통한 정량적 예측과 근거 기반 설계가 반드시 필요
스택은 작게 할당하면 위험하고, 과하게 잡으면 리소스를 낭비합니다.
StackAnalyzer와 같은 도구는 그 균형을 객관적인 분석을 통해 정밀하게 계산해주는 도구입니다.
작지만 치명적인 공간, 스택의 안전을 지키는 StackAnalyzer
스택은 시스템 메모리에서 상대적으로 작은 공간을 차지하지만, 그 영향력은 결코 작지 않습니다.
함수 호출, 인터럽트 처리, 태스크 스위칭 등 모든 실행 흐름에서 스택은 핵심적인 역할을 수행하며, 스택 오버플로우는 시스템 다운, 재부팅, 혹은 예측 불가능한 오동작으로 이어질 수 있는 가장 위험한 결함 중 하나입니다.
그렇다면, 이런 스택 오버플로우를 어떻게 사전에 방지할 수 있을까요?
바로 StackAnalyzer 도구를 활용하는 것입니다.
바이너리 기반의 정적 분석, 더 이상의 추정이 아닌 입증 기반 스택 검증
StackAnalyzer는 단순한 함수 호출 깊이 계산 도구가 아닙니다. 실제 타겟 CPU에서 실행될 바이너리 파일을 기반으로
▲ 함수 호출, 인터럽트 루틴, 반복/조건 분기, 재귀 호출 등 모든 경로를 분석하고
▲ 소스 코드뿐 아니라 링크된 정적 라이브러리, 어셈블리 함수까지 포함하며
▲ CPU의 특성과 Stack Pointer의 실제 이동 경로를 고려하여
▲ 모든 실행 시나리오에서 발생 가능한 최악의 스택 사용량(Worst-case Stack Usage)를 정밀하게 계산합니다.
그림 2. StackAnalyzer 결과 화면 리뷰
이처럼 StackAnalyzer는 단순한 코드 정적 분석 도구를 넘어서, 진정한 의미의 스택 안전을 제공합니다.
마치며…
많은 개발 현장에서 스택 사용량을 추정할 때, 컴파일러 출력이나 일부 정적 분석 도구에 의존합니다.
그러나 이러한 방식은 일반적으로,
▲ 단일 경로 기준으로만 분석하거나
▲ 인터럽트나 재귀 호출, 조건 분기 등을 무시하고
▲ 링크된 라이브러리 또는 어셈블리 함수는 아예 분석 대상에서 제외합니다.
즉, 실제 시스템에서 일어날 수 있는 복잡한 상황을 반영하지 못하고, 테스트 환경에서는 드러나지 않는 위험을 방치하는 결과로 이어질 수 있습니다.
StackAnalyzer는 그런 보이지 않는 위험을 수치화하고 입증할 수 있는 도구입니다.
스택은 작지만, 그 안전을 확보하는 것은 미션 크리티컬 시스템 개발의 첫 걸음입니다.
관련하여 문의사항이 있으신 경우, 언제든지 연락 남겨주시기 바랍니다. :)
MDS 인텔리전스
최대 Stack 사용량 검증 솔루션, StackAnalyzer
E. absint@mdsit.co.kr
