Martin Stein d8a71e5978 tresor: improved module framework and clean-up
* Make command pool a proper module
  * The command pool used to be kind of a module but it was driven via custom
    tresor-tester specific code. Now, it becomes a proper module that
    is driven by the module framework instead.
  * Move the code for creating and handling the module-execution progress flag
    into Module_composition::execute_modules as the function is always used with
    this code surrounding it.

* Reorganize files, remove deprecated files

* A new class Module_channel is introduced in the module framework and all
  channel classes inherit from it. With that class in place, the formerly
  module-specific implementations of the following methods are replaced by
  new generic implementations in the Module framework:

  * ready_to_submit_request
  * submit_request
  * _peek_completed_request
  * _drop_completed_request
  * _peek_generated_request
  * _drop_generated_request
  * generated_request_complete

* Module requests are now held for the duration of their lifetime at the
  module they originate from and not, like before, at their target module. As
  a result, modules can generate new requests inline (without having to wait
  for the target module), making code much simpler to read, reducing the amount
  of channel state, and allowing for non-copyable request types.

* Introduce a sub-state-machine for securing a superblock in the
  superblock_control module in order to reduce redundancy.

* Some modules, like free_tree, were completely re-designed in order to make
  them more readable.

* Replace all conditional exceptions by using the macros in
  tresor/assertion.h .

* Move methods that are used in multiple modules but that were implemented
  redundantly in each module to tresor/types.h.

* Remove verbosity node and all that was related to it from tresor tester
  config as the targeted verbosity can be achieved with the
  VERBOSE_MODULE_COMMUNICATION flag in tresor/verbosity.h .

* Extract the aspect of translating the byte-granular I/O-requests to
  tresor-block requests from the tresor VFS-plugin and move it to a new module
  called splitter.

* Rename the files and interface of the hashing back-end to not reflect the used
  hashing algorithm/config anymore, while at the same time making the hashing
  interface strict regarding the used types.

* Introduce the NONCOPYABLE macro that makes marking a class noncopyable short
  and clear.

* Replace the former tresor/vfs_utilities.h/.cc with a new tresor/file.h
  that contains the classes Read_write_file and Write_only_file. These classes
  significantly simplify the modules crypto, block_io, and trust_anchor by
  moving the details of file access to a sub-state machine.

* The former, rather trivial block allocator module is replaced by a normal
  object of type Pba_allocator that must be provided by the client of the
  Sb_initializer (reference in the Sb_initializer_request).

Ref #5062

tresor: read uninitialized vbas as all zeroes

Virtual addresses in a Tresor container that were not yet written by the user
should always return a data block that is all-zeroes. This was the concept
right from the beginning of the project. However, somehow this aspect either
never got implement or got lost along the way.

Some context for understanding the commit: The Tresor doesn't initialize the
payload data blocks of a container when creating a new container as this would
be rather expensive. Instead, it marks the leaf metadata nodes of the
virtual-block-device tree (those that reference the payload data blocks in
physical address space) with generation 0.

Now, this commit ensures that, whenever the virtual-block-device module reads
such a generation-0 leaf, instead of asking the block_io and crypto to deliver
data from disc, it directly provides the user with 4K of zeroes.

Ref #5062
2024-04-12 15:00:45 +02:00
2020-03-26 11:38:54 +01:00
2023-03-13 14:32:53 +01:00
2024-02-29 11:35:41 +01:00

                      =================================
                      Genode Operating System Framework
                      =================================


This is the source code of Genode, which is a framework for creating
component-based operating systems. It combines capability-based security,
microkernel technology, sandboxed device drivers, and virtualization with
a novel operating system architecture. For a general overview about the
architecture, please refer to the project's official website:

:Website for the Genode OS Framework:

  [https://genode.org/documentation/general-overview]

Genode-based operating systems can be compiled for a variety of kernels: Linux,
L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom "hw"
microkernel for running Genode without a 3rd-party kernel. Whereas the Linux
version serves us as development vehicle and enables us to rapidly develop the
generic parts of the system, the actual target platforms of the framework are
microkernels. There is no "perfect" microkernel - and neither should there be
one. If a microkernel pretended to be fit for all use cases, it wouldn't be
"micro". Hence, all microkernels differ in terms of their respective features,
complexity, and supported hardware architectures.

Genode allows for the use of each of the supported kernels with a rich set of
device drivers, protocol stacks, libraries, and applications in a uniform way.
For developers, the framework provides an easy way to target multiple different
kernels instead of tying the development to a particular kernel technology. For
kernel developers, Genode contributes advanced workloads, stress-testing their
kernel, and enabling a variety of application use cases that would not be
possible otherwise. For users and system integrators, it enables the choice of
the kernel that fits best with the requirements at hand for the particular
usage scenario.


Documentation
#############

The primary documentation is the book "Genode Foundations", which is available
on the front page of the Genode website:

:Download the book "Genode Foundations":

  [https://genode.org]

The book describes Genode in a holistic and comprehensive way. It equips you
with a thorough understanding of the architecture, assists developers with the
explanation of the development environment and system configuration, and
provides a look under the hood of the framework. Furthermore, it contains the
specification of the framework's programming interface.

The project has a quarterly release cycle. Each version is accompanied with
detailed release documentation, which is available at the documentation
section of the project website:

:Release documentation:

  [https://genode.org/documentation/release-notes/]


Directory overview
##################

The source tree is composed of the following subdirectories:

:'doc':

  This directory contains general documentation along with a comprehensive
  collection of release notes.

:'repos':

  This directory contains the source code, organized in so-called source-code
  repositories. Please refer to the README file in the 'repos' directory to
  learn more about the roles of the individual repositories.

:'tool':

  Source-code management tools and scripts. Please refer to the README file
  contained in the directory.


Additional hardware support
###########################

The framework supports a variety of hardware platforms such as different ARM
SoC families via supplemental repositories.

:Repositories maintained by Genode Labs:

  [https://github.com/orgs/genodelabs/repositories]


Additional community-maintained components
##########################################

The components found within the main source tree are complemented by a growing
library of additional software, which can be seamlessly integrated into Genode
system scenarios.

:Genode-world repository:

  [https://github.com/genodelabs/genode-world]


Community blog
##############

Genodians.org presents ideas, announcements, experience stories, and tutorials
around Genode, informally written by Genode users and developers.

:Genodians.org:

  [https://genodians.org]


Contact
#######

The best way to get in touch with Genode developers and users is the project's
mailing list. Please feel welcome to join in!

:Genode Mailing Lists:

  [https://genode.org/community/mailing-lists]


Commercial support
##################

The driving force behind the Genode OS Framework is the German company Genode
Labs. The company offers commercial licensing, trainings, support, and
contracted development work:

:Genode Labs website:

  [https://www.genode-labs.com]

Languages
C++ 73.7%
C 17.9%
Makefile 4.4%
Tcl 1.3%
PHP 1%
Other 1.5%