FreeRTOS Kernel Threat Model

Date written: 2023-08-11
Last Modified: 2023-12-01

This is the threat model for FreeRTOS ports that support hardware memory protection, such as the ARM Cortex-M Memory Protection Unit (MPU). It is applicable to applications using the MPU wrapper C file (mpu_wrappers_v2.c) introduced in FreeRTOS Kernel V10.6.2. Application writers that use FreeRTOS in their devices assume responsibility for securing both the device and the software running on it.

Assets

1. FreeRTOS Kernel C Code.
2. Application Code - defined as all the code other than the FreeRTOS Kernel C code.
3. FreeRTOS Kernel internal data.
4. Application Data - defined as all the data other than the FreeRTOS Kernel internal data.
5. Saved Task Context - the context of a task that is not in the Running state.
6. Task Stack – each task has its own stack.
7. Task System Call Stack - each task has a separate system call stack to execute system calls.
8. System Stack - the stack used by Interrupt Service Routines (ISRs).
9. Special CPU Registers such as –
   • MPU control registers.
   • CPU operational registers (e.g. execution mode).
10. General purpose CPU registers.

Actors

1. Unprivileged tasks – FreeRTOS tasks with limited privileges.
2. Privileged tasks – FreeRTOS tasks with full privileges.
3. System Calls - FreeRTOS system calls make the kernel services available to unprivileged tasks by wrapping kernel Application Programming Interface (API) functions with code that temporarily grants any unprivileged task which calls a kernel API the privilege necessary to execute kernel code.
4. Interrupt Service Routines (ISRs).
5. Peripherals with access to memory, for example Direct Memory Access DMA controllers and communication ports.

Authorizations

The following table describes each actor's authorizations for each asset, unless explicitly granted additional authorization at run-time (for example, an unprivileged task that is granted read only access to application data):

		Actor
		Unprivileged Task	Privileged Task	System Calls	ISR Code	Peripherals
Asset	Kernel Code	-	RX	RX	RX	RW
Application Code	RX	RX	RX	RX	RW
Kernel Data	-	RW	RW	RW	RW
Application Data	-	RW	RW	RW	RW
Task Context	-	RW	RW	RW	RW
Special Registers	-	RW	RW	RW	RW*
General Purpose Registers	RW	RW	RW	RW	-
Task's Own Stack	RW	RW	RW	NA	NA
Any Other Task's Stack	-	RW	RW	RW	RW
Task System Call Stack	-	RW	RW	RW	RW
System Stack	-	RW	RW	RW	RW

R - Read, W - Write, X - Execute, NA - Not Applicable. A dash without any letters means "no access".

* Peripherals have access to their own special registers.

Summarizing the table above:

1. Unprivileged tasks have:
   1. Read and Execute access to application code.
   2. Read and Write access to their own stack.
   3. Read and Write access to general purpose registers.
2. Privileged tasks have:
   1. Read and Execute access to all the code.
   2. Read and Write access to all the data.
   3. Read and Write access to all the registers.
3. System calls have:
   1. Read and Execute access to all the code.
   2. Read and Write access to all the data.
   3. Read and Write access to all the registers.
4. Interrupt Service Routines have:
   1. Read and Execute access to all the code.
   2. Read and Write access to all the data.
   3. Read and Write access to all the registers.
5. Peripherals have:
   1. Read and Write access to all the memory and their own registers.

Entry Points

System Calls – FreeRTOS system calls make the kernel services available to unprivileged tasks by wrapping kernel Application Programming Interface (API) functions with code that temporarily grants any unprivileged task which calls a kernel API the privilege necessary to execute kernel code. Within the controls of the FreeRTOS privilege management, we can also refer to CWE-269 as a reference to access control mappings to related threats.

Trust Boundaries

The only time the trust boundary is crossed is when an unprivileged task makes a system call to execute a kernel API function.

Invariant

After the FreeRTOS scheduler has started, an actor cannot access any asset it is not authorized to access.

Threat Analysis and Modeling

Threat categorization is based on the STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privileges) model.

