---
# System prepended metadata

title: Arch. review

---

# Arch. review

## Executive summary

The aim of a project is to port PhantomOS to Genode to adapt it to the requirements of modern operating systems and to enhance its security, reliability, portability (TODO)

## Project description

## Functional requirements

> Also, what platforms + environment are targeted?
    > Modern real CPUs, 64 bit (TODO)
> What workload do we want to run on the system?

### Platform and enviroment

- To be used as platform for SCADA systems
- Should be able to run on ARM based CPUs
    - Target platform is Raspberry Pi 3 at the moment
    > Check NOVA/genode supported hardware 
    > x86 is better to start
- Environment does not guarantee an abscence of power outages

### Requirements

- Should be able to maintain consistent state of running programs in the presence of power outages and hardware malfunctions
- The system should provide multiprogramming environment
- The system should be able to run programs written in at least one mainstream high-level language
- System should provide POSIX compatibility layer
- System should be able to communicate with other systems using TCP/IP stack or other network protocols
- Also system should be able to interact with arbitary devices

## Business context

### Till the start

- Phantom OS is
    - experimental 
    - persistent
    - general purpose
- Allows running userspace programs in Phantom language and very basic Java programs using bytecode translation.
- Phantom VM (PVM) originally supposed to be compatible with JVM and it is planned to add Python support
- Was actively developing from 2009 to 2011
- Work continued in 2016 and 2019
- Founded and being developed by Dmitry Zavalishin, owner of Digital Zone holding.
- During that time only one developer with plenty of commits by other 4 temporary developers. Generally speaking, only one person knows how system works :)
- There is no running installations of system at the moment and no clients


### Current work

> Reformulate in terms of aim, not focus on work (TODO)

- Focus on IoT
- Shift focus towards security and reliability
- Provide a basis for a formal verification
- General aim: adjust the system to modern world and make it usable for, at least, some specific IoT tasks (base of SCADA system or smart home hub)

### Business constraints

- Time: Till the end of the next semester
- Money: Zavalishin is ready to invest, however not much. The business model of the project is not well developed yet.
- Team: Me, A. Tormasov as supervisor and D. Zavalishin for consultations
- Expertise: one 4-th year student and two supervisors with a lot of experience and high expertise in the field. Also other professors of university can help with some particular tasks

### Development constraints

- Technologies: C language, Genode OS Framework, C++17, java (compiler)
- Phantom is currently running in 32-bit mode only
- Legacy: A lot of untested code in C that was written in different time periods
- Lack of external code reviews and opinions from different developers as well
- A lot of documentation available, but certain documents are outdated
- Design decisions
    - Phantom has its own kernel
    - There is no clean way to separate UI from kernel and VM at the moment
    - Global lock during snapshot
    - Drivers are integrated into the kernel
    - Java programs are very limited since the standard library is not available as well as JNI

## Architectural drivers


> 1 - modern microkernels -> drivers (devices compatibility), security (close to stong typying of Phantom), platform compatibility, support, maintanence e.t.c.

> In general, define some environment, specific workloads so that it would be possible to define QAS better

// TODO : Formulate reasonable QASs

### General drivers of Phantom

> Also TODO
> What do we want to get and why its not yet acheived TODO
- interoperability with regular systems

| part               | content                                                                                         |
| ------------------ | ----------------------------------------------------------------------------------------------- |
| Source of stimulus | Programmer                                                                                      |
| Stimulus           | Wants PhantomOS to be able to communicate with non-Phantom system using TCP/IP stack            |
| Environment        | Normal execution                                                                                |
| Artifact           | Network driver, network OS components                                                           |
| Response           | Packets are sent                                                                                |
| Response measure   | Number of packets sent and succesfully processed comparing with the same number on Linux system |


> Reasoning for languages (how legacy code lifecycle might be organized TODO)
- interoperability of languages

| part               | content                                                        |
| ------------------ | -------------------------------------------------------------- |
| Source of stimulus | Programmer                                                     |
| Stimulus           | Wants run program compiled for JVM                             |
| Environment        | Normal execution                                               |
| Artifact           | JVM bytecode translator, Phantom Virtual Machine               |
| Response           | Code is translated and executed in PVM with the same behaviour |
| Response measure   | Tests written for this program are passing                     |


> What do we want to persist (TODO)
    > for example KeyKOS requirements
    > Find classification of fault tolerance, reliability
- reliability
    - Should persist restarts, power outages, kernel errors, hardware faults
    - data in the system should be able to persist restarts/unexpected shutdowns and be consistent after them
    - running program should be able to persist restarts/unexpected shutdowns and be able to restore from the last snapshot so that it would be seamless
    
    | part               | content                                                                       |
    | ------------------ | ----------------------------------------------------------------------------- |
    | Source of stimulus | External factor                                                               |
    | Stimulus           | Causes unexpected restart                                                     |
    | Environment        | Power outage or hardware malfunction                                          |
    | Artifact           | Whole operating system                                                        |
    | Response           | Userspace programs will start in the state same as right before the shutdown  |
    | Response measure   | Programs execution state and their data are in consistent state after restart |

- Robustness
    - it should be able to continue running or restart and restore from checkpoint if one or more components of the system malfunctioned
    
    | part               | content                                                                       |
    | ------------------ | ----------------------------------------------------------------------------- |
    | Source of stimulus | Internal error                                                                |
    | Stimulus           | Causes unexpected restart                                                     |
    | Environment        | Kernel error occured or OS component failure happened                         |
    | Artifact           | Whole operating system                                                        |
    | Response           | Userspace programs will start in the state same as right before the shutdown  |
    | Response measure   | Programs execution state and their data are in consistent state after restart |

