https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/comments/1…
Inkább tűnik ez szerencsétlen egybeesésnek, mint hibának.
Ha elolvassátok az első leírást ami a fenti linken található, kiderül belőle:
Not all manufacturers protect the SPI serial flash, mainly because it allows upgrading the BIOS image directly from an OS.
The intel-spi driver makes it possible to read and write the SPI serial flash, if certain protection bits are not set and locked. If it finds any of them set, the whole MTD device is made read-only to prevent partial overwrites. By default the driver exposes SPI serial flash contents as read-only but it can be changed from kernel command line, passing "intel-spi.writeable=1".
Szóval két dolog lehetséges szerintem:
- Ubuntu-ék / Kernel fejlesztők gondoltak egy merészet és defaultba beállították, hogy legyen csak writeable a flash :) (ez akkor Ubuntu / Kernel bug)
- vagy az érintett gyártó implementációja gáz, mert olyan területekre történik írás egy operációs rendszer telepítése során (nem BIOS frissítés, mert az Ubuntu ilyet asszem azért alapból installkor nem csinál ...) ahova nem lenne szabad
Én a másodiknak adok nagyobb esélyt, de simán lehet az első is.
Biztonsági szempontból nem tűnik jó ötletnek mezei op.rendszerből BIOS frissítgetni, ennyi erővel egy kártevő is dönthet úgy, hogy ideje másik BIOS-t betölteni, mondjuk olyat ami titkosítja a disket és bitcoinért cserébe visszaállít ... hm? :)
A cdírós firmware-es történet meg egyenesen hajmeresztő ... a cd (minden) olvasása közben a driver mintát keres és ha valami hasonlít egy cd firmware-re akkor azt benyalja és onnantól "ujj a torkon ..." ahogy Drex mondaná.
szerk: ez mondjuk gyanús :)
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git…
author Bin Meng 2017-09-11 02:41:53 -0700
committer Greg Kroah-Hartman 2017-11-30 08:40:55 +0000
spi-nor: intel-spi: Fix broken software sequencing codes
commit 9d63f17661e25fd28714dac94bdebc4ff5b75f09 upstream.
There are two bugs in current intel_spi_sw_cycle():
- The 'data byte count' field should be the number of bytes
transferred minus 1
- SSFSTS_CTL is the offset from ispi->sregs, not ispi->base