The main user of libsparkcrypto in the past was the CBE block encryption
ecosystem. However, the CBE was replaced with the Tresor block encryption that
uses libcrypto instead.
Ref #4819
This commit introduces preliminary support for joining networks secured
via WPA3-personal. So far it was only tested with the one OpenWRT AP
configured for WPA3 (see excerpt below) where it WPA3-only as well as
WPA2/WPA3 mixed worked fine.
Scan results excerpt:
00:11:22:33:44:55 5180 -45 [WPA2-SAE-CCMP][SAE-H2E][ESS][UTF-8] PewPew
00:11:22:33:44:55 2412 -67 [WPA2-PSK+SAE+PSK-SHA256-CCMP][SAE-H2E][ESS][UTF-8] PewPew2
Issue #4861.
It turns out solely relying on the name of the compilation-unit
is not enough. In at least one multi-device driver, e.g. rtlwifi,
an equally called compilation-unit is found in several different
directories. There KBUILD_MODNAME is used to name the driver,
which fails later on as the driver framework refuses to register
an equally named driver twice.
Instead of only considering the name of the compilation-unit also
include the last element of the path to generate differentiating
KBUILD_MODNAME value.
Issue #4861.
The supplicant is updated to the current release and is now downloaded
as archive rather than pulled from git. For the time being 'libnl' is
still kept at 3.2.25 as the current 3.7.0 release relies on more Linux
infrastructure that our integration does not provide.
Issue #4861.
This commit changes the firmware handling from requesting each
firmware file as a ROM module that is checked against a list of
known images (including their size) to requesting each file via
the local VFS of the 'wifi_drv'. This allows for using the original
probing mechanism that tries to select a matching firmware version.
The 'repos/dde_linux/src/drivers/wifi/README' file contains more
detailed information on how to configure the driver.
Issue #4861.
This function is called when decrypting RX frames on the CPU on 32 bit
platforms. Since the frames are normally decrypted by the wireless LAN
device and this code path is triggered rather infrequently the byte-wise
implementation should not pose a performance risk.
So far it was only encounter with a 7260 device when running netperf.
Issue #4861.
The bulk of the driver code now lives in the 'dde_linux' repository,
which is available on all platforms, from where it can be referenced by
other repositories.
The 'wifi_drv' binary was delegated to a generic harness that includes
all configuration and management functionality shared by all wireless
device driver components, e.g., the wpa_supplicant. The code of the
device driver emulation environment is located in 'src/lib/wifi'. It
is referenced by the platform-specific driver library that resides in
the corresponding platform repository. The runtime configuration needs
to point the driver to proper driver library.
The platform-specific library is in charge of orchestrating the contrib
source utilized by the driver as well as providing the 'source.list'
and 'dep.list' files. It must include the generic library snippet
'repos/dde_linux/lib/wifi.inc' that deals with managing the emulation
environment code.
The 'repos/dde_linux/src/drivers/wifi/README' file contains more
detailed information on how to deploy the driver.
Issue #4861.
* 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
Changes to the platform driver triggered a map() error while mapping an
address block at 0x3000 of size 0x800. Since the mapped size was larger, the
loop continued and tried mapping address 0x4000 where no dataspace was
found.
genodelabs/genode#4761
By transforming the Device_pd into an Io_mmu::Domain, we implement an
IOMMU device that uses the kernel API for controlling the IOMMU. This
device gets special treatment and is used by default for every device
that has no <io_mmu/> child.
genodelabs/genode#4761
Every session component manages a registry of Io_mmu::Domain objects
that it creates on demand depending on the acquired devices (i.e. the
IOMMU devices referenced by the acquired devices). Via the domain
objects, a session component adds/removes the address ranges of the
allocated DMA buffers. Additionally, domain objects provide an interface
for enabling/disabling pci devices.
Domain objects get destroyed with the corresponding control device.
Moreover, on devices/policy ROM updates, domain objects of control
devices that are not referenced by any acquired device anymore get destroyed.
genodelabs/genode#4761
This allows referencing an arbitrary number of IOMMU devices within a
<devices> node, e.g.:
<device>
<io_mmu name="foobar"/>
</device>
The specified name is supposed to refer to an existing device in the
devices ROM. The platform driver automatically acquires known IOMMU
devices whenever they become available so that the device object can be
looked up from the platform-driver-owned devices.
genodelabs/genode#4761
With this change, platform-specific code is able to define factories that
acquire IOMMU devices to be used by the platform driver.
genodelabs/genode#4761
The method did not handle device changes properly. When a new policy
does not contain an owned device any more, we must consider this device
as changed and release it. Moreover, the warning messages were interchanged.
genodelabs/genode#4761
"-cpu phenom" does not support all CPU instructions necessary with
gcc 12 toolchain update issuing more SSSE3, e.g. pshufb.
Additionally, remove good/bad Qemu version check of outdated versions.
Issue genodelabs/genode-world#329
In 'SUPR3InitEx' (SUPLib.cpp) a 'SUPQUERYFUNCS' structure is allocated
with
! (PSUPQUERYFUNCS)RTMemAllocZ(SUP_IOCTL_QUERY_FUNCS_SIZE(CookieReq.u.Out.cFunctions));
where 'CookieReq.u.Out.cFunctions' is 0. To determine the size of the
allocation
! #define SUP_IOCTL_QUERY_FUNCS_SIZE(cFuncs) \
! RT_UOFFSETOF_DYN(SUPQUERYFUNCS, u.Out.aFunctions[(cFuncs)])
is used with cFuncs = 0 (SUPDrvIOC.h) leading to an allocation up to the
arrow below
! typedef struct SUPQUERYFUNCS
! {
! /** The header. */
! SUPREQHDR Hdr;
! union
! {
! struct
! {
! /** Number of functions returned. */
! uint32_t cFunctions;
! /** Array of functions. */
==> end of allocation
! SUPFUNC aFunctions[1];
! } Out;
! } u;
==> sizeof(SUPQUERYFUNCS)
! } SUPQUERYFUNCS, *PSUPQUERYFUNCS;
In sup.cc (Genode) 'ioctl(SUPQUERYFUNCS &request)' will lead to
'with_out_ioctl'
! auto &out = request.u.Out;
where auto is 'SUPQUERYFUNCS' and finally
! out = { };
will zero out 'SUPQUERYFUNCS' up to the second arrow above. Because
'RTMemAllocZ' will call 'calloc' to allocate the memory 'out = { };'
will corrupt the slab block after the allocation. Therefore, it is
reasonable to allocate at least 'sizeof(SUPQUERYFUNCS)'.
Note there might be other 'ioctl' cases like this. A better way might be
to use 'SUPQUERYFUNCS.Hdr.cbOut' to determine the 'out' size.
fixes#4675
In case the meta data (or more) got zeroed upon 'free', print error
message. The offset in the meta data can never be zero. This does not
help on other memory corruptions, but at least gives a hint in the too
much zeroed out case.
issue #4675
GPU device access is hard to achieve in run scripts and even harder to
implement generic.
Use the "Modularize Sculpt OS image creation"
(commit b723b11b30)
approach instead.
issue #4900
The XHCI model reserves 0x4000 of IO memory but uses only 0x530.
Implement read (0) and write (nop) for these regions as real hardware
does.
fixes#4902
