Security Target PikeOS Separation Kernel v4.2.2 Document ID Revision DOORS Baseline Date State 00101-8000-ST 20.6 N.A. 2018-10-10 App Author: Dominic Eschweiler SYSGO AG Am Pfaffenstein 14, D-55270 Klein-Winternheim Notice: The contents of this document are proprietary to SYSGO AG and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by SYSGO AG. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 2 of 47 This page intentionally left blank Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 3 of 47 This page intentionally left blank Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 4 of 47 Table of Contents 1 Introduction.................................................................................................................... 6 1.1 Purpose of this Document........................................................................................... 6 1.2 Document References................................................................................................ 6 1.2.1 Applicable Documents......................................................................................... 6 1.2.2 Referenced Documents....................................................................................... 6 1.3 Abbreviationsand Acronyms....................................................................................... 6 1.4 Termsand Definitions................................................................................................. 8 1.5 Imperative Terms..................................................................................................... 11 2 ST Introduction............................................................................................................. 12 2.1 ST Reference.......................................................................................................... 12 2.2 TOE Reference ....................................................................................................... 12 2.3 TOE Overview......................................................................................................... 12 2.3.1 Usage and Major Security Services of the TOE..................................................... 12 2.3.2 TOE Type ....................................................................................................... 13 2.4 TOE Description...................................................................................................... 13 2.4.1 TOE Architecture.............................................................................................. 13 2.4.2 TOE............................................................................................................... 14 2.4.3 TOE Operational Environment............................................................................ 14 2.4.4 TOE Life Cycle................................................................................................. 16 2.4.5 TOE Physical Boundary .................................................................................... 18 2.4.6 TOE Logical Boundary...................................................................................... 20 3 Conformance Claims..................................................................................................... 21 3.1 CC Conformance Claim............................................................................................ 21 3.2 Protection Profile Claim ............................................................................................ 21 3.3 Package Claim........................................................................................................ 21 3.4 Conformance Rationale............................................................................................ 21 4 Security Problem Definition ............................................................................................ 22 4.1 Assets.................................................................................................................... 22 4.2 Threats................................................................................................................... 23 4.3 Organizational Security Policies................................................................................. 23 4.4 Assumptions........................................................................................................... 23 5 Security Objectives....................................................................................................... 25 5.1 Security Objectives for the TOE ................................................................................. 25 5.2 Security Objectives for the Operational Environment..................................................... 25 5.3 Security Objectives Rationale.................................................................................... 26 5.3.1 Security Objectives Rationale: Threats ................................................................ 27 Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 5 of 47 5.3.2 Security Objectives Rationale: Assumptions......................................................... 28 6 Extended Components Definition .................................................................................... 29 7 Security Requirements................................................................................................... 30 7.1 Security Functional Requirements.............................................................................. 30 7.1.1 User Data Protection (FDP)............................................................................... 30 7.1.2 Identification and Authentication (FIA).................................................................. 38 7.1.3 Security Management (FMT).............................................................................. 38 7.1.4 Resource Utilization (FRU) ................................................................................ 40 7.2 Security Assurance Requirements.............................................................................. 41 7.3 Security Requirements Rationale ............................................................................... 41 7.3.1 Security Objective: OT.CONFIDENTIALITY.......................................................... 43 7.3.2 Security Objective: OT.INTEGRITY..................................................................... 43 7.3.3 Security Objective: OT.RESOURCE_AVAILABILITY.............................................. 44 7.3.4 Security Objective: OT.API_PROTECTION.......................................................... 44 7.3.5 Security Assurance Requirements Rationale........................................................ 44 7.3.6 Security Assurance Requirements Dependency Analysis ....................................... 44 8 TOE Summary Specification........................................................................................... 45 9 Acknowledgment.......................................................................................................... 47 List of Figures Figure 1: TOE and TOE Operational Environment during Operational Use................................... 13 Figure 2: System Integration Phase of the TOE Lifecycle .......................................................... 17 List of Tables Table 1: Applicable Documents............................................................................................... 6 Table 2: Referenced Documents............................................................................................. 6 Table 3: Abbreviations and Acronyms...................................................................................... 7 Table 4: Assets................................................................................................................... 23 Table 5: Security Objectives Rationale................................................................................... 27 Table 6: Coverage of Security Objectivesfor the TOE by SFR. “X” isfor where a dependency to an objective exists. .................................................................................................................. 42 Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 6 of 47 1 Introduction 1.1 Purpose of this Document Thisisthe Security Target for the PikeOS Separation Kernel. 1.2 Document References 1.2.1 Applicable Documents Ref. Document ID - Document Title Version [Com12] Common CriteriaSponsoring Organizations, Common Criteria for Information Technology Security Evaluation. Version 3.1, revision 4 (final), September 2012, http://www.commoncriteriaportal.org/thecc.html. 3.1, revision 4 Table 1: Applicable Documents 1.2.2 Referenced Documents Ref. Document ID - Document Title [ANSSI15] Agence nationale de la sécurité dessystèmesd'information, Référentiel général de sécurité, Processus de qualification d'un produit de sécurité - niveau standard - version 1.2, 2015, https://www.ssi.gouv.fr/uploads/2015/07/RGS_qualif_standard_version_1- 2.pdf. [Bun08] Bundesamt für Sicherheit in der Informationstechnik(BSI) and Sirrix AG security technologies, Protection Profile for High-Assurance Security Kernel: Version 1.14, June 2008, http://web.archive.org/web/*/http://www.sirrix.com/media/downloads/54500.pdf. [Inf07] Information Assurance Directorate, U.S. Government Protection Profile for Separation Kernelsin EnvironmentsRequiringHigh Robustness. Version 1.03, June 2007, https://web.archive.org/web/20110108022547/http://www.niap-ccevs.org/cc- scheme/pp/pp_skpp_hr_v1.03/. [LNIM10] Timothy E. Levin, Thuy D. Nguyen, Cynthia E. Irvine, Michael McEvilley, Separation Kernel Protection Profile revisited: Choicesand rationale, 4th Annual Layered Assurance Workshop (LAW), 2010, http://fm.csl.sri.com/LAW/2010/. [OSPP] Stephan Mueller, GeraldKrummeck, Helmut Kurth, Operating System Protection Profile, 2010, https://www.commoncriteriaportal.org/files/ppfiles/pp0067b_pdf.pdf. Table 2: Referenced Documents 1.3 Abbreviations and Acronyms Abbreviation / Acronym Description APEX Application Executive API Application Programming Interface ARINC Aeronautical Radio, Inc. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 7 of 47 ASP Architecture Support Package CC Common Criteriafor Information Technology Security Evaluation CPU Central Processing Unit DMA Direct Memory Access EAL Evaluation Assurance Level ELF Executable and Linkable Format HASK High-Assurance Security Kernel I/O MMU Input / Output Memory Management Unit I/O Input / Output IPC InterprocessCommunication IT Information Technology MILS Multiple Independent Levelsof Security MMU Memory Management Unit OSEK Offene Systeme und deren Schnittstellen für die Elektronikin Kraftfahrzeugen OSP Organizational Security Policy OSPP Operating SystemsProtection Profile POSIX Portable Operating System Interface PSP Platform Support Package RAM Random AccessMemory RTEMS Real-Time Executive for Multiprocessor Systems SAR Security Assurance Requirement SFP Security Function Policy SFR Security Functional Requirement SKPP SeparationKernel Protection Profile SSP System Security Policy ST Security Target TOE Target of Evaluation TSF Target of Evaluation Security Functionality TSS_XXX TOE Security Service XXX USB Universal Serial Bus VMIT Virtual Machine Initialization Table XML Extensible Markup Language Table 3: Abbreviationsand Acronyms Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 8 of 47 1.4 Terms and Definitions Access Flag: An access flag isbit specifying whether a certainaccessoperation isallowed. Access Mode: An access mode isa set of accessflags. Application: An application isexecutable data. An application isa special case of “Executable”. Architecture Support Package: An architecture support package (ASP) is part of the PikeOS Separation Kernel. The ASP providesspecific low-level functionality for each supported CPU architecture. Since the CPU instruction set isalso CPU dependent, thegeneric componentsare CPU specific at the object code level. The main responsibilitiesof an ASP are: (1) abstraction of data typerepresentation, (2) processor exception handling, and (3) low level addressspace and memory management. In operational use, the TSF alwayscontainsonly one ASP. Bootloader: See “Firmware”. Builtin File Provider: A builtin file provider isan executable providedby the TOE that implementsfile services. Communication Object: Partitionscan communicate with each other under the supervision of the PikeOS Separation Kernel. A communication object isan object exposed to one or multiple partitions with accessrightsasdefined in the configuration data. Configuration Data: The configuration data definesa set of ruleson how the TOE behaves. The configuration data comprisesa top-level configuration XML document called VMIT (Virtual Machine Initialization Table) and the property file system. Accessto each property file system node iscontrolled by the file accesscontrol defined in the VMIT. The configuration data isdefined during Step3 of the system integration phase and used by the TOE to enforce theSystem Security Policy (SSP, Section 2.4.4.2). The default configuration isthat there isno communication between any partitions. Any communication between partitionshasto be explicitly allowedby the integrator in the configuration data. CPU Architecture: The CPU architecture ischaracterised by design implementing the CPU instruction set. PikeOS hasbeen evaluated for the CPU architecturesx86 64-bit, ARMv7, or ARMv8. Cyclic Periodicity: Cyclic periodicity isthe repetition of a scheduling scheme: when the last time window of the scheduling scheme hasfinished, the scheduling scheme beginsagain with itsfirst time window. ELF File: An ELF file isa file in ELF format, used to load applications. Executable: “Executable” isthe term for an application within a partition or other executable code linked to PikeOS. • An executable iscritical if it can have accessto critical hardware. Critical hardware can bypass PikeOS partitioning. Exampleswhere a normal partition hostsa critical executable are: o An executable in a normal partitioniscritical if the integrator in the configuration assignsto it accessto control a critical hardware which can do DMA, there isno I/O MMU in place, and the hardware can write to arbitrary system memory, thustampering with PikeOS. Another example isan executable that hassufficient control over a hardware device allowing the executableto tamper with the device’sBIOS or non-volatile memory. We refer the reader to the TOE User Manualsfor more details. • A non-privileged executable isan application in a normal partition that isnot critical. Thus, a non-privileged executable can be an arbitrary executable, which can contain unintentional errorsor be even malicious. A privileged executable iseither: A critical application in a normal partition, or any application in a system partition, or the PSP, or a kernel device driver, or a system extension. That is, a Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 9 of 47 privileged executable hasaccessto PikeOS API or to critical hardware that can bypassPikeOS partitioning. Therefore, a privileged executable must be non-evil, and the integrator must verify that it complieswith the system design aswell asthat it will not interfere with PikeOS and the security policiesdefined in the VMIT. External File Provider: An external file provider isan executable provided by third-party developers that implementsfile servicesand isconfined by VMIT. File Descriptor: A file descriptor isan identifier for a file. Firmware: Firmware ishardware-specific software which comprisesthe following: • Software and data stored in non-volatile memory of the hardware that initializesthe hardware after the power on. • Software that (fully or partially) loadsthe TOE into RAM memory and handsover the full control to the TOE. In particular, a TOE-external checkof the TOE may be implemented in the bootloader (e.g. for “secure boot”). Fusion Tool Chain: The PikeOS fusion tool chain project isa linker that linksone or several executablesand the PikeOS Separation Kernel for the x86 64-bit, ARMv7, or ARMv8 architectures. The tool-chain provideslinker for the required CPU architectures, i.e. x86 64-bit, ARMv7, or ARMv8. The tool chain can be used on a development machine with Linux or Windows. Hardware: Hardware isthe physical part of the TOE operational environment on which the TOE is executed. Usually, hardware isa board with several componentssuch asCPUsand I/O devices(e.g. serial interfaces, networkadapters) etc. ThisST considersfirmware aspart of thehardware. Integration Tool Chain: The PikeOS integration tool chainproject takesasinput one or more applications, the VMIT, the property file system, and theresultsof the fusion tool chain and produces the product based on PikeOS, in the form of a ROM image. The tool-chain supportsthe required CPU architectures, i.e. x86 64-bit, ARMv7, or ARMv8. Thetool chain can be used on a development machine with Linux or Windows. Integrator: The integrator executesthe system integration phase, which resultsin a product based on the TOE. InterprocessCommunication: IPC isa communication protocol in PikeOS to exchangemessages within a partition or between partitionssynchronously. The communication objectsare IPC messages. Isolation: Isolation of a partition isthe absence of communication with other partitions, except partitionshosting the componentsimplementing the system API, when no communication channelsor shared resourcesbetween the partition and other partitionsare configured. Isolationisa special case of separation. Kernel Info Page: The kernel info page isa memory page that ismapped in read-only accessmode to all partitions. Kernel Device Driver: A kernel device driver isa software component supplied and approved by the integrator and linked with the PikeOS Separation Kernel via the kernel device driver API. A kernel device driver canprovide specific functionality to applicationswithin partitionsand isprotected from non-privileged executablesby accesscontrol and resource management enforced by the PikeOS Separation Kernel. Life Cycle: The life cycle phasesfor thisTOE are development (source code development), manufacturing (compilation to binary) and delivery to the integrator. The integrator executesthe system integration phase, which resultsin a product based on the TOE. Memory Page: A memory page isan aligned and contiguousarea of memory of a CPU architecture dependent size (e.g. 4096 bytes). Normal Partition: A normal partition canuse the API provided by PikeOS to partitionsthat only consistsof non-privileged calls(“normal partitionAPI”). Non-Privileged Executable: See “Executable”. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 10 of 47 Own (for a Task or a Thread): A partition owns a taskif the taskis assigned to it by the integrator in the VMIT. A partition ownsa thread if the thread iscreated by one of itsapplications. Partition: A partition isa logical unit maintained by the PikeOS Separation Kernel and configured by the SSP. A partition containsuser data. For each partition, the PikeOS Separation Kernel provides resources. Resourcesof a partition comprise physical memory and allocated CPU time for each CPU. Partition Switch: Partition switches are defined by SSP aspart of the scheduling scheme and assign CPU(s) to another partition. PikeOS Operating System: The PikeOS Operating System consistsof the PikeOS Separation Kernel and additional system componentssuch asthe PSP, (kernel) device drivers, and system extensions. Such additional componentsare usually used for making the PikeOS Operating System fully compatible with itsuse-case and theused hardware. PikeOS Separation Kernel: The PikeOS Separation Kernel providesthe TSF and operatesthe product based on PikeOS. The TSF implementsmechanismsto assign resourcesto partitions, providing the execution environmentsfor applications, and implementing communication between partitionsasdefined by the configuration data. The PikeOS Separation Kernel isprovided asbinary for each CPU architecture, i.e. one instance for x86 64-bit, ARMv7, or ARMv8. The functionality of the PikeOS Separation Kernel isCPU architecture-independent thanksto the usage of the ASP that abstractsthe underlying CPU architecture. PikeOS: The term PikeOS isusually used in the documentation when thedescribed system includes at least the PikeOS Separation Kernel. The termsPikeOS and PikeOS Separation Kernel are used synonymously in thisST. Platform Support Package: A platform support package (PSP) containsa set of driversfor specific hardware componentsand issupplied and approvedby the integrator. A PSP usesthe TSF’sPSP API. In operational use, the product based on PikeOS alwayscontainsexactly one PSP. A PSP is protected from non-privileged executablesby accesscontrol and resource management enforced by the PikeOS Separation Kernel. The main tasks of a PSP are (1) platform initialization, (2) interrupt management, (3) hardware timer management. Port: A port isa communication endpoint for message based communication. A port iseither configured assource port or destination port. A sender writesa message to a source port and a receiver readsthe message from the connected destination port. PikeOS supportstwo kindsof message transfer modes- queuing mode and sampling mode. The mode isdefined by the port type. Only portsof the same type canbe connected. Messagessent to a source queuing port are buffered in a queue until they are read from the connected destination port. The number of messagesthat can be buffered isa configurable property of a queuing port. A message sent to a source sampling port is only buffered until the next message issent, the new message will replace theold one. Privileged Executable: See “Executable”. Product Based on PikeOS: The product based on PikeOS isthe output of the system integration phase (Section 2.4.4.2). The product based on PikeOS containsthe configuration data in a representation readable by the PikeOS Separation Kernel, the PSP, system extensions, kernel device drivers, and partitions. PikeOS readsand set up the configuration, and confinesnon-privileged executableswithin their partitionsaccording the SSP. Property Node: A property node isa file in the property file system. Theintegrator can use the property file system to describe propertiesof hardware in the operational environment. Resource: In thisST we consider resources of partitionsand TSF data. The resourcesof a partition comprise physical memory and allocated CPU time for each CPU. Separation: The TOE separates partitionsby managing their accessesto and usage of resources, such asmemory, devices, processors, and communication channels, asdefined by the configuration. Subject: In thisST the term subject isused for a threadin a partition, for an application, or for a partitionasa whole depending on the context. In the running TOE the entity executing application code isa PikeOS thread. In a partition there can be multiple threadsand each thread isuniquely assigned to itspartition. Since thisST workson security policiesat partitionlevel, we abstract all Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 11 of 47 threadsin one partition to the partition subject. System Extension: A system extension isa software component supplied and approved by the integrator and linked with the PikeOS Separation Kernel via the system extension API. A system extension can provide specific functionality to applicationswithin partitionsand isprotected from non- privileged executablesby accesscontrol and resource management enforced by the PikeOS SeparationKernel. System Partition: A system partition can use the whole API provided by PikeOS to partitions(“system partitionAPI”), i.e. use both non-privileged(normal partition API) and additional privileged calls. The integrator can define a partition asa system partition in thePikeOS configuration. System Security Policy (SSP): The configuration data uniquely definesthe System Security Policy (SSP) consisting of configuration choicesmade by an integrator. The SSP definespartitions, setting their resources, defining communication objects, defining accessto and parametersfor PSP, system extensions, and kernel device drivers, setting their content and resources, setting PikeOS Separation Kernel attributes, comprising scheduling scheme, policy for memory cache handling on a partition switch to theextent supported by the operational environment’shardware, scheme for automatic handling of error conditions. The SSP isa subset of the VMIT. Time Window: A time windowisthe basic scheduling entity of CPU time assigned to a partition that is specified by the offset from the start of a cyclical time period and the window duration. TOE Security Service: A TOE Security Service isa logical part of the TOE that hasto be relied upon for enforcinga related subset of the rulesregulating how the SSP ismaintainedby the TOE. TOE User Manuals: The TOE User Manuals are documentation provided with the TOE on how to use the TOE in general environmentsand in safety and security critical environments. User: A “user” of the TOE isa partition. Virtual Machine Initialization Table (VMIT): The configuration data definesa set of ruleson how the TOE behaves. The configuration data comprisesa top-level configuration XML document called VMIT (Virtual Machine Initialization Table) and the property file system. Accessto each property file system node iscontrolled by the file accesscontrol defined in the VMIT. The SSP isa subset of the VMIT. 1.5 Imperative Terms Use of the words'shall', 'should', 'may' and 'will' within thisdocument observe the following rules: The word 'shall' in a text expressesa mandatory definition. The words'should' and 'may' in a text expressa non mandatory definition. 'should' isused, when a non mandatory provision isrecommended, otherwise 'may' isused. The word 'will' in a text expressesa definition in casesa simple futurity isrequired. 'will' isalso used to expressa task (done by an individual or an organization), which isnot controlled by thisdocument. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 12 of 47 2 ST Introduction Thisisthe Security Target for the PikeOS Separation Kernel also called PikeOS in thisdocument.. 2.1 ST Reference • Title: Security Target PikeOS Separation Kernel v4.2.2 • Version: 20.6 • Issuer: SYSGO AG • Keywords: Operating system, Separation kernel, MILS (Multiple Independent Levelsof Security), Virtualization, Hypervisor • Date: 10. October 2018 • TOE Version: 4.2.2 Thisdocument isthe Security Target for the Common Criteria evaluation of the PikeOS Separation Kernel. It complieswith the Common Criteria for Information Technology Security Evaluation Version 3.1 Revision 4 [Com12] (CC). 2.2 TOE Reference The TOE isthe PikeOS Separation Kernel version 4.2.2 running on the microprocessor family (x86 64- bit, ARMv7, or ARMv8) hosting different applications. The TOE isreferenced asPikeOS 4.2.2 base product build S5400 for Linux and Windowsdevelopment host with PikeOS 4.2.2 Certification Kit build S5400. 2.3 TOE Overview 2.3.1 Usage and Major Security Services of the TOE The TOE isa special kind of microkernel, a separation kernel, which allowsto effectively separate different applicationsrunning on the same platform from each other. Applicationsare hosted in partitionsthat can be separated from each other. Such non-privileged applicationscan also be operating systems. Non-privileged applicationsmay be malicious, and even in that case the TOE ensuresthat the maliciousapplicationsare harming neither the TOE nor other applicationsin other partitions. The TOE will be installed and run on a hardware platform (e.g. embedded systems). SYSGO definesseparation asfollows: The TOE separates partitionsby managing their accesses to and usage of resources, such asmemory, devices, processors, and communication channels, as defined by the configuration. Isolation of a partition isthe absence of communication with other partitions, except partitionshostingthe componentsimplementing the system API, when no communication channelsor shared resourcesbetween the partition and other partitionsare configured. Isolation isa special case of separation. The TOE isa real time separation kernel, thus, the partitioning isconfigured statically and the TOE doesnot include typical desktop operating system services(e.g. user login, printer drivers). The major security servicesprovided by the TOE are: • Separationin space of applicationshosted in different partitionsfrom each other and from the PikeOS Operating System according to the configuration data, • Separationin time of applicationshosted in different partitionsfrom each other and from the PikeOS Operating System according to the configuration data, • Control of information flowsbetween applicationshosted in different partitionsvia assigning to the partitionscommunication objectsand accessrightsto those, Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 13 of 47 • Management of the TOE (e.g. system partition API) andthe TOE data (e.g. threads, tasks). 2.3.2 TOE Type The TOE isa separationkernel with real-time support. The typical life cycle phasesfor thisTOE type are development (source code development), manufacturing (compilation to binary) and delivery to the integrator. The integrator executesthe system integration phase, which resultsin a product based on the TOE. The TOE may run on varioushardware platforms. The hardware platform isnot part of the TOE. The minimum requirementson the hardware platform comprise a CPU with a memory management unit (MMU) and support for different CPU privilege modesaswell ashaving a suitable Platform Support Package (PSP). The supported CPU architecturesare x86 64-bit, ARMv7, or ARMv8. 2.4 TOE Description 2.4.1 TOE Architecture The TOE, including itsarchitecture, and the TOE operational environment isdepicted in Figure 1. PSP Driver ASP PSP API System ext. API System partition API System partition 1 System partition M System extension Driver Normal partition API Normal partition N Non-privileged application(s) E.g., Linux Normal partition 2 Non-privileged application(s) E.g., POSIX … … PikeOS Separation Kernel Normal partition 1 Non-privileged application(s) E.g., C application System extension TOE Normal partition content, e.g. non-privileged applications, arbitrary user data Privileged executable content, user data that has to be approved by the system integrator Operational environment Red line defines security domains separated by technical means Hardware Firmware Kernel device driver API Kernel device driver Kernel device driver PikeOS Operating System Dashed line defines the PikeOS Operating System Figure 1: TOE and TOE Operational Environment during Operational Use Figure 1 will be explained in detail in the next sections(Section 2.4.2 and 2.4.3). Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 14 of 47 2.4.2 TOE The TOE isthe PikeOS Separation Kernel, shown in Figure 1 by the blue box. It consistsof the PikeOS Kernel and System Software, which containsall security functions(TSF) claimed in this ST, and the TSF data (e.g. configuration data and run-timedata such assecurity attributes) necessary to configure and control them. The PikeOS Separation Kernel providesthe TSF and operatesthe product based on PikeOS. The TSF implementsmechanismsto assign resourcesto partitions, providing the execution environments for applications, and implementing communication between partitionsasdefined by the configuration data. The separation kernel hasthe following interfaces(depicted asdashed boxeswithin the blue box in Figure 1): • The PikeOS Separation Kernel providesAPIsto normal partitionsand system partitionsaswell as APIsto system extensions, kernel device driversand the platform support package (PSP). • An architecture support package (ASP) ispart of the PikeOS Separation Kernel. The ASP providesspecific low-level functionality for each supported CPU architecture. Supported CPU architecturesare x86 64-bit, ARMv7, or ARMv8. In operational use, the TSF alwayscontainsonly one ASP. TSF data consistsof: • Configuration data: data used by the TOE to enforce the System Security Policy (SSP, Section 2.4.4.2). • Run-time data such assecurity attributes. 2.4.2.1 PikeOS Operating System The PikeOS Operating System consistsof the PikeOS Separation Kernel and, depending on the configuration used, of additional software componentsasmentioned in Section 2.4.3. Such componentsare depicted in Figure 1 by the red boxeson the right side. 2.4.3 TOE Operational Environment In a final product, e.g., an embedded system product based on the TOE, the TOE will use additional supporting software componentsto adapt the product to itsoperational environment, including the system’shardware. These additional componentsare provided by the integrator and are not covered by thisevaluation and belong therefore to the TOE’soperational environment. They interact with the PikeOS TOE through the TOE’swell-defined interfacesand do not change the TOE binary. Some of the componentsexecute privileged CPU instructionsor use privileged PikeOS servicesand could therefore interfere with security policiesenforced by the TSF at runtime. Those componentsare collectively referred to asprivileged executables (see Section 2.4.3.1.3). It isoutside the scope of thisevaluation how the trust for the privileged executableswill be established. The integrator of a product based on the TOE must establish trust for these privileged executables, e.g. the integrator may use a national scheme’s accreditation for componentsand/or the product based on the TOE, a Common Criteria evaluation of the product based on the TOE, or the integrator may provide some other arguments to the user of the product based on the TOE. The TOE’soperational environment consistsof everything outside the blue box in Figure 1. The variousprivileged (red) or non-privileged (green) componentsthat may be added by the system or platform integratorsare the following: 2.4.3.1 Partition A partition isa logical unit maintained by the PikeOS Separation Kernel and configured by the configuration data. A partition containsuser data. For each partition, the PikeOS Separation Kernel providesresources. Resources of a partition comprise physical memory and allocated CPU time for each CPU. PikeOS supportstwo different kindsof partitions: normal and system partitions. Normal partitions, depicted asgreen boxesin Figure 1, are defined in Section 2.4.3.1.1. System partitions, depicted as red boxesin Figure 1, are defined in Section 2.4.3.1.2. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 15 of 47 Partitionscan communicate with each other under the supervision of the PikeOS Separation Kernel. Thiscommunication occursvia communication objects. A communication object isan object exposed to one or multiple partitionswith accessrightsasdefined in the configurationdata. 2.4.3.1.1 Normal Partition A normal partition can use the API provided by PikeOS to partitionsthat only consistsof non-privileged calls(“normal partition API”). The integrator can define a partition asa normal partition in the PikeOS configuration. 2.4.3.1.2 System Partition A system partition can use the whole API provided by PikeOS to partitions(“system partition API”), i.e. use both non-privileged (normal partition API) and additional privileged calls. The integrator can define a partition asa system partition in the PikeOS configuration. 2.4.3.1.3 Executable, Non-privileged Executable, Privileged Executable “Executable” isthe term for an application within a partitionor other executable code linked to PikeOS. • An executable iscritical if it can have accessto critical hardware. Critical hardware can bypass PikeOS partitioning. Exampleswhere a normal partition hostsa critical executable are: o An executable in a normal partitioniscritical if the integrator in the configuration assignsto it accessto control a critical hardware which can do DMA, there isno I/O MMU in place, and the hardware can write to arbitrary system memory, thustampering with PikeOS. Another example isan executable that hassufficient control over a hardware device allowing the executableto tamper with the device’sBIOS or non-volatile memory. We refer the reader to the TOE User Manualsfor more details. • A non-privileged executable isan application in a normal partition that isnot critical. Thus, a non-privileged executable can be an arbitrary executable, which can contain unintentional errorsor be even malicious. • A privileged executable iseither: A critical application in a normal partition, or any application in a system partition, or the PSP, or a kernel device driver, or a system extension. That is, a privileged executablehasaccessto PikeOS API or to critical hardware that can bypassPikeOS partitioning. Therefore, a privileged executable must be non-evil, and the integrator must verify that it complies with the system design aswell asthat it will not interfere with PikeOS and the security policies defined in the VMIT. 2.4.3.2 System Extension A system extension isa software component supplied and approved by the integrator and linked with the PikeOS Separation Kernel via the system extension API. A system extension can provide specific functionality to applicationswithin partitionsand isprotected from non-privileged executablesby accesscontrol and resource management enforced by the PikeOS Separation Kernel. 2.4.3.3 Kernel Device Driver A kernel device driver isa software component supplied and approved by the integrator and linked with the PikeOS Separation Kernel via the kernel device driver API. A kernel device driver can provide specific functionality to applicationswithin partitionsand isprotected from non-privileged executables by accesscontrol and resource management enforced by the PikeOS Separation Kernel. 2.4.3.4 Platform Support Package (PSP) A platform support package (PSP) containsa set of driversfor specific hardware componentsand is supplied and approvedby the integrator. A PSP usesthe TSF’sPSP API. In operational use, the product based on PikeOS alwayscontainsexactly one PSP. A PSP isprotected from non-privileged Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 16 of 47 executablesby accesscontrol and resource management enforced by the PikeOS Separation Kernel. 2.4.3.5 Communication Object A communication object isa file, shared memory, a port, an IPC message, or an event. 2.4.3.6 Hardware Hardware isthe physical part of the TOE operational environment on which the TOE isexecuted. Usually, hardware isa board with several componentssuch asCPUsand I/O devices(e.g. serial interfaces, networkadapters) etc. Hardware may also comprise firmware. Firmware ishardware-specific software which comprisesthe following: • Software and data stored in non-volatile memory of the hardware that initializesthe hardware after the power on. • Software that (fully or partially) loadsthe TOE into RAM memory and handsover the full control to the TOE. In particular, a TOE-external checkof the TOE may be implemented in the bootloader (e.g. for “secure boot”). 2.4.4 TOE Life Cycle 2.4.4.1 TOE Development, TOE Manufacturing At the TOE manufacturer’ssite (SYSGO), theTSF isdeveloped (source code development), and manufactured (compiled to binary). The TOE manufacturer also producesthe TOE User Manuals. 2.4.4.2 System Integration At the integrator’ssite, the TOE isintegrated. Figure 2 presentsthe system integration phase of the TOE lifecycle. Componentsused to build the product based on the TOE are provided by different sources: applicationdevelopers, integrators, and the TOE manufacturer (SYSGO). During system integration, the TOE, applicationsand other executablesonly have to be linked, i.e. their implementationsdo not need to be changed or recompiled. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 17 of 47 Figure 2: System Integration Phase of the TOE Lifecycle The system integration phase can be split into the four steps: selection of the TOE operational environment, non-privileged and privileged executables, and deciding on system partitionsand normal partitions(Step 1), fusion (Step 2), configuration of the TOE (Step 3), and integration (Step 4). Step 1 Selection The integrator selectshardware, and if applicable, firmware the TOE runson. The integrator installsthe PikeOS 4.2.2 product and the PikeOS 4.2.2 Certification Kit on the development machine for the corresponding CPU architecture. The integrator selectsthe content of components: PSP, optional system extension(s), optional kernel device driver(s), optional system partition(s), and normal partition(s) to be integrated in the TOE. The content of any privileged executable shall be developed complying with theobligationsgiven in Section 4.4 and be approved by the integrator. Step 2 Fusion In thisstep the integrator: • providesconfiguration for the PSP, kernel device drivers, and system extensions, and Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 18 of 47 • uses the fusion tool chain to linkthe PSP, kernel device drivers, and system extensionswith the PikeOS Separation Kernel binary image. Step 3 Configuration The integrator configuresthe product by: • defining normal and system partitions, setting their content and resources, • defining communication objects, • defining accessto and parametersfor PSP, system extensions, and kernel device drivers, setting their content and resources, • setting PikeOS Separation Kernel attributes, comprising: o scheduling scheme, o policy for memory cachehandling on a partition switch to the extent supportedby the operational environment’shardware, o scheme for automatic handling of error conditions, definingthe meaning of the safe and secure state. The result of thisactivity isthe configurationdata. The configuration data definesa set of rules on how the TOE behaves. The configuration data comprisesa top-level configuration XML document called VMIT (Virtual Machine Initialization Table) and the property file system. Accessto each property file system node iscontrolled by the file accesscontrol defined in the VMIT. The configuration data uniquely definesthe System Security Policy (SSP) consisting of configuration choicesmade by an integrator. The SSP definespartitions, setting their resources, defining communication objects, defining accessto and parametersfor PSP, system extensions, and kernel device drivers, settingtheir content and resources, setting PikeOS Separation Kernel attributes, comprising scheduling scheme, policy for memory cache handling on a partition switch to the extent supported by the operational environment’s hardware, scheme for automatic handling of error conditions. The SSP isa subset of the VMIT. The SSP isenforced by the TSF and it cannot be circumventedby non-privileged executables. The default configuration isthat there isno communication between any partitions. Any communication between partitionshasto be explicitly allowedby the integrator in the configuration data. Step 4 Integration The integrator usesthe integration tool chain to create a product based on PikeOS (in the form of a binary image) from the selected componentsand the PikeOS configuration data, creatingthe product based on PikeOS, including configuration data in a representation readable by the PikeOS Separation Kernel. 2.4.4.3 Operational Use of the Product Based on the TOE At power on the hardware isinitialized and then the product based on PikeOS isloaded. Immediately after the product based on PikeOS hasbeen loaded, the PSP getsexecuted. The PSP then startsthe PikeOS separation kernel (TSF), thePikeOS Separation Kernel initializesitself and startsenforcing the SSP, i.e. PikeOS readsand set up the configuration, and confinesnon-privileged executables within their partitionsaccording theSSP. 2.4.5 TOE Physical Boundary The TOE isthe PikeOS Separation Kernel. In Figure 1, each component within the blue box iswithin the TOE physical boundary. Each component outside of the blue box isoutside of the TOE physical boundary. Thus, no hardware belongsto the TOE, and no software for kernel device drivers, PSP, Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 19 of 47 system extensionsand no partitionsbelong to theTOE. The TOE also includesthe TOE User Manuals, which are used during the system integration phase. A list of TOE User Manualsisgiven by the following table: Title Architecture Version PikeOS Safety and Security Manual Generic 20.16 PikeOS Safety and Security Manual (x86 AMD64Supplement) X86_64 20.13 PikeOS Safety and Security Manual (ARM7 Supplement) ARM V7 20.14 PikeOS Safety and Security Manual (ARM8 Supplement) ARM V8 20.15 PikeOS Platform Manual for x86-amd64 Boards X86_64 4.2-225 PikeOS Platform Manual for ARM v7 Boards ARM V7 4.2-182 PikeOS Platform Manual for ARM v8-A 64-bit Boards ARM V8 4.2.182 User Manual PikeOS Certification Kit(X86_AMD64) X86_64 20.6 User Manual PikeOS Certification Kit(ARM_V7HF) ARM_V7 20.6 User Manual PikeOS Certification Kit(ARM_V8HF) ARM_V8 20.6 PikeOS 4.2 InstallationGuide Generic 20.04.2018 PikeOS User Manual Generic 4.2-330 PikeOS Kernel Reference Manual Generic 4.2-107 PikeOS System Software Reference Manual Generic 4.2-132 PikeOS PSP Developer’sGuide Generic 4.2-104 PikeOS Device Driver ProgrammingReferenceManual Generic 4.2-151 P4EXT PikeOS NativePersonality Extensions Generic 4.2-40 CENV C Language Programming Environment Generic 4.2-22 The TOE on the corresponding architecture isprovided through: TOE on x86 64-bit Short description ISO name Content PikeOS 4.2.2 x86 64-bit R4p2_PIKEOS_MT_CMB_X86_S5400.iso PikeOS 4.2.2 build S5400 for x86 64-bit architecture PikeOS 4.2.2 x86 64-bit Certification Kit R4p2_PIKEOS_DK_CMB_X86_AMD64_- CERTKIT_S5400.iso PikeOS 4.2.2 certificationdocumentation for x86 64-bit TOE on ARM v7 Short description ISO name Content PikeOS 4.2.2 ARM v7 R4p2_PIKEOS_MT_CMB_ARM_V7HF_- S5400.iso PikeOS 4.2.2 build S5400 for ARM v7 architecture PikeOS 4.2.2 ARM v7 Certification Kit R4p2_PIKEOS_DK_CMB_ARM_V7HF_- CERTKIT_S5400.iso PikeOS 4.2.2 certificationdocumentation for ARM v7 Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 20 of 47 TOE on ARM v8 Short description ISO name Content PikeOS 4.2.2 ARM v8 R4p2_PIKEOS_MT_CMB_ARM_V8HF_- S5400.iso PikeOS 4.2.2 build S5400 for ARM v8 architecture PikeOS 4.2.2 ARM v8 Certification Kit R4p2_PIKEOS_DK_CMB_ARM_V8HF_- CERTKIT_S5400.iso PikeOS 4.2.2 certificationdocumentation for ARM v8 2.4.6 TOE Logical Boundary The TOE providesthe following TOE security services, abbreviated asTSS_XXX: • TSS_SSA: Separation in space of applicationshosted in different partitionsfrom each other and from the PikeOS Operating System according to the SSP by using the underlying hardware, as shown by the red linesin Figure 1. Applicationscan be hosted in different partitions. Partitionsget assigned resources(i.e. space) according to the SSP, which comprise memory rangesand a set of CPUs. The TSF enforcesthe corresponding part of the SSP by the enforcement of accesscontrol on partition content, per- partitionprovision of physical memory space and allocated CPU time for each CPU. By confining non-privileged executablesinto partitions, the TSF enforcesthat these applications can affect neither applicationsin other partitionsnor the PikeOS Operating System itself. • TSS_STA: Separation in time of applicationshosted in different partitionsfrom each other and from the PikeOS Operating System according to the SSP. Applicationscan be hosted in different partitions. Partitionsget assigned CPU time (i.e. time windows) according to the SSP. TheTSF enforcesthe corresponding part of the SSP by per- partitionallocation of a predefinedamount of CPU time for each CPU. On a partition switch CPUs will be reused. • TSS_COM: Provision and management of communication objects. Applicationshosted in different partitionscan get assigned a set of communication objects. A communication object isan object exposed to one or multiple partitionswith accessrightsas defined in the configuration data, thusallowing communication between partitions. • TSS_MAN: Management of the TOE (e.g. system partition API) andthe TOE data (e.g. threads, tasks) The PikeOS Separation Kernel restrictsa non-privileged application to only manage tasks and threadswithin itspartition. The PikeOS Separation Kernel providesan API to privileged applicationsto manage the TOE and the TOE data. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 21 of 47 3 Conformance Claims 3.1 CC Conformance Claim ThisSecurity Target (ST) conformsto the Common Criteria for Information Technology Security Evaluation Version 3.1 Revision4 [Com12] (CC) asfollows: • Part 2 conformant • Part 3 conformant 3.2 Protection Profile Claim ThisST doesnot claim conformance with any Protection Profile. 3.3 Package Claim ThisST claimsconformance to the Evaluation Assurance Level 3 (EAL 3), augmented with ALC_FLR.3. Thus, thisST isEAL 3 augmented. 3.4 Conformance Rationale Since thisST doesnot claim conformance to any protection profile, thissection isnot applicable. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 22 of 47 4 SecurityProblem Definition 4.1 Assets All assetswithin the same domain asthe TSF (see Figure 1, red-line shape with TSF) are treated in thissecurity target together with the asset TSF data (AS.TSF_DATA). Asset Name Description Security Propertiesto be Preserved Memory (AS.MEM) RAM or ROM memory, memory mapped I/O, and port mapped I/O assigned to a partition by the integrator. confidentiality, integrity, availability Files(AS.FILE) Accessto filesand accessmodesassigned to a partition by the integrator. confidentiality, integrity Ports(AS.PORT) Each port iseither a source port or a destination port. The integrator useschannelsto specify from which source ports PikeOS transfersmessagesto which destination ports. confidentiality, integrity Interrupts (AS.INT) Set of interruptsallocated to each partition, configured by the integrator. confidentiality, integrity Accessto PSP- specific services (AS.PS) For each accessto PSP-specific services, the right to invoke that driver isconfigured by the integrator per partition. confidentiality, integrity CPU cores (AS.CORE) Set of CPU coresallocated to each partition, configured by the integrator. integrity Memory reserved for exclusive accessby the PikeOS hypervisor (AS.KMEM) Memory reserved for exclusive accessby the PikeOS hypervisor used on behalf of the resource partition, configured by the integrator. Application Note: Thismemory is withinthe same domain asthe TSF. availability CPU processing time (AS.TIME) The integrator assignstime windowsto partitions. This definesthe CPU processing time of each partition. availability Tasks (AS.TASK) An application alwayshasat least one task. Tasks are used to structure the assigned memory into addressspaces. This asset consistsof thisstructure. Application Note: The content of tasks is already covered by AS.MEM. API protection Threads (AS.THR) An application alwayshasat least one thread. The asset consistsof all threadsthat can be created in a partition. API protection TSF data (AS.TSF_DATA) TSF data consistsof: Configuration data: Data used by the TSF to enforce the System Security Policy (SSP, Section 1.4.4.2). confidentiality, integrity Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 23 of 47 Asset Name Description Security Propertiesto be Preserved Run-time data such aspartition attributes, taskand thread management data. System Partition API (AS.SYS_PART_ API) The system partition API isan interface to functionsof the TSF available for system partitions. API protection Table 4: Assets 4.2 Threats Assets are defined in Table4 in Section 4.1. An attacker isa non-privileged executable. T.DISCLOSURE An attacker readsan asset of which the property confidentiality shall be maintained according to Table 4 and the SSP. T.MODIFICATION An attacker writesan asset of which the property integrity shall be maintained according to Table 4 and the SSP. T.DEPLETION By consuming resourcesof which the property availability shall be maintained according to Table 4 and the SSP an attacker makesthese resourcesunavailable to the TOE itself and/or to non-privileged executablesand/or to privileged executables. T.EXECUTION An attacker executesa management function of which the property API protection shall be maintained according to Table 4 and the SSP without being authorized to do so. 4.3 Organizational Security Policies ThisST definesno organizational security policies. 4.4 Assumptions A.PRIVILEGED_EXECUTABLES All privileged executablesare approved by the integrator. Theintegrator thereby takesresponsibility that the privileged executableshave been developed according to the TOE User Manualsand do not violate the SSP. The integrator takesresponsibility not to put privileged executablesand non- privileged executablesinto the same partition. Application Note: TheTOE User Manualsprovide detailed guidance on secure configuration and usage of the TOE. A.HARDWARE The underlying hardware, firmware andbootloader needed by PikeOS to guarantee secure operation provide the necessary properties, are working correctly and have no undocumented or unintended security critical side effect on the functionsof the TOE. The hardware must fulfill the following requirements, asexplained in the TOE User Manuals: Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 24 of 47 1. Provide CPU(s) with at least two privilege modes(“user” and “supervisor” mode). Only the PikeOS Separation Kernel itself and privileged executablesmay run in the “supervisor” mode. Non-privileged executablesalwaysrun in “user mode”. In “user mode”, only a limited set of instructionsisavailable; in “supervisor mode”, all instructionsare available. 2. The hardware shall have a MMU, which iscapable of restricting accesses(e.g. destinationsof load and store CPU instructions) of non-privileged executablesto certain memory regions. The MMU shall only be configurable from a privileged CPU mode, thus, it can only be configurable through the TOE to configure the policiesspecifying these accessrestrictions. These policiesare part of the SSP. DuringTOE run time, these policiesare represented as page tablesused by the MMU. 3. The hardware (CPU or CPUs) shall provide instructionsto switch between privilege modes and to use the memory management to set up different segmentsof memory. 4. The hardware (CPU or CPUs) shall allow the TOE to reuse CPU(s) for different non-privileged executables, in a way that there isno residual information flow through CPU registersacrossa partitionboundary. 5. The hardware shall provide default valuesfor security-relevant settingsat power-on (e.g. program counter, detailed instructionsshall be included in the hardware reference manual). Thissupportsthe TOE reachingthe initial safe and secure state. 6. If the hardware possesses any other active componentsbeside CPUsor CPUshave operating mode(s) not under control of PikeOS, then the hardware shall provide support either to turn these componentscompletely off or to control them asdescribed in the TOE User Manuals. For example, if a device accessible by non-privileged executablescan execute DMA, then all DMA shall be switched off or, in order to control DMA, the hardware shall provide an I/O MMU, with an I/O MMU driver protected by PikeOS. The timer facilitiesprovided by the hardware shall be sufficient for the timing requirements(e.g., timer resolution) of the product based on PikeOS. The CPU-specific requirementsare met by all x86 64-bit, ARMv7, or ARMv8 CPUsspecified in the TOE User Manualsfor the selected CPU architecture. A.EXCLUSIVE_RESOURCES All resourcesrequired by PikeOS, itsprivileged executables, and itsnon-privilegedexecutablesare exclusively controlled by the TOE. A.PHYSICAL It isassumed that the IT environment providesthe TOE with appropriate physical security, commensurate with the value of the IT assetsprotected by the TOE. A.TRUSTWORTHY_PERSONNEL The personnel configuring, integrating, and developing the product based on the TOE (integrator) are trustworthy, act according to the TOE User Manualsand are sufficiently qualified for thistask. Application Note: Thesystem integration phase (Section 2.4.4.2) can be split into the four steps: selection of the TOE operational environment, non-privileged and privileged executables, and deciding on system partitionsand normal partitions(Step 1), fusion (Step 2), configuration of the TOE (Step 3), and integration (Step 4). At each step of the system integration phase, the integrator shall follow the TOE User Manuals. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 25 of 47 5 SecurityObjectives 5.1 Security Objectives for the TOE OT.CONFIDENTIALITY For each asset, the TOE shall preserve itsconfidentiality according to Table 4 and the SSP. OT.INTEGRITY For each asset, the TOE shall preserve itsintegrity according to Table 4 and the SSP. OT.RESOURCE_AVAILABILITY For resourcesassigned to partitionsand to TSF data, the TOE shall preserve their availability according to Table 4 and the SSP. Application Note: In thisST availability meansthat the TOE will provide a specified amount of a resource or ability to use some TOE services. ThisST doesnot consider availability in the sense of physical availability such astolerance to power failure. OT.API_PROTECTION The TSF shall prevent any execution of a management function reserved to privileged executablesby non-privileged executables. 5.2 Security Objectives for the Operational Environment OE.PRIVILEGED_EXECUTABLES All privileged executablesare approved by the integrator. Theintegrator thereby takesresponsibility that the privileged executableshave been developed according to the TOE User Manualsand do not violate the SSP. OE.HARDWARE The underlying hardware, firmware andbootloader needed by PikeOS to guarantee secure operation provide the necessary properties, are working correctly and have no undocumented security critical side effect on the functionsof the TOE. The hardware must fulfill the following requirements, asexplained in the TOE User Manuals: 1. Provide CPU(s) with at least two privilege modes(“user” and “supervisor” mode). Only the PikeOS separation kernel itself and privileged executablesmay run in the “supervisor” mode. Non-privileged executablesalwaysrun in “user mode”. In “user mode”, only a limited set of instructionsisavailable; in “supervisor mode”, all instructionsare available. 2. The hardware shall have a MMU, which iscapable of restricting accesses(e.g. destinationsof load and store CPU instructions) of non-privileged executablesto certain memory regions. The MMU shall only be configurable from a privileged CPU mode, thus, it can only be configurable through the TOE to configure the policiesspecifying these accessrestrictions. These policiesare part of the SSP. DuringTOE run time, these policiesare represented as page tablesused by the MMU. 3. The hardware (CPU or CPUs) shall provide instructionsto switch between privilege modes and to use the memory management to set up different segmentsof memory. 4. The hardware (CPU or CPUs) shall allow the TOE to reuse CPU(s) for different non-privileged executables, in a way that there isno residual information flow through CPU registersacrossa partitionboundary. 5. The hardware shall provide default valuesfor security-relevant settingsat power-on (e.g. program counter, detailed instructionsshall be included in the hardware reference manual). Thissupportsthe TOE reachingthe initial safe and secure state. 6. If the hardware possesses any other active componentsbeside CPUsor CPUshave operating mode(s) not under control of PikeOS, then the hardware shall provide support either to turn these componentscompletely off or to control them asdescribed in the TOE User Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 26 of 47 Manuals. For example, if a device accessible by non-privileged executablescan execute DMA, then all DMA shall be switched off or, in order to control DMA, the hardware shall provide an I/O MMU, with an I/O MMU driver protected by PikeOS. Specific requirementsto the x86 64-bit architecture are: • The processors are operated in 64-bit mode. • AMD64 instruction set architecture. • Non-Execute bit (NX bit) support enabled in the BIOS. Specific requirementsto the ARMv7 architecture (Cortex-A7, Cortex-A9, Cortex-A15…) are: • The processors are operated in 32bit mode. • Memory Management Unit (MMU) with Virtual Memory System Architecture. • Vector Floating Point (VFP) / Advanced SIMD (Neon) extension. Specific requirementsto the ARMv8 architecture (Cortex-A35, Cortex-A53, Cortex-A57 and Cortex- A72) are: • The processors are operated in 64-bit mode. • Memory Management Unit (MMU) with Virtual Memory System Architecture. • Vector Floating Point (VFP) / Advanced SIMD (Neon) extension The timer facilitiesprovided by the hardware shall be sufficient for the timing requirements(e.g., timer resolution) of the product based on PikeOS. The CPU-specific requirementsare met by all x86 64-bit, ARMv7, or ARMv8 CPUsspecified in theTOE User Manualsfor the selected CPU architecture. OE.EXCLUSIVE_RESOURCES All resourcesrequired by PikeOS, itsprivileged executables, and itsnon-privilegedexecutablesare exclusively controlled by the TOE. OE.PHYSICAL The IT environment providesthe TOE with appropriate physical security, commensurate with the value of the IT assetsprotected by the TOE. OE.TRUSTWORTHY_PERSONNEL The personnel configuring and integrating the TOE (integrator) and those installing and operating the TOE (system operator) are trustworthy, act according to the TOE User Manuals, and are sufficiently qualified for thistask. 5.3 Security Objectives Rationale The following table providesan overview for security objectivescoverage (TOE and itsenvironment) and also gives an evidence for sufficiency and necessity of the defined objectives. It shows that all threatsand OSPsare addressed by the security objectivesand it also showsthat all assumptionsare addressed by the security objectivesfor the TOE operational environment. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 27 of 47 OT.CONFIDENTIALITY OT.INTEGRITY OT.RESOURCE_AVAILABILITY OT.API_PROTECTION OE.PRIVILEGED_EXECUTABLES OE.HARDWARE OE.EXCLUSIVE_RESOURCES OE.PHYSICAL OE.TRUSTWORTHY_PERSONNEL T.DISCLOSURE X T.MODIFICATION X T.DEPLETION X T.EXECUTION X A.PRIVILEGED_EXECUTABLES X A.HARDWARE X A.EXCLUSIVE_RESOURCES X A.PHYSICAL X A.TRUSTWORTHY_PERSONNEL X Table 5: Security ObjectivesRationale A justification required for suitability of the security objectivesto cope with the security problem definition isgiven below: 5.3.1 Security Objectives Rationale: Threats 5.3.1.1 Threat: T.DISCLOSURE If the security objective OT.CONFIDENTIALITY hasbeenreached, the threat T.DISCLOSURE is completely eliminated. 5.3.1.2 Threat: T.MODIFICATION If the security objective OT.INTEGRITY hasbeen reached, the threat T.MODIFICATION iscompletely eliminated. 5.3.1.3 Threat: T.DEPLETION If the security objective OT.RESOURCE_AVAILABILITY hasbeen reached, the threat T.DEPLETION is completely eliminated. 5.3.1.4 Threat: T.EXECUTION If the security objective OT.API_PROTECTION hasbeen reached, the threat T.EXECUTION is Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 28 of 47 completely eliminated. 5.3.2 Security Objectives Rationale: Assumptions Each security assumption in thisSecurity Target isaddressed by at least one security objective for the operational environment. Thissection mapsassumptionsto environmental security objectivesand providesa rationale how the assumption isfulfilled. 5.3.2.1 Assumption: A.PRIVILEGED_EXECUTABLES OE.PRIVILEGED_EXECUTABLES directly upholdsA.PRIVILEGED_EXECUTABLES. 5.3.2.2 Assumption: A.HARDWARE OE.HARDWARE directly upholdsA. HARDWARE. 5.3.2.3 Assumption: A.EXCLUSIVE_RESOURCES OE.EXCLUSIVE_RESOURCES directly upholdsA.EXCLUSIVE_RESOURCES. 5.3.2.4 Assumption: A.PHYSICAL OE.PHYSICAL directly upholdsA.PHYSICAL. 5.3.2.5 Assumption: A.TRUSTWORTHY_PERSONNEL OE.TRUSTWORTHY_PERSONNEL directly upholdsA.TRUSTWORTHY_PERSONNEL. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 29 of 47 6 Extended Components Definition ThisST doesnot include any extended components. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 30 of 47 7 SecurityRequirements Thissection definessecurity functional requirements(SFRs) and security assurance requirements (SARs), which apply for the TOE. 7.1 Security Functional Requirements We perform assignment, selection, and refinement of the SFRsprovided by the CC. The assignment operation ismarked by square brackets“[]”. The selection operationismarked in italic. In a refinement operation added text isunderlined and removed text iscrossed out. The iterationoperation isused when a component isrepeated on varying assets. Iteration isdenoted by showing a slash (“/”) and the iteration indicator after the component identifier. For example, FDP_ACF.1/CPA indicatesan iteration of FDP_ACF.1 on ‘communication port access’. Iterations applied to assetsfollow the order of Table 4 in Section 4.1 (assets). Where sentencesare grouped by having the same indentation level, the terms“OR” and “AND” in uppercase are used to indicate their logical relation. Configuration XML elements, attributes, and valuesare denoted in . These configuration elements, attributes, and valueshave speaking names, and when the configuration maintainsa list of elements, then thislist isreferred to in the configuration as. For a detailed explanation on how to use the configuration to configure PikeOS see the TOE User Manuals. All symbolsbeginning with “p4_” or “vm_” are API symbolsthat PikeOS providesto applications. In thisST we list only those symbolsthat trigger a system call and are not convenience user space wrappersfor other calls. See the TOE User Manualsfor details. Application Note: TheSSP isa subset of the VMIT configured by the integrator. The SFP isa set of rulesthat are parameterized by the SSP. These rulesare fix-coded in the implementation of the TSF. Thus, the behavior of a product based on PikeOS dependson the SFP and SSP. In the following the SFP issplit up into sub-SFPsasfollows: • memory accesscontrol policy (MA) • file accesscontrol policy (FA) • communication port accesscontrol policy (CPA) • interrupt accesscontrol policy (IA) • PSP-specific servicesaccesscontrol policy (PSA) • CPU core accesspolicy (CCA) • IPC and event communication policy (IEC) Application Note: In thisST the term subject isused for a thread in a partition, for an application, or for a partition asa whole depending on the context. In the running TOE theentity executing application code isa PikeOS thread. In a partition there can be multiple threadsand each thread isuniquely assigned to itspartition. Since thisST workson security policiesat partitionlevel, we abstract all threadsin one partition to the partition subject. 7.1.1 User Data Protection (FDP) 7.1.1.1 Complete Access Control (FDP_ACC.2) and Security Attribute Based Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 31 of 47 Access Control (FDP_ACF.1) 7.1.1.1.1 FDP_ACC.2/MA Complete AccessControl – Memory Access FDP_ACC.2.1/MA: The TSF shall enforce the [memory accesscontrol policy] on [subjects: partitions, objects: memory] andall operationsamong subjectsand objectscovered by the SFP. FDP_ACC.2.2/MA: The TSF shall ensure that all operationsbetween any subject controlled by the TSF and any object controlled by the TSF are covered by an accesscontrol SFP. Application Note: The TSF initializesthe MMU of the CPU and setsup page tablesin the memory allocated to the TSF to enforce thispolicy. 7.1.1.1.2 FDP_ACF.1/MA Security Attribute Based AccessControl – Memory Access FDP_ACF.1.1/MA: The TSF shall enforce the [memory accesscontrol policy] to objectsbased on the following [subjects: partitions, objects: memory areas, security attributes: partition ID, attributes defined for the memory area]. FDP_ACF.1.2/MA: The TSF shall enforce the following rulesto determineif an operation among controlled subjectsand controlled objectsisallowed: [ Accessto physical memory M of type , , , or isallowed to a subject in partition PA if: • M isspecified in a MR in the contained within the P and the attribute isset to AND • the accessoperation isread or write or execute and the accessmode of MR matches for read, for write, and for execute correspondingly OR • M isspecified in a MR in the contained within the P and the attribute isset to AND • the accessoperation isread or write or execute and the of MR matches for read, for write, and for execute correspondingly OR • M isin the text segment of an ELF file referenced in a element in the contained in a of the of the P and the attribute isset to AND • the accessoperation isread or execute Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 32 of 47 OR • M isspecified in a property file system node PN AND • the element of PA hasan element of type where the attribute isAM and attribute matchesthe PN AND • a subject in partition PA hassuccessfully performed open operation (vm_open) on the property node name PN with accessflagsAF including and AF being subset of AM, resulting in a file descriptor FD AND • a subject in partition PA hassuccessfully performed a property memory mapping (vm_prop_mem_map) operation with the file descriptor FD AND • the accessoperation isread or write or execute and compatible with AF OR • M isspecified in a property file system node PN AND • the element of PA hasan element of type where the attribute isAM and the attribute matchesthe PN AND • a subject in partition PA hassuccessfully performed open operation (vm_open) on the property node name PN with accessflagsincluding and accessflags being subset of AM, resulting in a file descriptor FD AND • A subject in partition PA hassuccessfully performed a property I/O port mapping (vm_prop_ioport_map) operation with the file descriptor FD AND • the accessoperation isread or write OR • M hasbeen received viamapping IPC (p4_ipc) with the requested accessmode allowing to read or write M AND •the accessoperation isread or write respectively Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 33 of 47 OR • M hasbeen received viavm_map with accessmode MAM AND • There isfile F in entry with F in the list contained within the P AND • F is successfully opened (vm_open) according to FDP_ACF.1.2/FA with an accessmode AM including and beinga superset of MAM AND • the accessoperation isread or write or execute and the MAM matches for read, for write, and for execute correspondingly OR • M ispart of a memory page that the TSF hasmapped in read-only accessmode to all partitions(“kernel info page”) AND • the accessoperation isread ] FDP_ACF.1.3/MA: The TSF shall explicitly authorize accessof subjectsto objectsbased on the following additional rules: [none]. FDP_ACF.1.4/MA: The TSF shall explicitly deny accessof subjectsto objectsbased on thefollowing additional rules: [none]. Application Note: Theoperationson I/O portsare availableonly for the x86 platform. The TSF on x86 configuresthe CPU’sI/O port unit. Application Note: Thememory pool can be used by a partition in three ways: (1) an application in a partitionusesmemory allocation service calls(e.g. vm_malloc) to get memory from the pool; (2) the application ELF file ismapped to the memory allocated from the pool during partition initialization, if it is specified in the VMIT; (3) memory ismapped from the pool to partitionduring partition initialization, if it isspecified in the VMIT. Application Note: Shared memory in PikeOS isimplemented asfilesprovided by internal file provider shm. Shared memoriesare specified in the and are processed in thesame way asthe disjunction for the case vm_map. 7.1.1.1.3 FDP_ACC.2/FA Complete AccessControl – File Access FDP_ACC.2.1/FA: The TSF shall enforce the[file accesscontrol policy] on [subjects: partitions, objects: files] and all operationsamong subjectsand objectscovered by the SFP. FDP_ACC.2.2/FA: The TSF shall ensure that all operationsbetween any subject controlled by the TSF and any object controlled by the TSF are covered by an accesscontrol SFP. 7.1.1.1.4 FDP_ACF.1/FA Security Attribute Based AccessControl – File Access FDP_ACF.1.1/FA: The TSF shall enforce the [file accesscontrol policy] to objectsbased on the following: [subjects: partitions, objects: files, security attributes: partition ID, attributesdefined for the filesin the configuration element of the partitionin the VMIT]. FDP_ACF.1.2/FA: The TSF shall enforce the following rulesto determine if an operation among Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 34 of 47 controlled subjectsand controlled objectsisallowed: [ • an open operation (vm_open) on any fileF provided by a builtin file provider, external file provider, system extension or kernel device driver to partition PA isallowed if: o The element of PA hasan element of type where attribute matchesF AND o the accessflagsprovided asan argument to the vm_open operation are subset of element for file F • a mount operation (vm_mount) on any volume V to partition PA isallowed if: o The element of PA hasan element of type where attribute matchesV and contains flag AND o the accessflagsprovided asan argument to the vm_mount operation are subset of element for the volume V • a statusrequest operation (vm_stat) on any file F by a builtin file provider, external file provider, system extension or kernel device driver to partition PA isallowed if: o The element of PA hasan element of type where attribute matchesF • an accessoperation (vm_close, vm_fstat, vm_fsync, vm_ioctl, vm_lseek, vm_map, vm_prop_read, vm_prop_write, vm_read, vm_read_at, vm_tdiscard_at, vm_test, vm_write, vm_write_at) on file F provided by a builtin file provider, system extension or kernel device driver to partition PA isallowed if: o the file hasbeen successfully opened before with the accessflagsincluding and the accessoperation isvm_read, vm_read_at, or vm_prop_read OR o the file hasbeen successfully opened before with the accessflagsincluding and the accessoperation isvm_write, vm_write_at, or vm_prop_write OR o the file hasbeen successfully opened before with the accessflagsincluding and the accessoperation isvm_map OR o the file hasbeen successfully opened before with the accessflagsincluding or and the accessoperation isvm_lseek OR o the file hasbeen successfully opened before and the operationisvm_close, vm_fstat, vm_fsync, vm_ioctl, vm_test, vm_tdiscard_at ]. Application Note: Filescan be provided by builtin file providers, system extensions, kernel device drivers, external file providers, or volume providers. An accessoperation itself on a file provided by a builtin file provider isimplemented by the TSF. An accessoperation on a file provided by a system extension or kernel device driver isdirectly forwarded by the TSF, after validating the file descriptor, to the corresponding function of the system extension or kernel device driver after the checkdescribed FDP_ACF.1.2/FA. An accessoperationon a file provided by an external file provider isimplemented as a direct IPC to the file provider. See FDP_IFC.2 and FDP_IFF.1. An open, statusrequest or access operation on a file provided by a volume file provider isimplemented asa direct IPC to thevolume provider. See FDP_IFC.2 and FDP_IFF.1. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 35 of 47 FDP_ACF.1.3/FA: The TSF shall explicitly authorize accessof subjectsto objectsbased on the following additional rules: [none]. FDP_ACF.1.4/FA: The TSF shall explicitly deny accessof subjectsto objectsbased on the following additional rules: [none]. 7.1.1.1.5 FDP_ACC.2/CPA Complete AccessControl – Communication Port Access FDP_ACC.2.1/CPA: The TSF shall enforce the [communication port accesscontrol policy] on [subjects: partitions, objects: communication ports] and all operationsamong subjectsand objects covered by the SFP. FDP_ACC.2.2/CPA: The TSF shall ensure that all operationsbetween any subject controlled by the TSF and any object controlled by the TSF are covered by an accesscontrol SFP. 7.1.1.1.6 FDP_ACF.1/CPA Security Attribute Based AccessControl – Communication Port Access FDP_ACF.1.1/CPA: The TSF shall enforce the [communication port accesscontrol policy] to objects based on the following: [subjects: partitions, objects: communication ports, security attributes: partition ID, port attribute in the VMIT, configuration elementsin the VMIT]. FDP_ACF.1.2/CPA: The TSF shall enforce the following rulesto determine if an operation among controlled subjectsand controlled objectsisallowed: [ • an open operation (vm_qport_open, vm_sport_open) on port PO isallowed to partition PA if: o the element of PA hasan element of type where attribute equalsPO or the of PA hasan element of type where attribute equalsPO o the argument direction to the open (vm_qport_open, vm_sport_open) operation isequal to the attribute of the PO • a statusrequest operation, (vm_qport_iterate, vm_qport_stat, vm_sport_iterate, vm_sport_stat) on port PO isallowed to partition PA if: o the element of PA hasan element of type where attribute Name equalsPO or the of PA hasan element of type where attribute equalsPO • an accessoperation on port PO successfully opened by PA isallowed if: o if the operation isread (vm_qport_read, vm_qport_read_routed, vm_sport_read), and the port PO wassuccessfully opened with destination direction . o if the operation iswrite (vm_qport_write, vm_qport_write_routed, vm_sport_write) and the port wassuccessfully opened with destination direction . o all other accessoperations(vm_qport_clear, vm_qport_close, vm_qport_control, vm_qport_pstat, vm_qport_psync, vm_qport_test, vm_sport_clear, vm_sport_close, vm_sport_control, vm_sport_pstat, vm_sport_psync, vm_sport_test) on portsare allowed ]. FDP_ACF.1.3/CPA: The TSF shall explicitly authorize accessof subjectsto objectsbased on the following additional rules: [none]. FDP_ACF.1.4/CPA: The TSF shall explicitly deny accessof subjectsto objectsbased on the following additional rules: [none]. 7.1.1.1.7 FDP_ACC.2/IA Complete AccessControl – Interrupt Access FDP_ACC.2.1/IA: The TSF shall enforce the [interrupt accesscontrol policy] on [subjects: partitions, objects: interrupts] and all operationsamong subjectsand objectscovered by the SFP. FDP_ACC.2.2/IA: The TSF shall ensure that all operationsbetween any subject controlled by the TSF Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 36 of 47 and any object controlled by the TSF are covered by an accesscontrol SFP. 7.1.1.1.8 FDP_ACF.1/IA Security Attribute Based AccessControl – Interrupt Access FDP_ACF.1.1/IA: The TSF shall enforce the [interrupt accesscontrol policy] to objectsbased on the following: [subjects: partitions, objects: interrupts, security attributes: partitionID, attributesdefined for filesin the configuration element of the partitionin the VMIT]. FDP_ACF.1.2/IA: The TSF shall enforce the following rulesto determine if an operation among controlled subjectsand controlled objectsisallowed: [ The operation p4_int_attach of attaching to interrupt IN (i.e., to have an interrupt handler invoked when interrupt IN istriggered) isallowed to a subject in partition PA if: • IN isspecified in a property file system nodePN • The element of PA hasan element of type where the attribute matchesPN and attribute AM • A subject in partition PA hassuccessfully performed an open operation (vm_open) on the property node PN with accessflagsincluding and being subset of AM, resulting in file descriptor FD • A subject in partition PA hasperformed successfully vm_prop_int_grant with the file descriptor FD, giving a valid interrupt number IN ]. FDP_ACF.1.3/IA: The TSF shall explicitly authorize accessof subjectsto objectsbased on the following additional rules: [none]. FDP_ACF.1.4/IA: The TSF shall explicitly deny accessof subjectsto objectsbased on the following additional rules: [none]. 7.1.1.1.9 FDP_ACC.2/PSA Complete AccessControl – Accessto PSP-Specific Services FDP_ACC.2.1/PSA: The TSF shall enforce the [PSP-specific servicesaccesscontrol policy] on [subjects: partitions, objects: PSP-specific services] and all operationsamong subjectsand objects covered by the SFP. FDP_ACC.2.2/PSA: The TSF shall ensure that all operationsbetween any subject controlled by the TSF and any object controlled by the TSF are covered by an accesscontrol SFP. 7.1.1.1.10FDP_ACF.1/PSA Security Attribute Based AccessControl – Accessto PSP-Specific Services FDP_ACF.1.1/PSA: The TSF shall enforce the [PSP-specific servicesaccesscontrol policy] to objects based on the following: [subjects: partitions, objects: interrupts, security attributes: partition ID, attributesdefined for filesin the configuration element of the partition in the VMIT]. FDP_ACF.1.2/PSA: The TSF shall enforce the following rulesto determine if an operation among controlled subjectsand controlled objectsisallowed: [ The operation of invoking a PSP-specific service PS (p4_dev_call) isallowed to a subject in partition PA if: • PS isspecified in a property file system node PN • The element of PA hasan element of type where the attribute matchesto the PN and attribute AM • A subject in partition PA hassuccessfully performed an open operation (vm_open) on the property node PN with accessflagsincluding and being subset of AM, resulting in file descriptor FD Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 37 of 47 • A subject in partition PA hassuccessfully performed vm_prop_dev_grant with the file descriptor FD, giving accessto the PSP-specific service PS ]. FDP_ACF.1.3/PSA: The TSF shall explicitly authorize accessof subjectsto objectsbased on the following additional rules: [none]. FDP_ACF.1.4/PSA: The TSF shall explicitly deny accessof subjectsto objectsbased on the following additional rules: [none]. 7.1.1.1.11FDP_ACC.2/CCA Complete AccessControl – CPU Core AccessControl FDP_ACC.2.1/CCA: The TSF shall enforce the [CPU core accesscontrol policy] on [subjects: partitions, objects: CPU cores] and all operationsamong subjectsand objectscovered by the SFP. FDP_ACC.2.2/CCA: The TSF shall ensure that all operationsbetween any subject controlled by the TSF and any object controlled by the TSF are covered by an accesscontrol SFP. 7.1.1.1.12FDP_ACF.1/CCA Security Attribute Based AccessControl – CPU Core Access Control FDP_ACF.1.1/CCA: The TSF shall enforce the[CPU core accesscontrol policy] to objectsbased on the following: [subjects: partitions, objects: CPU cores, security attributes: partition ID, CPU coresin the configuration element of the partition in the VMIT]. FDP_ACF.1.2/CCA: The TSF shall enforce thefollowing rulesto determine if an operation among controlled subjectsand controlled objectsisallowed: [ • The partitionPA can run a thread on CPU core C if the element of PA hasset the Cth bit in the .] FDP_ACF.1.3/CCA: The TSF shall explicitly authorize accessof subjectsto objectsbased on the following additional rules: [none]. FDP_ACF.1.4/CCA: The TSF shall explicitly deny accessof subjectsto objectsbased on the following additional rules: [none]. 7.1.1.2 FDP_IFC.2 Complete Information Flow Control FDP_IFC.2.1: The TSF shall enforce the [IPC and event communication policy] on • [all subjects: partitions] and all operationsthat cause that informationto flow to and from subjectscovered by the SFP. FDP_IFC.2.2: The TSF shall ensure that all operationsthat cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. 7.1.1.3 FDP_IFF.1 Simple Security Attributes FDP_IFF.1.1: The TSF shall enforce the [IPC and event communication policy] based on the following typesof subject and informationsecurity attributes: [ • subject identity: thread ID • information security attributes: file accesspermissionsto a filemarked with attribute or ] 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 ruleshold: [ The operation signal event (p4_ev_signal) or send IPC (p4_ipc), from a thread in partition PA1 to a subject in partition PA2 or vice versa isallowed if Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 38 of 47 • the VMIT specifiesthat partition PA1 providesa file F with attribute AND • the of PA2 hasan element of type where attribute isAM and attribute matchesF AND • PA1 hassuccessfully registered the fileprovider (vm_fp_register) with the TOE AND • a subject in PA2 hassuccessfully performed an open operation (vm_open) on file F with accessflagsbeing subset of AM OR • the VMIT specifiesthat partition PA1 providesa volume V with attribute AND • the of PA2 hasan element of type where is AM and contains and attribute matchesV AND • PA1 hassuccessfully registered the volume provider (vm_vp_register) with the TOE AND • a subject in PA2 hassuccessfully performed a mount operation(vm_mount) on V with access flagsbeingsubset of AM] FDP_IFF.1.3: The TSF shall enforce the [additional information flow rules: none]. FDP_IFF.1.4: The TSF shall explicitly authorize an information flow based on the following rules: [none]. FDP_IFF.1.5: The TSF shall explicitly deny an information flow based on the following rules: [none]. 7.1.2 Identification and Authentication (FIA) 7.1.2.1 FIA_UID.2 User Identification FIA_UID.2.1: The TSF shall require each user partition to be successfully identified before allowing any other TSF-mediated actionson behalf of that user partition. Application Note: A “user” of the TOE isa partition. 7.1.3 Security Management (FMT) 7.1.3.1 FMT_MSA.1 Management of Security Attributes FMT_MSA.1.1: The TSF shall enforce the [IPC and event communication policy, memory access control policy, file accesscontrol policy, communication port accesscontrol policy, PSP-specific servicesaccesscontrol policy, interrupt accesscontrol policy, CPU core accesscontrol policy] to restrict the ability to [write] the security attributes[specified in the VMIT and property file system] to [system partitions]. 7.1.3.2 FMT_MSA.3 Static Policy Attribute Initialization FMT_MSA.3.1: The TSF shall enforce the [IPC and event communication policy, memory access control policy, file accesscontrol policy, communication port accesscontrol policy, PSP-specific Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 39 of 47 servicesaccesscontrol policy, interrupt accesscontrol policy, CPU core accesscontrol policy] to provide [restrictive or integrator-defined] default valuesfor security attributesthat are used to enforce the SFP. Application Note: Theintegrator definesthe VMIT. The VMIT isused by the TSF asthe source of initial SSP values. If an attribute isnot defined by the integrator in the VMIT for a subject, then the default isto deny any operationsinvolving thisattribute, i.e. a white list security policy isimplemented. Thisbehavior isspecified in FMT_MSA.3.1 as“restrictive default values”. Attributeswith integrator- defined valuesin the VMIT are also initial valuesfor the TSF. Thisbehavior isspecified in FMT_MSA.3.1 as“integrator-defined default values”. FMT_MSA.3.2: The TSF shall allow [no one] to specify alternative initial valuesto override the default valueswhen an object or information iscreated. Application Note: TheTSF doesnot have any functionality for specifying alternative initial valuesto override the default values. 7.1.3.3 FMT_MTD.1/SYS Management of TSF Data – System Partition API FMT_MTD.1.1/SYS: The TSF shall restrict the ability to [invoke] the [System Partition API] to [system partitions]. Application Note: The complete definitionof the System Partition API isgiven in the TOE User Manuals. 7.1.3.4 FMT_MTD.1/TASK Management of TSF Data – Tasks FMT_MTD.1.1/TASK: The TSF shall restrict the ability to [ • activate (p4_task_activate) • terminate (p4_task_terminate) • modify (p4_comm_grant, p4_comm_link, p4_dev_grant, p4_dev_link, p4_int_grant, p4_int_link, p4_task_start, p4_task_donate, p4_task_hm_register, p4_task_hm_wait, p4_task_hm_wake) • read (p4_task_get_attr) ] the [tasks] to [the owning partition or system partitions]. Application Note: Tasks are also TSF data. A partition owns a taskif the taskis assigned to it by the integrator in the VMIT. 7.1.3.5 FMT_MTD.1/THR Management of TSF Data – Threads FMT_MTD.1.1/THR: The TSF shall restrict the ability to [ • create (p4_thread_create_syscall) • delete (p4_thread_delete) • modify (p4_fast_set_prio, p4_thread_alarm_syscall, p4_thread_ex_affinity, p4_thread_ex_exh, p4_thread_ex_priority, p4_thread_ex_regs, p4_thread_ex_sched_syscall, p4_thread_except, p4_thread_preempt, p4_thread_resume, p4_thread_set_regs, p4_thread_stop_syscall, p4_thread_yield) • read (p4_fast_get_prio_syscall, p4_my_cpuid, p4_my_uid_syscall, p4_thread_get_attr, p4_thread_get_regs) ] the [threads] to [the owning partition or system partitions]. Application Note: Threadsare also TSF data. A partition ownsa thread if the thread iscreated by one of itsapplications. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 40 of 47 7.1.3.6 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1: The TSF shall be capable of performing the following management functions: [ • thread management • task management • TOE management (System Partition API) ] 7.1.3.7 FMT_SMR.1 Security Roles FMT_SMR.1.1: The TSF shall maintain the roles: [ • “system partition” and • “normal partition”. ] FMT_SMR.1.2: The TSF shall be able to associate userspartitionswith roles. Application Note: TheTSF supportsroleson partition granularity. 7.1.4 Resource Utilization (FRU) 7.1.4.1 FRU_RSA.2/MEM Minimum and Maximum Quotas – Memory FRU_RSA.2.1/MEM: The TSF shall enforce maximum quotasof the following resources: [ • System memory: the maximum amount of system memory isthe sum of the sizesof all elementsof type with attribute set to or of type assigned to that partition in the VMIT ] that subjects, which are thenon-privilegedexecutablesin a normal partition can use simultaneously. FRU_RSA.2.2/MEM: The TSF shall ensure theprovision of minimum quantity of each: [ • System memory: the minimum amount of system memory isthe sum of the sizesof all elementsof type with attribute set to or of type assigned to that partition in the VMIT ] that isavailable for subjects, which are the non-privileged executablesin a normal partition to use simultaneously. 7.1.4.2 FRU_RSA.2/TIME Minimum and Maximum Quotas – Processing Time FRU_RSA.2.1/TIME: The TSF shall enforce maximum quotasof the following resources: [ • Processing time: the maximum amount of CPU processing time isthe sum of the attributesof assigned elementsof its in the VMIT ] that subjects, which are thenon-privilegedexecutablesin a normal partition can use over a specified period of time. FRU_RSA.2.2/TIME: The TSF shall ensure the provision of minimum quantity of each: [ • Processing time: if time windowsare assigned to a partition exclusively, the minimum amount of CPU processing time isthe sum of the attributesof assigned elementsof its in the VMIT ] that isavailable for subjects, which are the non-privileged executablesin a normal partition to use over a specified period of time. Application Note: The“specified period of time” isthe sum of the attributesof all elementsthe . The schedule scheme isrepeated with cyclic periodicity. Application Note: If a window isassignedto more than onepartition, i.e. the window isnot assigned Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 41 of 47 exclusively, the integrator can use the attributesfor partitionssharing the window to set up a sharing scheme for the CPU processing time within that window. 7.2 Security Assurance Requirements ThisST claimsconformance to the assurance level EAL 3 augmented with ALC_FLR.3. For the security assurance requirement AVA_VAN.2 of EAL 3, the following refinement isused in AVA_VAN.2.4E: “The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determinethat the TOE isresistant to attacksperformed by an attacker possessing Enhanced-Basic attackpotential.” 7.3 Security Requirements Rationale The following table providesan overview for security functional requirementscoverage also giving an evidence for sufficiency and necessity of the SFRschosen. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 42 of 47 OT.CONFIDENTIALITY OT.INTEGRITY OT.RESOURCE_AVAILABILIT Y OT.API_PROTECTION FDP_ACC.2/MA X X X FDP_ACF.1/MA X X X FDP_ACC.2/FA X X FDP_ACF.1/FA X X FDP_ACC.2/CPA X X FDP_ACF.1/CPA X X FDP_ACC.2/IA X X FDP_ACF.1/IA X X FDP_ACC.2/PSA X X FDP_ACF.1/PSA X X FDP_ACC.2/CCA X X FDP_ACF.1/CCA X X FDP_IFC.2 X FDP_IFF.1 X FIA_UID.2 X X FMT_MSA.1 X X FMT_MSA.3 X X FMT_MTD.1/SYS X FMT_MTD.1/TASK X FMT_MTD.1/THR X FMT_SMF.1 X FMT_SMR.1 X X FRU_RSA.2/MEM X X FRU_RSA.2/TIME X X Table 6: Coverage of Security Objectivesfor the TOE by SFR. “X” isfor where a dependency to an objective exists. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 43 of 47 7.3.1 Security Objective: OT.CONFIDENTIALITY For all assets, the operationsof non-privileged executablesare controlled by the TSF: • For the asset AS.MEM the SFRsFDP_ACC.2/MA and FDP_ACF.1/MA ensure that non-privileged executablescan only accessmemory (AS.MEM) according to the SSP. • For the asset AS.FILE the SFRsFDP_ACC.2/FA and FDP_ACF.1/FA ensure that non-privileged executablescan only accessfiles(AS.FILE) according to the SSP. • For the asset AS.PORT the SFRsFDP_ACC.2/CPA and FDP_ACF.1/CPA ensure that non- privileged executablescan only accesscommunication ports(AS.PORT) according to the SSP. • For the asset AS.INT the SFRsFDP_ACC.2/IA and FDP_ACF.1/IA ensure that non-privileged executablescan only accessinterrupts(AS.INT) according to the SSP. • For the asset AS.PS the SFRsFDP_ACC.2/PSA and FDP_ACF.1/PSA ensure that non-privileged executablescan only accessPSP-specific services(AS.PSA) according to the SSP. • For the asset AS.CORE the SFRsFDP_ACC.2/CCA and FDP_ACF.1/CCA ensure that non- privileged executablescan only accessCPU cores(AS.CORE) according to theSSP. • For the asset AS.TSF_DATA, the TSF configuresthe MMU to disallow non-privileged executables to accessthe memory of any of these other assets(i.e., the memory used for AS.TASK, AS.TSF_DATA and AS.THR). The TSF data also includesall security attributesthat TSF usesto manage any asset (e.g. security attributesfor file accessrightsor the schedule schemesused for assignment of CPU processing time). FIA_UID.2 ensuresthat partitionsare identified; FMT_SMR.1 providessecurity rolesto partitions. FMT_MSA.1 restrictsthe ability to write the security attributesspecifiedin the VMIT and the property file system to system partitions. FMT_MSA.3 providesrestrictive or integrator-defined default values for security attributes. FDP_IFF.1, FDP_IFC.2 ensure that IPC and event communication information flowsoriginating from non-privileged executablesare restricted to information flowsallowed according to the SSP. FRU_RSA.2/MEM ensuresthat no information flow against the SSP can be initiated by memory depletion. FRU_RSA.2/TIME ensuresthat no information flow against the SSP can be initiated by CPU processing time depletion. 7.3.2 Security Objective: OT.INTEGRITY For all assets, the operationsof non-privileged executablesare controlled by the TSF: • For the asset AS.MEM the SFRsFDP_ACC.2/MA and FDP_ACF.1/MA ensure that non-privileged executablescan only accessmemory (AS.MEM) according to the SSP. • For the asset AS.FILE the SFRsFDP_ACC.2/FA and FDP_ACF.1/FA ensure that non-privileged executablescan only accessfiles(AS.FILE) according to the SSP. • For the asset AS.PORT the SFRsFDP_ACC.2/CPA and FDP_ACF.1/CPA ensure that non- privileged executablescan only accesscommunication ports(AS.PORT) according to the SSP. • For the asset AS.INT the SFRsFDP_ACC.2/IA and FDP_ACF.1/IA ensure that non-privileged executablescan only accessinterrupts(AS.INT) according to the SSP. • For the asset AS.PS the SFRsFDP_ACC.2/PSA and FDP_ACF.1/PSA ensure that non-privileged executablescan only accessPSP-specific services(AS.PSA) according to the SSP. • For the asset AS.CORE the SFRsFDP_ACC.2/CCA and FDP_ACF.1/CCA ensure that non- privileged executablescan only accessCPU cores(AS.CORE) according to theSSP. • For the asset AS.TSF_DATA, the TSF configuresthe MMU to disallow non-privileged executables to accessthe memory of any of these other assets(i.e., the memory used for AS.TASK, AS.TSF_DATA and AS.THR). The TSF data also includesall security attributesthat TSF usesto Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 44 of 47 manage any asset (e.g. security attributesfor file accessrightsor the schedule schemesused for assignment of CPU processing time). FIA_UID.2 ensuresthat partitionsare identified; FMT_SMR.1 providessecurity rolesto partitions. FMT_MSA.1 restrictsthe ability to write the security attributesspecifiedin the VMIT and the property file system to system partitions. FMT_MSA.3 providesrestrictive or integrator-defined default values for security attributes. 7.3.3 Security Objective: OT.RESOURCE_AVAILABILITY • For the assetsAS.MEM and AS.KMEM, FRU_RSA.2/MEM ensuresthat limitsare enforced according to the SSP on the minimum and maximum amount of memory (AS.MEM) and exclusive hypervisor memory (AS.KMEM) available to non-privileged applicationsin normal partitions. • For the asset processing time (AS.TIME), FRU_RSA.2/TIME ensuresthat limitsare enforced according to the SSP on the minimum and maximum processing time (AS.TIME) available to non- privileged applicationsin normal partitions. These limitsalso ensure that resourcesused for AS.TASK, AS.TSF_DATA and AS.THR are not depleted through operationsof non-privileged executables. 7.3.4 Security Objective: OT.API_PROTECTION FMT_SMF.1 specifiesthat the management API can be used for management of threads, tasks and the TOE. FMT_MTD.1/SYS ensuresthat the TOE preventsaccessfrom normal partitionsto the system application API. FMT_MTD.1/TASK restrictsthe accessthat a normal partition hasvia the normal partitionAPI to tasks that the normal partition owns. FMT_MTD.1/THR restrictsthe accessthat a normal partition hasvia the normal partition API to threadsthat the normal partition owns. All other APIsreserved for privileged executables(PSP, system extensionsand kernel device drivers) only can be reached from executableslinked to the TOE. FDP_ACC.2/MA and FDP_ACF.1/MA ensure that the TOE preventsany execution of the APIsby non- privileged applications. 7.3.5 Security Assurance Requirements Rationale EAL 3+ hasbeen considered appropriate to ensure the robust and reliable separation of partitions. ALC_FLR.3 hasbeen included to ensure that integratorsunderstand how to submit security flaw reportsto SYSGO and how to register themselveswith SYSGO so that they may receive these corrective fixes. AVA_VAN.2.4E hasbeen refined to elevate the vulnerability analysisto one required for attackpotential of “enhanced-basic” in order to support compatibility with [ANSSI15]. 7.3.6 Security Assurance Requirements Dependency Analysis In thissection, we provide a dependency analysisfor the security assurance requirementsasdefined by the CC. There are no unfulfilled dependencies. ThisST claimsconformance to the standard EAL 3 package. For the EAL 3 standard package, all dependenciesin CC v3.1 part 3 provided packagesare fulfilled. ALC_FLR.3 dependson: No dependencies. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 45 of 47 8 TOE SummarySpecification Thissection describeshow each TOE Security Service defined in Section 2.4.6 isimplemented and coversitsSFRs. TSS_SSA: Separation in space of applications hostedin different partitions from each other and from the PikeOS Operating System according to the SSP: Applicationscan be hosted in different partitions. Partitionsget assigned resources(i.e. space) according to the SSP, which comprise memory rangesand a set of CPUs. The TSF enforcesthe corresponding part of the SSP by the enforcement of accesscontrol on partition content, per-partition provision of physical memory space and allocated CPU time for each CPU. By confining non-privileged executablesinto partitions, the TSF enforcesthat these applicationscan affect neither applicationsin other partitionsnor the PikeOS Operating System itself. The TSF definesseparatedsecurity domainsvia pagetables. For memory (AS.MEM) the SFRs FDP_ACC.2/MA and FDP_ACF.1/MA are implemented because the TSF configuresthe MMU to use these page tablesto confine singleload/store operationswithin a predefined physical memory. For interrupts(AS.INT) the SFRsFDP_ACC.2/IA and FDP_ACF.1/IA are implemented and ensure that non-privileged executablescan only accessinterruptsaccording to the SSP. For PSP-specific services(AS.PS) the SFRsFDP_ACC.2/PSA and FDP_ACF.1/PSA are implemented and ensure that non-privileged executablescan only accessPSP-specific services according to the SSP. For CPU cores(AS.CORE) the SFRsFDP_ACC.2/CCA and FDP_ACF.1/CCA are implemented and ensure that non-privileged executablescan only accessCPU coresaccording to theSSP. FRU_RSA.2/MEM (AS.MEM and AS.KMEM) isimplementedbecause limitson the minimum and maximum amount of memory available to non-privileged executablesin normal partitionsare enforced according to the SSP. Separationin space includesaccesscontrol to devicesvia device drivers, e.g. Ethernet or USB drivers. The driverscan be configured by the SSP to be contained in a partition. Separationin space also includesexecution of industrial APIs/libraries. These APIs/librariescan be run asnon-privileged executables, for example POSIX, ARINC 653 (APEX), Linux, RTEMS, OSEK, and thuscannot bypassthe SSP. TSS_STA: Separation in time of applications hosted in different partitions from each other and from the PikeOS Operating System according to the SSP: Applicationscan be hosted in different partitions. Partitionsget assigned CPU time (i.e. time windows) according to the SSP. The TSF enforcesthe corresponding part of the SSP by per-partition allocation of a predefinedamount of CPU time for each CPU. On a partition switch CPUswill be reused. FRU_RSA.2/TIME isimplemented because limitson the minimum and maximum amount of processing time available to non-privileged executablesin normal partitionsare enforced according to the SSP. TSS_COM: Provisionand management of communication objects: Applicationshosted in different partitionscan get assigned a set of communication objects. A communication object isan object exposed to one or multiple partitionswith accessrightsasdefined in the configuration data, thusallowing communication between partitions. For communication ports(AS.PORT) the SFRsFDP_ACC.2/CPA and FDP_ACF.1/CPA are implemented and ensure that non-privileged executablescan only accesscommunication ports according to the SSP. For files(AS.FILE) the SFRsFDP_ACC.2/FA and FDP_ACF.1/FA are implemented and ensure that non-privileged executablescan only accessfilesaccordingto the SSP. For memory that isused asshared memory (AS.MEM) FDP_ACC.2/MA and FDP_ACF.1/MA are Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 46 of 47 implemented because the TSF configuresthe MMU to use these page tablesto confine single load/store operationswithin a predefined physical memory. For IPC and event communication, FDP_IFC.2 and FDP_IFF.1 are implemented by providing communication objectsand because information flowsoriginating from non-privileged executablesare restricted to information flowsallowed by the SSP. TSS_MAN: Management of the TOE (e.g. system partition API) and the TOE data (e.g. threads, tasks): The TSF protectsthe confidentiality and integrity of TSF data and the availability of resources. FIA_UID.2 isimplemented by requiring each partition to be successfully identified before allowing any other TSF-mediated actionson behalf of that application. FMT_MSA.1 isimplemented because the TSF restrictsthe ability to write the security attributesspecified in the VMIT and the property file system to system partitions. FMT_MSA.3 isimplemented because the TSF providesrestrictive or integrator-defined default valuesfor security attributesthat are used to enforce the SFP. FMT_SMF.1 is implemented because the TSF providesfunctionsfor thread management, taskmanagement and TOE management (System Partition API). FMT_MTD.1/SYS isimplemented because the TOE preventsany accessof a non-privileged executable to the system partition API. FMT_MTD.1/TASK is implemented because the TOE restrictsthe accessto tasks that a non-privileged executable hasto tasks that itsnormal partition owns. FMT_MTD.1/THR isimplemented because the TOE restrictsany accessof a non-privileged executable the accessto threadsthat itspartition to threadsthat itspartition owns. FMT_SMR.1 isimplemented by assigningthe roles“system partition” and “normal partition” and associating each partition with a role. Doc. ID: 00101-8000-ST Revision: 20.6  Copyright 2018 All rightsreserved. SYSGO AG Page 47 of 47 9 Acknowledgment Part of thisST isbased on SKPP [Inf07, LNIM10], OSPP [OSPP], HASK-PP [Bun08]. ThisST has benefited from the workin the TECOM (FP7 grant 216888), SeSaM (BMBF grants01BY1120 to 01BY1123), PASS (BMWi grant 01 MD 16002D) and EURO-MILS (FP7 grant 318353) projects.