[Fault Injection] A Micro Architectural Events Aware Real-Time Embedded System Fault Injector

 

 

 

임베디드 시스템의 성능을 끌어올리기 위해 멀티코어 CPU와 복잡한 캐시 계층 구조를 사용하는데.. 시스템이 복잡해질수록 Soft Error에 취약해진다. 

 

시스템의 신뢰성을 테스트하려면 의도적으로 Fault를 넣어 봐야 하는데, 하드웨어 방식은 제어하기 어렵고 소프트웨어 방식은 제어하기 쉽지만 실행 시간이 너무 오래 걸린다. 

 

그러니 새로운 Debug Unit을 제안함. 낮은 오버헤드로 원하는 시점에 Fault를 넣어 볼 수 있는 환경을 제공한다.

 

최신 CPU의 PMU는 clock cycle, memory operation, cache hit/miss, branch statistics를 실시간으로 추적하고 이런 데이터는 HPC에 기록된다. 

그러니 결함이 발생했을 때 발생하는 하드웨어 이벤트 패턴을 수집해 효과적인 머신러닝 기반 Fault Detector를 구축할 수 있다.

 

 

 

 

 

 

현대 마이크로프로세서는 정밀한 제어를 제공하는 전용 디버거를 가지고 있다.

즉, 소시보 수업에서 다뤘던 JTAG 디버거를 쓰면 하드웨어 수준에서 실행을 중지하거나 레지스터 값을 조작할 수 있음.

 

공격자는 (target_location, target_instruction) 튜플을 생성하고 Fault Inject를 수행함.

튜플 하나가 위치와 시점에 정확하게 연결되니 테스트 데이터를 추출하기 좋다. 

 

원래대로라면 CPU가 추적할 수 있는 이벤트에 비해 HPC의 개수가 너무 적어 데이터 수집에 문제가 있지만, 이 방법을 사용하면 동일한 결함을 반복 주입할 수 있어 매번 다른 HPC지표를 수집할 수 있으니 전체적인 결함 Pulse 패턴을 완성할 수 있다.

 

그냥 딱딱이로 치거나 전압 흔들어버리면 되는 거 같은데 앞서 말했듯 굳이 디버거를 쓰는 이유가 있음..

전압을 흔들어버리면 칩 전체가 영향받는다. 근데 나는 특정 레지스터의 3번째 비트만 뒤집고 싶은데? 

 

JTAG 프로토콜을 사용하면 튜플 덕분에 정밀 저격이 가능함. 

어셈블리 명령어 수준에서 실행을 멈추고 레지스터와 메모리 값을 조작할 수 있다. 

 

그런데 전압 흔들기를 인식하려면 전압 흔들기에 대한 데이터를 수집해야 하지 정밀 저격 데이터를 수집하면 안되는거 아닌가 싶기도 한데..

원인과 결과를 잘 짚어야 한다. 

 

원인은 다른데 결과는 Bit-Flip으로 똑같음.

전압이 흔들리는 소리를 듣는게 아니라 비트가 뒤집혀서 CPU가 어리버리까는 소리를 학습하기에 문제가 없다는 것..

비트가 뒤집힌 후에 CPU는 잘못된 명령어를 실행하려고 하거나 이상한곳으로 점프한다.

이런 동작을 처리하면서 뱉는 신호에 집중한다고 보면 됨.

 

애초에 전압을 흔들면 데이터에 노이즈가 많이 껴서 학습할 때 힘들어진다.

그러니 Bit-Flip의 순수한 패턴을 학습하는게 필요함.

 

Fault Injection 은 5가지 방법으로 Bit-Flip을 유도하는데, 공격의 결과는 Bit-Flip이지만 공격의 신호는 각각 다르다.

이 논문에서는 Bit-Flip 으로 발생하는 현상만 다루지만 각 공격별로 나타나게 되는 신호를 추가적으로 학습한다면 정교한 비교가 가능할 듯..

 

 

 

 

 

실제 실험 환경을 구축할 때는 Host와 Target을 분리한다.

 

