GitLab

The checks for modifying the access time via bolt_fs_touch was
previously disabled because it did not work on file-systems
that have the noatime flag set (for very obvious reasons).
Separate these checks out and re-enable them but make their
execution depended on the file-system support for access times,
as reported via statvfs(2).

Access time is not always supported, so support for it is best-effort.
We disable such assertions so bolt can be unit tested on systems that have
"noatime" configured to speed up the filesystem.

This is only a bugfix release so we keep the 0.9 prefix.

Since bolt is also being used for Thunderbolt 4 and USB 4, put
less emphasis on the version, specifically version 3, in the
README.md and the spec file.

Add a .md file section and insist we use spaces there.

Describe how to use the Address Sanitizer in bolt.

Free the `idstr` for the MockDevice, free the `dmi` path variable
for the dmi device path and also free the return value from
umockdev_testbed_get_root_dir.

When the address sanitizer is enabled, skip the recover_guards_fail
test, since we fork() in there and that somehow trips up ASAN.

Use the compiler specific method to detect if the code was compiled
with the address sanitizer enabled. This might be needed to skip
some incompatible tests.

When removing the host device via mock_sysfs_host_remove, destroy
the MockDevice for the host.

The function 'bolt_flags_class_to_string' returns a dynamically
allocated string. This was previously not freed, creating a memory
leak. Its ownership is now correctly transferred to the GVariant
instead.

The memory for custom_id, to identify a custom conversion, is
dynamically allocated, but was not freed in bolt_wire_conv_unref.
Explicitly set it to NULL in the other constructor so we don't
attempt to free invalid memory.

Normally 'path' gets freed in bolt_guard_remove, which is called
from the dispose method of the BoltGuard. There is one exception
though: when the pipe (named fifo) is still active, we do not
unlink the path, since we want to recover that guard later. In
that case the memory for path will be leaked. Add an additional
g_clear_pointer for path in the 'finalize' method to ensure that
path always gets freed.

Ensure that we are not saved already in 'bolt_guard_save'.

Add missing g_clear_pointer / g_clear_object calls when a pointer
was re-used during the tests. In MockSysfs, free the force-power
path. In test-glue, use g_autoptr for all allocated GParamSpecs.

Properly unref the config key file when finalizing the object.

If a device is a host device, i.e. does not have a parent device, use
the new host identification method, which will transparently fall
back to use the SMBIOS/DMI information, in case the standard
device information is not available, which is the case on embedded
thunderbolt controllers.

Add a test to check all host identification method code paths,
including the standard one via 'bolt_sysfs_device_ident' as
well as the fallback to DMI information.

Add the ability to mock the SMBBIOS/DMI sysfs device. For now only
the sys_vendor, product_{name, version} attributes are supported,
which is what we us in bolt.

If the force power device has not yet been removed, do so in the
'finalize' method of the MockSysfs object. Move the un-ref'ing of
the umockdev TestBed down so it happens after the hash tables
are destroyed.

Add a new method that allows to remove a host device, i.e. unplug
the device and remove it from the associated domain.

Add a new method to do host identification, which will first check
if the host device can be identified via the normal device ident
method. This will fail in case of embedded thunderbolt controller,
which do not have a DROM and have no device and vendor information
and thus no corresponding sysfs attributes. In that case we fall
back to using the SMBIOS/DMI information for the system to ident
the host.

The SMBIOS/DMI information is exported to userspace via sysfs,
which is convenient, because the information can thus be read
conveniently and as a non-root user.
Define constants for relevant information that can be used to
identify the computer / host, like the product, vendor and the
general path to the sysfs device providing that information.

Check the 'bolt_sysfs_device_ident' method and the newly added
'BoltIdent' structs.

Introduce a new BoltIdent struct that holds the name and vendor
information for a thunderbolt device together with a reference
to the 'struct udev_device' that provides those information.
This binds the lifetime of the char pointers directly to the
struct where they are contained and thus prevent accidental
bugs where the strings are used after the udev_device is not
valid anymore (got un-referenced).
Since the struct holds a reference, define a clear method for
it and the corresponding auto-cleanup method.
Use the new BoltIdent struct for 'bolt_device_ident'. Re-factor
it to not use a loop anymore.

The read_sysattr_name helper, use in 'bolt_device_ident' now
uses the recently introduced sysattr value getter.

Add a new sysfs attribute getter that does error reporting via
GErrors. This will be convenient in a lot of places where the
error handling is duplicated. Use it in the existing unique_id
helper.

This is mostly in preparation for the host identification via DMI
where 'Dell Inc.' is used, whereby the thunderbolt host controller
usually identifies itself as "Dell". To stay consistent we relabel
the dmi id one.

When labeling a device, we normally do a duplication check, and
if we find more than once device with the same name, we append
a number suffix. Let's not do that for host devices, since they
are arguably represent the same thing, even if technically the
are different controllers with their own unique id.

We started auto-importing the host device in commit f9205d16, with
the reason that in non-native enumeration mode, the host device
will disappear and the generation information will thus not be
available anymore. But on embedded thunderbolt controller, the
host device has an unstable unique_id, which means that host device
will have a different uuid on next boot and thus can not be matched
with the previously stored one. Thus stale host devices would
accumulate in the store. Luckily, on embedded thunderbolt, the host
device does not have device/vendor sysfs attributes, which means
that currently creating a BoltDevice for it will not work, which is
a bug, that also prevents stale host devices for now. Once that bug
will get fixed we were to get stale host records, unless we don't
store those host devices. To do so we check if the domain of the
host device is stored which is an indicator of the uuid stability,
checked via the pci id of the native host interface. If the domain
is stored we store the host and vice versa.

Move the device identification, i.e. name and vendor detection, to
bolt-sysfs.c as 'bolt_sysfs_device_ident'. This uses the existing
helper function to first check `${attr}_name` for vendor and name
attributes and then fall back to plain `${attr}`.

Add the missing getter for the domain associated with a device, or
NULL if there is none, i.e. the device is offline.

Instead of directly accessing the sysfs attribute, use the new
common helper to get the unique_id for the device.

Instead of directly getting the unique_id via the udev device, use
the new common syfs helper.

Simulate the normal and the error case and make sure we get the
correct result or error.

Only set the device and vendor name and id if it is non-null in
the device identification. This will allow us to test the error
handling but also prepare for simulating embedded thunderbolt
controller, which have no DROM and thus no (host) device name
or vendor identification.

Add a new helper to get the unique id (uid) for a device. It uses
the new define in bolt-names.h for the sysfs attribute.

Add a define for the the 'unique_id' sysfs attribute which is used
to uniquely identify thunderbolt devices.

In the manager's initialization, we want to make sure that we have
at least one domain controller online in order detect the security
level. Additionally, now that stale domains are cleaned up on store
upgrades, we also want to make sure that domain controllers are
fully initialized and the corresponding BotlDomain is online, so
that we don't accidentally clean up a non-stale domain. In order
to do so, we wait for at least one host controller to be present,
not just the plain domain. For this we enumerate all domains and
for each domain we enumerate the thunderbolt udev device directly
beneath it (should only be one).
Rename and re-purpose the various `count_domains` functions.
Adapt the test to add host devices to the corresponding domains.

Use the LOG_DOM () macro and do not use `bolt_domain_get_id`
which might return NULL for disconnected domains.