Message ID | 20190928154658.12957-1-seth.forshee@canonical.com |
---|---|
Headers | show |
Series | Fix panic when parsing tpm event log from firmware | expand |
On Sat, Sep 28, 2019 at 10:46:55AM -0500, Seth Forshee wrote: > BugLink: https://bugs.launchpad.net/bugs/1845454 > > SRU Justification > > Impact: Some systems are getting kernel panics during boot while parsing > tpm event logs from the firmware. This happens only when the tpm and > secure boot are both enabled in the firmware. > > Fix: 3 patches which are currently applied to the upstream EFI > maintainer tree. > > Test Case: On an affected system, booting a 5.3-based kernel will panic > during boot when the tpm and secure boot are enabled. A patched kernel > will boot successfully. The patches have been verified to fix the issue > on a gen 6 Lenovo X1 Carbon. > > Regression Potential: If the patches have bugs they could cause > regressions on systems not currently experiencing issues. The patches > are pretty straightforward though and tagged for stable, so I believe > the risk is minimal and (given the severity of the issue on affected > hardware) acceptable. > > Thanks, > Seth I couldn't spot any bugs in these patches. Considering they've been tested with positive result, it seems sane to me to apply them, therefore: Acked-by: Andrea Righi <andrea.righi@canonical.com> > > > Jerry Snitselaar (1): > efi/tpm: only set efi_tpm_final_log_size after successful event log > parsing > > Peter Jones (2): > efi/tpm: Don't access event->count when it isn't mapped. > efi/tpm: don't traverse an event log with no events > > drivers/firmware/efi/tpm.c | 24 ++++++++++++++++++------ > include/linux/tpm_eventlog.h | 16 ++++++++++++---- > 2 files changed, 30 insertions(+), 10 deletions(-) > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On 28.09.19 17:46, Seth Forshee wrote: > BugLink: https://bugs.launchpad.net/bugs/1845454 > > SRU Justification > > Impact: Some systems are getting kernel panics during boot while parsing > tpm event logs from the firmware. This happens only when the tpm and > secure boot are both enabled in the firmware. > > Fix: 3 patches which are currently applied to the upstream EFI > maintainer tree. > > Test Case: On an affected system, booting a 5.3-based kernel will panic > during boot when the tpm and secure boot are enabled. A patched kernel > will boot successfully. The patches have been verified to fix the issue > on a gen 6 Lenovo X1 Carbon. > > Regression Potential: If the patches have bugs they could cause > regressions on systems not currently experiencing issues. The patches > are pretty straightforward though and tagged for stable, so I believe > the risk is minimal and (given the severity of the issue on affected > hardware) acceptable. > > Thanks, > Seth > > > Jerry Snitselaar (1): > efi/tpm: only set efi_tpm_final_log_size after successful event log > parsing > > Peter Jones (2): > efi/tpm: Don't access event->count when it isn't mapped. > efi/tpm: don't traverse an event log with no events > > drivers/firmware/efi/tpm.c | 24 ++++++++++++++++++------ > include/linux/tpm_eventlog.h | 16 ++++++++++++---- > 2 files changed, 30 insertions(+), 10 deletions(-) > > The patches seem to do what they are claiming and have good test results. Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
On Sat, Sep 28, 2019 at 10:46:55AM -0500, Seth Forshee wrote: > BugLink: https://bugs.launchpad.net/bugs/1845454 > > SRU Justification > > Impact: Some systems are getting kernel panics during boot while parsing > tpm event logs from the firmware. This happens only when the tpm and > secure boot are both enabled in the firmware. > > Fix: 3 patches which are currently applied to the upstream EFI > maintainer tree. > > Test Case: On an affected system, booting a 5.3-based kernel will panic > during boot when the tpm and secure boot are enabled. A patched kernel > will boot successfully. The patches have been verified to fix the issue > on a gen 6 Lenovo X1 Carbon. > > Regression Potential: If the patches have bugs they could cause > regressions on systems not currently experiencing issues. The patches > are pretty straightforward though and tagged for stable, so I believe > the risk is minimal and (given the severity of the issue on affected > hardware) acceptable. Applied to eoan/master-next.