Newer versions of dtc agressively pack the string table, using *any* matching
suffix rather than whole strings. This is specification compliant, but breaks
if you use the offset as a hash key as a [premature] optimization.
Just use the string table as a flat block of memory rather than pre-parsing it.
This fixes reading the system FDT on new OpenBMC builds.
This refactors the code as it was getting very confusing; before FuSmbios was
reading both SMBIOS and the kernel-provided DT -- and various things were
injecting overrides in three different place. To properly support FDT remove
one layer of indirection.
This also lets us use the compatible strings to enable plugins specifying the
flag _REQUIRE_HWID -- which means we only load the plugin if it's got a chance
of working. e.g.
[aspeed,ast2500]
These paths may be used for bind mounts, which we can't accurately
discover. Leave a message in the logs accordingly, but allow these
paths.
fixes: #5185
This is needed because multiple plugins will soon be consuming the system FDT,
and we don't want to either parse this multiple times, or duplicate the loading
logic.
Remove the FuDeviceClass padding, as this library now loaded using an rpath
rather than a shared library with a static API. This matches what we did for
the FuFirmwareClass objects a while ago.
This will eventually allow us to reconstruct a SBoM using a UEFI file volume.
This can be used like this `fwupdtool firmware-parse efi/fwupdx64.efi pefile`
to produce:
<firmware gtype="FuPefileFirmware">
<data size="0xef59">MZ.</data>
<firmware>
<id>.text</id>
<offset>0x2d0</offset>
<size>0x7bab</size>
<data size="0x7bab">H...QRH.=....H.5</data>
</firmware>
...
<firmware gtype="FuCoswidFirmware">
<id>fwupd-efi:fwupdx64</id>
<idx>0x7</idx>
<version>1.4</version>
<offset>0xc4e0</offset>
<size>0xce</size>
<data size="0xce">..een-US</data>
<version_scheme>semver</version_scheme>
<product>fwupdx64</product>
<summary>EFI helpers to install system firmware</summary>
<colloquial_version>1.3-7-g881a508</colloquial_version>
<link>
<href>https://spdx.org/licenses/LGPL-2.0.html</href>
<rel>license</rel>
</link>
<entity>
<name>Richard Hughes</name>
<regid>hughsie.com</regid>
<role>maintainer</role>
<role>tag-creator</role>
</entity>
</firmware>
</firmware>
The GCab decompression code is *scary* low level C that has not had any security
auditing other than by the fuzzer (which found plenty of memory-safety bugs).
Supporting LZX is useless at best, and could be a security exploit at worst.
This only have any protective effect if we're using multiple threads -- which
we're not. Removing these unused locks does not affect startup speed, but does
drop the idle RSS by ~10kB.
We're not going to subclass this, and making it final saves during startup:
* 300K calls of fu_progress_get_instance_private()
* 280K calls of fu_progress_get_step_weighting()
In various places the code was checking if a release was set, but this would
always be false as the release was being auto-created. This was masking valid
bugs, and was confusing to have the superclass have different semantics to the
baseclass.
