Instead of using the user passphrase directly, use its SHA256 hash calculated
using libcrypto. The passphrase hash is still stored in the key file to be
used as base for the very primitive way of generating the private key.
Ref #4032
Closing the keyfile handle after a write operation wasn't synchronised to the
actual end of the write operation.
Issuing a write operation at the back end returns successfull as soon as the
back end has acknowledged that it will execute the operation. However, the
actual writing of the data might still be in progress at this point. But the
plugin used to close the file handle and declare the operation finished at this
point which led to warnings about acks on unknown file handles and leaking
resources. Now, the plugin issues a sync operation directly after the write
operation and waits for the sync to complete. This ensures that the plugin
doesn't declare the operation finished too early.
Ref #4032
The unlocking operation in the trust anchor was broken wich caused bad keys in
the CBE. This rewrites the whole operation to work as desired. Note that this
doesn't make it more safe! The private key is still almost the same as the
passphrase and stored plaintext.
Ref #4032
The plugin used to close file handles via the 'vfs_env.root_dir.close'.
However, this lead to resource leaks and apparently isn't the right way to
do it. Other VFS plugins do it by calling 'close' directly on the handle and
doing it in the trust anchor plugin also, fixes the leaks.
Ref #4032
Closing the hashfile handle after a write operation wasn't synchronised to the
actual end of the write operation.
Issuing a write operation at the back end returns successfull as soon as the
back end has acknowledged that it will execute the operation. However, the
actual writing of the data might still be in progress at this point. But the
plugin used to close the file handle and declare the operation finished at this
point which led to warnings about acks on unknown file handles and leaking
resources. Now, the plugin issues a sync operation directly after the write
operation and waits for the sync to complete. This ensures that the plugin
doesn't declare the operation finished too early.
Ref #4032
There were no means for issuing a Deinitialize request at the CBE using the
CBE VFS plugin. The new control/deinitialize file fixes this. When writing
"true" to the file, a Deinitialize request is submitted at the CBE. When
reading the file, the state of the operation is returned as a string of the
format "[current_state] last-result: [last_result]" where [current_state] can
be "idle" or "in-progress" and [last_result] can be "none", "success", or
"failed".
Ref #4032
When discarding a snapshot, the CBE VFS plugin didn't communicate the ID of
the snapshot to the CBE. Instead it set the ID argument to 0. Therefore the
operation never had any effect.
Ref #4032
The snapshots file system used to return the number of snapshots on
'num_dirent' when called for the root directory although it was expected to
return 1. This confused the tooling ontop of the VFS.
Ref #4032
Despite being readable, the files control/extend and control/rekey proclaimed
that they were not when asked. This caused the fs_query tool to not report the
content of the files although it could have.
Ref #4032
Stat calls on the control/extend and control/rekey files returned a bogus file
size that led to an error in the VFS File_content tool. The tool complained
that the size of the file determined while reading the content differs from the
one reported by the stat operation. Now, the stat call will always determine
the actual size of what would be read. However, it isn't guaranteed that this
size doesn't change in the time after the stat operation and before the read
operation.
Ref #4032
The service is loaded dynamically VBoxSharedClipboard.so at runtime. The
VFS configuration mounts the shared object at /VBoxSharedClipboard.so as
the file is checked by contrib code before loading. An init
configuration in pkg/vbox6/runtime illustrates this and how to re-label
the VBoxSharedClipboard.so ROM to its real name
virtualbox6-sharedclipboard.lib.so.
During Windows 10 boot with sequential block requests, the AHCI request
worker finished earlier than the EMT thread signals hEvtProcess and
begins waiting for hEvtProcessAck indefinitely. The timeouts helps to
survive this short phase.
A better solution would use conditional variables, which are not
provided in VirtualBox's runtime.
This patch introduces a C API to be used by input drivers to generate
Genode events. The initial version is limited to multitouch events only.
Fixes#4273
* Use the architecture-dependent minimal alignment for all allocations,
e.g. on ARM it is necessary to have cacheline aligned allocations for DMA
* Remove the allocation functions without alignment from generic API
* Fix a warning
Fix#4268
After a DMA transaction do only invalidate cachelines from the
corresponding DMA buffers if data got transfered from device to
CPU, and not vice versa. Otherwise it might result in data corruption.
Ref #4268
The former implementation did not internally track ROM changes notified
vs. delivered to the client. We adapt the versioning implementation
implemented in dynamic_rom_session.h and enable explicit notification of
the current version.
The feature is used by the clipboard to notify permitted readers of the
clipboard ROM service on focus change via the newly created private
Rom::Module::_notify_permitted_readers() function.
Fixes#4274
The includes for the address-space-ID allocator and the translation table are
usually specific to the CPU in use. Therefore these includes can be moved from
their current location in the board header to the CPU headers. This reduces the
number of decisions a board maintainer has to make if the CPU model he's aiming
for is already available.
This can probably also be applied for other includes in the board headers but I
intentionally leave it for a future commit as I don't have the time to do it
all now.
Ref #4217
For base-hw Core, we used to add quite some hardware-specific include paths
to 'INC_DIR'. Generic code used to include, for instance, '<cpu.h>' and
'<translation_table.h>' using these implicit path resolutions. This commit
removes hardware-specific include paths except for
1) the '<board.h>' include paths (e.g., 'src/core/board/pbxa9'),
2) most architecture-specific include paths (e.g., 'src/core/spec/arm_v7'),
3) include paths that reflect usage of virtualization or ARM Trustzone
(e.g., 'src/core/spec/arm/virtualization').
The first category is kept because, in contrast to the former "spec"-mechanism,
the board variable used for this type of resolution is not deprecated and the
board headers are meant to be the front end of hardware-specific headers
towards generic code which is why they must be available generically via
'<board.h>'.
The second category is kept because it was suggested by other maintainers that
simple arch-dependent headers (like for the declaration of a CPU state) should
not imply the inclusion of the whole '<board.h>' and because the architecture
is given also without the former "spec"-mechanism through the type of the build
directory. I think this is questionable but am fine with it.
The third category is kept because the whole way of saying whether
virtualization resp. ARM Trustzone is used is done in an out-dated manner and
changing it now would blow up this commit a lot and exceed the time that I'm
willing to spend. This category should be subject to a future issue.
Ref #4217
The 'src/core/board/<board>/board.h' header is thought as front end of
hardware-specific headers of a given board towards the generic base-hw Core
code. Therefore it leads to problems (circular includes) if the board.h header
is included from within another hardware-specific header.
If hardware-specific headers access declarations from namespace Board in a
definition, the definition should be moved to a compilation unit that may
include board.h. If hardware-specific headers access declarations from board.h
in a declaration, they should either use the primary declaration from the
original header or, if the declaration must be selected according to the board,
another board-specific header should be introduced to reflect this abstraction.
This is applied by this commit for the current state of base-hw.
Ref #4217
It is not necessary to have a class, an object, and a generic header for the
perfomance counter. The kernel merely enables the counter using cpu registers
('msr' instructions, no MMIO) on arm_v6 and arm_v7 only. Therefore this commit
makes the header arm-specific and replaces class and global static object with
a function for enabling the counter.
Fixes#4217
Let the kernel's driver for the global IRQ controller be a member of the one
Kernel::Main object instead of having it as static variables in the drivers for
the local IRQ controllers. Note that this commit spares out renaming 'Pic' to
'Local_interrupt_controller' which would be more sensible now with the new
'Global_interrupt_controller' class. Furthermore, on ARM boards the commit
doesn't move 'Distributer' stuff to the new global IRQ controller class as they
don't have real data members (only MMIO) and can be instanciated for each CPU
anew. However, the right way would be to instanciate them only once in Main as
well.
Ref #4217
The unmanaged-singleton approach was used in this context only because of the
alignment requirement of the Core main-UTCB. This, however can also be achieved
with the new 'Aligned' utility, allowing the UTCB to be a member of the Core
main-thread object.
Ref #4217
It's sufficient to access the boot info only on kernel initialization time.
Therfore, it can remain completely hidden to the rest of the kernel inside
kernel/main.cc in the initialization function.
Ref #4217
This commit introduces the Kernel::Main class that replaces the former way of
initializing the kernel (former 'kernel_init' function) and calling the C++
kernel entry handler (former 'kernel' function). These two are now
'Main::initialize_and_handle_kernel_entry' and 'Main::handle_kernel_entry'.
Also reading the execution time of the idle threads was already moved to
'Main'. The one static Main instance is meant to successivly replace all the
global static objects of the base-hw kernel with data members of the Main
instance making the data model of the kernel much more comprehensible. The
instance and most of its interface are hidden in kernel/main.cc. There are only
rare cases where parts of the Main interface must be accessible from the
outside. This should be done in the most specific way possible (see main.h)
and, if possible, without handing out references to Main data members or the
Main instance itself.
Ref #4217
Normally, the board header can be found for each supported board under
'src/core/board/<BOARD>/board.h'. This was not the case for the board 'pc'
that was located under 'src/core/spec/x86_64/board.h'. The commit fixes this.
Ref #4217
The class name Core_thread in Kernel for the object of the first thread of
core is too generic as there can be an arbitrary number of threads in core
besides this one. Furthermore, creating a core thread has its own syscall
'new_core_thread' that isn't related in any way to Core_thread. Therefore
this commit introduces the more specific name Core_main_thread as replacement
for Core_thread.
Ref #4217
