Toyota’s killer firmware: Bad design and its consequences

출처: http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware–Bad-design-and-its-consequences

 

Barr’s ultimate conclusions were that:

• Toyota’s electronic throttle control system (ETCS) source code is of unreasonable quality.
• Toyota’s source code is defective and contains bugs, including bugs that can cause unintended acceleration (UA).
• Code-quality metrics predict presence of additional bugs.
• Toyota’s fail safes are defective and inadequate (referring to them as a “house of cards” safety architecture).
• Misbehaviors of Toyota’s ETCS are a cause of UA.

 

토요타의 주장과 Barr 그룹의 주장. Evidence를 들여다보고 싶다.

Category	Toyota	Barr Group
Hardware	2005 Camry’s CPU had error detecting and correcting(EDAC) RAM	It didn’t. EDAC or at least parity RAM is relatively easy and low-cost insurance for safety-critical systems
Software		Mirroring(where key data is written to redundant variables) was not always done.
		This gains extra significance in light of stack overflow
	only 41% of the allocated stack space was being used	94% was closer to the truth
		stack-killing, MISRA-C rule-violating recursion was found in the code
		the CPU doesn’t incorporate memory protection to guard against stack overflow
		Two key items were not mirrored: The RTOS’ critical internal data structures; and—the most important bytes of all, the final result of all this firmware—the TargetThrottleAngle global variable.
		Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.
		Toyota’s ETCS used a version of OSEK, which is an automotive standard RTOS API. For some reason, though, the CPU vendor-supplied version was not certified compliant.
		Unintentional RTOS task shutdown was heavily investigated as a potential source of the UA
		As single bits in memory control each task, corruption due to HW or SW faults will suspend needed tasks or start unwanted ones
		Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration
		A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks

Toyota Case: Single Bit Flip That Killed

출처: EETimes

 

Bar라고 하는 애들이 도대체 도요타에게 무슨 짓을 저지른 것일까? 저렇게 시험해서 온전하게 돌아가는 제품이 있을까? IMF때 금리올리고 회사 다 망하게 놔두고 국유화하지 말라고 한 그들이 정작 자기네들 문제생겼을때는 금리내리고 회사 국유화시키고 … 한 것처럼 그렇게 하면 망하는 것을 다른 나라에게 요구하는 것인가? 생각이 들기도 한다.

미국내 제품을 대상으로 시험해도 과연 통과할까? …

---

Task X death
Now that the experts’ testimony and findings have been made public through the Oklahoma trial, let’s get into details. What defects were found in Toyota’s electronic throttle control systems?

Barr said that the 2005 Camry L4 source code and in-vehicle tests by the experts confirmed that some critical variables are not protected from corruption, and sources of memory corruption are present. He believes that Toyota’s engineers sought to protect numerous variables against software- and hardware-cause corruptions, but they failed to mirror several key critical variables, and they made no hardware protection available against bit flips.

Stack overflow and software bugs led to memory corruption, he said. And it turns out that the crux of the issue was these memory corruptions, which acted “like ricocheting bullets.”

중요변수에 대한 FMEA를 하는 것이 필요하다는 의미이다. 하면 품질관점에서 좋아지긴 하겠지, 근데 그 기준이라는 것이 상당히 결정하기 어려운 문제인데, 위의 문구만 보면 Detailed design수준의 FMEA가 필요한 것처럼 보인다.

Stack overflow및 memory corruption에 대한 대비책을 위해서 protection을 hw level 뿐만 아니라 sw level에서 해야 한다.

 

Barr explains the issue this way:

Memory corruption as little as one bit flip can cause a task to die. This can happen by hardware single-event upsets — i.e., bit flip — or via one of the many software bugs, such as buffer overflows and race conditions, we identified in the code.

There are tens of millions of combinations of untested task death, any of which could happen in any possible vehicle/software state. Too many to test them all. But vehicle tests we have done in 2005 and 2008 Camrys show that even just the death of Task X by itself can cause loss of throttle control by the driver — even as combustion continues to power the engine. In a nutshell, the fail safes Toyota did install have gaps in them and are inadequate to detect all of the ways UA can occur via software.

메모리 bit flip에 의해서 task가 die에 이르는 문제는 아주 심각한 문제인데, mcu에서 이런 문제를 해결하기 위한 설계가 필요할 뿐만 아니라 OS에서도 cover해줘야 한다. 그런데, …. 이건 정말 맘먹고 털려고 작정해서 턴게 아닌가? 이런 생각이 든다. 아직까지 그와 같은 엄격한 수준의 상세화가 표준화되지도 않았는데, 과연 누가 저렇게까지 설계를 했을까 생각이 들기도 한다.. 그런데 누군가는 그렇게 했을지도 모르지..