- Performance
    - comparable performance relatively to modern systems
    
    | part               | content                                                                                  |
    | ------------------ | ---------------------------------------------------------------------------------------- |
    | Source of stimulus | User                                                                                     |
    | Stimulus           | System runs SCADA workloads                                                              |
    | Environment        | Normal operation                                                                         |
    | Artifact           | Whole operating system                                                                   |
    | Response           | Execution time of operations performed is comparable to other OSs running same workloads |
    | Response measure   | Execution time on Phantom should be not more than 5% bigger comparing to Linux           |
    
    - small and predictable (as far as possible) restart time
    - small and predictable checkpointing time
    
    | part               | content                                                                                                |
    | ------------------ | ------------------------------------------------------------------------------------------------------ |
    | Source of stimulus | User                                                                                                   |
    | Stimulus           | Starts the system                                                                                      |
    | Environment        | Normal operation, attached devices have predictable initialization time                                |
    | Artifact           | Whole system                                                                                           |
    | Response           | The system should finish all initialization procedures in a small and predictable period of time       |
    | Response measure   | The system should start in less than 5 seconds (with adjustments given current hardware configuration) |

> TODO : Power saving (comes with performance)

- scalability
    - system should be able to use hardware accelerators
    
    | part               | content                                                                                                    |
    | ------------------ | ---------------------------------------------------------------------------------------------------------- |
    | Source of stimulus | User                                                                                                       |
    | Stimulus           | Installs the system on the hardware providing any kind of hardware acceleration with corresponding drivers |
    | Environment        | Normal operation                                                                                           |
    | Artifact           | Virtual machine, drivers                                                                                   |
    | Response           | Userspace programs should be able to use hardware acceleration                                             |
    | Response measure   | Code segments that are using hardware acceleration should be able to use it                                |
    
    - system should be able to scale to the given hardware resources
    
    | part               | content                                                                                            |
    | ------------------ | -------------------------------------------------------------------------------------------------- |
    | Source of stimulus | User                                                                                               |
    | Stimulus           | Installs system on the hardware with different CPU, memory and disk configurations                 |
    | Environment        | Normal operation                                                                                   |
    | Artifact           | Resource management system                                                                         |
    | Response           | System should be able to use all available cores, memory and disk space                            |
    | Response measure   | Userspace programs will be able to use more memory. More threads should be able to run in parallel |

- availability (?) 
    > Hardware abilities
    > Software solutions
    > Search internet TODO
    > Also hot updates

- debugability
    - system should provide debugger for userspace programs and kernel as well
        
    | part               | content                                                                                      |
    | ------------------ | -------------------------------------------------------------------------------------------- |
    | Source of stimulus | Developer                                                                                    |
    | Stimulus           | Wants to debug a program or new system feature                                               |
    | Environment        | Debugging                                                                                    |
    | Artifact           | Whole system                                                                                 |
    | Response           | Debugging interfaces should be provided                                                      |
    | Response measure   | Developer should easily access required debugging information and control the execution flow |

    

- extensibility
    - It should be possible to add new driver for new device as a separate component without modifications in the kernel or system in general
            
    | part               | content                                                                                   |
    | ------------------ | ----------------------------------------------------------------------------------------- |
    | Source of stimulus | Developer                                                                                 |
    | Stimulus           | Wants to add a new driver                                                                 |
    | Environment        | Development                                                                               |
    | Artifact           | Virtual machine, drivers                                                                  |
    | Response           | New driver will be added to the system                                                    |
    | Response measure   | Addition of a new driver should not affect the code of any other components of the system |

    
    - System should provide opportunity for adding new VM native methods to be called from userspace without modifications in the kernel or system in general

    | part               | content                                                                                   |
    | ------------------ | ----------------------------------------------------------------------------------------- |
    | Source of stimulus | Developer                                                                                 |
    | Stimulus           | Wants to add a new native method for virtual machine                                      |
    | Environment        | Development                                                                               |
    | Artifact           | Virtual machine, required by the method components                                        |
    | Response           | New method will be added to the system                                                    |
    | Response measure   | Addition of a new method should not affect the code of any other components of the system |
> TODO portability
    > drivers, other component (TODO)
    > Requirements from new network devices

> Different classes of new strorage technologies (in memory computations). Intel Optane e.t.c.
> CRIU and Optane, what benefits we can obtain
> Also to the top (TODO) hardware persistency 

- security
    > Check how modern OS and applications security requirements  (Rasheed Hussain)
    - atack on one component of the system should not affect others
    - userspace processes should not know about other processes without clear permission
    - userspace processes should not communicate with other processes without clear permission

    | part               | content                                                                |
    | ------------------ | ---------------------------------------------------------------------- |
    | Source of stimulus | Malicious code                                                         |
    | Stimulus           | Is being executed by one of the programs or components of the system   |
    | Environment        | Normal operation                                                       |
    | Artifact           | Affected program and modules it is using                               |
    | Response           | Malicious code can't see requested information or permission is denied |
    | Response measure   | No other modules or programs affected                                  |

// formal verification
    > Ask Naumchev
    > seL4 papers
    > Papers in general about formal verification
    > seL4 FOSDEM 


### Drivers related to the current project

## Architecture decisions

(CAUSES AND ALT)
- Translators provided for interoperability with other languages
    - 
- Checkpointing mechanism is used to provide orthogonal persistence, reliability and robustness
> Perisitence without persistence API (transparent)
- Security, extensibility and certain reliability issues may be solved using Genode

## Views :)

![](https://i.imgur.com/ZaeUgbv.jpg)
