Jaderné noviny – 30. 6. 2011: Regrese správy napájení ve 2.6.38

12. 7. 2011 | Jirka Bourek | Jaderné noviny | 3761×

Aktuální verze jádra: 3.0-rc5. Citáty týdne: Frederic Weisbecker, Mauro Carvalho Chehab, Andrew Morton. -EJAKOUCHYBU? PCIe, správa napájení a problematické BIOSy. Umravňování výstupu do logů.

Obsah

• Aktuální verze jádra: 3.0-rc5
• Citáty týdne: Frederic Weisbecker, Mauro Carvalho Chehab, Andrew Morton
• -EJAKOUCHYBU?
• PCIe, správa napájení a problematické BIOSy
• Umravňování výstupu do logů

Aktuální verze jádra: 3.0-rc5

Současné vývojové jádro je 3.0-rc5 vydané 27. června. Nic výrazně zajímavého. Nejzajímavější věc je asi to, že v ovladačích je jenom čtvrtina změn, víc (40 %) mají ve skutečnosti na svědomí souborové systémy: jsou tu btrfs, cifs, ext4, jbd2 a nfs. Detaily lze nalézt v kompletním changelogu.

Stabilní aktualizace: 23. června vyšly s dlouhým seznamem oprav aktualizace jader 2.6.32.42, 2.6.33.15 a 2.6.39.2. Aktualizace 2.6.34.10 – první od dubna – vyšla 26. června taktéž s velmi dlouhým seznamem oprav.

Citáty týdne: Frederic Weisbecker, Mauro Carvalho Chehab, Andrew Morton

Protože jsem se tak dlouho zabýval rcu dynticky pro věci ohledně nohz cpuset, hádám, že moje podvědomí došlo k závěru, že rozšířené klidové stavy rcu jsou celosvětově rozšířeným tématem, o kterém rodiny mluví během večeře a které se dokonce stalo základem některých ukolébavek. Stále slyším ten refrén, který vám umožní přepnout se s klidem do klidového stavu...

-- Frederic Weisbecker

Specifikace V4L2 je potřeba opravit, co se chybových kódů týče. Autoři ovladačů jsou mnohem kreativnější než autoři DocBook.

-- Mauro Carvalho Chehab

Různá POSIX_FADV_něco jsou tak špatně definovaná, že bylo chybou je vůbec použít. Měli jsme udělat něco jasně specifického pro Linux a dát uživatelskému prostoru explicitnější a přímější kontrolu na cache stránek.

-- Andrew Morton

-EJAKOUCHYBU?

napsal Jonathan Corbet, 29. června 2011

Uživatelé API Video4Linux2 ví, že je poněkud komplikované, obsahuje 91 různých příkazů ioctl(). Co se hlášení chyb týče, je mnohem jednodušší: pokud se něco pokazí, aplikaci se téměř určitě vrátí EINVAL. Tato chyba může uživatelskému prostoru zkoušet sdělit, že zařízení je ve špatném stavu, že nějaký parametr byl mimo rozsah nebo jednoduše že požadovaný příkaz nebyl implementován. Není potřeba říkat, že pro vývojáře je těžké zjistit, co se vlastně stalo.

Správce V4L2 Mauro Carvalho Chehab nedávno zaslal patch, který mění návratový kód na ENOIOCTLCMD v případech, kdy relevantní ovladač neimplementuje požadovaný příkaz. Tato změna by rozlišila alespoň jednu sadu problémů – až na to, že kód VFS v tichosti překládá ENOIOCTLCMD na EINVAL předtím, než chybu vrátí do uživatelského prostoru. Z pohledu aplikace se tedy nemění nic.

Zajímavé je, že podle pravidel je jasné, co se v takové situaci má stát: pokud ioctl() příkaz nebyl implementován, jádro by mělo vrátit ENOTTY. Některé části jádra tuto konvenci dodržují, jiné ne. A není to nový problém ani problém specifický pro Linux; jak to řekl Linus: Tahle věc okolo EINVAL jde hodně do minulosti a je to pohroma. Pokud vím, je to starší záležitost než Linux samotný. Navrhl jednoduše změnit ENOIOCTLCMD na ENOTTY v celém jádře a zjistit, co se stane.

