> **NOTE: The remainder of section 4.3 is more of a collection of notes than an overview - not ready for review yet.**
> FIXME include the relation graphic between verticals here to explain the outside relationship.
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: 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?
> FIXME GitLab pipeline doesn't work with mermaid
An operating system abstracts the hardware and provides services to other software on the system with the overall purpose of making the development and execution of software simpler, more convenient, and more secure. While in most cases the operating system mediates access to the hardware, in some use cases software outside of the operating system directly accesses hardware.
> FIXME Detailed OS architecture description in progress, temporarily located in Annex E
## 4.4 Use Cases
@@ -1154,6 +1110,57 @@ A.PROPER ADMIN: The administrator of the OS is not careless, willfully negligent
> 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.**
> FIXME include the relation graphic between verticals here to explain the outside relationship.
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: 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
