# 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 :)