> FIXME some of these could be normative references
> FIXME more informative references
# 3 Definition of terms, symbols and abbreviations
# 3 Definition of terms, symbols and abbreviations
> **NOTE: Existing ETSI terms and abbrevations can be searched here: [https://webapp.etsi.org/Teddi/](https://webapp.etsi.org/Teddi/)**
> **NOTE: Existing ETSI terms and abbrevations can be searched here: [https://webapp.etsi.org/Teddi/](https://webapp.etsi.org/Teddi/)**
@@ -336,13 +331,13 @@ Out of scope use cases and environments include those explicitly carved out by t
## 4.3 Product overview and architecture
## 4.3 Product overview and architecture
> Explain the overall architecture and relationship among the parts of the products. Use diagrams if that is helpful.
> NOTE: Below is the technical definition as of August 2025 draft.
> A useful free diagram tool is [https://app.diagrams.net/](https://app.diagrams.net/), which allows you to save a PNG with the diagram source as SVG inside it.
Operating systems include software products with digital elements that provide an abstract interface of the underlying hardware and control the execution of software, and that may provide services such as computing resource management and configuration, scheduling, input-output control, managing data, and providing an interface through which applications interact with system resources and peripherals.
> FIXME write an operating systems overview and make some diagrams
This category includes but is not limited to real-time operating systems, general-purpose and special-purpose operating systems.
> FIXME include the current vertical definition supplied by the EC, use that as a starting point.
> FIXME write an operating systems overview and make some diagrams
> FIXME include the relation graphic between verticals here to explain the outside relationship.
> FIXME include the relation graphic between verticals here to explain the outside relationship.
@@ -352,8 +347,6 @@ The internal structure/architecture/security design of an operating system depen
### 4.3.0 Hybrid monolithic/micro kernel operating systems
### 4.3.0 Hybrid monolithic/micro kernel operating systems
> FIXME: Use the definition from section 4.5 as a starting point?
> FIXME: Extend our definition of operating systems with the sentences below?
> 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).
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.
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.
@@ -361,6 +354,7 @@ Mechanisms for run-time fixups of hardware (e.g. CPU microcode upload/update) as
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.
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).
> 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 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 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 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?
@@ -372,8 +366,6 @@ Special case configuration files? Not code in most cases, but substantial impact
### 4.3.1 Monolithic kernel based operating systems
### 4.3.1 Monolithic kernel based operating systems
> FIXME write an operating systems overview and make some diagrams
Comments:
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.
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.
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.
@@ -381,7 +373,7 @@ Yes, the statements above somewhat contradict what Wikipedia is saying.
### 4.3.2 Microkernel based operating systems
### 4.3.2 Microkernel based operating systems
>
### 4.3.3 Exokernel 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?
> 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?
@@ -464,6 +456,51 @@ _The following use cases are provided to assist manafacturers in selecting risk
* connects to trusted local networks
* connects to trusted local networks
* hardware likely contains tamper-evident indicators and secure elements for cryptographic storage
* hardware likely contains tamper-evident indicators and secure elements for cryptographic storage
Remaining use cases to code:
1. Stateless multi-user terminal
* Multi-user system
* Handles different workloads of different users
* No local data or session storage
* Highly network dependent (likely company network with firewall)
1. Enterprise work station (stationary)
* Effectively single user (unless shared, but then more likely to be a "stateless terminal"?)
* Connected to enterprise network with firewall
* Web browsing and office applications
* Managed by the enterprise's IT department
* Transmits and stores business-critical data
* System failure can cause monetary loss (if no proper BCM)
* Always stationary (and supervised), access to hardware interfaces unlikely
1. Personal server
* Usually single account, may give accounts to small trusted circle
* Not exposed to the public
* Behind a firewall
* Access from anywhere via the internet possible (depending on services running)
* Semi-professional semi-automated management by one or a few people
* Always stationary, access to hardware interfaces unlikely
1. Enterprise laptop
* Single account, single user
* Connected to enterprise network with firewall, potentially via VPN
* Web browsing and office applications
* Managed by the enterprise's IT dep. (perhaps with Mobile Device Management)
* Transmits and stores business-critical data
* System failure can cause monetary loss (if no proper BCM)
1. Enterprise multi-user server, internal access only
* Multiple accounts each with a trusted user
* Users may install software into personal directories
* Behind professionally managed firewall
* Automated management and monitoring by IT professionals
* Processes sensitive data
1. Firewalls
1. Corporate server providing services on public internet
* Multiple accounts for isolation of services
* Automated management and monitoring by IT professionals
* Processes sensitive data
1. Corporate server hosting many public users
* Many accounts, many users, no mutual trust
* Automated management and monitoring by IT professionals
* Processes sensitive data
## 4.5 Risk factors
## 4.5 Risk factors
### 4.5.1 List of risk factors
### 4.5.1 List of risk factors
@@ -575,56 +612,19 @@ Note: "account" refers to a user in the operating systems sense: a unique system
Val: Phone should be significantly riskier than a personal laptop but comes out less risky, suggests that the available risk levels may need to be changed. The goes-everywhere, always-on, super loaded with personally identifiable data, filled with data stealing apps part isn't fully reflected. I would expand FNET, PHYS, LOSS, DATA perhaps? Also maybe add the lower admin/user sophistication?
**Discussion**
Remaining use cases to code:
Potential additional risk factors:
1. Stateless multi-user terminal
* Professional or amateur administration
* Multi-user system
* Is audit/logging being watched?
* Handles different workloads of different users
* Web browsing or not
* No local data or session storage
* Sensitivy of data collected or transferred
* Highly network dependent (likely company network with firewall)
* Sensitivity of functions
1. Enterprise work station (stationary)
* Running on bare metal vs. hypervisor
* Effectively single user (unless shared, but then more likely to be a "stateless terminal"?)
* Many devices have multiple OS's for elements
* Connected to enterprise network with firewall
* Web browsing and office applications
* Managed by the enterprise's IT department
* Transmits and stores business-critical data
* System failure can cause monetary loss (if no proper BCM)
* Always stationary (and supervised), access to hardware interfaces unlikely
1. Personal server
* Usually single account, may give accounts to small trusted circle
* Not exposed to the public
* Behind a firewall
* Access from anywhere via the internet possible (depending on services running)
* Semi-professional semi-automated management by one or a few people
* Always stationary, access to hardware interfaces unlikely
1. Enterprise laptop
* Single account, single user
* Connected to enterprise network with firewall, potentially via VPN
* Web browsing and office applications
* Managed by the enterprise's IT dep. (perhaps with Mobile Device Management)
* Transmits and stores business-critical data
* System failure can cause monetary loss (if no proper BCM)
1. Enterprise multi-user server, internal access only
* Multiple accounts each with a trusted user
* Users may install software into personal directories
* Behind professionally managed firewall
* Automated management and monitoring by IT professionals
* Processes sensitive data
1. Firewalls
1. Corporate server providing services on public internet
* Multiple accounts for isolation of services
* Automated management and monitoring by IT professionals
* Processes sensitive data
1. Corporate server hosting many public users
* Many accounts, many users, no mutual trust
* Automated management and monitoring by IT professionals
* Processes sensitive data
> FIXME more use cases?
**Discussion**
Val: Phone should be significantly riskier than a personal laptop but comes out less risky, suggests that the available risk levels may need to be changed. The goes-everywhere, always-on, super loaded with personally identifiable data, filled with data stealing apps part isn't fully reflected. I would expand FNET, PHYS, LOSS, DATA perhaps? Also maybe add the lower admin/user sophistication?
Carl-Daniel:
Carl-Daniel:
Separate question for the application delivery mechanism:
Separate question for the application delivery mechanism:
@@ -636,35 +636,6 @@ Separate question for the application delivery mechanism:
Aeva: Carl-Daniel's comment could also apply to enterprise computers (laptops, desktops, servers) -- most also contain a second OS for remote management.
Aeva: Carl-Daniel's comment could also apply to enterprise computers (laptops, desktops, servers) -- most also contain a second OS for remote management.
industrial operations we have to include probably?
A few risk factors extracted from the use cases:
* Number of accounts
* Number of users: 0, 1, more than 1
* Whether users trust each other
* No trust
* Corporate colleagues level
* Family
* Children
* Purchaser vs. users
* Stationary vs. mobile
* Public vs. private physical environment
* Exposure to theft and loss
* Behind a firewall or directly connected to internet
* airgap
* system can reach the internet
* internet can reach the system
* Source of applications installed post-market (if any)
* Professional or amateur management
* Web browsing or not
* Sensitivy of data collected or transferred
* Sensitivity of functions
* End user configurability (how locked down)
* End user modifiability to hardware
* Running on bare metal vs. hypervisor
* Many devices have multiple OS's for elements
## 4.6 Security levels
## 4.6 Security levels
### 4.6.1 General
### 4.6.1 General
@@ -677,7 +648,6 @@ Security levels are associated with sets of risk factor levels.
> FIXME take filled out table of use case mapping to risk factor, simplify down, set levels
> FIXME take filled out table of use case mapping to risk factor, simplify down, set levels
## 4.7 Essential functions
## 4.7 Essential functions
> List the essential functions of the product, including:
> List the essential functions of the product, including:
@@ -724,13 +694,13 @@ An operating system may provide, depending on the hardware available and its con
* Logging
* Logging
* Monitoring/notifications
* Monitoring/notifications
> Put this in a diagram with dependencies and interface/attack surface
> FIXME Put this in a diagram with dependencies and interface/attack surface?
## 4.8 Operational Environment
## 4.8 Operational Environment
The technical requirements of the present document apply under the environmental profile for operation of the equipment, which shall be in accordance with its intended use. The equipment shall comply with all the technical requirements of the present document at all times when operating within the boundary limits of the operational environmental profile defined by its intended use.
The technical requirements of the present document apply under the environmental profile for operation of the equipment, which shall be in accordance with its intended use. The equipment shall comply with all the technical requirements of the present document at all times when operating within the boundary limits of the operational environmental profile defined by its intended use.
The manufacturer shall document and communicate the expected environmental profile for the product to the cosumer.
The manufacturer shall document and communicate the expected environmental profile for the product to the consumer.
## 4.9 Users
## 4.9 Users
@@ -789,9 +759,9 @@ The operating system often provides many security functions to other components
>
>
> In the future, a dedicated administrative cooperation group “ADCO” whose duties and creation are described in CRA Recitals 22, 62, 108, 109 and Article 52 (15), (16)<a href="#_ref_i.1">[i.1]</a> will assist in the process of setting minimum support periods by collecting and analyzing data on support periods set by manufacturers and setting minimums should manufacturers systematically fail to provide adequate support periods. These duties and powers are described in Recital 62, Recital 117, and Article 13 (8) of the Act<a href="#_ref_i.1">[i.1]</a>. Any support period set by the standards will be superseded by those produced by the commission or its delegates.
> In the future, a dedicated administrative cooperation group “ADCO” whose duties and creation are described in CRA Recitals 22, 62, 108, 109 and Article 52 (15), (16)<a href="#_ref_i.1">[i.1]</a> will assist in the process of setting minimum support periods by collecting and analyzing data on support periods set by manufacturers and setting minimums should manufacturers systematically fail to provide adequate support periods. These duties and powers are described in Recital 62, Recital 117, and Article 13 (8) of the Act<a href="#_ref_i.1">[i.1]</a>. Any support period set by the standards will be superseded by those produced by the commission or its delegates.
The support period of an operating system shall be at least 10 years.
The support period of an operating system shall be at least 10 years, unless [QUANTIFIABLE JUSTIFICATION DESCRIBED HERE].
FIXME explain how shorter support periods can be justified.
> FIXME explain how shorter support periods can be justified.
In accordance with Article 13 (8) of the CRA<ahref="#_ref_i.1">[i.1]</a>, the manufacturer shall document how it reached a decision on a specific support period in the technical documentation of the product. The manufacturer shall document the following considerations that affected the decision making process:
In accordance with Article 13 (8) of the CRA<ahref="#_ref_i.1">[i.1]</a>, the manufacturer shall document how it reached a decision on a specific support period in the technical documentation of the product. The manufacturer shall document the following considerations that affected the decision making process:
@@ -819,6 +789,7 @@ In accordance with Article 13 (8) of the CRA<a href="#_ref_i.1">[i.1]</a>, the m
> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)
> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)
Baseband OS running on the baseband processor on most smartphones is a special case: Usually it has DMA write access to the user-facing OS (Android), on the application procesor and the user-facing OS can't protect itself against that.
*[MITRE EMB3D](https://emb3d.mitre.org/):
* https://trustedcomputinggroup.org/resources/
Anything can run with elevated privileges if root runs it... is there a mitigation here?
Baseband OS running on the baseband processor on most smartphones is a special case: Usually it has DMA write access to the user-facing OS (Android), on the application procesor and the user-facing OS can't protect itself against that.
Anything can run with elevated privileges if root runs it... is there a mitigation here?
