diff options
author | Shankho Boron Ghosh <shankhoghosh123@gmail.com> | 2020-11-18 19:55:02 +0530 |
---|---|---|
committer | Jan-Simon Moeller <jsmoeller@linuxfoundation.org> | 2020-11-23 13:15:50 +0000 |
commit | 65bd017e8b8f9a06008266de46303c88a9ac51c8 (patch) | |
tree | ce07633c0011cef0c1272b2a948856a2693b8ba7 /docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md | |
parent | 7d32dd28e9b9fa97dd43bed13fb3050eb7ff8b3d (diff) |
Revision of Architecture Guides
v1:
Introduction : Skeleton file of Build Process [WIP].
Security Blueprint : Multiple markdowns appended into single markdown.
v2:
Security Blueprint :
4_Kernel.md - Fixed Internal Link.
Annexes.md - Uniform markdown Title.
Bug-AGL: [SPEC-3633]
Signed-off-by: Shankho Boron Ghosh <shankhoghosh123@gmail.com>
Change-Id: I1ab478348a05464612d67f0e8a4570bda309022d
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25586
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
(cherry picked from commit 9cc56459419f1225f5e9851825ad305424b3d6fb)
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25602
Diffstat (limited to 'docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md')
-rw-r--r-- | docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md | 69 |
1 files changed, 0 insertions, 69 deletions
diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md deleted file mode 100644 index 73a0cab..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/2_Secure_Boot/1.2.2.0_Abstract.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Introduction ---- - -# Part 2 - Secure boot - -## Abstract - -<!-- section-todo --> - -Domain | Improvement ---------------- | ---------------------------------------------------- -Boot-Abstract-1 | More generic and add examples (The chain of trust). - -<!-- end-section-todo --> - -Secure boot refers to preventing malicious software applications and -“unauthorized” operating systems from loading during the system start-up -process. The goal is to protect users from rootkits and other low-level malware -attacks. Modern bootloaders come with features that can be used to enable secure -boot in the system. - -**Boot Hardening**: Steps/requirements to configure the boot sequence, in order -to restrict the device from executing anything other than the approved software -image. - -In this part, we will see a series of settings that will allow us to improve -security during boot phase. For the purposes of reference and explanation, we -are providing guidance on how to configure an embedded device that runs with a -3.10.17 Linux kernel. If the integrity is not checked or if a critical error -occurs, the system must boot on a very stable backup image. - -**Requirements**: These requirements must be met even if an alternative version -of the Linux kernel is chosen. - -**Recommendations**: Detailed best practices that should be applied in order to -secure a device. Although they are not currently listed as hard requirements, -they may be upgraded to requirements status in the future. In addition, specific -operators may change some of these recommendations into requirements based on -their specific needs and objectives. - -<!-- section-todo --> - -Domain | Improvement ---------------- | ------------------------------------------- -Boot-Abstract-1 | Review the definition of the "boot loader". - -<!-- end-section-todo --> - -**Boot loader**: The boot loader consists of the Primary boot loader residing in -**OTP** memory, sboot, U-Boot and Secure loader residing in external flash (NAND -or SPI/NOR flash memory). The CPU on power on or reset executes the primary boot -loader. The **OTP** primary boot loader makes the necessary initial system -configuration and then loads the secondary boot loader sboot from external flash -memory to ram memory. The sboot then loads the U-Boot along with the Secure -loader. U-Boot then verifies the Kernel/system image integrity, then loads the -Kernel/system image before passing control to it. - --------------------------------------------------------------------------------- - -## Acronyms and Abbreviations - -The following table lists the terms utilized within this part of the document. - -Acronyms or Abbreviations | Description -------------------------- | ----------------------------------------------------------------------- -_FUSE_ | **F**ilesystem in **U**ser**S**pac**E** -_OTP_ | **O**ne-**T**ime-**P**rogrammable -_DOCSIS_ | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification |