Nie celkom. Koľko z dnešných počítačov má BIOS ? Aj keď tá chyba by mohla byť funkčná aj voči EFI...
Ja mám Dell s BIOSom z roky 2010 z Ubuntu 17.10 a pozoroval som len dve veci.
strata gfx pre grub a boot default jadra
a celé sa to stalo pri použití vlastného jadra s RTAI patchom a problémom s tvorbou initramfs, a tak aom menil pokusne dracut za dropbear (či naopak)
a je to urcite Setup? neni to UEFI Configuration? ;-)
pokud tomu vyrobce rika BIOS tak to nepopira ze je to proto, ze to jmeno je zazite a jiz zuniversalnilo...
kazdopadne protoze ses machr, tak bacha aby si nemel problem se stazenim nove verze UEFI pro svoji desku, protoze vyrobce ti ji nabidne v Download kolonce BIOS ;-)
Ja osobne myslím že najlepšie sú staršie verzie OS či už Win alebo Linux... ja osobne mám momentálne v dualboote Win8.1 a Ubuntu 16.04 Gnome 3... nejdem hneď po najnovšom, ale počkám si nejaký čas kým všetky chyby opravia a pod.... ale v prípade MS to zatím vyzerá že Win10 ešte dlouho nebude "plnefunkčnej bez závažných chýb"...
Ešte stále mám po tejto správe stiahnutý žalúdok. Dvaapolročnú toshibu som predvčerom hodil do koša - aspoň už viem, čím to bolo spôsobené. Výmena MB by stála 300€. Už mám nový notebook a tiež mám na ňom Ubuntu 17.10. Týka sa to len Ubuntu? Pomôže preinštalovanie na iné distro, či čakať na opravu? Som bezradný, pre mňa je to veľký zásah do rozpočtu.
no tak ono technicky tomu notebooku nic není. Stačí něco co umí komunikovat na SPI (BusPirate atp) či programátor paralelních flash pamětí, sehnat si image BIOSu pro vaši desku (třeba ho vyseparovat z update BIOSu od Toshiby) a nahrát image zpět na flash paměť v desce za použití programátoru.
To nestaci, je treba vymenit HW (cip biosu) protoze jeho vnitrni cmos pamet je nastavena na READ-ONLY. Problem neni v tom ze by se podelal FW, FW na tech vadnych laptopech je "naprosto" v poradku... jak je uvedeno v Issue, zatim jedinym resenim je sehnat stejny new cip, precist programatorem data ze stareho a nahrat jej na novy... a ten novy napajet na motherboard... takze zatim je treba HW servisni zasah cloveka co vi co dela...
nutne neni treba HW (cip biosu) menit, pokud uzivatel nepotrebuje menit nastaveni BIOSu (ten co by nemohl), pro boot z USB lze (a je to u bugreportu take uvedene) pozuit z nabehleho systemu (lze pouziti z jineho HW, pokud je v vadnem NB cistej hdd) efibootmgr a nahradit dosavadni Grub za rEFInd kterej ma vlastni/interni podporu bootu z USB nezavisle nad (ne)moznostmi BIOSu...
ani to tim nemuselo byt ;-) sel ti zapnout? startoval z interniho disku? protoze tento bug se projevuje:
Chování je velmi různorodé, od nemožnosti uložit novou konfiguraci BIOSu až po neschopnost počítače nabootovat z USB zařízení."
ohledne nemoznosti bootovat z USB zarizeni je u bugreportu uveden workaround fungujici na uz postizenych NB, kdy lze z nabehleho systemu pomoci efibootmgr nahradit grub zavadecem rEFInd kterej ma vlastni/interni podporu pro boot z USB zarizeni, takze i kdyz BIOS/UEFI po poskozeni neumi boot z USB, timto se da boot z USB zaridit...
dale pro nepostizene je u bugreportu v prispevcich uvedeno ze problem je jiz vyresen (pred 9hodinama) v balicku kernelu 4.13.0-21.24, momentalne mi aktualizace 17.10 nabizi jeste predchozi 4.13.0-21.22, pocitam ze ten opraveny probubla do stable repositare behem par hodin az dni...
btw: u bugreportu je uvedeno ze problem se tyka i openSUSE...
btw: obecne se da overit zda problematicka funkce je v jadru dostupna takto:
# u Debian/Ubuntu/Mint/atd (kde je config v /boot)
cat /boot/config-$(uname -r) | grep CONFIG_SPI_INTEL_SPI_PLATFORM
# pro distra kde je config dostupny pres procfs
zcat /proc/config.gz | grep CONFIG_SPI_INTEL_SPI_PLATFORM
pokud je odpovedi:
CONFIG_SPI_INTEL_SPI_PLATFORM=m
je pritomno jako jaderny modul
pokud je odpovedi:
CONFIG_SPI_INTEL_SPI_PLATFORM=n
neni pritomno...
EDIT: omlouivam se za mystifikaci, prehledl sem se pri aktualizaci opravdu opravny balicek kernelu 4.13.0-21.24 je(a byl) dostupny jiz v stable security repositari pro 17.10
http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_4.13.0-21.24/changelog
Taky se mi odpalil motherboard (3 roky stare HP) notas nebootoval. Znackovy servis me poslal nekam ... neznackove taky....
Objednal jsem si repas motherboard z ebay za $ 150,- . Ztahl servisni manual... desku vymenil... a Vse slape jak ma... jiz 3roky..Momentalne ubuntu 17.10..;-)... notas stakl 20 k. ...
Kod pro SPI flash byl pridan od v4.11-rc1 a opraveno v4.15-rc4:
https://github.com/torvalds/linux/commit/ff00d7a32a1b88b772981a13fc198e0d29300666#diff-7d690ccea0339eab44643985431f548d
https://github.com/torvalds/linux/commit/d9018976cdb6eefc62a7ba79a405f6c9661b08a7#diff-7d690ccea0339eab44643985431f548d
Jo to je už taková doba. Všechno se rychle mastí aby se mohlo co nejdříve uvolnit do prodeje a chyby se řeší operativně. Mobily jsme taky kdysi nemuseli téměř nikdy updatovat. Dnes? - minimálně jednou týdně. To že nenaleznete nějakou užitečnou položku v biosu a že těch možností spíše ubývá již taky pozoruji nějaký ten rok - no přeci bfu ani neví že nějaký bios/uefi je a proč by měl v něm něco měnit.
Mobily se neaktualizovaly, ale to neznamená, že v nich nebyly vážné chyby. Pamatuju se, že můj první Siemens C25 se dal jednoduše kousnout posláním SMS ve tvaru #English (nebo podobně). Nejen že to telefon sejmulo na dálku, ale ta zpráva se pak nedala ani smazat ani přečíst a SIM musela do jiného telefonu. Takových chyb byly mraky u každé značky. Jen se o tom tolik nemluvilo a zneužitelnost byla nižší, protože to byl opravdu jen telefon. Ale ty chyby tam byly.
[Jarda_P]
No, to me ani tak nedesi, ale z diskuzi mi zacina vyplivat, ze je docela problem ten bios obnovit. To me hlava nebere. Chlapek vyse psal, ze ten notas poslal Toshibe do servisu a oni mu jej vratily jako neopraveny. To neumeji sakra prehrat bios? O.o
P.S.
Nechci tim tvrdit, ze pro me je to malina, kterou delam z nudy u ranniho kafe. Ale u servisu vyrobce bych cekal trochu vetsi technickou zdatnost... :(
myslíš, že evropské zastoupení vyměňovačů náhradních dílů ti bude flashovat nějakého švába? To fungovalo takhle na počátku, dnes dostávají jen návod jak to rozmontovat a jak vyměnit konkrétní díly, které vyměnitelné jsou, což v praxi je základní deska.
Docela by mě zajímal důvod zamítnutí reklamace. Za mě výrobek, kde SW může omylem přepsat nějakou paměť a rozbije s tím HW je vadný, není to běžná vlastnost a je to za mě důvod k reklamaci, nejspíš v manuálu upozornění, že tuhle konkrétní paměť nemám v žádném případě přepisovat nebylo, stejně tak nebylo potřeba udělat jiné úpravy, které by zápis zpřístupnili.
Ale tu sa pise ze rovnaku chybu ma aj OpenSUSE tak aby si si neodpalil aj druhy NTB
https://www.root.cz/clanky/ubuntu-17-10-bylo-docasne-stazeno-poskozuje-bios-nekterych-notebooku/nazory/952104/
technicky to je skoro jedno, šikovný člověk si to udělá sám. Problém je, že na to nemají návody, postupy, zařízení, mají třeba jednotky lidí na celou EU, kteří toho jsou schopní, ale k nim jdou jiné technické problémy často od firemních zákazníků.
Lenovo (IBM) dřív opravovalo třeba přímo v Praze, dnes to vše někam posílal a zpravidla zamítají rovnou i jednoznačné problémy, asi mají nějaká kpi.
Toshiba má i v Praze poměrně dost technických lidí, ale customer reklamace k nim nechodí, asi se jim to nevyplatí.
Jde jen o to, do jaké míry opravitelné. Notebooky opravitelné jsou - výměnou dílu. Základní deska sama o sobě opravitelná (spolehlivě, se zárukou) není. Přidejte k tomu náklady na identifikaci problému - zaměstnáte tím velmi kvalifikovaného člověka v řádu hodin a finanční efekt opravy proti výměně pryč.
Jako zákazník si u dražšího notebooku připlaťte za další rok záruky. Jako firma s počtem notebooků v řádu mnoha desítek až stovek se na to vykašlete, protože statisticky se vám to nevyplatí - občas koupíte nějaký notebook předčasně, ale v průměru vám vydrží dobře použitelné nějaké 4 roky, když nekupujete úplně nejlevnější kousky. Drobnosti, jako výměna disku nebo nový zdroj, případně rozšíření paměti, servis většinou nevyžadují.
Notebooky opravitelné jsou - výměnou dílu.
Jak které...
V masine kde som mal Intel e1000 som mal od nich aj wifi kartu (uz si presne nepamatam model). Povodny firmware tej wifi karty sa obcas zblazdnil a cez DMA pisal "co vidiel vo vzduchu" na nahodne adresy v pamati. Kedze islo o HW problem, tak to robilo aj v Linuxe aj vo Windowse ... to boli prebdene noci, nez som nasiel co sa s tym laptopom deje ... a to nehovorim o kolko veci som prisiel medzi daily backupami ...
Na desktopu ma linux tak jedno procento, z toho jsou notebooky mozna pulka. To je 5 z 1000. Z toho si ubuntu nainstaluje tak kazdej patek. To je 1 z risice potencialne ohrozenych uzivatelu
A pak to zazlobi mozna na kazdem stem stroji jen pro dobry vypocet a to je 1 z milionu uzivatelu pc je timto clankem ohrozen.
Já se vyjadřoval k tomu velmi obecnému tvrzení, že "pokud se dá hardware poskodit softwarem, je to automaticky chyba výrobce". Takže mě zajímá, jestli je chybou výrobce umožnit přetaktování, ovládání ventilátorů nebo přeflashování BIOSu. Všechno se to provádí prostřednictvím softwaru, je tedy chybou výrobce, když tyhle "díry" někdo používá špatně a v důsledku si ten hardware odpálí?
A ted mi rekni jak pretaktovanim/vypnutim ventilatoru poskodim HW ?
Pokud je mi znamo tak standardni MB neumoznuji extremni taktovani s vypnutymi ochranami ktere se pouziva na soutezich kde vylozene nici jednu sestavu za druhou - protoze s tim pocitaji.
Kdyz vypnu ventilatory a pretaktuji GPU nebo CPU tak dojde na throttling a pri nejhorsim na shutdown... k poskozeni HW to ma daleko, pokud se mi tim podari znicit HW tak je neco spatne -> reklamace.
K tomu BIOSu to ze nekdo povoli zapis do BIOSu jeste nutne neznamena ze to je spatne, spatne je kdyz ten zapis nenavratne umrtvi BIOS, vzdy by mela byt moznost nejake recovery napr. drzet pri bootu specifickou klavesu a do portu USB1 mit vlozenou flash s FAT32 na ktere je /bios.bin z ktereho se BIOS obnovi do factory stavu.
Treba v pripade teto chyby nechapu proc ma SW moznost nastaivt CMOS v BIOSu jako read-only a tim jej prakticky umrtvit
Pokud se CPU pretaktovanim da znicit, je chyba vyrobce CPU ze to dovoli. Pokud se PC da znicit vypnutim ventilatoru, je opet chyba vyrobce, ze to dovoli.
Normalni totiz je, ze kdyz se neco zacne trebas prehrejvat, tak se to zcela samo brani, naprosto bez ohledu na SW. Trebas tak, ze se to proste vypne.
lol ... tys vzivote naprosto zadny CPU nevidel ze? I blby TTL hradlo se umi branit prehrati, a kdyz prekrocis jeho frekvencni parametry tak se ... nestane VUBEC NIC. Proste jen nebude fungovat. Nekdy se hranicni parametry vyuzivaj trebas na generovani nahodnych cisel, ale to TY nemuzes ani tusit.
Zrejme nevite jak funguje CMOS, kdyz neco takoveho pisete. U technologie CMOS roste spotreba linearne s frekvenci a pri prechodu z H do L a naopak jsou tam po urcitou dobu proudove spicky. Cim rychleji nutite CMOS hradla pracovat, tim vice vam bude rust spotreba a teplota. Ani nemusite dosahnout maximani frekvence, na ktere je cip schopen pracovat a pokud budete mit spatne chlazeni, tak to bez ochrany znicite.
2J: Ja samozrejme velmi dobre vim, ze CPUcka maji uz dlouhou dobu ruzne ochrany proti prehrati.Pres snizovani frekvence hodin az po THERMTRIP, kdy se CPU samo vypne. Ja jsem reagoval na Vasi odpived, ze i TTL hradla se sama brani proti prehrati. Srovnavat dynamicke chovani TTL a CMOS technologie je dost mimo. CMOS se dynamicky chova uplne jinak, nez TTL.
Vetraky si na x86 nemas co ovladat z OS. Maximalne muzes poslat setting LOW,MID,HI,AUTO. O ovladani se ma starat nadrazeny system. Ovladni z OS je typicky systemovy antipatern.
Pretaktovat CPU z os muzes v ramci povoleneho scalingu. Dal ne. A ani bych tomu nerikal pretaktovat protoze to je vyrobcem doporucena mez.
Upgrade BIOSu nemas co delat z OS. Na to ma byt jiny externi interface. Napr. po bootu nebo ruzne out-of-band management systemy.
To bylo v dobách, kdy byl hardware a software. To už je desítky let pryč.
Dnes máte doma kromě toho ještě firmware. Plus se ten rozdíl stírá díky věcem jako jsou FPGA, DSP atd. Prostě vám v kdejaké kravině dřepí něco, co vykonává program. V takovém PC máte dnes desítky procesorů, protože řada věcí se řádově snadněji řeší pomocí MCU vykonávajícího nějaký program.
Zjednodušeně se dá říci, že dnes se část HW dá rekonfigurovat za běhu. Zda je nová konfigurace vhodná ten HW nepozná a spoléhá se na to, že to někdo ověří před tím, než ji do HW nahraje. A zvykli jsme si na to, běžně akceptujeme, že součástí updatu ovladačů je i nový firmware.
Pokud se budeme ale bavit o téhle konkrétní chybě, tak to je špatně. Před lety bylo běžné, že jste prostě nemohl nahrát nový BIOS bez překonání nějaké ochrany - dříve to byl jumper na desce, časem volba v BIOSu, která to dočasně povolí. To není o HW a SW.
HW a SW je tu porad. Mam tu 15 let starou krabku, ma firmware, da se aktualizovat ... a vis co se stane kdyz tam nahrajes klidne data z generatoru? NIC. Nebude to fungovat, ale ma to NEPREPISOVATELNOU cast, ktera umozni ten firmware kdykoli prepsat (a je mu uplne jedno co tam zapisujes, veme to proste jako binarni stream a presne jak to posles to i zapise) ... PROC? Protoze tvuce nebyl debil.
Řešíte teď úplně jinou věc. Zkuste místo náhodných dat nahrát validní program, který ale bude dělat nějakou botu. Ochranu ve formě "když nesedí checksum tak to nespouštěj" má dnes všechno. Zajímavější jsou ochrany proti tomu, aby to neudělalo něco špatně. A tam už to pokulhává na obě nohy. Když do MCU nahraju firmware, který na signál koncového spínače nereaguje, tak prostě nereaguje. A to jsou pak právě lidé chytří "když SW dokáže zničit HW". Ještě by byla legrace se podívat, zda se třebas nedají nastavit "fuse", to také bývá docela legrace, že to u mnohých MCU jde nastavit při ISP.
Mimochodem, dnešní CNC stroje mají dvě úrovně koncových spínačů. Kupříkladu Hallovu sondu, která generuje signál pro MCU (a to si na to reaguje jak uzná programátor za vhodné), a pak mechanický spínač až na konci (který vypne napájení). Důvod je právě nedůvěra ve firmware. Je sice fajn, že firmware dokáže zareagovat a stroj správně zastavit (postupně spomalí, pošle zprávu řadiči a drží stroj v nějakém definovaném stavu), ale pořád se bojí, že v tom může být chyba. Proto je tam fyzický koncák, který vypne napájení - ovšem za cenu poškození obrobku i stroje (krokový motor bez proudu nemá žádnou sílu, části co se hýbaly mají hybnost atd.)
Co to placas probuh ... To ze nekam nahrajes SW kterej nedela co ma neni zniceni HW.
Vis co udela kazdy normalni letadlo kdyz nejde elektricky nebo hytraulicky vysunout podvozek? Vyuzije gravitaci a on se vysune sam. Tomu se rika bezpecnej navrh konstrukce. Vis kdo moh za to ze psonkove pristavali na bricho? Neschopny piloti, ostatne jako v 80% pripadu.
Na zastaveni motoru na dorazu neni treba cidlo vubec zadny. Staci na to trebas uplne obycejna pojistka = kus dratku co prehori pri zvysenym odberu.
Tak hlavně jak bylo ve vyšetřovací zprávě konstatováno, aerolinky neprovedly instalaci ochrannýho rámečku pojistkového panelu (takže si piloti kufrem pojistku vyšťouchli), a neprovedly proškolení mechaniků, kteří by jinak piloty na možnou vystrčenou pojistku upozornily. Tak holt někdo v aerolinkách ušetřil za kousek plechu a školení za cenu odepsanýho éra za cca miliardu.
Nevite prosim nekdo jestli se to tyka i Kubuntu 17.10 nebo jen klasickeho Ubuntu? Mam Lenovo (ne sice notebook, ale All in One) s Windows 8.1 na disku complu a z externiho usb disku obcas nabootuji Kubuntu 17.10. Prave na tech Win potom pozoruji rozhozeny cas, coz by mohlo souviset s BIOSem. Podotykam, ze jedu v legacy modu a ne UEFI. Nerad bych si podelal BIOS.
@D.A. Tiger:
Nejspíš jo.. Takhle to má Debian:
$ grep INTEL_SPI /boot/config-4.13.0-0.bpo.1-amd64
# CONFIG_SPI_INTEL_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
>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_dword(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_dword(dev, BCR, &bcr);
if (!(bcr & BCR_WPD)) {
bcr |= BCR_WPD;
pci_write_config_dword(dev, BCR, bcr);
pci_read_config_dword(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.
Stalo se to i u IBM. IBM vs lmsensors. V mem pripade tedy Thinkpad 770Z. Nastesti se podarilo sehnat nahradni cip.
http://www.thinkwiki.org/wiki/Problem_with_lm-sensors
Celkem se divim ze se o tom nikdo ve foru tady nezminil.
Jinak rozhozený čas je častý při přechodu mezi Linuxem a Windows kvůli různé vnitřní reprezentaci toho, co BIOS čas znamená (jestli je v UTC - výchozí v Linuxu nebo v lokálním čase jak to předpokládají Windows). Projevovalo by se to posunem o násobek hodin (1 resp. 2 hodiny v našich zeměpisných šířkách).
Toto chcel byt asi humor, ale nie je.
Tato situacia ma s Ubuntu a Debian spolocne iba tolko, ze pouzivatelia vsetkych distribucii mozu podakovat Ubuntu pouzivatelom, ze si to za nich vyzrali.
Problem nie je v Ubuntu ale v kerneli Linuxu. Ubuntu ma dostatocnu vahu a ochotu to s Lenovom riesit. Hoci za Ubuntu stoji firma ja ho stale vnimam pod povodnym heslom: od ludi pre ludi.
Smutne je ze nevyuzili prvotne hlasenia od beta testerov, aj instalacku nestiahli dostatocne rychlo, aby ochranili dalsich pouzivatelov. Proste ta spetna vezba od pouzivatelov nie je tak idealna ako by mohla byt.
Ty si ale neuvedomujes jednu vec. Ubuntu je "jednoduchy Linux" pro "jednoduche lidi" a tak to ma byt. Ne kazdy je guru, aby zvladl napriklad LFS. Prave kvuli takovym nazorum ma Linux na desktopu tak male zastoupeni. Nedovedu si predstavit ze bych treba me matce nebo dedovi rekl at si zkompiluji a nastavi Gentoo. Lidi jsou totiz hloupi a lini a tak k nim musis pristupovat. Vetsina lidi se totiz snazi myslet jen do nezbytne nutne miry a na nejake odladovani a experimenty kaslou. Ja takovy nejsem, ale vetsina proste je. Chteji snadne a hotove reseni. Ubuntu takove reseni nabizi ... ktere zvladne mozna i sedmilete dite a to je dobre.
Přesně!
Jen bych to zmírnil z "hloupí a líní" na "neambiciózní nebo nemající čas".
Vždyť kolik z nás jezdí autem a dovede si na něm udělat běžnou údržbu (filtry, provozní kapaliny)? A kdo z nás dovede vyměnit svíčky? Většina lidí jen jezdí a nechá to profesionálům - a stejně to máme s počítači: hlavně ať to funguje a nemusím se o to starat.
A tak je to správně (komparativní výhoda).
K tem autum bych to vubec neprirovnaval. Dneska se bohuzel ani ty nejjednodussi ukony neobejdou bez ruznych specialnich pripravku nebo triku. Treba takovy francouzky takyauta je lahudla. Vymena parkovaci zarovicky u renaultu - vytocte kolo, otevrete platovej dekl v podbehu a satrejte rukou. Vyndani snad ok, nasazeni chce vetsi trpelivost. V autorizovanem servisu to technich po 20 minutach vzdal, me se to asi nahodou povedlo po peti minutach. Pak se divte lidem ze jedou radej do servisu s takovoudle popelnici,
Lenze to je troska ine... V IT je to este vacsi extrem. Nikto nechce po beznych useroch zaklady programovania a sietariny alebo len trocha hlbsie vedomosti o HW stroja. Ale bezny useri nevedia castokrat ani zaklady prace s PC, nemaju ani elementarne vedomosti o nastroji, ktory pouzivaju. A to je fatalny rozdiel - pretoze vodic auta musi mat nejake zakladne vedomosti o automobile a jeho riadeni (ved sa to uci aj v autoskole). Cize ja by som to cele prirovnal skor asi takto. PC useri su ako vodici, ktory hovoria: ja nepotrebujem vediet, naco sluzi volant, ja len chcem aby to islo. A ked sa clovek spyta, ci chcu ist dopredu alebo dozadu, ani len nepoznaju odpoved.
Az na to, ze kdyby to byli profici, tak jim to rad necham. Bohuzel to vypada tak, ze jim musis rict co maj delat, jak maj delat a jeste nad nima stat s klackem v ruce aby to vazne i udelali ... a to si ten servis uz muzu udelat rovnou sam a bez nervu.
Onehda sem se s jednim takovym trotlem dohadoval jestli teda tu svicku vynda nebo ne, paac na ten motor cumel jak kdyby to byla technologie z jiny galaxie.
Bezna udrzba auta je soucasti technicke pripravy v autoskole takze ridic ji ma zvladat. Proto ma taky s sebou navod k pouziti. Pokud to nezvlada, tak to holt zacvaka a jeste mu to neprojde u policajtu pokud to resi v navaznosti na nakou nehodu. Svicky nebo zhaviky nejsou soucasti bezne udrzby. To tak maximalne u sekacky ci male motorky.
U svicek je motor dnes zadeklovany a kolikrat se k tomu bez specialich nastroju nedostanes.
Treba v pripade letadel si ani servis jako pilot delat nesmis. Jediny co muzes tak otevrit dekl motoru a podivat se jestli motor vypada ok. I zapojit kabel na baterce musi kvalifikovany mechanik.
Neviem, kedy si absolvoval autoškolu a či v ČR ešte niečo také zostalo, ale na Slovensku technická príprava vyučovaná v autoškole je momentálne asi tak pozrieť sa, či svietia svetlá a či nie sú mäkké gumy (manželka si robila autoškolu pred rokom).
Ja som mal pred 14 rokmi trošku podrobnejšiu, a bolo treba sa naučiť obkec o jednotlivých technických častiach, ale to je už minulosťou.
Udrzba auta neni soucasti autoskoly a jestli kdy byla tak 50let zpatky mozna. Tak maximalne tam byla(a je) hromada naprostych nesmyslu. Ostatne bych chtel kohokoli videt, jak si bude vymenovat nekde venku na silnici rezervu s tou parodii na hever a klic. 2m lesenarsky trubky aby se to dalo povolit sebou bezne vozi kazda mamina s kocarem.
Udrzba/servis auta se resila tak mozna ve vojensky autoskole, protoze nase army byla narozdil od ty US koncipovana tak, ze si ridic musi umet auto i kompletne opravit.
Mas smulu brouku.
Zrovna ceskou autoskolu delam protoze muj ridicak ze zahranici zde neplati. Zakladni udrzba auta/motorky je soucasti autoskoly. C,D,E to maji jeste brutalnejsi.Jenom si to nesmis vykladat tak jako ze kazdy z autoskoly bude umet vyplachnout prevodovku a seridit predstih. To ostatne neumi dneska poradne ani znackove servisy. Zakladni udrzba auta neni to same co servis.
Mezi udrzbu auta patri napriklad: Zakladni diagnostika typu: mam nedostatek brzdovky,mam spatnou hladinu oleje. Dolevani provoznich kapalin.Kam se co leje, jaky mam palivo, mam spravna kola, sviti to,blika to,troubi to. Jaky mam gumy, jsou podhustene/prehustene? Co da auta leju za palivo/energie? Co znamenaji kontrolky? Co delat pri vymene kola (pravda, tady jsem vetsinou fungoval jak americky vojak v afghanistanu(helpdesk) protoze ty americke kraksny vazi 2 tuny...). Kde muzu najit co se kde nachazi->navod.
Presne, keby to dotiahol momentovým kľúčom na nejakých 110 Nm či koľko býva u bežných áut, tak to ide v pohode.
Teda v pohode to nebolo u mňa raz, keď som jedno auto mal viacmenej odstavené 3 roky. Ale vlastne si nepamätám, či som to vôbec pred tým uťahoval sám osobne alebo to tiež bola práca nejakého prasiča.
Prasata v pneuservisech mivaji levne pneumaticke klice bez vymezeni momentu. Nejake osetreni sroubu polosuchym/suchym mazivem na to se kasle. Takze clovek muze skoncit tak ze mu to utahli treba 2x tak vetsim krouticim momentem ( a to si fandim ze to nebylo vic a nenatrhli zavit nebo nepraskl sroub).
Jak je clovek starsi, tak ceka hovado na kazdem rohu. Uz se bojim dat si cokoliv externe opravit.
Osobna skusenost je taka, ze ked som chcel aspon trocha pouzitelny zvuk tak som si musel skompilovat vlastny kernel. Takze som nechal ten debilny Debian iba na serveri, aby to bolo z rovnakej rodiny ako Ubuntu na desktope. S nicim v zivote som nemal tolko problemov ako s Debianom.(Invektivy pouzivam umyselne, aby bolo jasne, ze dalej docuram.)
Intel PCH/PCU SPI flash platform driver (SPI_INTEL_SPI_PLATFORM)
CONFIG_SPI_INTEL_SPI_PLATFORM:
This enables platform support for the Intel PCH/PCU SPI
controller in master mode. This controller is present in modern
Intel hardware and is used to hold BIOS and other persistent
settings. Using this driver it is possible to upgrade BIOS
directly from Linux.
Say N here unless you know what you are doing. Overwriting the
SPI flash may render the system unbootable.
V Ubuntu evidentne nevedej co delaj :)
Možná by stačilo to nechat jako modul, ale blacklistnout to v modprobe.d aby se to nenačetlo automaticky. Ale ano, to by znamenalo, že ví co dělají.
Já mám 4.12 debian unstable a ta ta to má vypnuté. (Ale je pravda, že jsem musel před třemi měsíci taky dávat notebook do servisu, protože se nejdřív nechtěl vypnout a pak se přestal nabíjet, takže je možné, že je tam ještě nějaká chyba. Ale tehdy jsem měl asi nižší kernel. (snad 4.9) )
Na obranu Ubuntu se slusi rict, ze to je napsano u pulky veci v kernelu :) Proste klasicky disclaimer.
Kazdopadne spise nechapu jinou vec - kdyz se mrknes na tu opravu:
Tak z toho jasne plyne, ze driver behem sve INICIALIZACE zmeni WPD bit - tzn. umozni zapis do tohoto regionu (a to je to, co detekuje Lenovo BIOS, mysli si, ze doslo k flashovani a tim se to rozbije) - to mi prijde jako obrovsky fail a zasadni chyba - k takove operaci neni nutne pristupovat dokud si to nekdo skutecne nevyzada (e.g. chce tam neco zapisovat)
v dobe psani tveho prispevku uz bylo davno (1.5dne) aktualizovane jadrou s vyplou problematickou funkci, jedine kde to zatim nezmenili je iso 17.10, pokud uz si ale nainstalovano mel, stacila jen aktualizace jadra ;-)
viz https://www.root.cz/clanky/ubuntu-17-10-bylo-docasne-stazeno-poskozuje-bios-nekterych-notebooku/nazory/#o952113
Spis Lenovo ne ? 92% odpovednosti za tuto chybu spada na lenovo/dodavatele BIOSu kde je prasarna/nestandardni chovani implementovane, 8% na ten driver ktery se jen chova podivne ale ne vylozene spatne protoze nastaveni WRITE bitu by nemelo nikdy nic rozbyt (pokud v FW nejsou prasarny)
A teď bych ještě prosil vysvětlení, co je tomu driveru do toho, jestli to zařízení je nebo není zapisovatelný, jestli do něj má co zapisovat, a pokud do něj nic k zapsání nemá, tak proč ochranu proti zápisu vypíná. Protože pokud nikam nic zapisovat nechci, nemám co ji vypínat a rumplovat "páčkama" jak mě napadne jen proto, že k tomu mám prostředky. A pokud nic k zapsání nemám, tak nemám ani důvod zjišťovat, jestli někam zapisovat jde. A skutečně vřele pochybuju, že (s maličkou nadsázkou) vytažení transportní pojistky a uvolnění vrhový pojistky je u granátu optimální způsob zjišťování, jestli je ostrej.
Abych to shrnul, hochům se podařilo celou distribuci slušně diskreditovat a budou mít velikou hoňku, aby ten průser napravili, protože do budoucna si každej s byť jen stopou pudu sebezáchovy hodně rozmyslí, jestli Ubu vůbec instalovat.
BTW můj návrh jména "Aggressive Alien" by tý verzi seděl daleko líp.
Az na tu drobnost, ze ten modul je v jadru prave a pouze kvuli zapisu, a tvurce toho modulu zjevne predpoklada, ze kdyz uz si ho nekdo loadne, tak ze zapisovat nejspis neco chce, protoze jinak ten modul nanic nepotrebuje a tudiz (v souladu s tim co je napsany i v jeho popisu) ho nema pouzivat.
IMO hlavní chyba je u výrobce notesu, který tento switch u flash ROM používá k indikaci autoupdate a proto se poškodí BIOS/UEFI (nebo jak je to třeba u Lenovo Yoga k indikaci změny konfigurace BIOS/UEFI konfigurace a proto smaže CMOS data). K tomu ten switch opravdu neslouží, to si mají poznamenat někde jinde než k tomu zneužívat tenhle bit pro indikaci RW/RO flash ROMky.
Jojo, ale úplně stejně bys mohl argumentovat tím, že než na nějaký hw pustíš svůj se, měl by sis v jeho dokumentaci ověřit jeho chování. Protože "vytažení pojistky" blokující nějakou operaci v každodenní logice neznamená "kontrola jestli je operace proveditelná", nýbrž "jsem připraven dotyčnou operaci provést a provést ji chci".
Jističe doma taky neshazuješ primárně proto, aby sis ověřil že skrz ně přestane téct elektrika, nýbrž proto, že na vedení za nimi chceš a vzápětí budeš pracovat. Dům taky neodemykáš proto, abys zkontroloval možnost otočení zámkovou vložkou, nýbrž proto, že hodláš vstoupit.
Vynulování příznaku "zápis zakázán" s cílem ověřit, jestli to nehodí chybu, je v nejlepším případě bastl. Ten čip má mít read-only bit, který mi to řekne.
A pokud k přečtení vlastnosti použiji bit, který říká "nebraň se zápisu", pak se ani neobtěžuju ho vrátit na původní hodnotu, a pak se divím že se něco potento, měl bych si vrazit facku přes celou hubu.
"mít read-only bit, který mi to řekne" ... jo, a pak zjistis jak vypada realita ... sem zvedav, jak trebas overis ze se da/neda zapisovat na flashku s nejakym mechanickym prepinacem. Kdyz ani ta flashka sama nevi, jestli je nebo neni RW.
Takze docela chapu, ze jedinej zpusb jak realne zjistit ze se nekam neco zapsa da, je vyzkouset to.
S touhle argumentací mi jistě dokážeš říct, kdo naposled na SPI sběrnici použil jumper namísto toho, aby se zařízení na ní "prostě" zeptal. Protože pokud to chápu správně, bavíme se tu o sběrnici v PCčku, po který si BIOS/EFI od pamětí při startu vyžádají jejích parametry, po který se aktualizuje samotný BIOS/EFI, apod.
Boha jeho! Po kolikátý už se tohle stalo? Uživatel/SW se pokusí o triviální a operaci, kterou naprosto právem nepovažuje za jakkoliv nebezpečnou, ale FW/HW se při ní zachová tím nejdementnějším možným způsobem a totálně na ní vybouchne. Chování dotyčnýho driveru vážně není úplně ideální (jak uvedli ostatní, pro účely testu zapisovatelnosti měl kód zkusit onen bit překlopit, ověřit výsledek a okamžitě obnovit bezpečný stav a hlavně to určitě zbytečně nedělat během inicializace, ale až při pokusu o flashování), ale to stejně absolutně nijak nemění fakt, že se výrobce opět projevil jako 100% nukleární hovado. Pro mě tenhle incident znamená definitivní ztrátu důvěry v Lenovo.
ono i ofiko distribucni jadro je skoro tejden opravene/aktualizovane ;-)
https://www.root.cz/clanky/ubuntu-17-10-bylo-docasne-stazeno-poskozuje-bios-nekterych-notebooku/nazory/#o952113
btw: na x260 ten problem asi ani nebyl, ja mam 17.10 (s distribucnim jadrem) na T420s a zadnej problem ani s "vadnym" jadrem nemel... problem meli jen zkryplene modely