Samozřejmě se stane to, že se změní ABI pro uživatelský prostor. Je zcela možné, že někde venku nějaký program závisí na tom, že při chybějící ioctl() funkci dostane EINVAL a že když se návratový kód změní, přestane fungovat. Je ale jenom jeden způsob, jak to říci s jistotou: udělat změnu a zjistit, co se stane. Mauro hlásí, že tato změna ve V4L2 podle všeho nic nerozbíjí, takže je slušná šance, že se dostane do jádra 3.1. Změna v celém stromě by ale mohla mít mnohem širší důsledky; jestli někdo najde odvahu to zkusit, to se uvidí.

PCIe, správa napájení a problematické BIOSy

napsal Jonathan Corbet, 29. června 2011

V dubnu Phoronix s fanfárou oznámil, že jádro 2.6.38 – a ta následující – obsahuje „zásadní“ regresi ve správě napájení, která na některých systémech výrazně snižuje dobu běhu na baterie. Problém vygeneroval poměrně dost diskuzí včetně tohoto vlákna v Launchpadu, ale málo řešení. Phoronix nyní tvrdí, že našli změnu, která způsobuje problém, a poskytl workaround, který pro některé uživatele stav zlepší. Skutečná oprava ale asi jen tak nepřijde.

Protože se u PCI-Express zařízení používají vysoké takty hodin, mohou tato zařízení spotřebovat hodně energie, i když jsou nečinná. Proto byla vyvinuta „správa napájení pro aktivní stav“ [Active state power management, ASPM], která periférie přepne do režimu se sníženou spotřebou, když se zdá, že nebudou potřeba. ASPM může ušetřit energii, ale je zde obvyklé něco za něco: zařízení v režimu nízké spotřeby není okamžitě k dispozici. Na systémech, kde se ASPM používá, může přístup k zařízení, které je právě vypnuté, trvat výrazně déle. V některých situacích (obvykle v těch, které zahrnují běh na baterie), to může být akceptovatelné; v jiných ne. Takže jako většinu mechanismů pro správu napájení lze i ASPM vypnout a zapnout.

Je to ale o něco komplikovanější; na systémech x86 se do toho vkládá BIOS. BIOS je pověřen počáteční konfigurací systému a tím, aby jádru sdělil, jaké funkce jsou k dispozici. Jednou z těchto informací je to, jestli systém obsahuje podporu ASPM. Jaderní vývojáři vcelku rozumně došli k závěru, že pokud BIOS řekne, že ASPM není podporováno, neměli by hrabat do registrů s ním spojených. Ukázalo se ale, že tento přístup nefungoval; v prosinci tedy Matthew Garret začlenil patch popsaný takto:

V současnosti se odmítáme dotknout ASPM registrů, když nám BIOS řekne, že ASPM není podporováno. To může způsobit problémy, pokud BIOS (z jakéhokoliv důvodu) na některých zařízeních ASPM i přesto povolil. Kód se mění tak, abychom explicitně vynulovali ASPM, pokud FADT udává, že ASPM není podporováno, a aby se všechno při odstranění zařízení uklidilo, což řeší případ připojování za běhu.

Jinými slovy BIOS někdy systému sdělí, že ASPM není podporováno, přestože je; a aby to bylo zábavnější, BIOS může ASPM na některých zařízeních zapnout (přestože tvrdí, že není k dispozici) předtím, než předá kontrolu jádru. Vývojáři operačních systémů nemají vývojáře BIOSů v úctě a má to své důvody.

Kdyby si Andrew Morton changelog uvedený výše přečetl, určitě by si stěžoval, že „může způsobit problémy“ je pro změnu jádra poměrně vágní odůvodnění. Autor článku se Matthewa zeptal a získal informativní odpověď, kterou stojí za to přečíst si ji celou:

Pokud je tento bit nastaven, platforma oznamuje OS, že nepodporuje ASPM. V minulosti jsme to brali tak, že jednoduše nemáme na ASPM bity sahat. Ukazuje se ale, že na některých systémech BIOS povoluje ASPM sám, pak nastaví bit „ASPM není podporováno“ a když dojde k přechodu do ASPM, hardware zhavaruje. Nejjednodušší věc, která se dá předpokládat, je, že BIOS je hloupý (abych byl upřímný, to předpokládám vždy) a neměl ASPM povolit. Od tohoto patche tedy vynulujeme stav ASPM, když BIOS oznámí, že platforma ASPM nepodporuje.

