Vlákno názorů k článku Ubuntu 17.10 bylo dočasně staženo, poškozuje BIOS některých notebooků od sdsgb - Nevite prosim nekdo jestli se to tyka i...

@D.A. Tiger:

Nejspíš jo.. Takhle to má Debian:

$ grep INTEL_SPI /boot/config-4.13.0-0.bpo.1-amd64
# CONFIG_SPI_IN­TEL_SPI_PLATFORM is not set


takže se to stát nemůže. Čert ví, která "chytrá" hlava v Ubuntu zase takovou věc vymyslela, že bude by default zapnuto, když to "mateřské" distro má vypnuté...

BTW. tohle píšu z notebooku Lenovo B50-70, který tímto je postižen, takže nemít tam Debian, ale zkusit tam nainstalovat tohle Ubuntu, tak už z něho tenhle příspěvek nepošlu :D

Ano, zapli si to sami.
Na druhou stranu - aby driver menil priznak zapisovatelnosti BIOS image pri sve inicializaci, to je taky docela silne kafe.
Chyba je samozrejme v BIOSu, ale tohle chovani ovladace je dost nepochopitelne

@tnr:

To je otázka pohledu, ovladač testuje, zda je zařízení RW nebo RO. To, že to Lenovo chápe "pomrvi obsah dat zařízení" je IMO hlavně chyba u nich. Kdyby to byla chyba v ovladači, pokazí tahle detekce zapisovatelnosti každý notebook bez výjimky, což se neděje.

>To je otázka pohledu, ovladač testuje, zda je zařízení RW nebo RO.

To prave neni pravda, ten bit je definovan jako vypnuti ochrany proti zapisu. A to, ze tuto ochranu proti zapisu ovladac vypne jen svym natazenim (a nikoliv napr. pri otevreni rozhrani a skutecnem pokusu o zapis) povazuji za zcela zasadni fail, jelikoz pripadu, kdy je zapis (a toto vypnuti) skutecne potreba, bude naproste minimum oproti situacim, kdy se ovladac jen nacte.

Takze za me je to rozhodne nevhodne navrhove rozhodnuti.

>To, že to Lenovo chápe "pomrvi obsah dat zařízení" je IMO hlavně chyba u nich. Kdyby to byla chyba v ovladači, pokazí tahle detekce zapisovatelnosti každý notebook bez výjimky, což se neděje.

Ze to chyba je zejmena u Lenova se rozhodne neda poprit, o tom se nehadam. Jen rikam, ze to chovani ovladace je na hlavu.

To prave neni pravda, ten bit je definovan jako vypnuti ochrany proti zapisu.

Ano, a proto jeho pokusem o přehození se dá detekovat zda je zařízení RW nebo RO. Přesně ta část kódu toto dělá. Hned to zase vrací zpátky a žádná data k přeprogramování neposílá. Lenovo si to vysvětluje po svém aniž by chápali, že když mají FlashROM švába na SPI sběrnici, že tohle je přesně způsob, jakým detekovat, zda na zařízení jde zapisovat nebo ne.

Takze za me je to rozhodne nevhodne navrhove rozhodnuti.

Vzhledem k výše napsanému mi to nevhodné návrhové rozhodnutí nepřijde, protože to nelikviduje všechny notesy, jen některé od Lenova, kde nechápou, že pokus o přehození tohoto bitu tam a zpět je pokusem o detekci (tak jak to chápou očividně i všichni ostatní), zda je zařízení zapisovatelné, ne že se má spustit nějaká interní přeprogramovací procedura.
Schválně si zkuste tipnout, jestli by se tohle stalo u Lenova, když patřilo IBM. Tady je prostě znát nedostatek know-how a bastlířský přístup současného výrobce.

> Ano, a proto jeho pokusem o přehození se dá detekovat zda je zařízení RW nebo RO. Přesně ta část kódu toto dělá. Hned to zase vrací zpátky a žádná data k přeprogramování neposílá.

To je hezky popis chovani, ale neodpovidajici realite :)

static int lpc_ich_init_spi(struct pci_dev *dev)
...
case INTEL_SPI_LPT:
pci_read_config_dwor­d(dev, RCBABASE, &rcba);
if (rcba & 1) {
spi_base = round_down(rcba, SPIBASE_LPT_SZ);
res->start = spi_base + SPIBASE_LPT;
res->end = res->start + SPIBASE_LPT_SZ - 1;

/*
* Try to make the flash chip writeable now by
* setting BCR_WPD. It it fails we tell the driver
* that it can only read the chip.
*/
pci_read_config_dwor­d(dev, BCR, &bcr);
if (!(bcr & BCR_WPD)) {
bcr |= BCR_WPD;
pci_write_con­fig_dword(dev, BCR, bcr);
pci_read_config_dwor­d(dev, BCR, &bcr);
}
info->writeable = !!(bcr & BCR_WPD);
}
break;