Threats mitigated by the kernel

In all the threats below, the attacker is assumed to be running unprivileged.

1. Access Privilege Violation

Threat Category - Tampering, Information disclosure, Elevation of privileges.

Description - An Access Privilege violation occurs if an actor successfully accesses (to read, write or execute) an asset it is not authorized to access.

Mitigation- The FreeRTOS kernel programs the MPU when the scheduler starts, and on each task context switch, so that the MPU enforces the authorizations described by the table in the Authorizations section.

2. Stack Overflow

Threat Category - Tampering.

Description - A stack overflow occurs when the stack pointer grows beyond the stack memory, leading to memory corruption.

Mitigation– The FreeRTOS kernel uses an MPU region to grant unprivileged tasks access to their own stack. The size and start address of the MPU region match the size and start address of the stack, so writing outside the stack results in a memory protection fault.

The application writer must ensure the stack size and alignment are compatible with any limitations imposed by the MPU hardware. The application writer must also ensure memory adjacent to the stack is not accessible to the same task.

3. Stack Manipulation Attacks

Threat Category - Tampering, Elevation of privileges.

Description - An unprivileged task has write-access to its own stack. An attacker can use this ability to exploit a kernel function that fails to initialize stack memory before using it.

Mitigation– Execute system calls on a separate stack accessible to privileged code only.

4. Exploiting system calls that take pointers as parameters to achieve arbitrary reads or writes

Threat Category - Tampering, Information disclosure.

Description - An attacker can pass incorrect parameters to a system call to trick the kernel code to read from or write to any memory.

Mitigation– System calls implement strict parameter checking, including access permission checks for pointer parameters.

5. Exploiting system calls which take a function pointer as a parameter to achieve arbitrary code execution

Threat Category - Elevation of privileges.

Description - An attacker can elevate their privilege by passing the address of a function to a system call, the implementation of which executes the supplied function from a privileged context.

Mitigation– Mitigated by reviewing all the system calls to ensure those that accept a function pointer as a parameter only execute the function in the calling task's context.

6. Exploiting system calls to achieve denial of service

Threat Category - Denial of service.

Description - An attacker can use FreeRTOS system calls to interfere with other tasks or the system as a whole.

Mitigation – FreeRTOS system calls which could be exploited to interfere with other tasks or the system as a whole have been restricted to privileged code only.

7. Fake kernel object handles

Threat Category - Tampering, Information disclosure.

Description - An attacker can trick the kernel into an arbitrary memory read or write by passing the address of a specially crafted memory block instead of a kernel object handle as a parameter to a system call.

Mitigation– Kernel object handles are opaque and indirectly verifiable integers, not addresses.

8. Using attacker controlled memory for creating kernel objects

Threat Category - Tampering, Information disclosure.

Description - Statically allocated kernel objects use memory provided by the application writer. Using memory provided by an attacker can enable the attacker to manipulate the kernel.

Mitigation– Unprivileged tasks cannot access system calls used to create kernel objects in statically allocated memory. Objects can be created using statically allocated memory from privileged tasks or before starting the scheduler.

9. Overriding kernel MPU protections

Threat Category - Tampering, Information disclosure, Elevation of privileges.

Description - An attacker can circumvent kernel memory protections by overlapping MPU regions (where supported by the MPU hardware).

