Packagers should still enable it so that tracking lost memory
in plugins is possible, but on some distros some archs don't
have valgrind available which would otherwise prevent fwupd
from running.
This is as problem currently for Debian unstable where some
archs valgrind fails to compile.
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.
