Architecture section is now early draft ready

## 4.3 Product overview and architecture

An operating system abstracts the hardware and provides services to itself and any other software on the system. It often serves as a central organizing authority that controls access to system resources, dividing up available resources among the applications and its own subsystems to meet implicit or explicit goals or constraints. An operating system often uses a large part of the resources of the system it runs on, but in return it simplifies the development and deployment of the overall system.

### 4.3.1 Overview

An operating system abstracts the hardware, allocates resources, and provides services to itself and any other software on the system. It often serves as a central organizing authority that controls access to system resources by various pieces of software, dividing up available resources among the applications and its own subsystems to meet implicit or explicit goals or constraints. An operating system often uses a large part of the resources of the system it runs on, but in return it simplifies the development and deployment of the overall system.

![Temporary architecture diagram](media/architecture.png)

Operating system architecture is quite varied, depending on factors such as the intended use case, the underlying platform, and the design philosophy of the developers. This overview will focus on the elements of operating system architecture that have a significant impact on the security functions and risk mitigations of an operating system.

To oversimplify, the security of an operating system depends on appropriately controlling the instructions to be executed on processors. Instruction flow is dependent on the text of the executable, any data it accesses, and the effects of hardware devices that have the ability to change either data or which instructions are being executed. For example, a network interface adapter can write to system memory, and a USB controller can raise an interrupt which can cause the interrupt controller to force the CPU to switch to executing interrupt handling code.

### 4.3.2 Operating system security functions

To oversimplify, the security of an operating system depends on appropriately controlling the instructions to be executed on the processors on the system under its control. Instruction flow is dependent on the text of the executable, any data it accesses, and any hardware that has the ability to change either data or which instructions are being executed. For example, a network interface adapter can write to system memory, altering the data and changing the execution of any code that results in it. A USB controller can raise an interrupt which can cause the interrupt controller to force the CPU to switch to executing interrupt handling code, altering the instruction flow.

A fundamental building block of operating system is privileges. Privileges which control which system resources or functions that program can access. The operating system grants a defined set of privileges to itself, its subsystems, and any other executing software program.

Generally privileges are enforced using hardware features such as a memory management unit and processor-defined privilege levels. If the hardware does not provide these features, the operating system may use a best effort system, such as relying on the compiler to generate code that is less likely to accidentally interfere with the functions of the operating system or other parts of the system. A best-effort approach is only acceptable in low-risk, low-impact use cases where all elements and users of the systems can be trusted to not deliberately attempt to compromise the system.

### 4.3.3 High-level operating system architectures

Operating systems architecure varies in many ways. Some of the most security-relevant ways include:

* Proportion of operating system code running in different protection domains

* Whether applications run in a separate protection domain from the operating system

* Method of communication between protection domains

Each of these design variations makes different tradeoffs between security, performance, and ease of implementation.

Reducing the proportion of code running at the highest privilege level improves security by reducing the amount of vulnerable code, at the cost of lower performance due to the need to switch between privilege domains more often. Applications running in a separate protection domain dramatically reduces the amount of vulnerable code on most systems, again at the cost of lower performance when switching between protection domains. The method of communication between protection domains is generally a tradeoff between the speed of shared memory and the safety of checking and copying specific data (e.g., directly reading/writing a region of shared memory vs. using a system call or interprocess communication interface).

A few of the more common operating systems architectures include:

**Monolithic kernel:** The operating system kernel is one executable running at the highest processor privilege level in one memory domain, providing the majority of system-wide services. Applications are in separate memory domains and have a lesser privilege level. Applications request services and resources via system calls. Often a monolithic kernel supports modules, which allows parts of the kernel of the kernel to be added or removed at run-time, but they are usually sharing the same memory domain and privilege level.

**Microkernel:** The operating system kernel running at the highest processor privilege level provides a minimal set of resource allocation services, while many of the operating systems services are provided by separate executables with lower privileges.

**Hybrid kernel:** A mix of microkernel and monolithic kernel, where some operating systems services are provided in the central kerrnel and some are provided by applications. Subsystems that do not need to be high performance and are a frequent source of vulnerabilities are often moved into applications, such as printer drivers or file systems with complex features and/or low performance requirements.

**Exokernel:** The operating system does not abstract the resources of the system, it only manages resource allocation between different applications.

**Unikernel:** The operating system and the application are effectively a single executable. Often this is described as a library operating system: a set of library routines that an application can include and effectively become the operating system.

Note that in many cases, system libraries and applications are necessary for the function of the operating system, and are included in the security-relevant parts of an operating system. Some examples include the init process, userspace helpers to set up or access USB devices, authentication software, and libraries that wrap or simplify the process of making system calls.

### 4.3.3 Access control mechanisms

Operating systems control access to resources in different ways, including:

**Access control lists:** Each resource has a list of users or processes that are allowed to access it.

**Role-based access control:** Users are assigned one or more roles, and roles have permissions associated with them.

**Capabilities:** Access to a resource is linked to a token which can be passed between processes.

### 4.3.4 Resource management