Just to clarify, the “tasks” are equivalent to apps running on smartphones or PCs. All software malfunctions from time to time — we often have to reboot our machines. The 2005 Camry L4 has a set of dozens of apps (or tasks). Because they are all meant to be running always, the death of one could have dire consequences.

When asked if the whole case for unintended acceleration could be pinned on the task X death, Barr replied, “The task X death in combination with other task deaths.” There are dozens of tasks and 16 million different ways those tasks can die. The experts group was able to demonstrate at least one way for the software to cause unintended acceleration, but there are so many other ways that could have happened.

Barr also said more than half the dozens of tasks’ deaths studied by the experts in their experiments “were not detected by any fail safe.”

Matching processor safety strategies to your system design

현재 마이크로컨트롤러는 제품을 선택할 때 다양한 옵션을 안전이 중요한 개발자에게 제공한다. 이런 다양성은 아마도 안전 무결성을 위한 가능한 프로세서 안전 전략을 평가할 때 가장 분명할 것이다. 이것은 “최고의” 솔루션이 시스템 개발자가 솔루션의 강점과 약점을 판단하기 위한 능력에 의존하게 된다.

안전 프로세싱을 위한 공통 솔루션을 고려하고자 할 때, 제품에서 제공하는 공통적인 아키텍처들이 있다. 가장 사용 가능한 CPU안전 솔루션은 single core, single core with hardware checking, dual-core lockstep, asymmetric dual core, 또는 symmetric dual core로 분류할 수 있다. 이들은 Figure 1에 표현되어 있다.

watchdog기반 솔루션은 비록 프로그램 순서 및 deadlock 모니터링에 대해 매우 유용하기는 하지만 processing에 대한 중요한 진단을 제공하지 못하며 그러므로 여기에서는 고려되지 않는다.

비교를 수행하기 위하여, 우리는 평가 범주를 몇 가지 정의해야 한다: 소프트웨어 복잡성, 실리콘 복잡도, 안전 분석 복잡도, 기능적 소프트웨어 실행을 위한 가용한 성능

소프트웨어 복잡도는 안전 매커니즘들을 통합하여 어플리케이션 소프트웨어로 만드는데 필요한 노력이다. 실리콘 복잡도는 다이위의 하드웨어 비용을 표현한다. 안전 분석 복잡도는 안전 분석을 수행할 때의 어려움을 측정한다. 마지막으로, 가용한 성능 측정은 구현된 안전 제약사항을 제외하고 single CPU대비 가용한 어플리케이션을 나타낸다. Single-core CPU솔루션은 다양한 범위의 제품에서 사용되고 분석의 기반이다.

single-core솔루션은 안전 무결성을 달성하기 위해 safety-critical code의 multiple execution과 같은 소프트웨어 기반 진단과 measure에 의존하며, 결과적으로 소프트웨어 복잡도에 대한 높은 비용을 초래한다. silicon 복잡도는 낮은데, 이는 safety support를 위한 특화된 silicon overhead가 없어서이다. 안전 분석 복잡도는 높은데, 그 이유는 구현된 소프트웨어가 모든 관련 있는 fault를 탐지하는 것을 입증하는 것은 어렵기 때문이다. 이것은 특히 transient fault에 대해서는 사실이다. 그리고 transient fault는 일시적으로 flip-lop이나 register의 상태를 변경시킬 수 있는데 그 뒤의 소프트웨어 수행에 의해 clear되는 것이다. 사용 가능한 성능은 낮은데, 그것은 소프트웨어 기반의 진단 때문이다. 소프트웨어 기반의 진단은 총 CPU 성능의 30%이상을 소비할 수 있다. safety-critical code의 중복 실행은 가용 성능을 더욱 줄일 것이다.

hardware checking이 있는 single core솔루션은 single-core솔루션의 많은 이슈들은 연속적이거나 주기적으로 동작하는 하드웨어 checker에 의해 처리되는 솔루션이다. 그와 같은 솔루션은 감소되는 증가되는 실리콘의 복잡도에 대한 소프트웨어 오버헤드의 trade-off이다. 이 솔루션의 안전 분석은 도전과제이다. design-for-safety에서 공통 표준의 부족은 하드웨어 checker의 전략이 각각의 평가자 에게 특별히 제공되어야 함을 의미한다. 가능한 CPU성능은 높으며, 종종 안전 진단에 소비되는 CPU 오버헤드의 5%미만을 차지한다.

 

…