Bug 1073836 - Disable CONFIG_SPI_INTEL_SPI_PLATFORM for avoiding breaking BIOS on Lenovo & others
Disable CONFIG_SPI_INTEL_SPI_PLATFORM for avoiding breaking BIOS on Lenovo & ...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Critical (vote)
: ---
Assigned To: Takashi Iwai
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-21 10:23 UTC by Takashi Iwai
Modified: 2022-07-21 17:20 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
oneukum: needinfo? (matthewtrescott)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Takashi Iwai 2017-12-21 10:23:16 UTC
The recent reports revealed that Intel SPI platform driver seems badly breaking BIOS on laptops of Lenovo and other vendors.  Just loading the driver results in the BIOS setup no longer changeable, e.g. no boot sequence can be changed any longer.

Until the real culprit is identified and fixed, let's disable the too dangerous driver for now.

The driver is present on TW and SLE15/Leap 15.0 kernels.
Comment 1 Takashi Iwai 2017-12-21 10:57:37 UTC
The recent kernels have CONFIG_SPI_INTEL_SPI_PCI that also uses the same code for touching the protection bit.  This config should be disabled as well.
Comment 2 Takashi Iwai 2017-12-21 11:00:03 UTC
The kernel config gets updated to disable SPI_INTEL_* temporarily in my master, stable, SLE15 and openSUSE-15.0 user branches.
Comment 3 Matthew Trescott 2018-01-30 20:29:33 UTC
The Linux 4.11.x kernel triggered this bug for me in Tumbleweed back in May (?) of last year. In the mailing list thread that mentioned this bug there was question of whether this was a problem for OpenSUSE, so I want to clarify that it was. Certain Ubuntu kernels seem to include a patch that was specifically meant to reverse the damage. That patched kernel (v4.14.10 from the Ubuntu mainline kernel PPA) fixed the problem for me, but it should be noted that simply blacklisting that module will not reverse the damage for affected users.
Comment 4 Oliver Neukum 2018-02-05 11:25:53 UTC
(In reply to Matthew Trescott from comment #3)

> clarify that it was. Certain Ubuntu kernels seem to include a patch that was
> specifically meant to reverse the damage. That patched kernel (v4.14.10 from

Do you have a pointer to that patch?
Comment 5 Matthew Trescott 2018-02-05 16:12:36 UTC
The Ubuntu bug report (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/+index?comments=all) links to this patch: http://people.canonical.com/~ypwong/lp1734147/0001-Clear-both-SR-and-CR-explicitly-and-also-add-debug-m.patch

Strangely, that patch is not included in the list of patches for 4.14.10 from the Ubuntu Mainline Kernel PPA, so I do not know how Linux 4.14.10 fixed it without this patch unless there is a partial fix (that just happened to work for me) already upstream.
Comment 6 Takashi Iwai 2018-02-22 09:35:11 UTC
FYI, the BIOS corruption seems to be already avoided by the upstream commit
9d63f17661e25fd28714dac94bdebc4ff5b75f09
    spi-nor: intel-spi: Fix broken software sequencing codes
since 4.15, and it's included in 4.14.x stable.

But this patch doesn't seem to recover the already broken BIOS, so it might need another kernel with a not-yet-in-upstream patch.

This one
  https://patchwork.ozlabs.org/patch/855504/
was NAK'ed for some rewrites, so not in 4.16-rc, so far.
Comment 7 Takashi Iwai 2018-06-08 13:44:01 UTC
The fix patch for spi-nor was queued to mtd spi-nor tree, and will be included in 4.18-rc1.  I backported to master branch, although we've already disabled the corresponding kernel config.