commit 99b317d4f7 introduced much
more strict confinement. This actually caused some regressions
though.
commit 3c54edb15e tried to fix
one of the problems, but didn't cover the rest.
The actual changes:
- Drop PrivateUsers=yes
This is causing crashes when initializing libsmbios
Presumably it's related to accessing memory.
- Add back in NoNewPrivileges
This hasn't caused any crashes for libsmbios for me.
- Remove ProtectKernelTunables
This is needed to access /sys for the dcdbas kernel
module used by libsmbios. Calls fail without it
- Add ReadWritePaths=/var/lib/fwupd /boot/efi
The refresh function was failing the first time due to
ProtectSystem=full being in effect and /var/lib/fwupd
being read only
Flashing UEFI capsules was failing due to being unable
to write to /boot/efi/EFI/$(EFIDIR)/fw/
For some reason NoNewPrivileges=yes causes the process to be killed when run on
hardware specifically from Dell. I can reliably reproduce this on my XPS 13 and
I assume it's something to do with libsmbios.
As found in https://github.com/dell/libsmbios/pull/13
there are some errors with libsmbios error paths.
These need to be fixed in libsmbios, but at least avoid
running this code on those systems (and crashing fwupd).
My compiler doesn't understand -Wno-discard-qualifiers so drop it and
fix the warnings instead. I think it is better to explicitly fix them
anyways instead of just to ignore the discarded const qualifier in
general.
I think the option should be avoided in hand-written code. The warning
is there for a reason: To protect you from possibly overwriting data you
expect to not be modified when passing pointers around.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41215
This significantly speeds up the test suite.
They can't really be easily represented anyways in the test suite
since the devnode would have to change so much between steps.
Although the same payload is used for all 3 MST hubs in TB16 or WD15
it's possible this may change one day. Create separate GUID's for
all 3 different combinations by encoding the chip ID into the GUID
string.
Although WD15 and TB16 share a same payload today, this may not
be the case some day in the future. Use the fu-dell-common method
to determine the dock in use to build the GUID.
Tracking a single smi object in the plugindata is more similar
to how other plugins operate and also allows moving FuPluginData
out of fu-dell-common, making fu-dell-tool less hacky and letting
other plugins use fu-dell-common as needed.
* thunderbolt: Add special handling for safe mode on Dell systems
Dell systems are known to have the Model ID the same as the SystemID
that can be recovered from libsmbios. If the thunderbolt controller
is in safe mode, identify with this ID to allow the controller to be
flashed with a good FW.
* Minor changes in Thunderbolt README file
* Remove PCI-oriented GUID
* Handle Thunderbolt controller in safe-mode
* Get progress status updates for Thunderbolt
* Fix for Thunderbolt FW version display
* Style changes from pull request review
There was a lot of confusion about when remote control was turned
on or off leading to dsyfunctional cascade support.
This has been confirmed to work for querying and flashing both
VMM3320s in a Rugged Latitude 5414 + dock.