Mitigation– The ARMv7-M MPU is the only supported MPU that allows overlapping MPU regions. On that architecture, higher MPU region numbers take precedence over lower MPU region numbers, so the kernel uses the highest region numbers (which can't be overridden) to protect it's own code and data.

10. Manipulating task context after it is swapped out

Threat Category - Tampering, Elevation of privileges.

Description - A task's context includes both general and special purpose registers. The kernel stores the context of each task that is not running, so that it can run the task again in the future. An attacker can hijack control flow, or escalate a task's privilege, by manipulating a saved context.

Mitigation- Task context is stored in the Task Control Block (TCB), which is a kernel internal data structure, and so not accessible to unprivileged code.

11. Privilege escalation attempts

Threat Category - Elevation of privileges.

Description - An attacker could execute assembly instructions used by system calls to escalate privilege.

Mitigation- Privilege escalations are only granted when originating from a system call.

12. Leaking information through a stack

Threat Category - Information disclosure.

Description - Confidential data stored on the stack by a system call could remain on the stack and accessible to the unprivileged task after the system call returns.

Mitigation– Mitigated by executing system calls on a separate stack accessible to privileged code only.

13. Unprivileged task accessing valid kernel objects using legitimate system calls

Threat Category - Tampering, Information disclosure.

Description - An unprivileged task may access a valid kernel object using legitimate system calls which it is not supposed to access.

Mitigation– The application writer must enable Access Control List (ACL) feature by setting configENABLE_ACCESS_CONTROL_LIST to 1 in their FreeRTOSConfig.h and grant unprivileged tasks access to the kernel objects they need.

Threats not mitigated by the kernel

1. Leaking information through registers

Threat Category - Information disclosure.

Description - Confidential data stored in a general purpose register by a system call could remain in the register accessible to the unprivileged task after the system call returns.

Mitigation– This threat is considered low risk and not mitigated because kernel system calls don't use data which would be problematic if read by an unprivileged task. System calls added by application writers that do use confidential data must take appropriate measures to remove the data from the registers before returning.

Threats required to be mitigated by the application

1. Untrusted code execution before starting the scheduler

Threat Category - Tampering, Information disclosure, Elevation of privileges.

Description - The microcontroller (MCU) boots into privileged mode and remains privileged until the scheduler starts. The kernel doesn’t provide any protections against untrusted code execution before the scheduler starts.

Mitigation- The application writer must ensure no untrusted code executes before the scheduler starts. It is strongly recommended to use a secure boot sequence that only boots verified signed images, and to only execute untrusted code in unprivileged tasks.

2. Untrusted code execution in ISRs

Threat Category - Tampering, Information disclosure, Elevation of privileges.

Description - The MCU enters privileged mode before executing ISRs. The kernel doesn't provide any protections against untrusted code execution between entering an ISR and the ISR either returning or lowering its privilege.

Mitigation- The application writer must ensure no untrusted code executes in any ISR. It is strongly recommended to use a secure boot sequence that only boots verified signed images, to keep ISRs as short as possible, and defer the majority of interrupt processing to unprivileged tasks. Installing a single entry point for all ISRs can help manage privilege levels.

3. Incorrect configuration

Threat Category - Tampering, Information disclosure.

Description - The application may fail to correctly export the following linker variables:

__FLASH_segment_start__ and __FLASH_segment_end__

Start and end of the memory containing all code.

__privileged_functions_start__ and __privileged_functions_end__

Start and end of the memory containing kernel code placed in the privileged_functions section.

__syscalls_flash_start__ and __syscalls_flash_end__

Start and end of the memory containing FreeRTOS system calls placed in the freertos_system_calls section.

__privileged_data_start__ and __privileged_data_end__

Start and end of the memory containing kernel data placed in the privileged_data section.

The application writer must ensure the size and alignment of the above memory regions are compliant with any limitations imposed by the MPU hardware. The application writer must define configENABLE_MPU to 1 for ARMv8-M ports.

Mitigation- The application writer must ensure that FreeRTOS is configured correctly.

4. Physical attacks

Threat Category - Tampering, Information disclosure.

Description - The end product may be subjected to physical attacks such as glitching or side channel attacks.

Mitigation- MPU protections do not protect against all physical attacks. The application writer must develop protections against physical attacks, or deploy the device running FreeRTOS in environments with physical access restrictions, if required.

5. Source Code Integrity

Threat Category - Tampering.

Description - FreeRTOS source code can be modified by the application writer which may introduce vulnerabilities.

Mitigation- The application writer must not modify the FreeRTOS source code.

6. Application Binary Integrity

Threat Category - Tampering.

Description - The binary running in the end product may be modified to introduce vulnerabilities.

Mitigation- The application writer must use mechanisms like hardware root of trust, secure boot, and cryptographic signature verification to ensure application binary integrity.