On 22.12.2017 04:36, Matt DeVillier wrote:
from what I recall, the driver was trying to be responsible and lock SPI write access by default,
Yep, I remember something like that too. But in the usual UEFI case there is nothing you could lock without breaking UEFI runtime at least ;) These MTD drivers seem to assume that they are the only entity accessing the chip. I doubt they saw the bigger picture at Intel when they upstreamed that driver. Maybe it's only meant for non-UEFI embedded use cases? Also, the Kconfig says (from the very beginning):
Say N here unless you know what you are doing. Overwriting the SPI flash may render the system unbootable.
I wonder why distros pick it up.
Nico -- did this ever get fixed in the upstream kernel? From what I saw, the "fixed" Ubuntu ISO simply omitted the driver in the kernel config/build
Yes, there was a train of fixes that took care of this, too. At least I hope it was the off-by-one fixed here:
9d63f17661e2 spi-nor: intel-spi: Fix broken software sequencing codes
Nico