Takze WPD (Write Protection Disable) se vypne (naporad) a tim, ze se necha vypnout, si ovladac overi, ze je to zapisovatelne. Ale nic zpatky nevraci - bit zustane vypnuty. A to sorry, ale to neni absolutne dobry navrh - to tam ten bit vubec nemusel byt :)

> Lenovo si to vysvětluje po svém aniž by chápali, že když mají FlashROM švába na SPI sběrnici, že tohle je přesně způsob, jakým detekovat, zda na zařízení jde zapisovat nebo ne.
To nemeni nic na tom, ze to je a) nesikovny zpusob detekce (ale pravdepodobne nelze jiny) b) ze se pri inicializaci driveru naporad ta write ochrana vypne (coz je prasarna, to se ma dit az tehdy, az je zapis potreba)

Njn, pravda. Koukal jsem trochu jinde... Zůstává to nastavené. Každopádně jestli někdo na takových strojích aktualizoval firmware, tak tuší co se nejspíš stalo. Při aktualizaci se nejdříve spustí aktualizační program, stroj jde do restartu a Flash ROM se přepisuje po resetu. Takže zřejmě tenhle nastavený bit firmware Lenova chápe jako příkaz k automatické aktualizaci a bere si image firmware odněkud, kde ho očekává (předem připraven tím programem). Ten SPI ovladač ten bit nastaví, ale image nepřipraví, takže si ten notes vlastní firmware nejspíše po restartu přepíše smetím.

Docela by mě zajímalo, kdo tenhle způsob aktualizace vymyslel. Jestli Lenovo nebo dodavatel BIOSu. A taky proč si sakra před programováním nezkontroluje image a jestli je vůbec k dispozici.

Pořád si myslím, že v tom ovladači není v principu chyba, protože jinak RW stav nejspíš testovat nejde a ovladač při natažení toto detekuje proto, aby mohl vypsat nějaké informace, včetně toho, že je zařízení zapisovatelné nebo ne. Je to prostě souběh ne úplně šťastných návrhů s tím, že největší kus másla má na hlavě Lenovo. Vypnutí této detekce v ovladači je spíše workaround pro vadné zařízení, které to chápe jako povel k autoaktualizaci, bez ohledu na to, zdá má k dispozici předem připravený image (ale je pravda, že by je nezabilo po detekci to vrátit zase do původního stavu). A pokud nemají u Lenova možnost záchranné akce při vadném naprogramování, tak je to fail č. 2!

> Takže zřejmě tenhle nastavený bit firmware Lenova chápe jako příkaz k automatické aktualizaci a bere si image firmware odněkud, kde ho očekává (předem připraven tím programem). Ten SPI ovladač ten bit nastaví, ale image nepřipraví, takže si ten notes vlastní firmware nejspíše po restartu přepíše smetím.

To si myslim, ze se nedeje, ale je to cista spekulace od nas obou. Kdyby to prepsal smetim, tak to skonci u mnohem horsich veci - napr. to ze ten stroj vubec nebude schopen bootovat (coz je).
Jen neni schopen si ulozit konfiguraci. Takze si spis myslim, ze se to nekde locklo v nejake okrajove podmince. Otazkou ovsem je, jestli tomto stavu pujde BIOS znovu flashovat napr. z Windows.

> Je to prostě souběh ne úplně šťastných návrhů s tím, že největší kus másla má na hlavě Lenovo.
Jop, to se shodneme.

> (ale je pravda, že by je nezabilo po detekci to vrátit zase do původního stavu)
Podle me by to takto detekovat vubec nemel. Bud to jde detekovat jinak (asi nejde), nebo to nedetekuji a pak proste zamitnu write. To je podle meho nazoru mnohem vice safe varianta.

Neobhajuji lenovo. Ale pri interakci s takto kritickymi, nizkourovnovymi komponenty systemu je proste potreba dodrzovat urcite zasady. Jako napr. nemenit nic, pokud to opravdu nepotrebuji.
Protoze co si budeme nalhavat - HW je plny bugu a ruzneho prapodivneho chovani.

To si myslim, ze se nedeje, ale je to cista spekulace od nas obou. Kdyby to prepsal smetim, tak to skonci u mnohem horsich veci

