ma: finish firmware security smartphone analogy

ma/safety_reset.tex

@@ -779,23 +779,27 @@ flaw in Apple's iPhone SoC first-stage ROM bootloader\footnote{
     flaw allows an attacker to circumvent these checks, booting code not authorized by Apple on a USB-connected iPhone,
     compromising Apple's chain of trust from ROM loader to userland right at its root.
 }, that allows a full compromise of any iPhone before the iPhone X. iPhone 8, one of the affected models, is still being
-manufactured and sold by Apple today\footnote{
-    i.e. at the time this paragraph was written, on %FIXME
-}. In another instance, Samsung put a flaw in their secure-world firmware used for protection of sensitive credentials
-in their mobile phone SoCs in % FIXME year % .
-If both of these very large companies have trouble securing parts of their secure embedded software stacks measuring a
-mere few hundred bytes in Apple's case or a few kilobytes in Samsung's, what is a smart electricity meter manufacturer
-to do? For their mass-market phones, these two companies have R\&D budgets that dwarf some countries' national budgets.
-% FIXME hyperbole?
-% FIXME cite
+manufactured and sold by Apple until April 2020.  In another instance in 2016 researchers found multiple flaws in the
+secure-world firmware used by Samsung in their mobile phone SoCs.  The flaws they found were both severe architectural
+flaws such as secret user input being passed through untrusted userspace processes without any protection and shocking
+cryptographic flaws such as CVE-2016-1919\footnote{\url{http://cve.circl.lu/cve/CVE-2016-1919}}\cite{kanonov01}.  And
+Samsung is not the only large multinational corporation having trouble securing their secure world firmware
+implementation. In 2014 \textcite{rosenberg01} found an embarrassing integer overflow flaw in the low-level code
+handling untrusted input in Qualcomm's QSEE firmware. For an overview of ARM TrustZone including a survey of academic
+work and past security vulnerabilities of TrustZone-based firmware see \textcite{pinto01}.
 
-Since thorough formal verification of code is not yet within reach for either large-scale software development or
-code heavy in side-effects such as embedded firmware or industrial control software\cite{pariente01}
-the two most effective measures for embedded security is reducing the amount of code on one hand, and labour-intensively
-checking and double-checking this code on the other hand. A smart electricity manufacturer does not have a say in the
-former since it is bound by the official regulations it has to comply with, and will almost certainly not have sufficient
-resources for the latter.
-% TODO expand?
+If all of these very large companies have trouble securing parts of their secure embedded software stacks measuring a
+mere few hundred bytes in Apple's case or a few kilobytes in Qualcomm's, what is a smart electricity meter manufacturer
+to do? For their mass-market phones, these two companies have R\&D budgets that dwarf some countries' national budgets.
+
+Since thorough formal verification of code is not yet within reach for either large-scale software development or code
+heavy in side-effects such as embedded firmware or industrial control software\cite{pariente01} the two most effective
+measures for embedded security is reducing the amount of code on one hand, and labour-intensively checking and
+double-checking this code on the other hand. A smart electricity manufacturer does not have a say in the former since it
+is bound by the official regulations it has to comply with, and will almost certainly not have sufficient
+resources for the latter. We are left with an impasse: Manufacturers in this field likely do not have the saftey
+resources to keep up with complex standards requirements. At the same time they have no option to reduce the scope of
+their implementation to alleviate the burden on firmware security.
 
 \subsection{Attack avenues in the smart grid}