Není těžké si představit, že přepnout zařízení do stavu, o kterém se jádru řeklo, že neexistuje, může v některých případech vyvolat zmatek. Trocha hledání například našla toho hlášení o zatuhnutí systému, které Matthewův patch opravil. Pokud BIOS tvrdí, že ASPM není podporováno, zdá se, že dává smysl ujistit se, že si žádné zařízení nebude myslet opak.

Tento patch nicméně také byl označen za viníka poté, co se na Phoronixu zabývali hledáním půlením [bisect], aby našli příčinu dané regrese. Dává smysl, že vypnutí stavu snížené spotřeby může vést k vyšší spotřebě. Workaround navržený v článku spočívá v tom, že se použije volba pcie_aspm=force; ta donutí systém zapnout ASPM bez ohledu na to, co BIOS tvrdí o jeho podpoře. Tento workaround může bezpochyby na některých postižených systémech poskytnout lepší životnost na baterie; jinde nemusí fungovat vůbec. V tom druhém případě se systém může jednoduše zaseknout – což je stav s ještě horší charakteristikou latencí kombinovaný s překvapivě špatným využíváním energie. Workaround tedy může být přijat uživateli, kteří zjistí, že životnost baterií výrazně vzrostla, ale správné řešení problému to není.

Najít toto správné řešení – pokud možno takové, které bude prostě fungovat bez potřeby přidávat zvláštní parametry pro boot – může být složité. Opět citujeme Matthewa:

Jaké jsou alternativy? Můžeme zachovat status quo a přidat whitelist hardwaru, o kterém víme, že funguje. Problém je, že i když máme specifikace hardwaru, často nemáme errata. Nevíme s jistotou, jestli něco funguje nebo ne. Mohli bychom patch zrušit a přidat víc hardwaru na blacklist. Pak ale budeme muset najít všechna zařízení, která nefungují. Nebo je možné, že původní kód byl správně a Linux jednoduše hardware programuje odlišně, což způsobuje problémy s ASPM, které jinde nelze vidět.

Vzhledem k nejistotě vývojáři jádra došli k závěru, že „plýtvání trochou energie“ je menší zlo než „na některých systémech se to zasekne“. Dokud nebude problém lépe pochopen, jiný přístup by bylo těžké ospravedlnit. Někteří uživatelé tedy budou muset workaround pcie_aspm=force používat ještě nějakou dobu.

Problém se spotřebou energie, alespoň pokud autor článku ví, se mezitím nikdy neobjevil v žádné jaderné vývojové e-mailové konferenci. Nikdy se neobjevil na seznamu regresí 2.6.38. Pro většinu vývojářů tedy byl neviditelný a není žádným překvapením, že se mu nedostalo větší pozornosti. Ať už je to dobře, nebo ne, vývojová komunita má svoje způsoby, jak řešit problémy. Nahlásit chybu na linux-kernel rozhodně negarantuje, že bude opravena, ale zvyšuje to pravděpodobnost. Kdyby byl tento problém předložen přímo zainteresovaným vývojářům, mohli bychom se o hlavní příčině dozvědět již před dlouhou dobou.

Umravňování výstupu do logů

napsal Jake Edge, 29. června 2011

Správně ošetřit data od uživatelů je jedním ze základních principů zabezpečení. Různé zprávy v jaderném logu umožňují vložit uživatelem kontrolované řetězce pomocí specifikátoru formátu „%s“; útočník by to mohl zneužít tak, že potenciálně zmate správce systému vložením řídících znaků do řetězců. Vasilij Kulikov tedy navrhl patch, který by ošetřil některé znaky, které se v těchto řetězcích objevují. Objevily se nějaké otázky o tom, které znaky mají být ošetřeny, ale větší otázka je v kruzích zabývajících se bezpečností prastará: whitelistovat nebo blacklistovat?