Host는 파이썬으로 구축되어있고 XSCT를 사용해 JTAG으로 보드에 명령을 내린다.

Pexpect 라이브러리를 사용해 보드에서 특정 메세지가 출력되면 메세지에 해당하는 명령을 내리라고 설정되어있음.

 

Target은 실제 보드로, FreeRTOS와 실행시킬 애플리케이션이 들어있는 몸통이다.

 

1. 무작위로 target_location과 target_instruction을 정해 Fault List를 만든다. 

2. 공격하려는 시점에 일시정지 버튼을 예약함. 

3. 보드가 실행되다가 그 지점에 걸리면 호스트가 제어권을 가져가 Bit-Flip 후 다시 실행시킨다.

4. 작업이 마무리되면 HPC를 읽어온다. 

 

HPC를 읽으려면 소스코드에 특수 명령어를 심어야 함.

 

int OS_main (){
    taskCreate( faultInjectorTask );
    taskStartScheduler();
    for( ;; ); // endless loop for the OS
}

static void faultInjectorTask(){
    confPMU();
    startTasks();
    readPMU();
    // taskDelete( NULL );
} // <- final breakpoint point here

 

 

외부 Host가 JTAG으로 읽는 것 보다 readPMU()로 읽는게 CPU 상태를 정확하고 빠르게 캡쳐할 수 있음.

HPC 카운터 개수가 한정되어있으니 동일한 결함을 여러 번 반복 주입하며 매번 다른 지표를 수집해 Pulse 패턴을 완성한다.

 

그래서 직접 해 보니까 결과는 다음과 같이 나왔다고 함.. 

 

하드웨어 스펙 

하드웨어 : Xilinx PYNQ Z2 보드 (Dual-corer ARM Cortex A9)

PMU : HPC 6개 / 168개 아키텍처 이벤트 모니터링 가능 

OS : FreeRTOS (실시간성 때문)

 

결과 분류 

Benign : 결과값이 정상과 같음 (Fault Injection 했지만 정상 실행과 결과가 같음)

SDC : 시스템은 끝까지 실행됐지만 결과값이 틀림 (공격이 성공한 상황) - Silent Data Corruption

Crash/Hang : 시스템이 멈추거나 응답이 없음 

 

벤치마크

SHA, Dijkstra : 연산 중심 애플리케이션 실행

QSort : 메모리 중심 애플리케이션 실행

 

 

CPU Register

PC나 Stack Pointer같은 위험한 레지스터를 제외했기에 대부분 Benign으로 나타남.

SHA, Dijkstra같이 연산이 많은 경우 SDC 비율이 높게 나타난다.

 

Program Counter

실행 흐름 자체가 엉망이 되니 대부분 Crash/Hang으로 나타남.

시스템이 멈춘걸 Host가 Timeout으로 인식해야하니 실험 시간도 길다.

 

Memory

메모리는 공간이 넓어 현재 사용하지 않는 데이터가 들어있는 곳에 Bit-Flip이 발생할 확률이 높음.

그러니 대부분 Benign으로 나타남.

 

 

 

 

Principal Component Analysis 결과 SDC와 Benign은 정상 HPC 패턴에서 큰 차이가 있음.

 

SDC는 정상 데이터가 모여 있는 군집에서 멀리 떨어지거나 분산이 넓은 형태로 분포된다. 

즉, 패턴 변화가 뚜렷하니 인공지능으로 가장 쉽고 확실하게 잡아낼 수 있음.

 

Benign은 일단 결과값이 정상이지만, 실행 사이클 수치에 변동이 생긴다. 

즉, Bit-Flip이 결과를 바꾸지 않아도 실시간성은 해칠 수 있다는 것.

Cycles나 내부 연산 흐름에 미세한 변화가 발생하니 이 타이밍의 불일치를 포착해 Benign 결함도 탐지할 수 있다.

 

 

 

 

 

참고

1. A Micro Architectural Events Aware Real-Time Embedded System Fault Injector

https://arxiv.org/abs/2401.08397