Operating systems often allocate system resources among different applications or threads, including processor time, memory, storage, file descriptors, and process table entries. Operating systems may implement limits on the number or proportion of specific resourcs that an application or thread may use, and may group these limits by user, process, process group, or other mechanism.

### 4.3.5 Scheduling

> FIXME finish this section

Operating systems may provide voluntary or involuntary switching between different threads. Some common models include:

> NOTE: More notes on OS architecture temporarily located in Annex E

**Cooperative scheduling:** Each thread executes on a process as long as it likes until it voluntarily yields the processor to another thread.

**Preemptive scheduling:** Each thread can be involuntarily halted and replaced by a different thread, as well as voluntarily yielding the CPU.

The operating system can choose which thread to schedule based on factors such as:

* Time spent executing during a previous time period

* Time since the thread was first marked runnable

* Explicit priorities associated with each thread

* Type of thread (kernel or application)

* Resource limits

* Performance considerations

## 4.4 Use Cases

> Describe how to treat any residual risks, for example by documenting them or informing the user.

# Annex E: Detailed OS architecture description

> FIXME This will go in the main body of the document when it reaches first draft status.

> **NOTE: The remainder of section 4.3 is more of a collection of notes than an overview - not ready for review yet.**

# Annex E: Notes

> FIXME include the relation graphic between verticals here to explain the outside relationship.

> **NOTE: This section is a temporary storage place for notes, will be deleted.

The internal structure/architecture/security design of an operating system depends a lot on the type of kernel and operating system as well as the security and separation mechanisms available on the taret hardware.

> FIXME: Use generic architectural descriptions (monolithic, microkernel, ...) or create a list of orthogonal properties (hardware access control for drivers, address space separation, ...) and differentiate based on that?

> FIXME: Refactor the kernel type definitions (below) so they connect to essential safety functions that operating systems provide.

### 4.3.0 Hybrid monolithic/micro kernel operating systems

> FIXME: Extend our definition of operating systems with the sentences below?

A generic operating system encompasses both a kernel implementing resource access control and resource allocation as well as hardware abstraction (drivers) for internal components and I/O interfaces. Commonly used libraries are also considered to be part of the operating system (part of the API/ABI).

Any not commonly used (or internal) library/interface which is directly or indirectly used by (or can in some way influence the security of) security or execution control mechanisms of the operating system, including but not limited to the init system, is also considered to be part of the operating system.

Mechanisms for run-time fixups of hardware (e.g. CPU microcode upload/update) as well as workarounds for run-time attack surface of hardware (microarchitectural and other side effects) are also considered to be part of the operating system.

In contrast to the run-time fixup mechanisms, the CPU microcode update itself is considered to be part of the scope of the microprocessor vertical because it modifies functionality of the microprocessor.

> FIXME include the relation graphic between verticals in the architecture overview to explain the outside relationship.

> FIXME: Ensure the following cases present in most x86 computers are not lost, assign them to the scope of a vertical (may be ours, may be another vertical).

Special case UEFI updates triggered by the operating system: The update mechanism as provided by the firmware (UEFI capsule) is considered to be in the scope of the boot manager vertical, as is the cryptographic verification of such updates.

Special case Windows drivers delivered as part of UEFI and retrieved by Windows from UEFI during Windows installation (usually hardware enabledment like storage and network drivers). FIXME: Look up the name of that mechanism.

Special case of Windows using calls into UEFI runtime services if no native Windows driver for a given peripheral (may even be the graphics card) exists. Does that make this specific UEFI driver part of the operating system?

Special case of System Management Mode (SMM) running in the background with privileges higher than the OS kernel and higher than the hypervisor (if any) and emulating hardware and/or monitoring CPU temperature, possibly forcing shutdown to prevent overheating.

Special case of verified/measured boot partially implemented outside the operating system and outside the CPU, e.g. delegated to the Intel CSME (separate x86/ARC CPU with JTAG access to the main CPU).

Special case configuration files? Not code in most cases, but substantial impact on the security configuration of the operating system.

### 4.3.1 Monolithic kernel based operating systems

Comments:

General comment on the Windows vs. Linux vs. macOS situation: Neither is a pure monolithic kernel nor a completely microkernel. Each of them can be described as hybrid of various flavours.

For example, printer drivers in Windows and Linux nowadays are not part of the operating system kernel or at least usually no not run with kernel level privileges. On the other hand, graphics drivers do at least partially live in the kernel and have hardware access permissions.

Yes, the statements above somewhat contradict what Wikipedia is saying.

### 4.3.2 Microkernel based operating systems

### 4.3.3 Exokernel based operating systems

> FIXME should this just be a special case of microkernel for most architectural purposes? If not, do we differentiate based on kernel design of based on hardware access privileges for applications?

### 4.3.4 Unikernel based operating systems

> FIXME differentiate between single-address-space/single-privilege-level combined binaries and binaries with some separation mechanisms baked in?

# Annex L (informative): Relationship between the present document and the requirements of EU Regulation 2024/2847

DRAFT ANNEX L - DO NOT CONSIDER THE CONTENT

The present document has been prepared under the Commission's standardisation request C(2025) 618 final to provide one voluntary means of conforming to the requirements of Regulation (EU) No 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).