Problém vychází z toho, že správci často k zobrazení souborů s logy použijí nástroje jako tail a more, kterými si je zobrazí na TTY. Pokud uživatel může vložit řídící znaky (a konkrétně escape sekvence) do logu, mohl by způsobit přehlédnutí potenciálně důležitých informací – nebo způsobit jiné zmatky. V nejhorším případě by escape sekvence mohly zneužít nějakou díru v emulátoru terminálu a vykonat kód nebo způsobit jiný druh špatného chování. V patchi Vasilij poskytl následující příklad: Řídící znaky by mohly roota zmást tak, že když si prohlíží logy na tty, mohlo by například ^[1A potlačit předchozí řádku v logu.. Znaky, které jsou filtrované, patch jednoduše nahrazuje „#xx“, kde xx je hexadecimální hodnota znaku.

Je to v podstatě poměrně nezávažná záležitost, ale není jasné, jestli pro používání řídících znaků v uživatelem dodaných řetězcích má nějaké legitimní použití. Tyto řetězce mohou přijít z různých míst; v diskuzi byla zmíněna jména souborů nebo ID řetězce USB produktů. První verze patche zjevně zacházela příliš daleko, když se ošetřily i znaky nad 0x7e (společně s řídícími znaky), což by vyřadilo i Unicode a další non-ASCII znaky. Po stížnostech Vasilijova druhá verze vyjímá pouze řídící znaky (tj. < 0x20) s výjimkou nové řádky a tabelátoru.

To ale příliš nesedlo Ingo Molnárovi, který si myslí, že místo whitelistování bezpečných znaků by se měly blacklistovat ty potenciálně škodlivé:

Také si myslím, že by se mělo vyřadit těch několik řídících znaků, které jsou škodlivé (jako o řádku výše a escape znak), místo toho aby se povolovaly všechny, o kterých víme, že jsou užitečné

[...] Je to také lepší přístup pro jádro: ošetřujeme věci, o kterých víme, že jsou škodlivé, a jinak povolujeme.

Jenže aby se vytvořil blacklist, je potřeba nejprve určit vliv různých řídících znaků na všech možných emulátorech terminálu, zatímco přístup s whitelistem má výhodu, že stačí jednoduše hodit mnohem větší síť. Jak píše Vasilij, zjistit, které znaky jsou problematické, není jednoduché:

Dokázal bys okamžitě odpovědět, kdybys nečetl předchozí diskuzi, které řídící znaky jsou škodlivé, které jsou občas škodlivé (na některých tty) a které jsou vždycky bezpečné a proč (nebo dokonce odpovědět na to, proč jsou vůbec škodlivé)? Já nejsem člověk od tty a abych tohle mohl zodpovědět, musím si přečíst console_codes(4) nebo podobnou dokumentaci, většina vývojářů jádra na tom asi bude stejně.

Rozkol mezi Ingem a Vasilijem patří mezi ty, které ve světě zabezpeční existují již mnoho let. Správná odpověď na to, co je lepší, neexistuje. Stejně jako u většiny věcí i u zabezpečení (a když jsme u toho u vývoje softwaru jako takového) mají whitelisty a blacklisty svá pro a proti. Obecně je pro uživatelem zadaná data (například ve webových aplikacích) konsenzem whitelistovat vstup, o kterém víme, že je správný, místo toho snažit se určit veškeré možné „špatné“ vstupy. Přinejmenším v tomto případě nicméně Ingo nepovažuje whitelisty za správný přístup:

Blacklist je dobře definovaný: zakáže zobrazení některých znaků, protože se ví, že jsou nebezpečné

Whitelist to na druhou stranu dělá špatným způsobem: snaží se vložit 'důkazní břemeno' na ty hodné – a to je opravdu kontraproduktivní.

Není překvapením, že Vasilij s touto analýzou nesouhlasí: Co uděláš s nebezpečnými znaky, u kterých ještě nevíš, že jsou nebezpečné? I když není moc sporů o tom, že whitelist dobrých znaků je bezpečnější, je také méně flexibilní, pokud by se našlo legitimní použití dalších řídících znaků v uživatelem dodaných řetězcích. Krom toho je Ingo skeptický k tomu, že by se v ASCII řídících znacích skrývala nějaká nebezpečí: Toto tvrzení je hloupé – chceš říci, že v prostoru vypisování ASCII je nějaká 'neznámá chyba'?

V tomto případě by obě řešení měla být dostatečná, protože neexistují dobré důvody takové znaky používat, ale Ingo má nejspíš pravdu v tom, že v ASCII se žádná skrytá nebezpečí neskrývají. Je otázka, jestli je tato změna vůbec zapotřebí. Obava, která vedla k patchi, se zakládá na tom, že by administrátor mohl přehlédnout důležité zprávy nebo být oklamán pečlivě sestaveným vstupem (Willy Tarreau poskytl zajímavý příklad toho druhého.) Linus Torvalds není přesvědčen, že se jedná o problém, který by bylo potřeba řešit:

Opravdu si myslím, že uživatelský prostor by si měl filtrování zajistit sám – nikdo nedělá jenom 'cat' na dmesg. A jestli jo, můžou si za to sami.

A afaik neošetřujeme escape sekvence ani na úrovni konzole, takže konzoli nelze řídícími znaky nijak zmást.

A nejnebezpečnější znak je ten, který nefiltruješ: ten, na který skutečně reagujeme, je '\n' a matoucí zprávy v logu bys mohl potenciálně vytvořit tak, že do svého řetězce zabuduješ novou řádku a potom se pokusíš, aby zbytek vypadal nějak špatně (třeba jako oops)

Vzhledem k Linusově skepticismu se nezdá, že by se patch dostal někam dál, i kdyby se použil přístup s blacklistem, který navrhuje Ingo. Je to, nebo by alespoň měla být, poměrně nevýznamná záležitost, i když spor o blacklistu vs. whitelistu pravděpodobně uvidíme znovu. Je spousta příkladů, kdy se v kontextu zabezpečení (i jiných) používají obě tyto techniky. Často se jedná o výběr mezi bezpečností (typicky whitelisting) a větší použitelností (blacklisting). Tento případ není nijak odlišný a určitě se objeví i jiné.

       

Komentáře

[pc2005]

Hmm rošáda s ioctl mě připadá jako pěkně hnusnej hack :-/, ale je možné, že jsem už propadl démonu optimalizace . Jinak ty escape sekvence jsou vtipný, tuhle jsem se snažil udělat vlastní superuniverzální printf a nakonec jsem došel k názoru, že by detektor formátu musel fungovat rekurzivně sám na sebe . Ale řešit escape sekvence kvůli potenciální kompromitaci je imho overkill, abych pravdu řekl, tak možnost, že by to šlo použít napadl až po přečtení .

BTW Ten rudej efekt neuzavřenýho tagu na nadpisy v menu je hustej :-O.

[Aleš Kapica]

BTW Ten rudej efekt neuzavřenýho tagu na nadpisy v menu je hustej :-O.

Pravdu díš..

[add.]

Jak se řeší ASPM ve windows (mohlo by to fungovat i v linuxu), pokud to může bios tak strašně konit?

[pc2005]

Řekl bych, že to bude podobný jako ta nedávná diskuze o rebootu (otestuje několikrát dostupnost a kdyžtak se na to vykašle). Je taky možný, že windowsům vyjde BIOS vstříc.

[pushkin]

A nebo je prostě možné, že ASPM explicitně zapínají ovladače od výrobce daného hardware (základní desky). Vzhledem k faktu, že ovladače od výrobce pod Windows instalují prakticky všichni, odůvodňovalo by to, proč prakticky nikdo pod Windows podobný problém nepozoruje.

[JoHnY2]

Drivery jsou vetsinou primo od intelu pro chipset a vyrobci desek na ne nesahaj. Jestli je v tech driverech jakejsi whitelist nebo blacklist by nemelo bejt slozity zjistit a Intel by mel sam mit zajem na tom aby na jeho HW chodilo ASPM spravne i v Linuxu.

Taky je klidne mozny, ze widle udelaj pri prvni startu s ASPM nejaky strasny veci a kdyz se jim system slozi (to se snadno pozna), tak se prestanou v ASPM vrtat.

[Ravensun]

Taky je klidne mozny, ze widle udelaj pri prvni startu s ASPM nejaky strasny veci....

Voodoo :D

či

Imperius :D

? :D

[JoHnY2]

Pravdepodobne oboji :-O ... MS je totiz mistr spinavejch reseni.

[koudy]

S tim bohuzel nelze nez souhlasit :) I kdyz uz se sem tam snazi dodrzovat sve standary (i kdyz to musi bejt nekdy makacka..)

[Sten]

ASPM se sděluje přes ACPI, které rozlišuje operační systémy, takže je klidně možný, že Windows to BIOS řekne správně, ale Linuxu (a jiným systémům, které výrobce netestoval) řekne nějakou blbost.

[Roger]

Linux se uz nejakou dobu kvuli podobnym vecem hlasi jako Windows, ne?

[Sten]

Ne, nehlásí a nehlásil. Navíc windowsí implementace ACPI je taková podivná, třeba u některých informací to používá BCD (0x10) pro hodnoty (10), i když podle standardu tam BCD nikde není.

[geebranz]

Interesting management

Rely