---
-edit_link: ''
title: Introduction
-origin_url: >-
- https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-4/0_Abstract.md
---
-<!-- 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 -->
-
# Part 4 - Kernel
## Abstract
The choice of kernel version for the AGL system is essential to its security.
Depending on the type of board and eventual production system, different kernel
-versions are used. For example, one of the systems under study uses the
-Linux kernel version 3.10, while another uses the Linux kernel version 4.4.
-For the Linux kernel version 3.10.31, there are 25 known vulnerabilities.
-These vulnerabilities would allow an attacker to gain privileges,
-bypass access restrictions, allow memory to be corrupted, or cause denial of service.
-In contrast, the Linux kernel version of 4.4 has many fewer known vulnerabilities.
-For this reason, we would in general recommend the later kernel version as a basis
-for the platform.
+versions are used. For example, one of the systems under study uses the Linux
+kernel version 3.10, while another uses the Linux kernel version 4.4. For the
+Linux kernel version 3.10.31, there are 25 known vulnerabilities. These
+vulnerabilities would allow an attacker to gain privileges, bypass access
+restrictions, allow memory to be corrupted, or cause denial of service. In
+contrast, the Linux kernel version of 4.4 has many fewer known vulnerabilities.
+For this reason, we would in general recommend the later kernel version as a
+basis for the platform.
-Note that, although there are fewer known vulnerabilities in the most recent kernel
-versions there may be many unknown vulnerabilities underlying.
-A rule of thumb is to update the kernel as much as possible to avoid the problems
-you do know, but you should not be complacent in the trust that you place in it.
-A defense-in-depth approach would then apply.
+Note that, although there are fewer known vulnerabilities in the most recent
+kernel versions there may be many unknown vulnerabilities underlying. A rule of
+thumb is to update the kernel as much as possible to avoid the problems you do
+know, but you should not be complacent in the trust that you place in it. A
+defense-in-depth approach would then apply.
If there are constraints and dependencies in upgrading to a newer kernel version
(e.g. device drivers, board support providers) and you are forced to an older
-Linux kernel version, there need to be additional provisions made to reduce
-the risk of kernel exploits, which can include memory monitoring, watch-dog services,
-and system call hooking. In this case, further defense-in-depth techniques
-may be required to mitigate the risk of attacks to known vulnerabilities,
-which can also include runtime integrity verification of components
-that are vulnerable to tampering.
+Linux kernel version, there need to be additional provisions made to reduce the
+risk of kernel exploits, which can include memory monitoring, watch-dog
+services, and system call hooking. In this case, further defense-in-depth
+techniques may be required to mitigate the risk of attacks to known
+vulnerabilities, which can also include runtime integrity verification of
+components that are vulnerable to tampering.
## Kernel Build Configuration
The kernel build configuration is extremely important for determining the level
-of access to services and to reduce the breadth of the attack surface.
-Linux contains a great and flexible number of capabilities and this is only controlled
+of access to services and to reduce the breadth of the attack surface. Linux
+contains a great and flexible number of capabilities and this is only controlled
through the build configuration. For example, the `CONFIG_MODULES` parameter
-allows kernel modules to be loaded at runtime extending the capabilities of the kernel.
-This capability needs to be either inhibited or controlled at runtime through
-other configuration parameters. For example, `CONFIG_MODULE_SIG_FORCE=y` ensures
-that only signed modules are loaded. There is a very large number of kernel
-configuration parameters, and these are discussed in detail in this section.
+allows kernel modules to be loaded at runtime extending the capabilities of the
+kernel. This capability needs to be either inhibited or controlled at runtime
+through other configuration parameters. For example, `CONFIG_MODULE_SIG_FORCE=y`
+ensures that only signed modules are loaded. There is a very large number of
+kernel configuration parameters, and these are discussed in detail in this
+section.
Code Review / AGL / documentation.git / blobdiff