path: root/Replicant_contributors_meeting_27_28_July_2019_Paris_France/bootloaders/Replicant_and_bootloaders.tex

\documentclass{beamer}
\usepackage[english]{babel}
\usepackage{color}
\usepackage{graphicx}
\usepackage{ifthen}
\usepackage[utf8]{inputenc}
\usepackage{listings}
\usepackage{pdfpages}

\lstdefinestyle{terminal}{
  backgroundcolor=\color{black},
  basicstyle=\scriptsize\color{green},
}

%% Based on:
%% https://tex.stackexchange.com/questions/136900/insert-a-full-page-image
\newcommand{\pictureframe}[1] {
  {
    \begin{frame}
      \noindent
      \resizebox{\textwidth}{\textheight}
                {\includegraphics{#1}}
                \hspace*{-\textwidth}
    \end{frame}
  }
}

\usetheme{Singapore}

\title{Replicant and bootloaders}
\author{Denis 'GNUtoo' Carikli}
\date{\today}

\begin{document}

\maketitle

%% TODO: Using \itemize{} fails to compile
%% TODO: convert \center frames to chapter title

\begin{frame}
  \center{Freedom Privacy and Security:}
  \begin{itemize}
  \item The Replicant website has a page (\url{https://replicant.us/freedom-privacy-security-issues.php}) that has more details on freedom, privacy and security issues commonly found in smartphones.
  \item That page consists mainly of HTML, its source code is available in \url{https://git.replicant.us/replicant/website.git}, and patches are reviewed on the Replicant mailing list.
  \item The README also has some information on a very easy way to deploy the website locally to test changes.
  \end{itemize}  
\end{frame}

\pictureframe{replicant_website/images/freedom-privacy-security-issues/hardware.png}

\begin{frame}
  \frametitle{Bootloader?}
  Here it is Equivalent to:
  \begin{itemize}
  \item The BIOS + GRUB
  \item UEFI: UEFI can load the Linux kernel directly
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Why are bootloader needed on smartphones and tablets?}
  By itself, the hardware is usually capable of loading and running a limited amount of
  code from the internal storage, however most of the hardware doesn't even work at
  boot, including:
  \begin{itemize}
  \item The Display
  \item The RAM
  \item The buttons
  \end{itemize}
\end{frame}

\pictureframe{replicant_website/images/freedom-privacy-security-issues/software.png}

\begin{frame}
  \center{Bootrom$\rightarrow$Bootloader$\rightarrow$ Replicant}
\end{frame}

\begin{frame}
  \center{Samsung devices}
  \raggedright
  Bootrom$\rightarrow$BL1$\rightarrow$s-boot 4.0$\rightarrow$Replicant
  \newline 
  Applies at least to the following devices:
  \begin{itemize}
  \item Galaxy S2         (I9100)
  \item Galaxy SIII       (I9300)
  \item Galaxy SIII 4G    (I9305)
  \item Galaxy Note II    (N7100)
  \item Galaxy Note II 4G (N7105)
  \end{itemize}
\end{frame}

\pictureframe{output/boot_midas.png}

\begin{frame}
  \center{General nonfree bootloader issues:}

  \raggedright
  The fact that the bootloader is mostly invisible to the user doesn't
  magically make its related freedom issues disapear.

  As with all software, it is required for it to be free software
  in order to respect users freedom.
\end{frame}

\begin{frame}
  \center{Examples of issues:}
  \begin{itemize}
  \item As it is able to modify the operating system it's supposed to load and
    execute, and that the code is nonfree, we cannot give any guarantees that
    it doesn't do that. Some BIOS do that with computrace for instance.
  \item It could refuses to boot if you changed the software or hardware.
    \begin{itemize}
      \item Apple's ipad and iphones?
      \item BIOS/UEFI with the WiFi card.
    \end{itemize}
    \item Or loads another extra software you don't whish.
    \item Be able to tinker with boot is also important (ways to boot, security,
      etc)
  \end{itemize}
\end{frame}

\begin{frame}
  \center{Examples of tinkering:}
  \begin{itemize}
  \item Adding filesystems (recent ext4).
  \item Adding dual boot.
  \item Adding new recovery ways (A/B recovery).
  \item Having a single bootloader for multiple devices.
  \item Having a single Android image for multiple devices.
  \item Fixing hardare security issues when they are found (rowhammer).
  \item Getting failed boot logs.
  \item Automatic testing of Replicant (install from the network, boot on it).
  \end{itemize}
\end{frame}

\begin{frame}
  \center{"Midas":}
  \begin{itemize}
  \item Galaxy SIII       (I9300)
  \item Galaxy SIII 4G    (I9305)
  \item Galaxy Note II    (N7100)
  \item Galaxy Note II 4G (N7105)
  \end{itemize}
\end{frame}

\begin{frame}
  \center{Issues found on Midas with BL1$\rightarrow$s-boot 4.0$\rightarrow$Linux:}
  \begin{itemize}
  \item Nonfree BL1 and s-boot
  \item Doesn't take the commandline arguments from the boot.img
  \item Doesn't support the devicetree
  \item Initialize the MMU
  \item Loads and run a second OS (MobiCore) in TrustZone that is nonfree.
  \end{itemize}
\end{frame}

\begin{frame}
  \center{TrustZone}
  \begin{itemize}
  \item Has more hardware privileges than the Linux kernel
  \item Implementing a rootkit in TrustZone is possible\cite{trustzone-backdoor}
  \item "the TEE has [..] monotonic clock that ticks in suspend\cite{gatekeeper}"
  \item SOC specific and lacks SOC documentation.
  \item Discussions on weather free software in TrustZone is desirable
    are planned in this conference.
  \end{itemize}
\end{frame}

\begin{frame}
  \center{Upstream Linux bootloader requirements}
  Documentation/arm/Booting:
  \begin{verse}
    The MMU must be off.

    Instruction cache may be on or off.

    Data cache must be off.
  \end{verse}
\end{frame}

\begin{frame}
  \center{MMU on in practice:}
  \begin{itemize}
  \item Requires a patch to boot:
    "ANDROID: arm: decompressor: Flush tlb before swiching domain 0 to client mode"
  \item I spent between several days and a week bisecting the commit that broke
    booting between 5.1 and 5.2-rc1 (merges, rebases, non-compiling commits, etc).
  \item Not substainable: What happens if in the future new maintainers don't
    have the time or skills to bisect breakages?
  \item Most of the work on Android 9 is still re-usable on future devices that would
    have free software bootloaders.
  \end{itemize}
\end{frame}


\begin{frame}
  \center{Sharp Zaurus (SA11x0)}
\end{frame}

\lstset{language=bash}
\begin{lstlisting}[style=terminal]
  $ ls arch/arm/boot/compressed/
  atags_to_fdt.c debug.S efi-header.S
  head-sa1100.S head-xscale.S
  ll_char_wr.S misc.c piggy.S
  vmlinux.lds.S big-endian.S decompress.c
  head.S head-sharpsl.S libfdt_env.h
  Makefile misc.h string.c
\end{lstlisting}

\begin{frame}
  \center{head-sa1100.S}
\end{frame}

%% Only Motorola68k and x86masm are available according to
%% http://ctan.mirrors.hoobly.com/macros/latex/contrib/listings/listings.pdf
\lstset{language={[x86masm]Assembler}}
\begin{lstlisting}[style=terminal]
   @ Data cache might be active.
   @ Be sure to flush kernel binary out of the cache,
   @ whatever state it is, before it is turned off.
   @ This is done by fetching through currently executed
   @ memory to be sure we hit the same cache.
   bic     r2, pc, #0x1f
   add     r3, r2, #0x4000         @ 16 kb is quite enough...
1: ldr     r0, [r2], #32
   teq     r2, r3
   bne     1b
   mcr     p15, 0, r0, c7, c10, 4  @ drain WB
   mcr     p15, 0, r0, c7, c7, 0   @ flush I & D caches

   @ disabling MMU and caches
   mrc     p15, 0, r0, c1, c0, 0   @ read control reg
   bic     r0, r0, #0x0d           @ clear WB, DC, MMU
   bic     r0, r0, #0x1000         @ clear Icache
   mcr     p15, 0, r0, c1, c0, 0
\end{lstlisting}

\begin{frame}
  \center{In practice}
  Russel King (ARM maintainer):
  \begin{verse}
    SA11x0 pre-dates the booting document, which came about because of the
    desire to make the kernel less dependent on the host CPU type.  So
    "sa11x0 does it so we can do it" is really not an argument I ever want
    to see to justify this kind of stuff.

    The booting requirements have been known since at least 2002, some
    SEVENTEEN years ago, and the problem was identified as buggy back in
    2012.  As far as I can see, nothing has changed.
  \end{verse}
\end{frame}

\begin{frame}
  \begin{verse}
    Entering the kernel with the MMU on and optionally caches on is an
    inherently unsafe thing to do.  The kernel would have been placed into
    RAM via the data cache, and then we're trying to execute code - unless
    the caches have been properly cleaned and invalidated, there is no
    guarantee that we'd even reach any instructions to do our own cache
    cleaning and invalidation.  So, caches on is utter madness.
  \end{verse}
\end{frame}

\begin{frame}
  \begin{verse}
    MMU on presents a problem: the kernel moves itself around during
    decompression - if it happens to move itself on top of the in-use
    page tables, then that would be really bad.  There's another issue as
    well - if the page tables are already setup, and we create a different
    mapping for the virtual address range, the \_only\_ way to safely switch
    to that mapping is via a break-make arrangement, which means we need
    code to disable the MMU, flush it.  It is not as simple as "a few extra
    instructions to flush TLBs" although that may work in the majority of
    cases.  Architecturally, it is wrong.
  \end{verse}
\end{frame}

\begin{frame}
  \begin{verse}
    Things can get even worse - what if the page tables are located where
    the kernel writes its own page tables - modifying the live tables and
    changing the type of the entries.  Architecturally unpredictable
    behaviour may result.

    What is written in Documentation/arm/Booting is not for our fun, it is
    there to spell out what the kernel requires to be able to boot reliably
    on hardware.  If it isn't followed, then booting a kernel will be
    unreliable.
  \end{verse}
\end{frame}

\begin{frame}
  \center{downstream u-boot port}
  \begin{itemize}
  \item No MMU enabled at boot
  \item Gets the commandline arguments from the boot.img
  \item Support the devicetree. Even supports modifying it on the fly.
  \item No display support, but leds are supported
  \end{itemize}
\end{frame}

\begin{frame}
  \center{Issues found on Midas with BL1$\rightarrow$u-boot$\rightarrow$Linux:}
  \begin{itemize}
  \item Nonfree and non-redistributable BL1
  \end{itemize}
\end{frame}

\begin{frame}
  Licenses:
  \begin{itemize}
  \item Attribution-ShareAlike 3.0 Unported for the two images that comes from
    the Freedom Privacy and Security page.
  \item \url{https://creativecommons.org/licenses/by-sa/4.0/} for
    the rest.
  \end{itemize}
\end{frame}

\begin{thebibliography}{99}

\bibitem{freedom-privacy-security-issues}
  \url{https://replicant.us/freedom-privacy-security-issues.php}

\bibitem{gatekeeper}
  \url{https://source.android.com/security/authentication/gatekeeper}

\bibitem{trustzone-backdoor}
  \url{https://hackinparis.com/data/slides/2013/Slidesthomasroth.pdf}
  
\end{thebibliography}

\end{document}