어떤 마이크로컨트롤러 계열에서 이 문제가 발견된 건지 정말 궁금함
만약 이게 lockstep, ECC 등을 사용하는 safety processor라면, ECC로는 감지되지 않는 수준의 비트 플립이 발생했다는 뜻임
데이터 손상이라면 단순 재시작이 아니라 한 워드 내에서 여러 비트가 동시에 뒤집힌 상황일 수도 있음
환경이 특별히 다르지 않다면, 전압 마진 같은 걸 줄였을 가능성도 있음
NVM인지 SRAM인지도 궁금함
다른 스레드에서 언급했듯이, 해당 시스템에는 EDAC이 없었음
MCU가 아니라 여러 칩으로 구성된 시스템이었고, 90년대에 설계되어 2002년에야 EDAC가 추가된 새 하드웨어 버전이 나왔음
이런 상황이라면 비트 플립이 충분히 일어날 수 있었음
자세한 내용은 ATSB 보고서에 있음
예전 Raspberry Pi 2 초기 리비전은 카메라 플래시 같은 강한 빛을 받으면 크래시가 났음
특히 제논 플래시가 문제였음
관련 사례는 포럼 글, 추가 토론, 공식 블로그, 유튜브 영상에서 볼 수 있음
제대로 된 SEU(단일 사건 업셋) 대응은 ECC만으로는 부족함
위성은 A320보다 훨씬 높은 고도에서 운용되며, 대부분 Triple Modular Redundancy를 사용함 TMR 설명, SEU 개념 참고
NASA는 유인 비행에서는 N을 5로 늘림
캐시를 완전히 비활성화하거나 ECC RAM을 지속적으로 리프레시하는 등의 방법도 있음
디지털 회로의 latch-up을 방지하는 하드웨어 대책도 존재함
하드웨어 문제를 소프트웨어 패치로 해결하려는 게 걱정스러움
컴퓨터 업계에 오래 있다 보면 이런 비트 플립 사건을 여러 번 보게 됨
ECC가 대부분은 구해주지만, 때로는 소프트웨어가 이상값을 감지하고 무시하도록 설계되어 있기도 함
실시간·안전 중요 시스템에서는 여러 시스템이 투표 방식으로 오류를 검증하기도 함
90년대에 CPU 캐시라인 비트 플립 때문에 몇 달 동안 고생한 적이 있음
우리 로그에서도 이런 현상을 본 적이 있음
대규모 트래픽을 처리하는 서비스에서 enum 형태의 값을 요약했는데, 불가능한 값이 몇 개 발견됨
문자열이 정확히 한 비트 차이로 잘못 기록된 걸 보고, 우주선(코스믹 레이) 영향일 가능성을 추정했음
예전에 함께 일하던 동료가 있었는데, 항상 문제 원인을 중성미자 탓으로 돌리곤 했음
실제로는 재현 가능한 버그였는데도, 커널·드라이버·클라이언트까지 다 의심한 뒤에야 자기 실수를 인정했음
그래도 천재였고, 이번 A320 사건에 대해서는 정말 그가 맞았을지도 모름
Hacker News 의견
어떤 마이크로컨트롤러 계열에서 이 문제가 발견된 건지 정말 궁금함
만약 이게 lockstep, ECC 등을 사용하는 safety processor라면, ECC로는 감지되지 않는 수준의 비트 플립이 발생했다는 뜻임
데이터 손상이라면 단순 재시작이 아니라 한 워드 내에서 여러 비트가 동시에 뒤집힌 상황일 수도 있음
환경이 특별히 다르지 않다면, 전압 마진 같은 걸 줄였을 가능성도 있음
NVM인지 SRAM인지도 궁금함
MCU가 아니라 여러 칩으로 구성된 시스템이었고, 90년대에 설계되어 2002년에야 EDAC가 추가된 새 하드웨어 버전이 나왔음
이런 상황이라면 비트 플립이 충분히 일어날 수 있었음
자세한 내용은 ATSB 보고서에 있음
특히 제논 플래시가 문제였음
관련 사례는 포럼 글, 추가 토론, 공식 블로그, 유튜브 영상에서 볼 수 있음
위성은 A320보다 훨씬 높은 고도에서 운용되며, 대부분 Triple Modular Redundancy를 사용함
TMR 설명, SEU 개념 참고
NASA는 유인 비행에서는 N을 5로 늘림
캐시를 완전히 비활성화하거나 ECC RAM을 지속적으로 리프레시하는 등의 방법도 있음
디지털 회로의 latch-up을 방지하는 하드웨어 대책도 존재함
컴퓨터 업계에 오래 있다 보면 이런 비트 플립 사건을 여러 번 보게 됨
ECC가 대부분은 구해주지만, 때로는 소프트웨어가 이상값을 감지하고 무시하도록 설계되어 있기도 함
실시간·안전 중요 시스템에서는 여러 시스템이 투표 방식으로 오류를 검증하기도 함
90년대에 CPU 캐시라인 비트 플립 때문에 몇 달 동안 고생한 적이 있음
대규모 트래픽을 처리하는 서비스에서 enum 형태의 값을 요약했는데, 불가능한 값이 몇 개 발견됨
문자열이 정확히 한 비트 차이로 잘못 기록된 걸 보고, 우주선(코스믹 레이) 영향일 가능성을 추정했음
실제로는 재현 가능한 버그였는데도, 커널·드라이버·클라이언트까지 다 의심한 뒤에야 자기 실수를 인정했음
그래도 천재였고, 이번 A320 사건에 대해서는 정말 그가 맞았을지도 모름
The Aviation Herald에 더 기술적인 세부 내용이 있음
“이 취약점은 최악의 경우 조종되지 않은 엘리베이터 움직임을 유발해 기체 구조 한계를 초과할 수 있음”
항공우주 업계는 오래전부터 비트 플립 대응책을 마련해왔음
Airbus/Thales의 이번 수정은 오류 검사를 강화하고, 문제가 생긴 컴포넌트를 자동으로 재시작하는 방식임
자세한 내용은 BEA 보고서에 있음
BoFH 스타일의 느낌이 남
“금요일 아침 일찍 출근했는데 전화가 울림. 변명 시트를 넘기니 ‘태양 플레어’가 나를 바라보고 있음…”
링크
이 사건이 어떻게 진단되었는지 궁금함
FDR(비행기록장치)이 저수준 오류까지 기록하는지, 아니면 고수준 입력값만 저장하는지 잘 모르겠음
방사선으로 인한 비트 플립이라면 그걸 어떻게 알아챘을까?
혹시 메인 비행 컴퓨터 간의 투표 오류 같은 게 기록되었을지도 궁금함
비슷한 SEU(단일 사건 업셋) 사례에 대한 훌륭한 사후 분석 보고서가 있음
“태양에 너무 가까이 날았다”는 농담 같은 반응임
이런 일로 전체 기단을 운항 중지할 필요가 있을까 의문임
수년간 수만 대 중 한 번의 사건이라면, 두 달 정도猶予를 주고 수정해도 충분하지 않을까 생각함
해결책은 다운그레이드하거나 이전 버전 하드웨어로 교체하는 것임
Airbus 입장에서는 운항 중지로 인한 직접 손실은 적지만, 만약 사고가 나면 평판·소송 리스크가 훨씬 큼
“우리는 선제적으로 대응하지만, 경쟁사는 사고 후에야 조치한다”는 식으로 말할 수 있음
언론 보도에 따르면 이번 조치는 소프트웨어 업데이트 롤백임
원래 업데이트의 목적이 무엇이었는지, 그리고 비행 컴퓨터 소프트웨어가 얼마나 자주 갱신되는지 궁금함