4 Commits

Author	SHA1	Message	Date
Martin Stein	b903ddeea7	tresor: fix and test handling of minimal trees ... * add testing of trees with minimal and maximal dimensions to tresor_tester.run * replace tresor_init-local configuration type with simpler and more conformant configuration type in tresor/types.h that does also XML-parsing and XML-generation of configurations * raise min degree to 2 because a degree of 1 is not practical und would require additional logic * fix overflow with num_blocks=0 in Superblock_control::Read|Write_vbas * fix off-by-one bug regarding the number of levels in Vbd_initializer * improve sanity checks in Tree_configuration constructors * document level indices in tresor_init/README * fix size of some arrays in order to be able to handle the maximum number of tree levels Ref #5077	2024-04-12 15:00:46 +02:00
Martin Stein	b4c4681733	tresor: streamline design further ... * differentiates request types that where merged formerly per module; e.g. instead of type Superblock_control::Request, there are now types * Superblock_control::Read_vbas * Superblock_control::Write_vbas * Superblock_control::Rekey * Superblock_control::Initialize * ... each holding only the state and functionality that is required for exactly that request * removes all classes of the Tresor module framework and adapts all Tresor- and File-Vault- related libs, apps, and tests accordingly * the former "channel" state is merged into the new request types, meaning, a request manages no longer only the "call" to a functionality but also the execution of that functionality; every request has a lifetime equal to the "call" and an execute method to be driven forward * state that is used by a request but has a longer lifetime (e.g. VFS file handles in Tresor::Crypto) is managed by the top level of the user and handed over via the execute arguments; however, the synchronization of multiple requests on this state is done by the module (e.g. Tresor::Crypto) * requests are now driven explicitly as first argument of the (overloaded) execute method of their module; the module can, however, stall a request by returning false without doing anything (used for synchronization on resources) * introduces Request_helper, Generated_request and Generatable_request in the Tresor namespace in order to avoid the redundancy of sub-request generation and execution * moves access to Client-Data pointers up to Tresor::Virtual_block_device in order to simplify Tresor::Block_io and Tresor::Crypto * removes Tresor::Client_data and introduces pure interface Client_data_interface in order to remove Tresor::Client_data and move management of Client Data to the top level of a Tresor user * introduces pure interface Crypto_files_interface in order to move management of Crypto files to the top level of a Tresor user * moves management of Block-IO and Trust-Anchor files to the top level of a Tresor user * adapts all execute methods, so, that they return the progress state instead of modifying a reference argument * removes Tresor::Request_and Tresor:Request and instead implements scheduling at the top level of the Tresor user * the Tresor Tester uses a list as schedule that holds Command objects; this list ensures, that commands are started in the order of configuration the Command type is a merge of the state of all possible commands that can be configured at the Tresor Tester; the actual Tresor requests (if any) are then allocated on-demand only * the Tresor VFS plugin does not use a dynamic data structure for scheduling; the plugin has 5 members that each reflect a distinct type of operation: * initialize operation * deinitialize operation * data operation * extend operation * rekey operation consequently, of each type, there can be only one operation in-flight at a time; at the user front-end each operation (except "initialize") can be controlled through a dedicated VFS file; for each of these files, the VFS expects only one handle to be open at a time and only one file operation (read, write, sync) active at a time; once an operation gets started it is finished without preemtion (except of the interleaving at rekey and extend); when multiple operations are waiting to be started the plugin follows a static priority scheme: init op > deinit op > data op > extend op > rekey op there are some operation-specific details * the initialize operation is started only by the plugin itself on startup and will be driven as side effect by subsequent user calls to file operations * the data file is the only contiguous file in the front end and the file operations work as on usual data files * the other 3 files are transactional files and the user is expected to follow this scheme when operating on them 1) stat (to determine file size) 2) seek to offset 0 3) read entire file once (this will be queued until there is no operation of this type pending anymore and return the last result: "none" | "failed" | "succeeded"; used primarily for synchronization) 4) write operation parameters (this returns immediately and marks the operation as "requested") 5) read entire file once (the same as above but this time in order to determine the operation result) * the rekey op and deinitialize op are requested by writing "true" * the extend op is requested by writing "tree=[TREE], blocks=[BLOCKS]" where TREE is either "vbd" or "ft" and BLOCKS is the number of physical 4K blocks by which the physical range of the tresor container expands (the physical range always starts at block address 0 and is always expanded upwards) * replaces the former <trust-anchor op="initialize"> command at the Tresor Tester with <initialize-trust-achor> as there are no other trust anchor operations that can be requested through the Tester config anyway * removes the "sync" attribute from all commands at the Tresor Tester except from <request op="rekey">, <request "extend_ft">, <request op="extend_vbd">; as the Tester controls scheduling now, requests are generally synchronous; at the rekeying and extension commands, the "sync" attribute determines wether subsequent commands are interleaved with the execution of these commands (if possible) * removes "debug" config attribute from Tresor VFS plugin and reworks "verbose" attribute to generate more sensible output * removes NONCOPYABLE macro and instead uses Genode::Noncopyable and in-place Constructors deletion * introduces types Attr and Execute_attr where a constructor or execute method have many arguments in order to raise readability * renames the "hashsum" file that is provided by the Tresor Trust-Anchor VFS plugin to "hash" in order to become conformant with the wording in the Tresor lib * makes the VFS Tresor test an automated test by merging in the functionality of vfs_tresor_init.run and removing the interactive front end; removes vfs_tresor_init.run as it is not needed anymore; adds consideration for autopilot file structure in the Test and adds it to autopilot.list * removes all snapshot controls and the progress files for rekeying and extending from the Tresor VFS plugin; both functionalities were tested only rudimentary by the VFS Tresor test and are not supported with the only real user, the File Vault * use /* .. */ instead of // .. * use (..) instead of { .. } in init lists Ref #5148	2024-04-12 15:00:45 +02:00
Norman Feske	5a75a2f930	gems: use [build_artifacts] in run scripts ... Issue #4860	2023-11-28 14:44:29 +01:00
Martin Stein	aeb65d6b1b	file_vault: version 23.05 ... * ARM support and detaching from Ada/SPARK * Remove all CBE-related code - especially the Ada/SPARK-based CBE library. * We have no means or motivation of further maintaining big projects in Ada/SPARK (the core Genode team is native to C++). * The Genode Ada/SPARK toolchain and runtime don't support ARM so far - an important architecture for Genode. This would mean extra commitment in Ada/SPARK. * We realize that block encryption more and more becomes a fundamental feature of Genode systems. * Implement a new block encryption library named Tresor that is inspired by the design and feature set of the former CBE library and that is entirely C++ and part of the Genode gems repository. * The Tresor block encryption is backwards-compatible with the on-disk data layout of the former CBE block encryption. * Except from the snapshot management and the "dump" tool, the Tresor block encryption provides the same feature set as the former CBE block encryption and accepts the same user requests at the level of the Tresor library API. * So far, the Tresor block encryption does not support the creation of user-defined snapshots. * In contrast to the former CBE, the Tresor ecosystem has no "dump" tool beause with the CBE library it turned out to be rarely of use. * In contrast to the Block back-end of the CBE "init" tool, the Tresor "init" tool uses a File System back-end. * The former CBE VFS-plugin is replaced with a new Tresor VFS-Plugin. * The Tresor-VFS plugin in general is similar to the former CBE VFS but has a slightly different API when it comes to re-keying and re-sizing. Each of these operations now is controlled via two files. The first file is named <operation> and the user writes the start command to it. The user must then read this file once in order to drive the operation. The read returns the result of the operation, once it is finished. The second file is named <operation>_progress and can be watched and read for obtaining the progress of the operation as percentage. * The file vault is adapted to use the new Tresor ecosystem instead of the former CBE ecosystem and thereby also gains ARM support. * The former CBE tester and CBE VFS-tests are replaced by equivalent Tresor variants and are now run on ARM as well (testing with a persistent storage back-end is supported only when running on Linux). * So far, the new Tresor block encryption has no internal cache for meta data blocks like the former CBE. * Add config/report user interface * Add a second option for the administration front end to the file vault named "config and report". With this front end the File Vault communicates with the user via XML strings. A ROM session is requested for user input and a Report session for user output. The front end type must be set at startup via the component config and is a static setting. The graphical front end that was used up to now is named "menu view" and remains the default. * The File Vault can now reflect its internal state and user input ("config and report" mode only) at the LOG session via two new static config attributes "verbose_state" and "verbose_ui_config" (both defaulting to "no"). * The Shutdown button in "menu view" mode is replaced with a Lock button. The new button doesn't terminate the File Vault but merely lock the encrypted container and return to a cleared passphrase input. The same transition is also provided in "config and report" mode. * The file_vault.run script is replaced with file_vault_menu_view.run and file_vault_cfg_report.run that address the two front end modes. In contrast to the former script, which is interactive, the latter script is suitable for automatic testing. * There is a new recipe/pkg/test-file_vault_cfg_report that essentially does the same as file_vault_cfg_report.run but uses the File Vault package and can be executed with the Depot Autopilot. The new test package is added to the default test list of depot_autopilot.run * The File Vault README is updated to the new version of the component and has gained a chapter "functional description". * Fixes a regression with the cbe_init_trust_anchor component that prevented reacting to a failed unlock attempt in the File Vault. * The new Tresor software Trust Anchor has an optional deterministic mode in which it replaces the normally randomized symmetric keys with 0. This mode comes in handy for debugging. However, it should never be activated in productive systems. When activated, the user is warned extensively on the LOG that this system mode is insecure. Ref #4819	2023-05-30 12:03:32 +02:00