It is possible that the first event in the event log is not actually a
log header at all, but rather a normal event. This leads to the cast in
__calc_tpm2_event_size being an invalid conversion, which means that
the values read are effectively garbage. Depending on the first event's
contents, this leads either to apparently normal behaviour, a crash or
a freeze.
While this behaviour of the firmware is not in accordance with the
TCG Client EFI Specification, this happens on a Dell Precision 5510
with the TPM enabled but hidden from the OS ("TPM On" disabled, state
otherwise untouched). The EFI firmware claims that the TPM is present
and active and that it supports the TCG 2.0 event log format.
Fortunately, this can be worked around by simply checking the header
of the first event and the event log header signature itself.
Commit b4f1874c6216 ("tpm: check event log version before reading final
events") addressed a similar issue also found on Dell models.
Fixes: 6b0326190205 ("efi: Attempt to get the TCG2 event log in the boot stub")
Signed-off-by: Fabian Vogt <email address hidden>
Link: https://<email address hidden>
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1165773
Signed-off-by: Ard Biesheuvel <email address hidden>
(cherry picked from commit 7dfc06a0f25b593a9f51992f540c0f80a57f3629)
Signed-off-by: You-Sheng Yang <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
It's not needed to set driver to NULL in mei_cl_device_remove()
which is bus_type remove() handler as this is done anyway
in __device_release_driver().
Actually this is causing an endless loop in driver_detach()
on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module.
The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty.
as the check is always true in __device_release_driver()
if (dev->driver != drv)
return;
The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'
Nevertheless the fix is correct also for the upstream.
Link: https://patchwork.<email address hidden>/
Cc: <email address hidden>
Cc: Andy Whitcroft <email address hidden>
Signed-off-by: Alexander Usyskin <email address hidden>
Signed-off-by: Tomas Winkler <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit e852c2c251ed9c23ae6e3efebc5ec49adb504207)
Signed-off-by: Aaron Ma <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
One VMD equipped platform has another PCI bridge with PCI ID [8086:a0bc]
that is not already in Ubuntu sauced PCI_DEV_FLAGS_ENABLE_ASPM list.
Link Capability Register shows ASPM L1 supported, but has ASPM Disabled
in Link Control status:
Some platforms have an AHCI controller behind VMD. These platforms are
working correctly except for a case when the AHCI MSI is programmed with
VMD IRQ vector 0 (0xfee00000). When programmed with any other interrupt
(0xfeeNN000), the MSI is routed correctly and is handled by VMD. Placing
the AHCI MSI(s) in the fast-interrupt allow list solves the issue.
This also requires that VMD allocate more than one MSI/X vector and
changes the minimum MSI/X vectors allocated to two.
Signed-off-by: Jon Derrick <email address hidden>
(cherry-picked from https://patchwork.kernel.org/patch/11758345/)
Signed-off-by: You-Sheng Yang <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
