docs/1_Architecture_Guides/1.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md

   1 ---
   2 edit_link: ''
   3 title: Introduction
   4 origin_url: >-
   5   https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-2/0_Abstract.md
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml -->
   9
  10 # Part 2 - Secure boot
  11
  12 ## Abstract
  13
  14 <!-- section-todo -->
  15
  16 Domain          | Improvement
  17 --------------- | ----------------------------------------------------
  18 Boot-Abstract-1 | More generic and add examples (The chain of trust).
  19
  20 <!-- end-section-todo -->
  21
  22 Secure boot refers to preventing malicious software applications and
  23 “unauthorized” operating systems from loading during the system start-up process.
  24 The goal is to protect users from rootkits and other low-level malware attacks.
  25 Modern bootloaders come with features that can be used to enable secure boot in the system.
  26
  27 **Boot Hardening**: Steps/requirements to configure the boot sequence, in order
  28 to restrict the device from executing anything other than the approved software
  29 image.
  30
  31 In this part, we will see a series of settings that will allow us to improve
  32 security during boot phase. For the purposes of reference and explanation, we
  33 are providing guidance on how to configure an embedded device that runs with a
  34 3.10.17 Linux kernel. If the integrity is not checked or if a critical error
  35 occurs, the system must boot on a very stable backup image.
  36
  37 **Requirements**: These requirements must be met even if an alternative version
  38 of the Linux kernel is chosen.
  39
  40 **Recommendations**: Detailed best practices that should be applied in order to
  41 secure a device. Although they are not currently listed as hard requirements,
  42 they may be upgraded to requirements status in the future. In addition, specific
  43 operators may change some of these recommendations into requirements based on
  44 their specific needs and objectives.
  45
  46 <!-- section-todo -->
  47
  48 Domain          | Improvement
  49 --------------- | -------------------------------------------
  50 Boot-Abstract-1 | Review the definition of the "boot loader".
  51
  52 <!-- end-section-todo -->
  53
  54 **Boot loader**: The boot loader consists of the Primary boot loader residing
  55 in **OTP** memory, sboot, U-Boot and Secure loader residing in external flash
  56 (NAND or SPI/NOR flash memory). The CPU on power on or reset executes the
  57 primary boot loader. The **OTP** primary boot loader makes the necessary initial
  58 system configuration and then loads the secondary boot loader sboot from
  59 external flash memory to ram memory. The sboot then loads the U-Boot along with
  60 the Secure loader. U-Boot then verifies the Kernel/system image integrity, then
  61 loads the Kernel/system image before passing control to it.
  62
  63 --------------------------------------------------------------------------------
  64
  65 ## Acronyms and Abbreviations
  66
  67 The following table lists the terms utilized within this part of the document.
  68
  69 Acronyms or Abbreviations | Description
  70 ------------------------- | -----------------------------------------------------------------------
  71 _FUSE_                    | **F**ilesystem in **U**ser**S**pac**E**
  72 _OTP_                     | **O**ne-**T**ime-**P**rogrammable
  73 _DOCSIS_                  | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification