\documentclass[aspectratio=169,obeyspaces,spaces,hyphens,dvipsnames]{beamer}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}% http://ctan.org/pkg/lm
\usepackage{minted}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{pgfplots}
\usepackage{tikz}
\usepackage[normalem]{ulem}

\mode<presentation>
\usetheme{Bootlin}

\def\signed #1{{\leavevmode\unskip\nobreak\hfil\penalty50\hskip2em
  \hbox{}\nobreak\hfil(#1)
  \parfillskip=0pt \finalhyphendemerits=0 \endgraf}}

\newsavebox\mybox
\newenvironment{aquote}[1]
  {\savebox\mybox{#1}\begin{quotation}}
  {\signed{\usebox\mybox}\end{quotation}}

\title{Buildroot: what's new?}
\authors{Thomas Petazzoni}
\email{thomas.petazzoni@bootlin.com}
\slidesurl{https://bootlin.com/pub/conferences/2022/elc/petazzoni-buildroot-whats-new/}
\institute{Bootlin}
\conference{Embedded Linux Conference}

\begin{document}

\addtocontents{toc}{\protect\setcounter{tocdepth}{-1}}
\section{Buildroot: what's new?}
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}}

\begin{frame}{Thomas Petazzoni}
  \begin{itemize}
  \item Co-owner and CEO at {\bf Bootlin}
    \begin{itemize}
    \item Embedded Linux experts
    \item Engineering services: Linux BSP development, kernel porting
      and drivers, Yocto/Buildroot integration, real-time, boot-time,
      security, multimedia
    \item Training services: Embedded Linux, Linux kernel drivers,
      Yocto, Buildroot, graphics stack, boot-time, real-time
    \end{itemize}
  \item Co-maintainer of {\bf Buildroot}, contributor since 2008,
    5200+ patches contributed.
  \item Former contributor to the Linux kernel, 900+ patches
    contributed.
  \item Program committee member and regular speaker at the Embedded
    Linux Conference
  \item Living in {\bf Toulouse}, south west of France
  \item \code{thomas@bootlin.com}
  \end{itemize}
  {\small \url{https://bootlin.com/company/staff/thomas-petazzoni/}}
\end{frame}

\begin{frame}{Agenda}
  \begin{columns}
    \column{0.6\textwidth}
    \begin{itemize}
    \item What is Buildroot?
    \item Comparison with Yocto
    \item What's new between 2020.05 and 2022.05
      \begin{itemize}
      \item Some numbers
      \item LTS and security maintenance
      \item Security vulnerability tracking
      \item Security default settings
      \item SELinux integration improvements
      \item Vendoring support for Go/Rust
      \item Python changes
      \item Significant new packages
      \item Testing improvements
      \item Toolchain improvements
      \item Architecture support
      \end{itemize}
    \end{itemize}
    \column{0.4\textwidth}
    \includegraphics[width=\textwidth]{logo.png}
  \end{columns}
\end{frame}

\begin{frame}{What is Buildroot?}
  \begin{itemize}
  \item Is an {\bf Embedded Linux build system}
    \begin{itemize}
    \item Tool that {\bf automates} the cross-compilation of a
      complete embedded Linux system from source
    \item Builds: toolchain/compiler, bootloader and Linux kernel,
      complete root filesystem with user-space applications and
      libraries
    \end{itemize}
    \pause
  \item Similar aim as Yocto/OpenEmbedded, OpenWrt, PTXdist
    \pause
  \item Relies on {\bf well-known} technologies
    \begin{itemize}
    \item {\em GNU Make} for the build, {\em Kconfig} for configuration
    \end{itemize}
    \pause
  \item Simple to use and learn
    \begin{itemize}
    \item \code{make menuconfig} $\rightarrow$ \code{make} $\rightarrow$ profit
    \end{itemize}
    \pause
  \item {\bf 2800+} built-in packages for most popular open-source software
    stacks
    \pause
  \item Very {\bf active community} of developers/users, used by many
    companies: silicon vendors, embedded system manufacturers,
    hobbyists
    \pause
  \item Oldest still maintained build system: started in 2001
  \end{itemize}
\end{frame}

\begin{frame}{Buildroot vs. Yocto}
  \begin{center}
    \huge
    The one question that everybody asks!
  \end{center}
\end{frame}

\begin{frame}{Buildroot vs. Yocto}
  \begin{itemize}
  \item What it builds
    \only<1> {
      \begin{itemize}
      \item {\bf Yocto}: builds a distribution, with binary packages and a
        package management system
      \item {\bf Buildroot}: builds a fixed functionality root
        filesystem, no binary packages
      \item Note: binary packages are not necessarily a good thing for
        embedded!
      \end{itemize}
    }
    \pause
  \item Configuration
    \only<2> {
      \begin{itemize}
      \item {\bf Yocto}: flexible, powerful but complex configuration
        description
      \item {\bf Buildroot}: very simple configuration system, but
        sometimes limited
      \end{itemize}
    }
    \pause
  \item Build strategy
    \only<3> {
      \begin{itemize}
      \item {\bf Yocto}: complex and heavy logic, but with efficient
        caching of artifacts and ``rebuild only what's needed'' features
      \item {\bf Buildroot}: simple but somewhat dumb logic, no caching
        of built artifacts, full rebuilds needed for some config changes
      \end{itemize}
    }
    \pause
  \item Ecosystem
    \only<4> {
      \begin{itemize}
      \item {\bf Yocto}: (relatively) small common base in OpenEmbedded,
        lots of features supported in third party layers $\rightarrow$
        lots of things, but varying quality
      \item {\bf Buildroot}: everything in one tree $\rightarrow$
        perhaps less, but more consistent quality
      \end{itemize}
    }
    \pause
  \item Complexity/learning curve
    \only<5> {
      \begin{itemize}
      \item {\bf Yocto}: admittedly steep learning curve, {\em bitbake}
        remains a magic black box for most people
      \item {\bf Buildroot}: much smoother and shorter learning curve,
        tool is simple to approach, and reasonably simple to
        understand
      \end{itemize}
    }
    \pause
  \item And also a matter of personal taste/preference, as often when
    choosing tools
  \end{itemize}
\end{frame}

\begin{frame}{Community vitality: some numbers}
  \begin{center}
    \includegraphics[height=0.8\textheight]{commits-per-release.pdf}
  \end{center}
\end{frame}

\begin{frame}{Community vitality: some numbers}
  \begin{center}
    \includegraphics[height=0.8\textheight]{contributors-per-release.pdf}
  \end{center}
\end{frame}

\begin{frame}{Community vitality: some numbers}
  \begin{center}
    \includegraphics[height=0.8\textheight]{emails-per-month.pdf}
  \end{center}
\end{frame}

\begin{frame}{Community vitality: some numbers}
  \begin{center}
    \includegraphics[height=0.8\textheight]{packages-per-release.pdf}
  \end{center}
\end{frame}

\begin{frame}{LTS and security maintenance}
  \begin{center}
    \includegraphics[width=\textwidth]{maintenance.pdf}
  \end{center}
  \begin{itemize}
  \item Maintenance: security fixes, bug fixes
  \item {\em YYYY.02} releases maintained for slightly over 12 months
  \item {\em YYYY.\{05,08,11\}} releases maintained for slightly over 3 months
  \end{itemize}
\end{frame}

\begin{frame}{LTS and security maintenance}
  \begin{itemize}
  \item Process started with 2019.02.x
  \item Process now works well: review of all commits in {\em master}
    and decision if applicable to the current LTS branch
  \item {\bf 2020.02.x} LTS branch
    \begin{itemize}
    \item 1219 commits
    \item 228 directly security related (probably more in reality)
    \item 12 point releases: 2020.02.1 $\rightarrow$ 2020.02.12
    \item End of life
    \end{itemize}
  \item {\bf 2021.02.x} LTS branch
    \begin{itemize}
    \item 751 commits
    \item 110 directly security related (same, probably more in
      reality)
    \item 12 point releases: 2021.02.1 $\rightarrow$ 2021.02.12
    \item End of life on April 6, 2022
    \end{itemize}
  \item {\bf 2022.02.x} LTS branch, current
    \begin{itemize}
    \item Started in February 2022
    \item End of life planned on April 2023
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Security vulnerability tracking}
  \begin{itemize}
  \item \code{make pkg-stats} matches your package set with the {\em
      NIST} security vulnerability database
    \begin{itemize}
    \item CVE database: {\em Common Vulnerability and Exposure}
    \item CPE database: {\em Common Platform Enumeration}
    \item HTML and JSON output
    \end{itemize}
    \pause
  \item Checks if packages...
    \begin{itemize}
    \item are affected by known CVEs
    \item have a CPE identifier known in the CPE database
    \end{itemize}
    \pause
  \item Helped with metadata from the package \code{.mk} file
    \begin{itemize}
    \item \code{<pkg>_IGNORE_CVES} to ignore matching CVEs if they are
      fixed locally by a security fix backport
    \item \code{<pkg>_CPE_ID_...} to override the default CPE identifier for the package\\
      \code{cpe:2.3:a:<pkg>_project:<pkg>:<pkg-version>:*:*:*:*:*:*}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{{\tt pkg-stats} output details}

  \includegraphics[width=\textwidth]{attr.png}

  \only<2>{
    \begin{itemize}
    \item some \code{<pkg>_CPE_ID_*} variables defined $\rightarrow$ CPE information verified
    \item CPE identifier exists in the CPE dictionary
    \item no known CVEs
    \end{itemize}
    \vspace{0.5cm}
  }

  \includegraphics[width=\textwidth]{acl.png}

  \only<3>{
    \begin{itemize}
    \item no \code{<pkg>_CPE_ID_*} variable $\rightarrow$ don't know
      if the default CPE identifier is correct
    \item based on this default CPE identifier $\rightarrow$ no known CVE
    \end{itemize}
    \vspace{0.5cm}
  }

  \includegraphics[width=\textwidth]{atop.png}

  \only<4>{
    \begin{itemize}
    \item some \code{<pkg>_CPE_ID_*} variables defined $\rightarrow$ CPE information verified
    \item no entry in CPE dictionary $\rightarrow$ version 2.6.0 not known by NVD
    \item CVE-2011-3618 applicable: NVD database indicates it applies to all versions.
    \end{itemize}
    \vspace{0.5cm}
  }

  \includegraphics[width=\textwidth]{busybox.png}

  \only<5>{
    \begin{itemize}
    \item some \code{<pkg>_CPE_ID_*} variables defined $\rightarrow$ CPE information verified
    \item no entry in CPE dictionary $\rightarrow$ version 1.33.0 not known by NVD
    \item no known CVEs
    \end{itemize}
    \vspace{0.5cm}
  }

\end{frame}

\begin{frame}{Security default settings}
  \begin{itemize}
  \item Default configuration settings changed to enable more
    security-hardening features
  \item {\em PIC/PIE} (position independent) $\rightarrow$ needed for
    some other security features
  \item {\em SSP} (Stack Smashing Protection) enabled by default:
    \code{-fstack-protector}
  \item {\em RELRO} (RELocation Read Only) enabled by default, making
    additional ELF sections read-only
  \item {\em FORTITY\_SOURCE} enabled by default, adds additional
    checks in the C library for buffer overflows
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{SELinux integration improvements}
  \begin{itemize}
  \item Set the SELinux file security context at build time and not
    run-time $\rightarrow$ allows read-only root filesystems with
    SELinux enabled
    \pause
  \item Reduce the size of the default policy from 2.4 MB to 250 KB,
    keeping only {\em base} SELinux policy modules
    \pause
  \item Allow the {\em refpolicy} package to
    \begin{itemize}
    \item Enable additional modules
    \item Provide additional custom modules
    \end{itemize}
    \pause
  \item Allow packages to enable additional SELinux modules
    \begin{itemize}
    \item From the standard refpolicy using \code{<pkg>_SELINUX_MODULES}
    \item Custom per-package ones in \code{package/<pkg>/selinux/}
    \end{itemize}
    \pause
  \item Many packages annotated with \code{<pkg>_SELINUX_MODULES}
    \begin{block}{}
\begin{minted}{make}
SYSTEMD_SELINUX_MODULES = systemd udev xdg
\end{minted}
    \end{block}
    \pause
  \item Contributions to upstream SELinux refpolicy to make it work
    with Buildroot
  \end{itemize}
\end{frame}

\begin{frame}{Vendoring support for Go/Rust (1)}
  \begin{itemize}
  \item Go and Rust have {\bf language-specific package managers}
  \item These package managers automatically download the dependencies
    \begin{itemize}
    \item Described by \code{go.mod} in Go
    \item Described by \code{Cargo.toml} in Rust
    \end{itemize}
    \pause
  \item They break fundamental features of build systems
    \begin{itemize}
    \item Integration into a download infrastructure: caching, local
      backup site
    \item Legal/license information collection: source code, license
      files
    \item Reproducibility
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Vendoring support for Go/Rust (2)}
  \begin{itemize}
  \item Buildroot download infrastructure has been extended with {\em
      post-download helpers}
    \pause
  \item After downloading the main package source code, ability to run
    custom logic to finalize the download
    \begin{itemize}
    \item \code{support/download/go-post-process}
    \item \code{support/download/cargo-post-process}
    \end{itemize}
    \pause
  \item Runs the Go or Rust specific tools to retrieve the
    dependencies
  \item Makes sure that
    \begin{itemize}
    \item The tarball contains the full source code, dependencies
      included
    \item The hash used by Buildroot to validate the tarball covers
      also the dependencies
    \item All source code and license files are available in the tarball
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Vendoring support for Go}
  \begin{itemize}
  \item Existing \code{golang-package} infrastructure
  \item Extended to use the {\em post-download} helper
  \end{itemize}
  \begin{block}{package/tinifier/tinifier.mk}
\begin{minted}{make}
TINIFIER_VERSION = 3.4.0
TINIFIER_SITE = $(call github,tarampampam,tinifier,v$(TINIFIER_VERSION))
TINIFIER_LICENSE = MIT
TINIFIER_LICENSE_FILES = LICENSE
TINIFIER_GOMOD = ./cmd/tinifier

$(eval $(golang-package))
\end{minted}
  \end{block}
\end{frame}

\begin{frame}[fragile]{Vendoring support for Rust}

  \begin{itemize}
  \item Newly added \code{cargo-package} infrastructure
  \item Uses a {\em post-download} helper
  \end{itemize}

  \begin{block}{package/bat/bat.mk}
\begin{minted}{make}
BAT_VERSION = 0.19.0
BAT_SITE = $(call github,sharkdp,bat,v$(BAT_VERSION))
BAT_LICENSE = Apache-2.0 or MIT
BAT_LICENSE_FILES = LICENSE-APACHE LICENSE-MIT

$(eval $(cargo-package))
\end{minted}
  \end{block}

\end{frame}

\begin{frame}{Python changes: Python 2.x removed}
  \begin{itemize}
  \item Python 2.x EOL upstream in January 2020
  \item Kept for some time in Buildroot, marked deprecated, to help
    migration
  \item Finally removed in {\em 2022.02}
  \item Allowed to remove a lot of complexity that was needed to
    support Python 2.x and Python 3.x in parallel
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Python changes: PEP517 build system support}

  \begin{itemize}
  \item Standard replacement for \code{setup.py}
  \item Uses a \code{pyproject.toml} file
  \item For now Buildroot supports \code{flit} based PEP517 build
    systems
  \item Needs \code{<pkg>_SETUP_TYPE = flit}
  \end{itemize}

  \begin{block}{package/python-cssselect2/python-cssselect2.mk}
    {\small
\begin{minted}{python}
PYTHON_CSSSELECT2_VERSION = 0.6.0
PYTHON_CSSSELECT2_SOURCE = cssselect2-$(PYTHON_CSSSELECT2_VERSION).tar.gz
PYTHON_CSSSELECT2_SITE = https://files.pythonhosted.org/packages/68/62/[...]
PYTHON_CSSSELECT2_SETUP_TYPE = flit
PYTHON_CSSSELECT2_LICENSE = BSD-3-Clause
PYTHON_CSSSELECT2_LICENSE_FILES = LICENSE

$(eval $(python-package))
\end{minted}
    }
  \end{block}

\end{frame}

\begin{frame}{Significant new packages}
  \begin{itemize}
  \item $\approx$~290 new packages added between 2020.05 and 2022.05
  \item GNU Octave
  \item Tracing: bpftool, uftrace, ply, babeltrace2
  \item ARM Mali GPU drivers
  \item Zabbix
  \item liburing
  \item WirePlumber
  \item OpenCV 4
  \item libvirt
  \item OpenZFS
  \item PostGIS
  \item Additional Qt5 modules: Qt5Knx, Qt5Coap, Qt5Mqtt, Qt5Lottie
  \item 63 additional Python packages
  \end{itemize}
\end{frame}

\begin{frame}{CI testing improvements}
  \begin{itemize}
  \item Already existing
    \begin{itemize}
    \item {\bf Build-time} testing of semi-random configurations,
      \code{autobuild.buildroot.org}
    \item Suite of {\bf run-time tests}, \code{support/testing},
      tested in Gitlab CI
    \item Defconfigs build tested, and if possible boot tested, in
      Gitlab CI
    \end{itemize}
    \pause
  \item Improvement
    \begin{itemize}
    \item Switch to {\bf fully random configurations} for build-time
      testing
    \item Architecture/toolchain config used to be taken from a set of
      pre-defined config
    \item Only package set was randomized
    \item Now the full configuration is randomized
    \item Allowed to {\bf detect many corner cases}, and fix them
    \item Still on-going
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Architecture support}
  \begin{itemize}
  \item Buildroot already {\bf supports more CPU architectures} than any
    other build system
    \begin{itemize}
    \item Synopsys ARC (LE/BE), AArch64 (LE/BE), ARM (LE/BE, including
      no-MMU Cortex-M), C-SKY, x86 (32-bit/64-bit), m68k, Microblaze
      (LE/BE), MIPS (32-bit/64-bit, LE/BE), NIOSII, OpenRISC, PowerPC,
      Power64 (LE/BE), RISC-V (32-bit/64-bit), SuperH, SPARC
      (32-bit/64-bit), Cadence Xtensa
    \end{itemize}
    \pause
  \item Addition of support for the {\bf S390x} CPU architecture
    \begin{itemize}
    \item Contributed and maintained directly by IBM
    \end{itemize}
    \pause
  \item Addition of support for the {\bf RISC-V 64-bit no-MMU}
    architecture
    \begin{itemize}
    \item Contributed mainly by Western Digital
    \end{itemize}
    \pause
  \item Removal of NDS32 happening soon
    \begin{itemize}
    \item Follows removal of NDS32 from upstream Linux
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Toolchain support}
  \begin{columns}
    \column{0.6\textwidth}
    \begin{itemize}
    \item Two choices in Buildroot for the toolchain/compiler:
      \begin{itemize}
      \item {\bf Internal toolchain}: Buildroot builds the full
        toolchain from source, i.e binutils, C library, kernel headers,
        gcc, gdb
      \item {\bf External toolchain}: Buildroot uses an existing
        pre-compiled cross-compilation toolchain
      \end{itemize}
      \pause
    \item Improvements
      \begin{itemize}
      \item {\bf Internal toolchain}: mainly updates to follow the
        latest upstream release of all components
      \item {\bf External toolchain}: main change is the direct support
        for 198 pre-built toolchains from \url{toolchains.bootlin.com}
      \end{itemize}
    \end{itemize}
    \column{0.4\textwidth}
    \begin{center}
      \includegraphics[height=0.5\textheight]{toolchains-bootlin-com.png}\\
      \vspace{0.2cm}
      \includegraphics[height=0.3\textheight]{toolchains-bootlin-buildroot.png}
    \end{center}
  \end{columns}
\end{frame}

\begin{frame}{Buildroot training course}
  \begin{columns}
    \column{0.5\textwidth}
    \begin{itemize}
    \item Bootlin has a full training course on Buildroot
    \item Taught by your speaker
    \item Training materials are freely available
      \begin{itemize}
      \item Like for all Bootlin training courses
      \end{itemize}
    \item Next public on-line course\\ September 5-9, 2022
    \end{itemize}
    \column{0.5\textwidth}
    \includegraphics[width=\textwidth]{training.png}
  \end{columns}
  \vspace{0.5cm}
  \begin{center}
    \url{https://bootlin.com/training/buildroot/}
  \end{center}

\end{frame}

\questionslide

\end{document}
