Huawei HongMeng Kernel Common Criteria Evaluation
ST: Security Target for Specified Hardware
Version 2.0
Status Released
Last update 2023-07-12
Classification Public
HUAWEI TECHNOLOGIES CO., LTD.
Copyright c Huawei Technologies Co., Ltd. 2021 - 2023. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided “AS IS” without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People’s Republic of China
Website: https://www.huawei.com
Change History
Date Version Section Number Change Description Author
2021.11.02 1.0 All Initial Draft Liu Zhe
2021.12.08 1.1 6.1.2, 6.2.4
Update Memory Opera-
tions
Liu Zhe, Wang Shiwei
2022.04.26 1.2 6.2, 6.4
Modify Some Descriptions
in SFR and SAR
Liu Zhe
2023.01.29 1.3 3.5, 4.2
Refine Assumptions and
Definitions on Environ-
ment
Liu Zhe
2023.04.30 1.4 1.1, 1.2 Update Version Number Pu Wenxu
2023.07.12 2.0 1.2, 1.4 Update Version Number Liu Zhe
Contents
1 Security Target Introduction 1
1.1 Security Target Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 TOE Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 TOE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3.1 TOE Usage and Major Security Features . . . . . . . . . . . . . . . . . . . . . . 1
1.3.2 TOE Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.3 Required Non-TOE Hardware/Software/Firmware . . . . . . . . . . . . . . . . . 2
1.4 TOE Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1.1 Initialization Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1.2 Inter Process Communication . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1.3 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1.4 Thread Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1.5 Kernel Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1.6 Capability System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 TOE Operational Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 TOE Physical Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.4 TOE Logical Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.5 Reference Device Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Conformance Claims 9
2.1 CC Conformance Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 PP Claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Security Problem Definition 10
3.1 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Users/Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Security Objectives 13
4.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Security Objectives for the Operational Environment . . . . . . . . . . . . . . . . . . . . 13
4.3 Security Objectives Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1 Security Objectives Rationale: Threats . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1.1 Threat: T.UNAUTHORIZED ACCESS . . . . . . . . . . . . . . . . . . 14
4.3.1.2 Threat: T.QUEUE SKIPPING . . . . . . . . . . . . . . . . . . . . . . 14
4.3.2 Security Objectives Rationale: Organizational Security Policies (OSPs) . . . . . . 15
4.3.2.1 OSP: OSP.SYSTEM INTEGRATOR . . . . . . . . . . . . . . . . . . . 15
4.3.2.2 OSP: OSP.SAFE SECURE STATE . . . . . . . . . . . . . . . . . . . . 15
4.3.3 Security Objectives Rationale: Assumptions . . . . . . . . . . . . . . . . . . . . . 15
4.3.3.1 Assumption: A.TRUSTWORTHY PERSONNEL . . . . . . . . . . . . 15
4.3.3.2 Assumption: A.ENVIRONMENT . . . . . . . . . . . . . . . . . . . . 15
4.3.3.3 Assumption: A.TRUSTED PROCESS . . . . . . . . . . . . . . . . . . 15
5 Extended Components Definition 16
5.1 Definition of Family FAU SAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1 FAU SAS Audit data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1.1 FAU SAS.1 Audit Storage . . . . . . . . . . . . . . . . . . . . . . . 16
6 Security Requirements 17
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.3 Security Function Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 TOE Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1 User Identification and TSF Protection . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1.1 FIA ATD.1 User attribute definition . . . . . . . . . . . . . . . . . . 21
6.2.1.2 FIA UID.2 User identification before any action . . . . . . . . . . . . 21
6.2.1.3 FIA USB.1 User-subject binding . . . . . . . . . . . . . . . . . . . . 22
6.2.1.4 FPT FLS.1 Failure with preservation of secure state . . . . . . . . . . 22
6.2.1.5 FMT SMR.1 Security roles . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.2 Capability-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2.2.1 FDP ACC.1/CAP Subset access control . . . . . . . . . . . . . . . . 23
6.2.2.2 FDP ACF.1/CAP Security attribute based access control . . . . . . . 23
6.2.2.3 FMT MSA.1/CAP Management of security attributes . . . . . . . . . 24
6.2.2.4 FMT MSA.3/CAP Static attribute initialisation . . . . . . . . . . . . 24
6.2.2.5 FMT SMF.1/CAP Specification of management functions . . . . . . 25
6.2.3 Information Flow Control and Residual Information Removal . . . . . . . . . . . 25
6.2.3.1 FDP IFC.1/ACTV Subset information flow control . . . . . . . . . . 25
6.2.3.2 FDP IFF.1/ACTV Simple security attributes . . . . . . . . . . . . . . 25
6.2.3.3 FMT MSA.1/ACTV Management of security attributes . . . . . . . . 26
6.2.3.4 FMT MSA.3/ACTV Static attribute initialisation . . . . . . . . . . . 26
6.2.3.5 FMT SMF.1/ACTV Specification of management functions . . . . . 27
6.2.3.6 FDP IFC.1/CHNL Subset information flow control . . . . . . . . . . 27
6.2.3.7 FDP IFF.1/CHNL Simple security attributes . . . . . . . . . . . . . . 27
6.2.3.8 FMT MSA.1/CHNL Management of security attributes . . . . . . . . 28
6.2.3.9 FMT MSA.3/CHNL Static attribute initialisation . . . . . . . . . . . 28
6.2.3.10 FMT SMF.1/CHNL Specification of management functions . . . . . 29
6.2.3.11 FDP RIP.1 Subset residual information protection . . . . . . . . . . . 29
6.2.4 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.4.1 FDP ACC.1/MEM Subset access control . . . . . . . . . . . . . . . 29
6.2.4.2 FDP ACF.1/MEM Security attribute based access control . . . . . . . 29
6.2.4.3 FMT MSA.1/MEM Management of security attributes . . . . . . . . 31
6.2.4.4 FMT MSA.3/MEM Static attribute initialisation . . . . . . . . . . . . 31
6.2.4.5 FMT SMF.1/MEM Specification of management functions . . . . . . 31
6.2.5 Thread Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.5.1 FRU PRS.1 Limited priority of service . . . . . . . . . . . . . . . . . 32
6.2.6 Platform Attestation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.6.1 FAU SAS.1 Audit storage . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Security Functional Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3.2 Coverage and Sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Security Assurance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4.1 ADV SPM.1 Formal TOE security policy model . . . . . . . . . . . . . . . . . 36
6.5 Security Assurance Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 36
7 TOE Summary Specification 37
7.1 User Identification and TSF Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1.1 Identification and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1.2 Protection of TSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1.3 SFR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2 Capability-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.1 Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.1.1 Discretionary Access Control . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.1.2 DAC Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.1.3 DAC Enforcement Algorithm . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.2 Security Management in Capability . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.3 SFR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3 Information Flow Control and Residual Information Removal . . . . . . . . . . . . . . . . 39
7.3.1 IPC Information Control Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.3.1.1 IPC Information Control Policy on Activation . . . . . . . . . . . . . . 39
7.3.1.2 IPC Information Control Policy on Channel . . . . . . . . . . . . . . . 39
7.3.2 IPC Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.3.2.1 Security Management on Activation . . . . . . . . . . . . . . . . . . . 40
7.3.2.2 Security Management on Channel . . . . . . . . . . . . . . . . . . . . . 40
7.3.3 Residual Information Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.3.4 SFR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.4 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.4.1 Memory Management Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.4.1.1 Page based Physical Memory Management . . . . . . . . . . . . . . . . 40
7.4.1.2 Capability based Virtual Memory Management . . . . . . . . . . . . . . 41
7.4.1.3 Syscalls of Memory Management . . . . . . . . . . . . . . . . . . . . . 41
7.4.2 Security Management in Memory Management . . . . . . . . . . . . . . . . . . . 41
7.4.2.1 Physical Memory Type Transfer . . . . . . . . . . . . . . . . . . . . . 41
7.4.2.2 Virtual Memory Address Space Authorization . . . . . . . . . . . . . . 42
7.4.3 SFR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.5 Thread Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.5.1 Kernel Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.5.2 Futex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.5.3 SFR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.6 Platform Attestation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.6.1 SFR Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8 Abbreviations 43
9 Terminologies 44
10 References 45
List of Figures
1 TOE and Operational Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 FAU SAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
List of Tables
1 Physical Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Actors in Device Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Security Objectives Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Security Functional Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Security Objectives and SFRs - Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Security Objectives and SFRs - Sufficiency . . . . . . . . . . . . . . . . . . . . . . . . . 34
7 SFRs Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1. SECURITY TARGET INTRODUCTION
1 Security Target Introduction
1.1 Security Target Reference
Title: Huawei HongMeng Kernel Common Criteria Evaluation ST: Security Target
for Specified Hardware
Author: Huawei OS Kernel Lab
CC Version: 3.1 (Revision 5)
Assurance Level: EAL 6
Version: 2.0
Reference: HongMeng Kernel Security Target
ITSEF: Brightsight
Certification Body: Netherlands Scheme for Certification in the Area of IT Security (NSCIB)
Keywords: Operating System, Micro-kernel
1.2 TOE Reference
Name: HongMeng Kernel
Developers: Huawei OS Kernel Lab
Version: V100R006C00SPC020B030
Type: Micro-kernel
User Guidance: Huawei HongMeng Kernel Common Criteria Evaluation AGD OPE:
Operational User Guidance [OPE]
Huawei HongMeng Kernel Common Criteria Evaluation AGD PRE:
Preparative Procedures [PRE]
Hardware Platform: Huawei Kirin 9000 SoC
1.3 TOE Overview
1.3.1 TOE Usage and Major Security Features
HongMeng Kernel1
, as our target of evaluation (TOE), is a micro-kernel that provides fine-grained resource
management for applications running on top of it. More precisely, HongMeng Kernel is designed and
implemented in such a way that it provides the means to hold:
• Confidentiality property: the resources of a subject (code, data, registers, interrupts, devices) cannot
be observed by other subjects without an explicit authorization.
• Availability property: the system resources (code, data, registers, interrupts, devices) can be used by a
subject (i.e. process) if and only if the subject is allowed by the TOE based on a priority-based queue.
By providing confidentiality and availability, HongMeng Kernel enforces secure access control and isolation
for system resources. Thus it is a desired micro kernel for security scenarios.
In this document, subjects are mainly processes and a process is an instance of an application running on top
of HongMeng Kernel. A process starts with some system resources, including but not limited to the initial
code, data, priority and thread. Once it is executed, it may create a few threads running concurrently and also
it acquires or releases some resources during its lifetime as well.
1In the following, the TOE and HongMeng Kernel are used interchangeably.
1
1. SECURITY TARGET INTRODUCTION
HongMeng Kernel is supposed to run on a real mobile device (e.g., mobile phone) with hardware support for
ARM TrustZone. Since TEE is not the only zone on mobile devices, it is common to see multiple
unconstrained applications running on the non-TEE side. However even in that case, those unconstrained
applications cannot interfere with TOE, neither the applications running on top of TOE.
To achieve the security targets we described above, HongMeng Kernel employs the capability-based security
model to control usage of the particular system resources and/or services (e.g., the memory, processor,
communication channels, etc.). A capability is a transferable, unforgeable token that represents authority. It
refers to a value that uniquely references an object along with an associated set of access rights. By virtue of
its possession by a process that uses the referenced object, the capability token grants that process the
capability to interact with an object in certain ways.
For example, HongMeng Kernel enforces restrictions on communications between separated processes by
delegating the capability of communication channels with thoughtful rights setup.
The TOE comprises of:
• Software used to provide the HongMeng Kernel security functionalities.
• The guidance for the secure usage of the TOE after delivery.
1.3.2 TOE Type
HongMeng Kernel is a micro-kernel that provides fine-grained resource management for processes.
HongMeng Kernel includes non-trivial mechanisms like Inter Process Communication (IPC), memory
allocations, locking, device accessing, etc. A full-fledged operating system is implemented using such
mechanisms. In this version, HongMeng Kernel does not include a file system or a device manager. Only
very critical drivers are included in HongMeng Kernel.
In a real mobile scenario, system components (e.g., the file system, device manager, device drivers, etc.) are
implemented as applications running on top of HongMeng Kernel. These additional components, together
with HongMeng Kernel constitute a full-featured operating system to support TEE.
1.3.3 Required Non-TOE Hardware/Software/Firmware
The TOE can run on Huawei Mate/P series mobile phones with a minimum set of the following non-TOE
hardware and software in the mobile phone.
Required non-TOE hardware:
• Huawei Kirin 9000 SoC.
• RAM (6GB or more), which can be configured with a secure region to be accessed only by trust zone.
• NVM (64GB or more), which contains sensitive information for secure boot, Android OS and
HongMeng Kernel image.
Required non-TOE software:
• Bootloader: It loads the kernel image into the memory and transfers the control to the kernel.
• ARM Trusted Firmware: It starts the trusted software (including the bootloader and the kernel) in the
trusted zone and is responsible for the switch between the secure world and the non-secure world.
• System applications: Essential system applications for providing POSIX interfaces and interaction
functionalities with the non-secure side.
Also, as we already mentioned in the paragraph of TOE Type, the TOE does not include any hardware or
user applications.
2
1. SECURITY TARGET INTRODUCTION
1.4 TOE Description
1.4.1 Architecture
Figure 1: TOE and Operational Environment
As shown in Figure 1, the TOE consists of the following components:
• Initialization Code
• Inter Process Communication (IPC)
• Memory Management
• Thread Management
– Kernel Scheduling
– Kernel Support for Synchronization (Futex)
• Kernel Driver
• Capability System
• Syscall Entry
1.4.1.1 Initialization Code
The initialization code is executed at the very beginning of the TOE. First, the devices and resources are
initialized according to the initial vectors and the device tree. Afterwards, it initializes other modules.
Finally, it creates the first process and transfers the control to it.
1.4.1.2 Inter Process Communication
The TOE provides two different methods for processes to communicate with each other, named Activation
and Channel.
3
1. SECURITY TARGET INTRODUCTION
Activation The Activation is used to support RPC (Synchronized IPC). By separating the execution
context of a thread from the scheduling context, an application can switch the execution context within the
same scheduling context. Compared with the IPC with Send/Receive semantics, Activation needs to do less
during switching. Therefore, the performance is better.
Channel Async IPC allows one thread to asynchronously send messages without waiting for the other end
to receive. Senders and receivers are organized via Channels. A receiver can invoke Receive on a Channel to
wait for a message. Upon receiving a message, the receiver will be unblocked with the message payload.
1.4.1.3 Memory Management
Memory management includes management of physical memory and management of virtual memory
address spaces.
In virtual memory address space management, the TOE only manages page tables. In the TOE, each virtual
memory address space is statically divided into the kernel part and the user part. User processes can
arbitrarily map (unmap) specified virtual memory regions in the user part to (from) specified physical
memory regions through syscalls. The TOE validates the virtual memory regions and physical memory
regions so that user processes cannot operate on virtual memory address spaces without permissions or touch
illegal physical memory regions.
As for the mangement of physical memory, the TOE assigns all available physical memory regions to
differerent page types. The TOE is able to decide what the physical memory region is used for according to
its page types. It can map the physical memory region to store user data or tell the TOE to use this physical
memory region to store specified kernel objects. For security reasons, the TOE records the information of all
physical memory regions and always guarantees the physical memory isolation between user space and
kernel. The TOE also allows the types of one physical memory to transfer from one type to another.
1.4.1.4 Thread Management
The TOE provides a combined set of mechanisms to manage threads.
Kernel Scheduling Kernel scheduling is a TOE module which decides the thread to run at a certain point
of time. The TOE implements the priority-based RR (first in, first out) scheduling. Upon scheduling, the
scheduler finds a ready thread with the highest priority and puts it to run on the current CPU. Each thread
has a timeslice to keep track of the current remaining time on the CPU, which will be decreased by 1 upon
each timer tick. When the timeslice is used up, the current thread will give up the CPU and be appended to
the tail of scheduler queue. At this point the scheduler will choose a new thread run. Note that in HongMeng
Kernel, the current running thread also gives up the CPU whenever a syscall occurs or preempted by a thread
with higher priority.
Kernel Support for Synchronization HongMeng Kernel provides a light-weight method for process
synchronization, i.e., Fast Userspace muTEXes (Futex). Futex can be used to implement the basic locking,
or as the base for building more advanced locking mechanism, such as the semaphores, mutex locks or
condition variables.
A Futex consists of a kernel space wait queue that is attached to an atomic integer in user space. Multiple
threads operate on the integer entirely in user space, and only resort to relatively expensive system calls to
request operations on the wait queue (for example, to wake up waiting processes when the lock is free, or to
put the current process on the wait queue when the lock is contended). So the process will not be trapped in
the kernel space if there is no contention, and this improves the kernel efficiency.
4
1. SECURITY TARGET INTRODUCTION
1.4.1.5 Kernel Driver
Only very critical drivers are included in HongMeng Kernel, while most of the drivers are implemented in
the user space.
HongMeng Kernel now contains the following kernel drivers:
• GIC driver: It provides the abstraction of the GIC interrupt controller:
– It gets the version of the GIC device from device tree, and initializes it accordingly.
– It provides the interfaces to operate on the GIC device: such as masking/unmasking the specific
interrupts, setting the priorities of the interrupts, reading the interrupt number, etc.
The kernel reads the interrupt request number from the GIC driver and then delivers it to the
appropriate hander to process it.
• Timer driver: It initializes the hardware timer on the platform which periodically triggers timer
interrupt. The timer interrupt is used for scheduling in TOE.
1.4.1.6 Capability System
The capability system implements the capability-based security mechanism to provide the basic access
control for the resources. It protects the resources owned by one process from being modified or tampered
with by other processes. The resources are represented as the kernel objects in HongMeng Kernel. To
operate on the kernel object, one process should be authorized with the corresponding permission first. In
addition to isolation, the capability system also allows to share the resources among processes by permitting
one process to grant the authorization to other processes with restricted rights.
Capability Rules A capability is an unforgeable token that points to a specific kernel object, and carries
access rights that control which methods can be called on object. Capabilities exist in the space of the
corresponding process, and the process can use a reference pointing to a certain capability to request the
kernel object. In general terms, the operating rules of capability are listed as follows:
• All kernel objects have corresponding capabilities.
• To perform an operation on an object, a process must hold a capability in its possession that has
sufficient access rights for the requested services.
• The kernel shall not reject any capability service invocation from a legitimate owner of this capability,
and guarantees that the requested service will be fulfilled.
Capability of Process The storage of capabilities of a process is separated from other processes, and other
processes cannot modify or tamper with it without an explicit authorization.
The initial capabilities are given to a process when it is created. Afterwards, only the process can create
capabilities for itself. When a capability is created, a corresponding kernel object is created at the same time.
A process can give its own capability to other processes and it can revoke the authorization at any time.
Support for Other Modules Capability mechanism gives the support for the security of other modules:
• Memory management: A page table is a kernel object owned by the individual process and only the
owner has the authorization at the beginning. It cannot be modified without awareness of the owner,
so the address space cannot be damaged by a malicious process.
• IPC: The channel used for communication is a kernel object. Only the processes which have the
capability to read from (or write to) the channel can receive messages from (or send to) the channel.
So the contents of the messages cannot be accessed by a malicious process.
5
1. SECURITY TARGET INTRODUCTION
1.4.2 TOE Operational Environment
Hardware is the physical part of operational environment of the TOE. In general, hardware includes CPUs,
RAM and NVM. The physical part also comprises the boot loader that is used to load the TOE on the
hardware, and transfers its control authority from the TOE afterwards.
In a mobile operating system (e.g., TEE), the TOE may share the hardware resource with REE OS (e.g.,
Android). In such case, the TOE is an isolated system that runs in parallel with the user-facing operating
system. Trusted Applications (TAs) based on the TOE are isolated to the ones in REE OS, while the
communication may still be possible.
1.4.3 TOE Physical Boundary
The TOE is a software product. In Figure 1, each component within the red block is within the TOE physical
boundary, and each component outside the red block is outside of the TOE physical boundary. Therefore,
hardware and firmware/bootloader do not belong to the TOE.
The TOE also includes guidance documents. Table 1 shows the physical scope of the TOE.
Type Delivery Item Version
Software Product Name: HongMeng
Format: Binary.
Info:
User can login the Configuration Management
Cloud (CMC) to download the software binary
archive in accordance to the version of the TOE.
User can verify the software by digital signature.
The digital signature is also published on the
CMC website.
Internal Version Number:
V100R006C00SPC020B030
Product
Guidance
Huawei HongMeng Kernel Common Criteria E-
valuation AGD OPE: Operational User Guidance
[OPE]
Format: PDF.
Info:
The document is delivered on CMC website in
accordance to the version of the TOE.
2.0
Huawei HongMeng Kernel Common Criteria
Evaluation AGD PRE: Preparative Procedures
[PRE]
Format: PDF.
Info:
The document is delivered on CMC website in
accordance to the version of the TOE.
2.0
Table 1: Physical Scope
1.4.4 TOE Logical Boundary
The TOE provides following security services.
• User identification and TSF protection
All processes have to be identified before performing any TSF-mediated activity. Meanwhile, the TOE
preserves a secure state when the TOE panic occurs.
• Capability-based access control
6
1. SECURITY TARGET INTRODUCTION
In the TOE, each kernel object is associated with a capability. To access a kernel object, a process
should show the capability associated with the specific rights of the kernel object explicitly.
• Information flow control and residual information removal
Only authorized processes can exchange information via IPC. In addition, any residual information in
message related structures will be filled with zero before use.
• Memory management
The TOE exploits memory management to achieve fine-grained access control for physical memory
and virtual memory.
• Thread management
By means of kenrel scheduling and Futex functionalities, that ensure that only processes with a
highest priority are allowed to use the resources.
• Safe and secure state preservation
The TSF supports reaching and keeping a safe and secure state of the TOE. After the TOE has been
successfully initialized, the global configuration is correct and matches the hardware conditions.
The TSF ensures also that the TOE is not compromised in the event of a failure during operation by
means of logical checks on key paths of the code.
• Platform attestation
The TOE provides the means to uniquely identify the underlying platforms.
1.4.5 Reference Device Life Cycle
The device life cycle outlined here is an overall life cycle from which implementations cannot deviate
according to development, manufacturing and assembly processes. The life cycle is split into following
phases:
• Phase 1 corresponds to the design of software TOE.
• Phase 2 corresponds to the overall design of the software, firmware and hardware platform supporting
the TOE.
• Phase 3 covers software preparation (linking the TOE and other software in user space).
• Phase 4 consists of device assembling. It includes any initialization and configuration step necessary
to bring the device to a secure state prior to delivery to the end-user.
• Phase 5 stands for the end-usage of the device.
Table 2 shows the whole life cycle of the TOE device.
The phase related to the TOE during the whole device life cycle is as below:
Phase 1 Software design: Including the TOE software design and development, and delivering source code
of the TOE to system integrator.
The other phases are out of scope of this ST.
7
1. SECURITY TARGET INTRODUCTION
Phase Actors
1 & 2: Firmware/
Software/Hardware
Design
The TOE developer:
1. is in charge of the TOE software development and testing.
2. does not develop the trusted firmware that instantiates/initializes the
the TOE (e.g. part of the secure boot code). It is developed by hard-
ware/firmware team and not included in this document.
3. specifies the TOE software linking requirements.
The TEE software designer (not the TOE developer) is in charge of TEE
software development and testing compliant with GlobalPlatform specification,
which is not the scope of the TOE developer’s responsibilities.
The device manufacturer (not the TOE developer) may design additional REE
software that will be linked with the TEE in Phase 4 to provide REE controlled
resources. Both the device manufacturer (not the TOE developer) and TEE
software designer (not the TOE developer) may design Trusted Applications
that they will integrate in Phase 4.
The TEE hardware designer is in charge of designing (part of) the processor(s)
where the TEE software runs on and designing (part of) the hardware security
resources used by the TEE.
The silicon vendor designs the NVM and the secure portion of the TEE chipset.
If the silicon vendor is not designing the full TEE hardware, the silicon vendor
integrates (and potentially augments) the TEE hardware designed by the TEE
hardware designer(s).
3: System Integrator The system integrator is responsible for the integration, validation and prepa-
ration of the software to load in the product that will include the TOE, any
pre-installed application, and additional software required to use the product
(e.g. REE, Client Applications).
4: Device Manufac-
turing
The device manufacturer is responsible for the device assembling and initial-
ization, and any other operation on the device (including loading or installation
of applications) before delivery to the end user.
5: End-usage Phase The end-user obtains a device ready for use.
Table 2: Actors in Device Life Cycle
8
2. CONFORMANCE CLAIMS
2 Conformance Claims
2.1 CC Conformance Claim
This Security Target conforms to CC Part 2 extended and Part 3 conformant, with a claimed Evaluation
Assurance Level of EAL 6, augmented by ALC FLR.1.
This Security Target claims conformance to the following specifications:
• Common Criteria for Information Technology Security Evaluation Part 2: Security Functional
Requirements, Version 3.1, Revision 5, April 2017.
• Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance
Requirements, Version 3.1, Revision 5, April 2017; augmented by ALC FLR.1.
2.2 PP Claim
This Security Target does not claim conformance to any PP.
9
3. SECURITY PROBLEM DEFINITION
3 Security Problem Definition
HongMeng Kernel is designed to enforce access control policy for all subjects (processes) running on top of
it and to enforce that all subjects use the available resources under control of HongMeng Kernel.
Thus security problems here can be described, based on different type of assets, by how a certain kind of
information might leak which breaks confidentiality, and how the processing resources is monopolized by a
process.
In this section, we first categorise the assets from subject’s (process’s) perspective and then address all the
potential ways a malformed application might threaten confidentiality and availability for each particular
asset.
3.1 Assets
Assets are categorised as user data, TSF data and processing resources. User data comprises
AS.PROC.DATA, AS.PROC.REG and AS.PROC.CODE. TSF data comprises AS.TSF.DATA and
AS.TSF.CODE.
AS.PROC.DATA
The private data of an individual process, including the heap, the stack and the shared memory.
AS.PROC.REG
The registers of a process are stored in CPU while the process is running.
AS.PROC.CODE
The code of a process.
AS.TSF.DATA
The data managed by the TSF, including the kernel objects used by kernel modules, such as IPC, scheduler,
kernel driver, Futex, etc.
AS.TSF.CODE
The code of TSF, including the code performing the system call and enforcing the security policy.
The underlying platform is protected from the user space perspective by means of the TSF and is grouped in
the asset defined below:
AS.RESOURCE.PHYSICAL
The processing resources of the platform managed by the kernel by means of the TSF with AS.TSF.DATA
(priority).
3.2 Users/Subjects
S.PROC
The users/subjects are the processes in the user space.
3.3 Threats
This section of the security problem definition shows the threats that are to be countered by the TOE, its
operational environment, or a combination of the two.
We assume that an attacker is a threat agent (a person or a process acting on his/her behalf) trying to
undermine the TOE security policy defined by the current ST and, hence, the TSF.
10
3. SECURITY PROBLEM DEFINITION
We also assume that an attacker will only carry out software attacks and attacks from other sources than
software shall be averted by the TOE operational environment or by an organisational security policy.
T.UNAUTHORIZED ACCESS
An attacker is able to read or modify user data and/or TSF data whose access is not authorized to the subject.
T.QUEUE SKIPPING
An attacker attempts to continuously execute threads using all the processing resources bypassing the
scheduler, thus preventing other threads in the queue to be executed.
3.4 Organizational Security Policies
This section presents the organizational security policies that have to be implemented by the TOE and/or its
operational environment.
OSP.SYSTEM INTEGRATOR
1. The system integrator shall verify hardware from Huawei Kirin 9000 SoC.
2. The system integrator shall ensure that the environment (either software, hardware, the OSP for the
product in field, or by a mix of these) ensures following properties:
(a) The bootloader shall initialize the hardware so the TOE starts in a safe and secure state.
(b) The integrity of the product binary image is ensured when the TOE is loaded and starts running.
3. The system integrator shall correctly perform the integration process according to the TOE guidance
[PRE].
4. The system integrator shall install the integrated product binary image on the hardware.
OSP.SAFE SECURE STATE
The TOE shall reach a safe and secure state after the bootloader has successfully verified the integrity of the
TOE, initialized the hardware required by the TOE, performed the hand-over to the TOE and after the TOE
is successfully initialized.
3.5 Assumptions
This section states the assumptions that hold on the TOE operational environment. These assumptions have
to be satisfied by the operational environment.
A.TRUSTWORTHY PERSONNEL
The personnel configuring, integrating and installing the TOE (system integrator) are trustworthy. In
particular, the system integrator should ensure following properties:
• The system integrator shall correctly perform the integration process according to the TOE guidance
[PRE]. operational policy (and, if necessary, according to the hardware manuals).
• The system integrator shall install the integrated product binary image on the hardware.
A.ENVIRONMENT
The environment (either software, hardware, or by a mix of both) should ensure following properties:
• The bootloader shall initialize the hardware so the TOE starts in a safe and secure state.
• The memory managed by the TOE, and the Kirin 9000 SoC required by the TOE shall be protected in
confidentiality and integrity from the outside of the TOE.
11
3. SECURITY PROBLEM DEFINITION
• The bootloader and ARM Trusted Firmware shall be protected in integrity from the outside of the
TOE.
• The ADC controller interfaces shall not be exposed to the software components.
• The cache shall be flushed before and after each relevant operation using the TOE’s features.
• The TRR mechanism shall be enabled to protect the DDR.
• The power domain of TEE shall be isolated from the REE side.
• The power consumption metrics and processor frequency scaling shall not be exposed to the software
components.
A.TRUSTED PROCESS
It is assumed that only trusted processes will be allowed to directly use TOE services and data. Specifically,
only those processes bound to the TOE before its operational use are assumed to be trusted.
Note: The trusted processes will be those which conform the whole OS as part of the kernel components in
the user space, and which will be configured during the integration phase before the TOE is in the final user
phase.
12
4. SECURITY OBJECTIVES
4 Security Objectives
4.1 Security Objectives for the TOE
This section states the security objectives for the TOE. The following objectives must be satisfied by the
TOE:
O.CONFIDENTIALITY
The TOE shall preserve confidentiality of assets with a confidentiality need.
O.ACCESS CONTROL
The TOE shall grant read and/or write permissions to assets only to authorised users. Specifically, only the
owner and processes granted to read or modify data , and only those processes which establish an IPC buffer
to exchange messages shall be allowed access user data and/or TSF data.
O.SAFE SECURE STATE
The TOE shall preserve a secure state when a failure occurs.
O.PRIORITY
The TOE shall define a priority based scheduling for the threads. In particular, only scheduled threads in the
queue with the highest priority can use resources of the system.
O.ATTESTATION
The TOE shall uniquely identify the underlying platforms. In particular, the underlying platforms are
Huawei Kirin 9000 SoC.
4.2 Security Objectives for the Operational Environment
This section states the security objectives for the TOE operational environment covering all the assumptions
and the organizational security policies that apply to the environment. The following security objectives
apply to any TOE operational environment that does not implement any additional security feature.
OE.TRUSTWORTHY PERSONNEL
The personnel (especially, the system integrator) configuring, integrating and installing the TOE are
trustworthy.
OE.ENVIRONMENT
The environment ensures the following properties:
• The bootloader initializes the hardware so the TOE starts in a safe and secure state.
• The memory managed by the TOE, and the Kirin 9000 SoC required by the TOE are protected in
confidentiality and integrity from the outside of the TOE.
• The bootloader and ARM Trusted Firmware are protected in integrity from the outside of the TOE.
• The ADC controller interfaces are not exposed to the software components.
• The cache is flushed before and after each relevant operation operation using the TOE’s features.
• The TRR mechanism is enabled to protect the DDR.
• The power domain of TEE is isolated from the REE side.
• The power consumption metrics and processor frequency scaling are not exposed to the software
components.
13
4. SECURITY OBJECTIVES
O.CONFIDENTIALITY
O.ACCESS
CONTROL
O.PRIORITY
O.SAFE
SECURE
STATE
O.ATTESTATION
OE.TRUSTWORTHY
PERSONNEL
OE.ENVIRONMENT
OE.TRUSTED
PROCESS
T.UNAUTHORIZED ACCESS
√ √ √ √ √
T.QUEUE SKIPPING
√ √ √ √
OSP.SYSTEM INTEGRATOR
√ √ √
OSP.SAFE SECURE STATE
√
A.TRUSTWORTHY PERSONNEL
√
A.ENVIRONMENT
√
A.TRUSTED PROCESS
√
Table 3: Security Objectives Rationale
OE.TRUSTED PROCESS
The key processes that are running on the TOE shall be providing necessary user space services correctly
and ensure their own integrity while running.
4.3 Security Objectives Rationale
Table 3 provides mappings between TOE Security Problem Definition (SPD) and Security Objectives.
4.3.1 Security Objectives Rationale: Threats
4.3.1.1 Threat: T.UNAUTHORIZED ACCESS
O.CONFIDENTIALITY prevents the disclosure of user data during normal operation of the TOE.
O.ACCESS CONTROL prevents the unauthorized access to user data and/or TSF data during normal
operation of the TOE, and O.SAFE SECURE STATE prevents the unauthorized access to data when the
TOE is in the failure state.
In addition, OE.TRUSTWORTHY PERSONNEL and OE.ENVIRONMENT ensure that the TOE is
configured and used in a secure state.
4.3.1.2 Threat: T.QUEUE SKIPPING
O.PRIORITY ensures that all processes using the TOE are executed based on a priority based queue, and
O.SAFE SECURE STATE prevents the execution of processes out of the queue when the TOE is in the
failure state.
In addition, OE.TRUSTWORTHY PERSONNEL and OE.ENVIRONMENT ensure that the TOE is
configured and used in a secure state.
14
4. SECURITY OBJECTIVES
4.3.2 Security Objectives Rationale: Organizational Security Policies (OSPs)
4.3.2.1 OSP: OSP.SYSTEM INTEGRATOR
The objective OE.TRUSTWORTHY PERSONNEL and OE.ENVIRONMENT directly enforce this OSP.
The objective O.ATTESTATION supports the enforcement of this OSP by providing a means to identify the
underlying platform.
4.3.2.2 OSP: OSP.SAFE SECURE STATE
The objective O.SAFE SECURE STATE directly enforces this OSP.
4.3.3 Security Objectives Rationale: Assumptions
4.3.3.1 Assumption: A.TRUSTWORTHY PERSONNEL
The assumption A.TRUSTWORTHY PERSONNEL is upheld by OE.TRUSTWORTHY PERSONNEL
directly.
4.3.3.2 Assumption: A.ENVIRONMENT
The assumption A.ENVIRONMENT is upheld by OE.ENVIRONMENT.
4.3.3.3 Assumption: A.TRUSTED PROCESS
The assumption A.TRUSTED PROCESS is upheld by OE.TRUSTED PROCESS.
15
5. EXTENDED COMPONENTS DEFINITION
5 Extended Components Definition
5.1 Definition of Family FAU SAS
To define the security functional requirements of the TOE an additional family (FAU SAS) of the Class FAU
(Security Audit) is defined here. This family describes the functional requirements for the storage of audit
data. It has a more general approach than FAU GEN, because it does not necessarily require the data to be
generated by the TOE itself and because it does not give specific details of the content of the audit records.
The family “Audit data storage (FAU SAS)” is specified as follows.
5.1.1 FAU SAS Audit data storage
Family behaviour
This family defines functional requirements for the storage of audit data.
Component levelling
Figure 2: FAU SAS
FAU SAS.1 Requires the TOE to provide the possibility to store audit data.
Management: FAU SAS.1
There are no management activities foreseen.
Audit: FAU SAS.1
There are no actions defined to be auditable.
5.1.1.1 FAU SAS.1 Audit Storage
Hierarchical to: No other components.
Dependencies: No other components.
FAU SAS.1.1 The TSF shall provide the capability to identify [assignment: list of subjects] and
store [assignment: list of audit information] in the [assignment: type of kernel
object].
16
6. SECURITY REQUIREMENTS
6 Security Requirements
6.1 Introduction
6.1.1 Conventions
The CC allows following operations to be performed on security requirements on the security component
level [CC2]:
• Assignment: The assignment operation is used to set the unspecified parameter with a specified value,
for example, the list of actions. The assignments having been made by the ST author are italicized text.
• Selection: The selection operation is used to select one or more items in a given component. The
selections having been made by the ST author are underlined text.
• Refinement: The refinement operation is used to present more details in security requirement, in order
to restrict the requirement or satisfy editorial reasons. The refinements having been made by the ST
author are bold text.
• Iteration: The iteration operation is used to describe multiple requirements based on the same
component. The iterations are identified by a suffix with slash added to the security requirement.
Other conventions used in descriptions of SFRs are as follows:
• Application Notes: Notes added by the ST author are called “Application Note” which are enumerated
as “a”, “b”, ... and are formatted with underline such as “Application Note a: AppNote Description”.
• References: Indicated with [square brackets].
6.1.2 Definitions
The security functional components [CC2] used in this Security Target are shown in the following table.
Security Functional Components Component Identification
FIA ATD.1 User attribute definition
FIA UID.2 User identification before any action
FIA USB.1 User-subject binding
FMT SMR.1 Security roles
FDP ACC.1/CAP Subset access control (for Capability)
FDP ACC.1/MEM Subset access control (for Memory)
FDP ACF.1/CAP Security attribute based access control (for Capability)
FDP ACF.1/MEM Security attribute based access control (for Memory)
FDP IFC.1/ACTV Complete information flow control (for Activation)
FDP IFC.1/CHNL Complete information flow control (for Channel)
FDP IFF.1/ACTV Simple security attributes (for Activation)
FDP IFF.1/CHNL Simple security attributes (for Channel)
FDP RIP.1 Subset residual information protection
FMT MSA.1/ACTV Management of security attributes (for Activation)
FMT MSA.1/CHNL Management of security attributes (for Channel)
FMT MSA.1/CAP Management of security attributes (for Capability)
17
6. SECURITY REQUIREMENTS
Security Functional Components Component Identification
FMT MSA.1/MEM Management of security attributes (for Memory)
FMT MSA.3/ACTV Static attribute initialization (for Activation)
FMT MSA.3/CHNL Static attribute initialization (for Channel)
FMT MSA.3/CAP Static attribute initialization (for Capability)
FMT MSA.3/MEM Static attribute initialization (for Memory)
FMT SMF.1/ACTV Management functions (for Activation)
FMT SMF.1/CHNL Management functions (for Channel)
FMT SMF.1/CAP Management functions (for Capability)
FMT SMF.1/MEM Management functions (for Memory)
FPT FLS.1 Failure with preservation of secure state
FRU PRS.1 Limited prioritized CPU time
FAU SAS.1 Audit storage
Table 4: Security Functional Components
The statement of the security functional requirements relies on the following characterization of the TOE in
terms of users, subjects, objects, information, user data, TSF data, operations and their security attributes (cf.
CC Part 1 [CC1] for the definition of these notions).
Users and subjects stand for entities outside the TOE, which refers to any process in the user space, denoted
as S.PROC.
Objects stand for kernel objects inside the TOE:
• OB.CNODE: The collection of the capabilities that a process owns, where each capability is
associated with a kernel object.
• OB.THREAD: Information set of a thread, such as priority, affinity, state, etc.
• OB.CHANNEL: The message channel for asynchronous communication containing the message itself
and information about the sender etc. A process may send a message to a specific channel, and
another process may receive the message from the particular channel.
• OB.ACTIVATION: A collection of execution resource: kernel execution context (register file), user
stack, process metadata.
• OB.ACTIVATIONPOOL: A RPC server has a set of activations to provide services and
OB.ACTIVATIONPOOL is used to manage these activations.
• OB.VSPACE: Address space of a user process.
• OB.PAGE: The attributes of a segment of physical memory, for example, the base physical address,
memory type, reference count, etc.
• OB.SYSCTRL: Kernel object containing system information to provide system control functions to the
user.
• OB.IRQCTRL: Kernel object containing interrupt configuration to provide system interrupt control
functions to the user.
Information stands for data exchanged between subjects:
• I.MSG: the message sent by the subjects through inter process communication mechanism.
18
6. SECURITY REQUIREMENTS
TSF data consists of runtime TSF data and TSF persistent data necessary to provide the security services. It
includes all the security attributes of users, subjects, objects and information.
The security attributes are defined as follows:
• ATTR.PROC.ID ::= PID: The PID of the process.
• ATTR.OB.OWNER ::= PID: Represents the process which the kernel object belongs to.
• ATTR.OB.SVISITOR ::= {PID}: Represents a set of processes which have the supervised access to the
kernel object.
• ATTR.OB.PERM: Maps from processes to the rights. The rights represent the functions that a process
can invoke.
• ATTR.PAGE.TYPE ::= one of {VOID, USER, IOMEM, PGTABLE, KOBJ, BOOTDATA}: Represents
the type of a physical memory region.
VOID means a fake physical memory region without memory in backend.
USER means a physical memory used for userspace map.
IOMEM means a physical memory used for IO map.
PGTABLE means a physical memory used to store data of page table.
KOBJ means a physical memory used for kernel object.
BOOTDATA means a physical memory used for kernel startup.
The authorized security roles for each kernel object are defined as follows:
• R.OWNER: The owner of a kernel object, the one who creates it. It can grant the corresponding kernel
object with the specific permissions to other processes, or delete it.
• R.VISITOR: The visitor of a kernel object. The ability to access that kernel object is granted from the
owner. It cannot modify the security attributes or delete the kernel object. The authorization can be
revoked at anytime by the owner.
• R.SVISITOR: The supervised visitor of a kernel object. The ability to access that kernel object is
gained by possessing the supervised access right to the OB.CNODE of that kernel object. It has the
same privilege of R.OWNER of that kernel object, includes granting the kernel object to a R.VISITOR,
but does not own it.
The operations on kernel objects are defined as follows:
• OP.GRANT: The owner and the supervised visitor of a kernel object grants the ability to access that
kernel object to the visitor.
• OP.REVOKE: The owner and the supervised visitor of a kernel object cancels the authorization of the
kernel object from the visitor.
• OP.REJECT: The visitor of a kernel object gives up the authorization to access that kernel object.
• OP.NEWCAP: A new capability with a specified right is created with the associated kernel object.
The operations of the IPC are defined below:
• Activation:
– OP.CALL: A message is delivered from one subject to another if the caller subject has access to
an OB.ACTIVATION.
– OP.REPLY: A message is delivered from one subject to another if the replier has access to an
OB.ACTIVATION.
19
6. SECURITY REQUIREMENTS
• Channel:
– OP.SEND: A message is delivered to an OB.CHANNEL.
– OP.RECEIVE: A message is grabbed from an OB.CHANNEL.
The operations about the memory are defined below:
• OB.VSPACE:
– OP.MAP: The operation to establish the mapping from the specific virtual addresses to specific
physical addresses of an OB.PAGE in an OB.VSPACE.
– OP.UNMAP: The operation to erase a mapping in an OB.VSPACE on the specific virtual
addresses.
– OP.FLUSH: The operation to flush cahe of specific virtual address range in an OB.VSPACE.
– OP.SHRINK: The operation to reclaim physical memory of page table for specific virtual address
range in an OB.VSPACE.
– OP.MPROTECT: The operation to change map protection of specific virtual address range in an
OB.VSPACE.
• OB.PAGE:
– OP.PG TRANS: The operation to transact the ATTR.PAGE.TYPE of OB.PAGE from one to
another.
The rights on operations are defined as follows:
• P.SEND: Right necessary for S.PROC to invoke OP.SEND.
• P.RECEIVE: Right necessary for S.PROC to invoke OP.RECEIVE.
• P.MAP: Right necessary for S.PROC to invoke OP.MAP.
• P.UNMAP: Right necessary for S.PROC to invoke OP.UNMAP.
• P.FLUSH: Right necessary for S.PROC to invoke OP.FLUSH.
• P.SHRINK: Right necessary for S.PROC to invoke OP.SHRINK.
• P.MPROTECT: Right necessary for S.PROC to invoke OP.MPROTECT.
6.1.3 Security Function Policies
This ST defines the following access control and information flow Security Function Policies (SFPs):
Activation IPC Information Flow Control SFP (SFP.ACTV):
1. Purpose: To control the flow of the message from and to processes using OB.ACTIVATION. This
policy contributes to ensuring the confidentiality of communication messages (I.MSG).
2. Subjects: User processes.
3. Information: I.MSG.
4. Security attributes: The specific sender processes and the receiver processes.
5. SFR instances: FDP IFC.1/ACTV, FDP IFF.1/ACTV.
Channel IPC Information Flow Control SFP (SFP.CHNL):
20
6. SECURITY REQUIREMENTS
1. Purpose: To control the flow of the message from and to processes using OB.CHANNEL. This policy
contributes to ensuring the confidentiality of communication messages (I.MSG).
2. Subjects: User processes.
3. Information: I.MSG.
4. Security attributes: The specific sender processes and the receiver processes.
5. SFR instances: FDP IFC.1/CHNL, FDP IFC.1/CHNL.
Capability-based Access Control SFP (SFP.CAP):
1. Purpose: To control the access to kernel objects.
2. Subjects: User processes.
3. Objects: Kernel objects.
4. Security attributes: The capabilities corresponding to the kernel objects.
5. SFR instances: FDP ACC.1/CAP, FDP ACF.1/CAP.
Memory Access Control SFP (SFP.MEM):
1. Purpose: To control the access to virtual memory spaces and physical memory.
2. Subjects: User processes.
3. Objects: Memory resources through OB.PAGE and OB.VSPACE.
4. Security attributes: The access right to certain virtual memory range and physical memory.
5. SFR instances: FDP ACC.1/MEM, FDP ACF.1/MEM.
6.2 TOE Security Functional Requirements
This chapter provides the set of Security Functional Requirements (SFRs) the TOE has to enforce in order to
fulfill the security objectives.
6.2.1 User Identification and TSF Protection
6.2.1.1 FIA ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA ATD.1.1 The TSF shall maintain the following list of security attributes belonging
to individual users: [assignment: ATTR.PROC.ID, ATTR.OB.OWNER, AT-
TR.OB.SVISITOR, ATTR.OB.PERM].
6.2.1.2 FIA UID.2 User identification before any action
Hierarchical to: FIA UID.1 Timing of identification.
Dependencies: No dependencies.
FIA UID.2.1 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
21
6. SECURITY REQUIREMENTS
6.2.1.3 FIA USB.1 User-subject binding
Hierarchical to: No other components.
Dependencies: FIA ATD.1 User attribute definition.
FIA USB.1.1 The TSF shall associate the following user security attributes with subjects acting
on the behalf of that user: [assignment: ATTR.PROC.ID, ATTR.OB.OWNER,
ATTR.OB.SVISITOR, ATTR.OB.PERM].
FIA USB.1.2 The TSF shall enforce the following rules on the initial association of user
security attributes with subjects acting on the behalf of users: [assignment:
• Each process is associated with a unique identifier ATTR.PROC.ID;
• Each process is associated with an initial OB.THREAD, an OB.CNODE
and several OB.PAGEs. The process is the owner of these kernel objects
and has entire permissions.
].
FIA USB.1.3 The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users: [assignment:
• The process identifier ATTR.PROC.ID cannot be modified;
• The owner of the kernel object ATTR.OB.OWNER cannot be modified;
• Only the owner of the kernel object can modify the permission AT-
TR.OB.PERM.
].
6.2.1.4 FPT FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur:
[assignment: Inconsistent state caused by transient failures during initialization
and runtime].
6.2.1.5 FMT SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA UID.1 Timing of identification.
FMT SMR.1.1 The TSF shall maintain the roles [assignment: R.OWNER, R.VISITOR,
R.SVISITOR].
22
6. SECURITY REQUIREMENTS
FMT SMR.1.2 The TSF shall be able to associate users with roles.
Application Note: The security roles maintained by the TSF are used for the
following purposes associated to each SFP:
• SFP.CAP: Implementation of proper management of capability access.
• SFP.ACTV: Limitation of the call functionality to the callers, and limitation
of the serving functionality to the servers.
• SFP.CHNL: Limitation of the notify functionality to the senders, and
limitation of the receiving functionality to the receivers.
• SFP.MEM: Access limitation to given a physical memory region.
6.2.2 Capability-based Access Control
6.2.2.1 FDP ACC.1/CAP Subset access control
Hierarchical to: No other components.
Dependencies: FDP ACF.1/CAP Security attribute based access control.
FDP ACC.1.1 The TSF shall enforce the [assignment: SFP.CAP] on [assignment:
• Subjects: S.PROC
• Objects: kernel objects
• Operations: OP.NEWCAP, OP.GRANT, OP.REVOKE, OP.REJECT
].
6.2.2.2 FDP ACF.1/CAP Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP ACC.1/CAP Subset access control
FMT MSA.3/CAP Static attribute initialisation.
FDP ACF.1.1 The TSF shall enforce the [assignment: SFP.CAP] to objects based on the
following: [assignment:
• Subjects: S.PROC
• Objects: kernel objects
• Security attributes: ATTR.OB.OWNER, ATTR.OB.PERM, AT-
TR.OB.SVISITOR
].
23
6. SECURITY REQUIREMENTS
FDP ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [assignment:
• The owner and the supervised visitor of the kernel object can OP.GRANT
it to other processes.
• The owner and the supervised visitor of the kernel object can OP.REVOKE
the authorization from the visitor.
• The visitor can OP.REJECT the authorization of the kernel object.
• A process can create a new kernel object (OP.NEWCAP).
].
FDP ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [assignment: None].
FDP ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [assignment: None].
6.2.2.3 FMT MSA.1/CAP Management of security attributes
Hierarchical to: No other components.
Dependencies: FDP IFC.1/CAP Subset information flow control
FMT SMR.1 Security roles
FMT SMF.1/CAP Specification of management functions.
FMT MSA.1.1/CAP-1 The TSF shall enforce the [assignment: SFP.CAP] to restrict the ability to [selec-
tion: modify] the security attributes [assignment: ATTR.OB.PERM of the spec-
ified kernel object] to [assignment: R.OWNER, R.SVISITOR] by OP.GRANT,
OP.REVOKE.
FMT MSA.1.1/CAP-2 The TSF shall enforce the [assignment: SFP.CAP] to restrict the ability to
[selection: modify] the security attributes [assignment: ATTR.OB.PERM of the
specified kernel object] to [assignment: R.VISITOR] by OP.REJECT.
6.2.2.4 FMT MSA.3/CAP Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT MSA.1/CAP Management of security attributes
FMT SMR.1 Security roles.
FMT MSA.3.1 The TSF shall enforce the [assignment: SFP.CAP] to provide [selection, choose
one of: restrictive] default values for security attributes that are used to enforce
the SFP.
FMT MSA.3.2 The TSF shall allow the [assignment: R.OWNER, R.SVISITOR] to specify alter-
native initial values to override the default values when an object or information
is created.
24
6. SECURITY REQUIREMENTS
6.2.2.5 FMT SMF.1/CAP Specification of management functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT SMF.1.1 The TSF shall be capable of performing the following management functions:
[assignment: OP.NEWCAP, OP.GRANT, OP.REVOKE, OP.REJECT].
6.2.3 Information Flow Control and Residual Information Removal
6.2.3.1 FDP IFC.1/ACTV Subset information flow control
Hierarchical to: No other components.
Dependencies: FDP IFF.1/ACTV Simple security attributes.
FDP IFC.1.1 The TSF shall enforce the [assignment: SFP.ACTV] on [assignment:
• Subject: S.PROC
• Objects: OB.ACTIVATION
• Operations: OP.CALL and OP.REPLY
].
6.2.3.2 FDP IFF.1/ACTV Simple security attributes
Hierarchical to: No other components.
Dependencies: FDP IFC.1/ACTV Subset information flow control
FMT MSA.3/ACTV Static attribute initialisation.
FDP IFF.1.1 The TSF shall enforce the [assignment: SFP.ACTV] based on the following types
of subject and information security attributes: [assignment:
• The subjects S.PROC and OB.ACTIVATION with security attributes AT-
TR.OB.OWNER and ATTR.OB.SVISITOR.
].
FDP IFF.1.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[assignment:
• OP.CALL operation delivers message from one subject to another iff the
caller subject has access to an OB.ACTIVATION, and the recipient acts
as the R.OWNER or R.SVISITOR of the specified OB.ACTIVATION.
• OP.REPLY operation delivers message from one subject to another iff
the replier subject has access to an OB.ACTIVATION and acts as the
R.OWNER or R.SVISITOR of it, and the recipient holds the access to a
related OB.ACTIVATION.
].
25
6. SECURITY REQUIREMENTS
FDP IFF.1.3 The TSF shall enforce the [assignment: None].
FDP IFF.1.4 The TSF shall explicitly authorise an information flow based on the following
rules: [assignment: None].
FDP IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules:
[assignment:
• If the message length exceeds the length threshold, the OP.CALL operation
will be denied.
• If a subject calls OP.REPLY, which acts as the R.OWNER or the
R.SVISITOR of an OB.ACTIVATION object, while the caller subject as-
sociated with this OB.ACTIVATION object is not waiting for a reply, the
OP.REPLY operation will be denied.
].
6.2.3.3 FMT MSA.1/ACTV Management of security attributes
Hierarchical to: No other components.
Dependencies: FDP IFC.1/ACTV Subset information flow control
FMT SMR.1 Security roles
FMT SMF.1/ACTV Specification of management functions.
FMT MSA.1.1/ACTV-1 The TSF shall enforce the [assignment: SFP.ACTV] to restrict the ability to
[selection: modify] the security attributes [assignment: ATTR.OB.PERM of
OB.ACTIVATION] to [assignment: R.OWNER, R.SVISITOR] by OP.GRANT,
OP.REVOKE.
FMT MSA.1.1/ACTV-2 The TSF shall enforce the [assignment: SFP.ACTV] to restrict the ability to
[selection: modify] the security attributes [assignment: ATTR.OB.PERM of
OB.ACTIVATION] to [assignment: R.VISITOR] by OP.REJECT.
FMT MSA.1.1/ACTV-3 The TSF shall enforce the [assignment: SFP.ACTV] to restrict the ability to
[selection: modify] the security attributes [assignment: ATTR.OB.PERM of
OB.ACTIVATION] to [assignment: None].
6.2.3.4 FMT MSA.3/ACTV Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT MSA.1/ACTV Management of security attributes
FMT SMR.1 Security roles.
FMT MSA.3.1 The TSF shall enforce the [assignment: SFP.ACTV] to provide [selection, choose
one of: restrictive] default values for security attributes that are used to enforce
the SFP.
FMT MSA.3.2 The TSF shall allow the [assignment: R.OWNER, R.SVISITOR] to specify alter-
native initial values to override the default values when an object or information
is created.
26
6. SECURITY REQUIREMENTS
6.2.3.5 FMT SMF.1/ACTV Specification of management functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT SMF.1.1 The TSF shall be capable of performing the following management functions:
[assignment:
• Management of security attributes ATTR.OB.PERM of OB.ACTIVATION
via OP.NEWCAP, OP.GRANT, OP.REVOKE, OP.REJECT.
].
Application Note: OB.ACTIVATION cannot be created or granted by user-
s. It is only created inside the kernel when an OP.CALL is performed on
an OB.ACTIVATION, and the newly created OB.ACTIVATION has the same
R.OWNER of the OB.ACTIVATION.
6.2.3.6 FDP IFC.1/CHNL Subset information flow control
Hierarchical to: No other components.
Dependencies: FDP IFF.1/CHNL Simple security attributes.
FDP IFC.1.1 The TSF shall enforce the [assignment: SFP.CHNL] on [assignment:
• Subject: S.PROC
• Object: OB.CHANNEL
• Operations: OP.SEND message (to OB.CHANNEL) and OP.RECEIVE
message (from OB.CHANNEL).
].
Application Note: To invoke the operation OP.SEND (or OP.RECEIVE), an
S.PROC should have the P.SEND (or P.RECEIVE) right.
6.2.3.7 FDP IFF.1/CHNL Simple security attributes
Hierarchical to: No other components.
Dependencies: FDP IFC.1/CHNL Subset information flow control
FMT MSA.3/CHNL Static attribute initialisation.
FDP IFF.1.1 The TSF shall enforce the [assignment: SFP.CHNL] based on the following
types of subject and information security attributes: [assignment:
• S.PROC and OB.CHANNEL with security attribute ATTR.OB.PERM.
].
27
6. SECURITY REQUIREMENTS
FDP IFF.1.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[assignment:
• OP.SEND operation delivers message to an OB.CHANNEL if caller subject
has access to an OB.CHANNEL with the presence of P.SEND right in its
ATTR.OB.PERM and the length of message is within the allowed buffer
length.
• OP.RECEIVE operation grabs message from an OB.CHANNEL if caller
subject has access to an OB.CHANNEL with the presence of P.RECEIVE
right in its ATTR.OB.PERM.
].
FDP IFF.1.3 The TSF shall enforce the [assignment: None].
FDP IFF.1.4 The TSF shall explicitly authorise an information flow based on the following
rules: [assignment: None].
FDP IFF.1.5 The TSF shall explicitly deny an information flow based on the following rules:
[assignment: None].
6.2.3.8 FMT MSA.1/CHNL Management of security attributes
Hierarchical to: No other components.
Dependencies: FDP IFC.1/CHNL Subset information flow control
FMT SMR.1 Security roles
FMT SMF.1/CHNL Specification of management functions.
FMT MSA.1.1/CHNL-1 The TSF shall enforce the [assignment: SFP.CHNL] to restrict the ability
to [selection: modify] the security attributes [assignment: ATTR.OB.PERM
of OB.CHANNEL] to [assignment: R.OWNER, R.SVISITOR] by OP.GRANT,
OP.REVOKE.
FMT MSA.1.1/CHNL-2 The TSF shall enforce the [assignment: SFP.CHNL] to restrict the ability to
[selection: modify] the security attributes [assignment: ATTR.OB.PERM of
OB.CHANNEL] to [assignment: R.VISITOR] by OP.REJECT.
6.2.3.9 FMT MSA.3/CHNL Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT MSA.1/CHNL Management of security attributes
FMT SMR.1 Security roles.
FMT MSA.3.1 The TSF shall enforce the [assignment: SFP.CHNL] to provide [selection, choose
one of: restrictive] default values for security attributes that are used to enforce
the SFP.
FMT MSA.3.2 The TSF shall allow the [assignment: R.OWNER, R.SVISITOR] to specify alter-
native initial values to override the default values when an object or information
is created.
28
6. SECURITY REQUIREMENTS
6.2.3.10 FMT SMF.1/CHNL Specification of management functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT SMF.1.1 The TSF shall be capable of performing the following management func-
tions: [assignment: Management of security attributes ATTR.OB.PERM of
OB.CHANNEL via OP.NEWCAP, OP.GRANT, OP.REVOKE and OP.REJECT].
6.2.3.11 FDP RIP.1 Subset residual information protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP RIP.1.1 The TSF shall ensure that any previous information content of a resource
is made unavailable upon the [selection: allocation of the resource to] the
following objects: [assignment: OB.CNODE, OB.THREAD, OB.CHANNEL,
OB.ACTIVATION, OB.VSPACE, OB.PAGE, OB.SYSCTRL, OB.IRQCTRL].
6.2.4 Memory Management
6.2.4.1 FDP ACC.1/MEM Subset access control
Hierarchical to: No other components.
Dependencies: FDP ACF.1/MEM Security attribute based access control.
FDP ACC.1.1 The TSF shall enforce the [assignment: SFP.MEM] on [assignment:
• Subjects: S.PROC
• Objects: physical memory (OB.PAGE) and virtual memory address space
(OB.VSPACE)
• Operations: OP.MAP, OP.UNMAP, OP.FLUSH, OP.SHRINK,
OP.MPROTECT, OP.PG TRANS.
].
6.2.4.2 FDP ACF.1/MEM Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP ACC.1/MEM Subset access control
FMT MSA.3/MEM Static attribute initialisation.
29
6. SECURITY REQUIREMENTS
FDP ACF.1.1 The TSF shall enforce the [assignment: SFP.MEM] to objects based on the
following: [assignment:
• Subject: S.PROC with security attribute: ATTR.PROC.ID
• Object: physical memory (OB.PAGE) with security attributes: AT-
TR.PAGE.TYPE
• Object: virtual memory address space (OB.VSPACE) with security at-
tributes: ATTR.OB.SVISITOR, ATTR.OB.OWNER and ATTR.OB.PERM
].
FDP ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [assignment:
• S.PROC can OP.MAP an OB.PAGE into an OB.VSPACE iff
– the S.PROC is allowed to use the ATTR.PAGE.TYPEof the OB.PAGE
– the S.PROC has P.MAP right according to the ATTR.OB.PERM of
the OB.VSPACE.
The ATTR.PAGE.TYPE of the OB.PAGE used for page table in the opera-
tion should be PGTABLE. And the ATTR.PAGE.TYPE of the OB.PAGEs
used in the operation of one user process should be USER or IOMEM.
• S.PROC can OP.UNMAP a virtual region in an OB.VSPACE iff the
S.PROC has P.UNMAP right according to the ATTR.OB.PERM of the
OB.VSPACE.
• S.PROC can OP.FLUSH cache of a virtual region in an OB.VSPACE iff
the S.PROC has OP.FLUSH right according to the ATTR.OB.PERM of the
OB.VSPACE.
• S.PROC can OP.SHRINK physical memory of page table of a virtual
region in an OB.VSPACE iff the S.PROC has OP.SHRINK right according
to the ATTR.OB.PERM of the OB.VSPACE.
• S.PROC can OP.MPROTECT protection of a virtual region in an
OB.VSPACE iff the S.PROC has OP.MPROTECT right according to the
ATTR.OB.PERM of the OB.VSPACE.
• S.PROC can OP.PG TRANS an OB.PAGE ATTR.PAGE.TYPE of a physical
memory region iif the transaction for ATTR.PAGE.TYPE is allowed.
].
Application Note: The OP.PG TRANS is allowed only when the following
conditions are satisfied:
• The applied transacting type is correct (i.e., from USER to KOBJ or
PGTABLE);
• The reference count of the target page is 0.
FDP ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [assignment: None].
FDP ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [assignment: None].
30
6. SECURITY REQUIREMENTS
6.2.4.3 FMT MSA.1/MEM Management of security attributes
Hierarchical to: No other components.
Dependencies: FDP IFC.1/MEM Subset information flow control
FMT SMR.1 Security roles
FMT SMF.1/MEM Specification of management functions.
FMT MSA.1.1/MEM-1 The TSF shall enforce the [assignment: SFP.MEM] to restrict the ability to
[selection: modify] the security attributes [assignment: ATTR.OB.PERM of any
R.VISITOR of an OB.VSPACE] to [assignment: R.OWNER, R.SVISITOR] by
OP.GRANT, OP.REVOKE.
FMT MSA.1.1/MEM-2 The TSF shall enforce the [assignment: SFP.MEM] to restrict the ability
to [selection: clear] the security attributes [assignment: ATTR.OB.PERM of
any R.VISITOR of an OB.VSPACE] to [assignment: the R.VISITOR itself] by
OP.REJECT.
6.2.4.4 FMT MSA.3/MEM Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT MSA.1/MEM Management of security attributes
FMT SMR.1 Security roles.
FMT MSA.3.1 The TSF shall enforce the [assignment: SFP.MEM] to provide [selection:
restrictive] default values for security attributes that are used to enforce the
SFP.
FMT MSA.3.2 The TSF shall allow the [assignment:R.OWNER] to specify alternative initial
values to override the default values when an object or information is created.
Application Note: All base OB.PAGEs are created by TSF during initialization.
6.2.4.5 FMT SMF.1/MEM Specification of management functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT SMF.1.1 The TSF shall be capable of performing the following management functions:
[assignment:
• OP.GRANT: Grant virtual memory address space (OB.VSPACE).
• OP.REVOKE: Revoke virtual memory address space (OB.VSPACE).
• OP.REJECT: Reject virtual memory address space (OB.VSPACE).
].
31
6. SECURITY REQUIREMENTS
6.2.5 Thread Management
6.2.5.1 FRU PRS.1 Limited priority of service
Hierarchical to: No other components.
Dependencies: No other components.
FRU PRS.1.1 The TSF shall assign a priority to each subject in the TSF.
FRU PRS.1.2 The TSF shall ensure that each access to [assignment: CPU time] shall be
mediated on the basis of the subjects assigned priority.
6.2.6 Platform Attestation
6.2.6.1 FAU SAS.1 Audit storage
Hierarchical to: No other components.
Dependencies: No other components.
FAU SAS.1.1 The TSF shall provide the capability to identify [assignment: the underlying
platforms] and store [assignment: the platform identification data] in the [assign-
ment: OB.SYSCTRL].
Application Note: Platform attestation is the means for the system integrator to
make sure that the platform is allowed to operate with the TOE.
6.3 Security Functional Requirements Rationale
6.3.1 Security Objectives for the TOE
O.CONFIDENTIALITY The following requirements contribute to fulfill the objective:
• FDP ACC.1/CAP, FDP ACF.1/CAP, FDP ACC.1/MEM and FDP ACF.1/MEM state the access
control measures based on SFP.CAP and SFP.MEM, which establish capability-based access control
policy to kernel objects and memory-based access control policy to memory regions, respectively.
Thus keeps kernel objects and memory regions confidential and out of the reach of a third party.
• FDP IFC.1/ACTV, FDP IFF.1/ACTV, FDP IFC.1/CHNL, FDP IFF.1/CHNL, state the information
flow control policies based on SFP.ACTV and SFP.CHNL, which ensure an inter process
communication channel between the sender and the receiver, preventing a third party to read
information transmitted through the communication channel.
• FMT MSA.1/CAP, FMT MSA.3/CAP, FMT SMF.1/CAP, FMT MSA.1/MEM, FMT MSA.3/MEM,
FMT SMF.1/MEM, FMT MSA.1/ACTV, FMT MSA.3/ACTV, FMT SMF.1/ACTV,
FMT MSA.1/CHNL, FMT MSA.3/CHNL, FMT SMF.1/CHNL establish the management functions
available to users to enforce SFP.CAP, SFP.MEM, SFP.ACTV and SFP.CHNL, thus preventing
disclosure of data based on the above mentioned SFPs.
• FDP RIP.1 states resource clean up policy to prevent disclosure of data upon allocation of kernel
objects.
O.ACCESS CONTROL The following requirements contribute to fulfill the objective:
32
6. SECURITY REQUIREMENTS
• FIA ATD.1 enforces the management of the user identity and properties as security attributes, which
then become TSF data, as an input for access control functions.
• FIA UID.2 requires the identification of the user before any action, thus allowing the access and
services and data, and their processing, to authorized users only.
• FIA USB.1 enforces the association of the user identity to the active entity that acts on behalf of the
user and to check that this is a valid identity. It is the starting point to ensure that only an authorized
user accesses and processes services and data.
• FMT SMR.1 establishes roles to be used for effective access control and process isolation, used to
support management functions for SFP.CAP, SFP.MEM, SFP.ACTV and SFP.CHNL.
• FDP ACC.1/CAP, FDP ACF.1/CAP, FDP ACC.1/MEM and FDP ACF.1/MEM state the access
control measures based on SFP.CAP and SFP.MEM, which establish capability-based access control
policy to kernel objects and memory-based access control policy to memory regions, respectively.
Thus keeps kernel objects and memory regions inaccessible to unauthorized users.
• FDP IFC.1/ACTV, FDP IFF.1/ACTV, FDP IFC.1/CHNL, FDP IFF.1/CHNL, state the information
flow control policies based on SFP.ACTV and SFP.CHNL, which ensure an inter process
communication channel between the sender and the receiver, preventing an aunauthorized user to
access a communication channel.
• FMT MSA.1/CAP, FMT MSA.3/CAP, FMT SMF.1/CAP, FMT MSA.1/MEM, FMT MSA.3/MEM,
FMT SMF.1/MEM, FMT MSA.1/ACTV, FMT MSA.3/ACTV, FMT SMF.1/ACTV,
FMT MSA.1/CHNL, FMT MSA.3/CHNL, FMT SMF.1/CHNL establish the management functions
available to users to enforce SFP.CAP, SFP.MEM, SFP.ACTV and SFP.CHNL, thus preventing
unauthorized access to data, memory regions or communication channels based on the above
mentioned SFPs.
O.SAFE SECURE STATE
• FPT FLS.1 states that the TOE has to reach a secure state upon initialization or device binding failure.
O.PRIORITY
• FRU PRS.1 states that the TOE has to manage the usage of resources based on a priority-based queue.
O.ATTESTATION
• FAU SAS.1 states that the TOE has the means for the system integrator to univocally check that the
platform is allowed to be integrated with the TOE.
6.3.2 Coverage and Sufficiency
This part provides the rationale for the internal consistency and completeness of the SFRs defined in this
Security Target.
Security Objectives Security Functional Requirements
O.CONFIDENTIALITY FDP ACC.1/CAP, FDP ACC.1/MEM, FDP ACF.1/CAP,
FDP ACF.1/MEM, FDP IFC.1/ACTV, FDP IFC.1/CHNL,
FDP IFF.1/ACTV, FDP IFF.1/CHNL, FDP RIP.1,
FMT MSA.1/ACTV, FMT MSA.1/CHNL, FMT MSA.1/CAP,
FMT MSA.1/MEM, FMT MSA.3/ACTV, FMT MSA.3/CHNL,
FMT MSA.3/CAP, FMT MSA.3/MEM, FMT SMF.1/ACTV,
FMT SMF.1/CHNL, FMT SMF.1/CAP, FMT SMF.1/MEM.
33
6. SECURITY REQUIREMENTS
Security Objectives Security Functional Requirements
O.ACCESS CONTROL FIA ATD.1, FIA UID.2, FIA USB.1, FDP ACC.1/CAP,
FDP ACC.1/MEM, FDP ACF.1/CAP, FDP ACF.1/MEM,
FDP IFC.1/ACTV, FDP IFC.1/CHNL, FDP IFF.1/ACTV,
FDP IFF.1/CHNL, FMT MSA.1/ACTV, FMT MSA.1/CHNL,
FMT MSA.1/CAP, FMT MSA.1/MEM, FMT MSA.3/ACTV,
FMT MSA.3/CHNL, FMT MSA.3/CAP, FMT MSA.3/MEM,
FMT SMF.1/ACTV, FMT SMF.1/CHNL, FMT SMF.1/CAP,
FMT SMF.1/MEM, FMT SMR.1.
O.SAFE SECURE STATE FPT FLS.1
O.PRIORITY FRU PRS.1
O.ATTESTATION FAU SAS.1
Table 5: Security Objectives and SFRs - Coverage
Security Functional Requirements Objectives
FIA ATD.1 O.ACCESS CONTROL
FIA UID.2 O.ACCESS CONTROL
FIA USB.1 O.ACCESS CONTROL
FDP IFC.1/ACTV O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP IFC.1/CHNL O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP IFF.1/ACTV O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP IFF.1/CHNL O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP ACC.1/CAP O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP ACC.1/MEM O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP ACF.1/CAP O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP ACF.1/MEM O.CONFIDENTIALITY, O.ACCESS CONTROL
FDP RIP.1 O.CONFIDENTILITY
FMT MSA.1/ACTV O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.1/CHNL O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.1/CAP O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.1/MEM O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.3/ACTV O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.3/CHNL O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.3/CAP O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT MSA.3/MEM O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT SMF.1/ACTV O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT SMF.1/CHNL O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT SMF.1/CAP O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT SMF.1/MEM O.CONFIDENTIALITY, O.ACCESS CONTROL
FMT SMR.1 O.ACCESS CONTROL
FPT FLS.1 O.SAFE SECURE STATE
FRU PRS.1 O.PRIORITY
FAU SAS.1 O.ATTESTATION
Table 6: Security Objectives and SFRs - Sufficiency
34
6. SECURITY REQUIREMENTS
6.3.3 Dependencies
The following table presents the dependencies between different security functional components.
SFRs CC Dependencies Satisfied Dependencies
FIA ATD.1 No Dependencies
FIA UID.2 No Dependencies
FIA USB.1 FIA ATD.1 FIA ATD.1
FDP ACC.1/MEM FDP ACF.1/MEM FDP ACF.1/MEM
FDP ACC.1/CAP FDP ACF.1/CAP FDP ACF.1/CAP
FDP ACF.1/MEM
FDP ACC.1/MEM
and FMT MSA.3/MEM
FDP ACC.1/MEM
FMT MSA.3/MEM
FDP ACF.1/CAP
FDP ACC.1/CAP
and FMT MSA.3/CAP
FDP ACC.1/CAP
FMT MSA.3/CAP
FDP IFC.1/ACTV FDP IFF.1/ACTV FDP IFF.1/ACTV
FDP IFC.1/CHNL FDP IFF.1/CHNL FDP IFF.1/CHNL
FDP IFF.1/ACTV
FDP IFC.1/ACTV
and FMT MSA.3/ACTV
FDP IFC.1/ACTV
FMT MSA.3/ACTV
FDP IFF.1/CHNL
FDP IFC.1
and FMT MSA.3
FDP IFC.1/CHNL
FMT MSA.3/CHNL
FDP RIP.1 No Dependencies
FMT MSA.1/ACTV
FDP ACC.1/ACTV or FDP IFC.1/ACTV
and FMT SMF.1/ACTV
and FMT SMR.1
FDP IFC.1/ACTV
FMT SMF.1/ACTV
FMT SMR.1
FMT MSA.1/CHNL
FDP ACC.1/CHNL or FDP IFC.1/CHNL
and FMT SMF.1/CHNL
and FMT SMR.1
FDP IFC.1/CHNL
FMT SMF.1/CHNL
FMT SMR.1
FMT MSA.1/MEM
FDP ACC.1/MEM or FDP IFC.1/MEM
and FMT SMF.1/MEM
and FMT SMR.1
FDP ACC.1/MEM
FMT SMF.1/MEM
FMT SMR.1
FMT MSA.1/CAP
FDP ACC.1/CAP or FDP IFC.1/CAP
and FMT SMF.1/CAP
and FMT SMR.1
FDP ACC.1/CAP
FMT SMF.1/CAP
FMT SMR.1
FMT MSA.3/ACTV
FMT MSA.1/ACTV
and FMT SMR.1
FMT MSA.1/ACTV
FMT SMR.1
FMT MSA.3/CHNL
FMT MSA.1/CHNL
and FMT SMR.1
FMT MSA.1/CHNL
FMT SMR.1
FMT MSA.3/MEM
FMT MSA.1/MEM
and FMT SMR.1
FMT MSA.1/MEM
FMT SMR.1
FMT MSA.3/CAP
FMT MSA.1/CAP
and FMT SMR.1
FMT MSA.1/CAP
FMT SMR.1
FMT SMF.1 No Dependencies
FPT FLS.1 No Dependencies
FRU PRS.1 No Dependencies
FAU SAS.1 No Dependencies
Table 7: SFRs Dependencies
35
6. SECURITY REQUIREMENTS
6.4 Security Assurance Requirements
This ST follows a set of Security Assurance Requirements (SARs) for the TOE. It consists of the EAL 6
package augmented with ALC FLR.1.
The Security Policy Model of the TOE is identified in ADV SPM.1.
6.4.1 ADV SPM.1 Formal TOE security policy model
Hierarchical to: No other components.
Dependencies: ADV FSP.4 Complete functional specification.
Developer action elements:
ADV SPM.1.1D The developer shall provide a formal security policy model for the [assignment:
SFP.CAP].
ADV SPM.1.2D For each policy covered by the formal security policy model, the model shall
identify the relevant portions of the statement of SFRs that make up that policy.
ADV SPM.1.3D The developer shall provide a formal proof of correspondence between the model
and any of formal functional specification.
ADV SPM.1.4D The developer shall provide a demonstration of correspondence between the
model and the functional specification.
Other elements of ADV SPM.1 comply with the ones defined in [CC3].
6.5 Security Assurance Requirements Rationale
The Evaluation Assurance Level 6 has been chosen to commensurate with the threat environment that is
experienced by typical consumers of the TOE. The assurance level defined in this ST consists of the
predefined assurance package EAL 6 with the augmentation ALC FLR.1.
36
7. TOE SUMMARY SPECIFICATION
7 TOE Summary Specification
For every security function a short identifier is specified in brackets to allow direct referencing to single
items in other documents.
The TOE performs the following security functions:
• User Identification and TSF Protection
• Capability-based Access Control
• Information Flow Control and Residual Information Removal
• Memory Management
• Thread Management
• Platform attestation
7.1 User Identification and TSF Protection
7.1.1 Identification and Authentication
The TOE does not identify physical users, only processes are identified by the TOE. Processes can be
viewed as the users and subjects at the same time.
Each process is identified by the process identifier ATTR.PROC.ID. The TOE maintains the security
attributes for each process that take the actions on behalf of a specified process.
Each kernel object has an associated owner process that is identified in ATTR.OB.OWNER, and may also
allow supervised access to other processes by ATTR.OB.SVISITOR.
The functions authorized to each process are mapped in ATTR.OB.PERM.
The attributes mentioned above are bound to the corresponding S.PROC as unique process identifier, kernel
object owner, process with supervised access and/or authorized operations, where applicable.
7.1.2 Protection of TSF
If the TSF is identified as a failure state in its initialization and runtime, it will panic, stop the TOE, and
enters the secure halt state. This status indicates a secure status when a failure condition is faced with. To
reenter the secure state, the TOE should be restarted.
The TOE utilizes BUG ON mechanism to check state consistency of the TOE. The checks are implemented
throughout all the key paths in the code, to check if key logical conditions are meet. If any memory error or
glitch causes logical inconsistency and get caught by the BUG ONs, the kernel will panic immediately and
halts.
7.1.3 SFR Summary
This security function covers the following SFRs: (FIA ATD.1, FIA UID.2, FIA USB.1, FPT FLS.1).
37
7. TOE SUMMARY SPECIFICATION
7.2 Capability-based Access Control
7.2.1 Capability
7.2.1.1 Discretionary Access Control
The TOE enforces capability-based access control as the Discretionary Access Control (DAC) mechanism to
protect the confidentiality of the kernel objects.
A capability is an unforgeable token of authority. Each kernel object is associated with a capability. To
access a kernel object, a process should first have the corresponding capability. A capability specifies the
rights a process is authorized to access the kernel object.
The capability is assigned to the kernel objects when it is created by means of OP.NEWCAP.
Each process has a collection of capabilities called CNode (OB.CNODE), which describes all the kernel
objects it is authorized to access. One CNode corresponds to and only to one process.
Each kernel object has one owner (i.e., a process bound to the role R.OWNER), and may have multiple
visitors. The owner can grant the capability of the kernel object to other processes to allow other processes
to access it by means of OP.GRANT. The owner can revoke the authority anytime by means of OP.REVOKE.
The process which accepts the capability is called the visitor of the kernel object bound to the role
R.VISITOR, and may also reject granted capabilities by means of OP.REJECT. The visitor cannot grant the
capability to other processes.
In addition, the TOE implements a supervised access mode bound to the role R.SVISITOR, where an owner
of a CNode can grant its CNode to other processes, and allows other processes to gain full access its
capabilities on behalf of it. In this scenario, those processes holds the granted CNode are called supervised
visitors (R.SVISITOR) to the capabilities in the granted CNode.
The rights of the kernel objects are stored in the corresponding capabilities. In the following, the ST author
refers the capability to represent the rights.
7.2.1.2 DAC Attributes
The DAC attributes of the kernel objects consist of the following parts:
• ATTR.OB.OWNER: The owner of the kernel object. It can give the authorization with the specified
rights to other processes.
• ATTR.OB.SVISITOR: A set which records the supervised visitors of the kernel object. A supervised
visitor is added to the set when the owner of the kernel object grants its CNode to another process. At
this point the process with granted CNode becomes a supervised visitor to the kernel object.
• ATTR.OB.PERM: A mapping from the processes to the rights/capabilities. It specifies which
processes can do what operations on the kernel object. The owner and the supervised visitors can
modify ATTR.OB.PERM.
Actually, the TOE does not use a mapping to store the ATTR.OB.PERM. The permissions reside in the
CNode of individual processes. Inside the CNode, there are two parts, storing two kinds of capabilities
separately:
– CNode.Own: A set of capabilities it owns.
– CNode.Grant: A set of capabilities it is granted.
A process grants the capability of the kernel object to another process by adding the capability to the
CNode.Grant of the target process.
A process revokes the capability of the kernel object from the specified process by removing the
capability from the CNode.Grant of the target process.
38
7. TOE SUMMARY SPECIFICATION
7.2.1.3 DAC Enforcement Algorithm
The TSF enforces the DAC policy to kernel objects based on the capability. The TOE uses the following
rules to determine whether a request to access the kernel object is permissible. To access the kernel object, a
process should show its capability list.
• Check the validity of the capability: The capability must be a valid element inside CNode of the
requester. Otherwise the request is refused.
• Check the rights specified in the capability: The operations to take on the kernel object must be
allowed by the rights described in the capability. Otherwise the request is refused.
7.2.2 Security Management in Capability
The owner and the supervised visitor of a kernel objects manages the security attributes. When a kernel
object is created, the owner and the supervised visitor specifies the initial rights to access it. The initial rights
cannot be modified afterwards, and the rights granted to other processes must be less than the initial rights.
A process can grant or revoke kernel objects to other processes only if it has the kernel objects’
corresponding capabilities in its CNode.Own, or it has the supervised access to those capabilities.
7.2.3 SFR Summary
This security function covers the following SFRs: (FDP ACC.1/CAP, FDP ACF.1/CAP, FMT MSA.1/CAP,
FMT MSA.3/CAP, FMT SMF.1/CAP, FMT SMR.1).
7.3 Information Flow Control and Residual Information Removal
7.3.1 IPC Information Control Policy
The TOE implements IPC Information Control Policy to control information flows associated with inter
process communications, namely Activation and Channel. In general, the TOE enforces that all the IPC
related objects (OB.ACTIVATION and OB.CHANNEL) are under the control of CAP, and only the authorized
subjects with correct roles can initiate IPC operations to transfer data from one process to another. Any
unauthorized attempt to transmit information between subjects via IPC will be immediately denied.
7.3.1.1 IPC Information Control Policy on Activation
For Activation, the client calls the servers activation pool to allocate a ready activation, some informations
will be transferred to the server activation, and the activation will be pushed on the clients tcb to execute.
The server activation will be popped from the client’s tcb while the execution of the server activation
finished and some information will be replied to the client.
7.3.1.2 IPC Information Control Policy on Channel
For Channel, the TOE uses OB.CHANNEL to incorporate S.PROCs that act as senders and receivers. An
OB.CHANNEL has attribute ATTR.OB.PERM, which consists of P.SEND right and/or P.RECEIVE right.
Under the control of CAP, for all S.PROCs with access (R.OWNER, R.VISITOR and R.SVISITOR) to a
particular OB.CHANNEL, only the S.PROC with P.RECEIVE right can invoke OP.RECEIVE on the
OB.CHANNEL to receive messages, and only the S.PROC with P.SEND right can send messages to the
OB.CHANNEL. Any attempt tries to receive or send data on an unauthorized OB.CHANNEL will be denied.
39
7. TOE SUMMARY SPECIFICATION
7.3.2 IPC Security Management
7.3.2.1 Security Management on Activation
The basic security attributes of Activation are managed under CAP, which controls the accessibility of
OB.ACTIVATION based on roles (R.OWNER R.SVISITOR R.VISITOR). In addition, OB.ACTIVATION is
statically configured to be only accessible by R.OWNER, i.e, it cannot be granted to other S.PROC thus will
not have any R.VISITOR.
7.3.2.2 Security Management on Channel
The TOE uses OB.CHANNEL as medium to implement Channel, and since OB.CHANNEL is managed by
capability subsystem, its security management functions obey capability operations. There is no additional
rules to limit the management.
7.3.3 Residual Information Removal
Kernel objects which have a dedicated memory region are zeroed in the creation procedure by wiping the
data stored in the memory. Specifically, the wiping process is applied over OB.CNODE, OB.THREAD,
OB.CHANNEL and OB.ACTIVATION.
The other kernel objects do not have a dedicated memory region. In such cases, the object data is initialized
with the corresponding default values, thus the kernel objects do not contain any trace of residual
information.
7.3.4 SFR Summary
This security function covers the following SFRs: (FDP IFC.1/ACTV, FDP IFF.1/ACTV,
FMT MSA.1/ACTV, FMT MSA.3/ACTV, FMT SMF.1/ACTV, FDP IFC.1/CHNL, FDP IFF.1/CHNL,
FMT MSA.1/CHNL, FMT MSA.3/CHNL, FMT SMF.1/CHNL, FMT SMR.1, FDP RIP.1).
7.4 Memory Management
7.4.1 Memory Management Policy
7.4.1.1 Page based Physical Memory Management
TOE uses the kernel object OB.PAGE to record the information of physical memory regions. Different kinds
of physical memory region are specified different page types. Page type is used to manage the permission of
physical memory with page type transaction. Page types include:
• PAGE TYPE VOID: fake physical memory region without physical memory in backend. It’s allowed
to transact with type PAGE TYPE USER and PAGE TYPE IOMEM.
• PAGE TYPE USER: physcal memory region used for user space map. It’s allowed to transact with
most of the types except PAGE TYPE IOMEM and PAGE TYPE BOOTDATA.
• PAGE TYPE IOMEM: physical memory region used for io map. It’s just allowd to transact with
PAGE TYPE VOID.
• PAGE TYPE BOOTDATA: physical memory region used for kernel booting. It’s not allowed to
transact types.
• PAGE TYPE PGTABLE: physcal memory region used for page table. It’s just allowed to transact
with PAGE TYPE USER.
40
7. TOE SUMMARY SPECIFICATION
• PAGE TYPE KOBJ: physical memory region used for kernel object. It’s just allowed to transact with
PAGE TYPE USER.
7.4.1.2 Capability based Virtual Memory Management
TOE uses kernel objects OB.VSPACE to record the information of virtual memory address spaces. The
R.OWNER of the virtual memory address space is a user process that owns a capability of an OB.VSPACE.
And the R.VISITOR of the virtual memory address space is a user process which a capability of an
OB.VSPACE has been granted to. The user processes, to which the R.OWNER grants its OB.CNODE, are the
R.SVISITOR of the OB.VSPACE. All permissions (owned or granted) of an OB.VSPACE recorded in
capability subsystem are within the ATTR.OB.PERM of the virtual memory address space.
7.4.1.3 Syscalls of Memory Management
All syscalls involving memory management in the TOE can be categorised as follows:
• Syscalls that map a physical memory region to user virtual memory address space by means of
OP.MAP;
• Syscalls that unmap a physical memory region from user virtual memory address space by means of
OP.UNMAP;
• Syscalls that flush cache of memory range for one process by means of OP.FLUSH;
• Syscalls that reclaim physcal memory that page table used of memory range of one processby means
of OP.SHRINK;
• Syscalls that change map protection of memory for one process by means of OP.MPROTECT;
• Syscalls that change an one OB.PAGE’s ATTR.PAGE.TYPE for a physcal memory region by means of
OP.PG TRANS;
These kinds of syscalls receive capability as a parameter, and check the permissions through capability
system. TOE never handles a syscall if:
• The user process tries to operate an OB.VSPACE without corresponding permission (P.MAP,
P.UNMAP, P.FLUSH, P.SHRINK, P.MPROTECT).
• The user process provides an OB.PAGE whose type is not allowed to use in user space, such as
PAGE TYPE PGTABLE, PAGE TYPE KOBJ, PAGE TYPE BOOTDATA and PAGE TYPE VOID.
• It tries to map a OB.PAGE to for kernel, whose type is invalid for kernel map, such as
PAGE TYPE VOID and PAGE TYPE USER.
• It tries to transact type of a OB.PAGE to another type, which is not permitted to transact to (see
Section 6.2.4.2).
7.4.2 Security Management in Memory Management
7.4.2.1 Physical Memory Type Transfer
There is a default type of all OB.PAGEs after kernel booting. Kernel classifies pages into different
ATTR.PAGE.TYPE for user processeses and other uses. User processes cannot modify ATTR.PAGE.TYPE of
one OB.PAGE directly. The capability operation OP.PG TRANS is used to change the ATTR.PAGE.TYPE of
a physcal memory range.
41
7. TOE SUMMARY SPECIFICATION
7.4.2.2 Virtual Memory Address Space Authorization
When a virtual memory address space is created, it must bind to a OB.CNODE with full permissions. Since
a virtual memory address is managed by capability system, its security management functions are same as
capability operations including OP.GRANT, OP.REVOKE and OP.REJECT. There is no additional rule to
limit the authorization.
7.4.3 SFR Summary
This security function covers the following SFRs: (FDP ACC.1/MEM, FDP ACF.1/MEM,
FMT MSA.1/MEM, FMT MSA.3/MEM, FMT SMF.1/MEM, FMT SMR.1).
7.5 Thread Management
7.5.1 Kernel Scheduling
In the priority-based RR scheduling, ready threads with the same priority are linked in a queue which is
sorted by the enqueue order. The scheduler is constructed with multiple queues where each queue stands for
a given priority. Upon scheduling, the scheduler finds a non-empty queue with the highest priority, then
chooses the thread in the head of the queue to run. Each thread has a timeslice to keep track of the current
remaining time on the CPU, which will be decreased by 1 upon each timer tick. When the timeslice is used
up, the current thread will be append to the tail of the queue of the corresponding priority queue in scheduler.
At this point the scheduler will choose a new thread from its queues (including the current thread) to execute.
Note that in the HongMeng, the current thread also gives up the CPU whenever a syscall occurs.
7.5.2 Futex
The Fast Userspace muTEXes (Futex), is a light-weight method for process synchronization in HongMeng
Kernel. The Futex operation is atomic and involves the memory shared by synchronized processes. When a
process enters or exits a race condition, the process first checks the Futex variable to find whether the race
happens. If the race happens, the process will be suspended in the kernel with the FUTEX WAIT call, and
the kernel will wake up this process with FUTEX WAKE. On the contrary, the process will not be trapped in
the kernel space if there is no race, and this may improve the kernel efficiency.
7.5.3 SFR Summary
This security function covers the following SFR: (FRU PRS.1).
7.6 Platform Attestation
The TOE stores unique platform attestation data to be used in its operational state. Specifically, platform
identification and allowed configuration values are stored in the kernel object OB.SYSCTRL.
7.6.1 SFR Summary
This security function covers the following SFR: (FAU SAS.1).
42
8. ABBREVIATIONS
8 Abbreviations
CA Client Application
CC Common Criteria
CEM Common Evaluation Methodology
DAC Discretionary Access Control
EAL Evaluation Assurance Level
GIC General Interrupt Controller
IPC Inter Process Communication
IT Information Technology
MMU Memory Management Unit
NVM Non-Volatile Memory
OS Operating System
OSP Organisational Security Policy
PP Protection Profile
RAM Random Access Memory
REE Rich Execution Environment
RFC Request For Comments
SAR Security Assurance Requirement
SFP Security Function Policy
SFR Security Functional Requirement
SoC System-on-Chip
SPD Security Problem Definition
ST Security Target
TA Trusted Application
TEE Trusted Execution Environment
TOE Target of Evaluation
TRR Target Row Refresh
TSF TOE Security Functionality
TSFI TSF Interface
TSS TOE Summary Specification
43
9. TERMINOLOGIES
9 Terminologies
This section contains definitions of technical terms that are used with a meaningful specific to this document.
Terms defined in the [CC1] are not reiterated here, unless stated otherwise.
ARM Trusted Firmware A firmware providing a reference implementation of secure world
software for ARMv7-A and ARMv8-A.
Bootloader A piece of program that loads and starts the kernel.
Client Application The applications running in the rich execution environment.
Kirin A series of integrated circuit chips produced by Huawei HiSilicon.
MAP The operation to establish the mapping from the specific virtual ad-
dresses to specific physical addresses.
MMU Address translation hardware in the CPU which automatically trans-
lates virtual addresses to physical addresses.
Page Table A data structure recording the mapping relations between virtual ad-
dresses and physical addresses.
Panic A safety measure taken by an operating system’s kernel upon detecting
an internal fatal error in which it either is unable to safely recover
from or cannot have the system continue to run without having a much
higher risk of major data loss.
REE The normal processing environment which runs the user-facing opera-
tion system. It is isolated from TEE.
TEE A secure area of a main processor. It guarantees code and data loaded
inside to be protected with respect to confidentiality and integrity .
Trusted Application The applications run in the trusted execution environment.
TrustZone A technology providing system-wide hardware isolation for trusted
software.
UNMAP The operation to erase the mapping from the specific virtual addresses
to specific physical addresses.
Virtual Memory A memory management technique that provides an abstracted view of
all accessiable memory resources on a machine.
44
10. REFERENCES
10 References
[CC1] Common Criteria for Information Technology Security Evaluation Part 1: Intro-
duction and General Model, Version 3.1, Revision 5, April 2017, CCMB-2017-
04-001.
[CC2] Common Criteria for Information Technology Security Evaluation Part 2: Security
Functional Requirements, Version 3.1, Revision 5, April 2017, CCMB-2017-04-
002.
[CC3] Common Criteria for Information Technology Security Evaluation Part 3: Security
Assurance Requirements, Version 3.1, Revision 5, April 2017, CCMB-2017-04-
003.
[CEM] Common Methodology for Information Technology Security Evaluation: Evalua-
tion Methodology, Version 3.1, Revision 5, April 2017, CCMB-2017-04-004.
[ARC] Huawei HongMeng Kernel Common Criteria Evaluation ADV ARC: Security
Architecture.
[OPE] Huawei HongMeng Kernel Common Criteria Evaluation AGD OPE: Operational
User Guidance.
[PRE] Huawei HongMeng Kernel Common Criteria Evaluation AGD PRE: Preparative
Procedures.
45