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
..
2024-02-29 11:08:28 +01:00
2024-02-29 11:08:28 +01:00
2024-04-12 12:57:28 +02:00
2024-02-29 11:08:28 +01:00
2024-02-29 11:08:28 +01:00
2024-02-29 11:08:28 +01:00
2024-02-29 11:08:28 +01:00
2024-04-12 15:00:44 +02:00
2022-05-25 12:23:04 +02:00

                      ===============================
                      Genode source-code repositories
                      ===============================


This directory contains the source-code repositories of the Genode OS
Framework. Each sub directory has the same principle layout as described in the
build-system manual:

:Build-system manual:

  [https://genode.org/documentation/developer-resources/build_system]

The build system uses a configurable selection of those reposities to obtain
the source codes for the build process. The repositories are not independent
but build upon of each other:

:'base':

  This directory contains the source-code repository of the fundamental
  frameworks and interfaces of Genode. Furthermore, it contains the generic
  parts of core.

:'base-<platform>':
  These directories contain platform-specific source-code repositories
  complementing the 'base' repository. The following platforms are supported:

  :'hw':
    The hw platform hosts Genode on a custom microkernel specifically
    developed for Genode. The name "hw" denotes that Genode is executed on
    bare hardware without a 3rd-party kernel underneath.

  :'linux':
    Linux kernel (both x86_32 and x86_64)

  :'nova':
    NOVA hypervisor ([https://hypervisor.org])

  :'foc':
    Fiasco.OC is a modernized version of the Fiasco microkernel with a
    completely revised kernel interface fostering capability-based
    security. It is not compatible with L4/Fiasco.

  :'okl4':
    OKL4 kernel (x86_32 and ARM) developed at Open-Kernel-Labs.

  :'pistachio':
    L4ka::Pistachio kernel developed at University of Karlsruhe.

  :'fiasco':
    L4/Fiasco kernel developed at University of Technology Dresden.

  :'sel4':
    seL4 microkernel ([https://sel4.systems/])

:'os':

  This directory contains the non-base OS components such as the init
  component, device drivers, and basic system services.

:'demo':

  This directory contains the source-code repository of various services and
  applications that we use for demonstration purposes. For example, a graphical
  application launcher called Launchpad and the Scout tutorial browser.

:'hello_tutorial':

  Tutorial for creating a simple client-server scenario with Genode. This
  repository includes documentation and the complete source code.

:'libports':

  This source-code repository contains ports of popular open-source libraries
  to Genode, most importantly the C library. The repository contains no
  upstream source code but means to download the code and adapt it to Genode.
  For instructions about how to use this mechanism, please consult the README
  file at the top level of the repository. Among the 3rd-party libraries
  are Qt5, freetype, ncurses, and Mesa.

:'dde_linux':

  This source-code repository contains the device driver environment for
  executing Linux subsystems as Genode components.

:'dde_ipxe':

  This source-code repository contains the device-driver environment for
  executing network drivers of the iPXE project.

:'dde_bsd':

  This source-code repository contains the device-driver environment for
  drivers of the OpenBSD operating system.

:'dde_rump':

  This source-code repository contains the port of rump kernels, which are
  used to execute subsystems of the NetBSD kernel as user level processes.
  The repository contains a server that uses a rump kernel to provide
  various NetBSD file systems to Genode.

:'pc':
  This source-code repository hosts device drivers that are specific for PC
  platforms. It depends on the 'dde_linux' repository.

:'ports':

  This source-code repository hosts ports of 3rd-party applications to
  Genode. The repository does not contain upstream source code but provides
  a mechanism for downloading the official source distributions and adapt
  them to the Genode environment. The used mechanism is roughly the same
  as used for the 'libports' repository. Please consult 'libports/README'
  for further information.

:'gems':

  This source-code repository contains Genode applications that use
  both native Genode interfaces as well as features of other high-level
  repositories, in particular shared libraries provided by 'libports'.