Ale já nemyslel, že si přepíše komplet BIOS. Spíš že při startu aktualizace dělá nějaké inicializace (smaže CMOS nebo ji nějak lockne, smaže nějaký mikrokód/přepíše smetím/lockne - proto nebootuje z USB) a pak to zdechne, protože není image, tak nenaflashuje ROMku. Ale mezitím už stihne napáchat škody v tomto "podpůrném" firmware (zažil jsem HP notes, který po naflashování BIOSu po restartu ještě aktualizoval někde nějaký mikrokód pro klávesnici, když to zdechlo, interní klávesnice už si ani neškrtla), protože si to nepřekontroloval jestli tu akci má vůbec pouštět. Ale jak píšeš, to už jsou spekulace.

Co se týká té opatrnosti v ovladači SPI v Linuxu, tak určitě mohla být, s tím souhlas. Ale když po tom pátrám, tak mi není jasné, proč se v dokumentaci píše, že ta ROMka je ve výchozím stavu v Linuxu jen RO a pro RW se musí zadat kernelu nebo modulu parametr:

https://github.com/torvalds/linux/blob/master/Documentation/mtd/intel-spi.txt

a taky mi není jasné, proč to v Ubuntu dali jako výchozí - k čemu?!

> Ale já nemyslel, že si přepíše komplet BIOS. Spíš že při startu aktualizace dělá nějaké inicializace (smaže CMOS nebo ji nějak lockne, smaže nějaký mikrokód/přepíše smetím/lockne - proto nebootuje z USB) a pak to zdechne, protože není image, tak nenaflashuje ROMku. Ale mezitím už stihne napáchat škody v tomto "podpůrném" firmware (zažil jsem HP notes, který po naflashování BIOSu po restartu ještě aktualizoval někde nějaký mikrokód pro klávesnici, když to zdechlo, interní klávesnice už si ani neškrtla), protože si to nepřekontroloval jestli tu akci má vůbec pouštět. Ale jak píšeš, to už jsou spekulace.

Souhlas

>Co se týká té opatrnosti v ovladači SPI v Linuxu, tak určitě mohla být, s tím souhlas. Ale když po tom pátrám, tak mi není jasné, proč se v dokumentaci píše, že ta ROMka je ve výchozím stavu v Linuxu jen RO a pro RW se musí zadat kernelu nebo modulu parametr:
> https://github.com/torvalds/linux/blob/master/Documentation/mtd/intel-spi.txt
> a taky mi není jasné, proč to v Ubuntu dali jako výchozí - k čemu?!

Protoze se divas na blbej driver. Tohle je driver k spi-nor:

https://github.com/torvalds/linux/blob/master/drivers/mtd/spi-nor/intel-spi.c

Ale chyba je v

https://github.com/torvalds/linux/blob/master/drivers/mfd/lpc_ich.c

Ten prvni ma writeable parametr, ktery se musi zapnout, ten druhy zadny parametr nema a WPD odstranuje pri inicializaci.

Takze ubuntu nic nezapinalo, jen ten driver meli v kernelu.
A mimochodem, tenhle driver ma popisek:

config LPC_SCH
tristate "Intel SCH LPC"
depends on PCI
select MFD_CORE
help
LPC bridge function of the Intel SCH provides support for
System Management Bus and General Purpose I/O.

Takze tam neni ani zadnej warning, jak jsi psal predtim. Coz je fakt na ....

Protoze se divas na blbej driver. ... Ale chyba je v ... lpc_ich

Tak moment, to nedává smysl, tenhle driver mám na Debianu taky, mám ho NATAŽENÝ a notebook je zcela v pořádku.

$ lsmod | grep lpc_ich
lpc_ich 24576 0
mfd_core 16384 2 lpc_ich,rtsx_pci


Koukám i na ty výše odkazované patche a týká se to bugu s Thinkpad Yoga, který maže CMOS pokud je tento bit nastavený jako RW.
Článek ale zřejmě píše o jiné chybě, protože i v bugzille Ubuntu píšou jasně o intel-spi-* ovladačích, které takto poškodí BIOS stroje. Tento ovladač v Debianu není, v Ubuntu ho zapnuli a problém se projevil.

Hmm Thinkpad Yoga mam, a pred par mesici sel do servisu (vymenili mu MB), protoze se nejdriv nechtel vypnout a pak se nechtel nabijet. Je klidne mozne, ze to bylo zpusobeno timto. Ted lpc_ich nacteny nemam, tak alespon vim na co si davat pozor.