Jaderné noviny - 6. 12. 2006

4. 1. 2007 | Robert Krátký

Články - Jaderné noviny - 6. 12. 2006  

Aktuální verze jádra: 2.6.19. Citát týdne: Al Viro. Začíná vývojový cyklus 2.6.20. Bezpečné mazání a podpora koše. Bezpečnostní riziko s hyper-threading. Správa jádra 2.4.

Aktuální verze jádra: 2.6.19

Aktuální verzí řady 2.6 je i nadále 2.6.19. Začalo začleňování patchů do 2.6.20 (vizte níže); bude však pravděpodobně trvat ještě alespoň týden, než vyjde 2.6.20-rc1.

V posledním týdnu nevyšly ani žádné nové -mm verze. Andrew Morton ale zveřejnil začleňovací plán pro -mm a verzi 2.6.20, takže se každý může podívat, jaké se očekává zmenšení -mm díky přesunu patchů do hlavního stromu.

1. prosince vyšla verze 2.6.18.5. Obsahuje několik desítek důležitých oprav.

Adrian Bunk vydal 2.6.16.35-rc1, kde je také slušná řádka oprav.

Willy Tarreau oznámil 2.4.34-rc1 s jednou bezpečnostní aktualizací a poměrně malým počtem dalších oprav.

Citát týdne: Al Viro

-static void stli_dohangup(void *arg)
+static void stli_dohangup(struct work_struct *ugly_api)
 {
-    stliport_t *portp = (stliport_t *) arg;
+    stliport_t *portp = container_of(ugly_api, stliport_t, tqhangup);

-- Al Viro přechází na nové API pracovních front.

Začíná vývojový cyklus 2.6.20

Ke konci vývojového cyklu verze 2.6.19 proběhla na LKML krátká diskuze o tom, jestli by 2.6.20 neměla být pouze opravná verze. Pokud by si snad někdo myslel, že to tak dopadne, patche zařazované do 2.6.20 vše objasní. V dalším stabilním vydání jádra bude spousta nových věcí.

Přesto je však počet patchů o trochu nižší než u některých předchozích verzí. Možná že změny v pracovní frontě způsobily nějaké konflikty, které proces zpomalují.

Mezi uživatelem viditelné změny patří:

• Nové ovladače pro ethernetové řadiče NetXen 1G/10G, Tsi108/9 a Chelsio (ale bez podpory TCP offload) a ethernetové moduly Atmel MACB.
• Množství vylepšení ovladačů SATA a PATA.
• SCSI řadiče mohou být volitelně skenovány asynchronně. Na velkých systémech s mnoha SCSI perifériemi to může výrazně zvýšit rychlost bootu.
• Skupina algoritmů pro kontrolu zahlcení TCP, které si mohou vybrat neprivilegované procesy, byla zúžena na ty, o kterých se ví, že jsou robustní a spravedlivé. Administrátor systému může pořád zvolit kterýkoliv z Linuxem podporovaných algoritmů.
• Různá vylepšení kódu DCCP, včetně podpory SELinuxu.
• Byly odstraněny zastaralé, nepodporované a pravděpodobně nepoužívané věci, včetně odchylovače rámců/paketů a ovladače pro floppy pásku (ftape).
• Byla přidána MD5 ochrana pro TCP sezení (RFC 2385); tato možnost je obyčejně využívána jen se směrovacím protokolem BGP.
• Je podporován protokol UDP-Lite (RFC 3828); vizte stránku UDP-Lite, kde je tomto protokolu, který je zaměřen na streamovací potřeby multimediálních aplikací, více informací.

Změny patrné pro vývojáře jádra:

• Byly začleněny změny v API pracovních front, což způsobilo změny v celém stromu. David Howells vystavil podrobné instrukce pro opravu kódu, který kvůli těmto změnám přestal fungovat.
• Hodně kódu týkajícího se sysfs bylo změněno, aby používal struct device místo struct class_device. Druhá struktura bude nakonec odstraněna, až budou začleněny mechanismy tříd a zařízení.

• Nová funkce:

      int device_move(struct device *dev, struct device *new_parent);
  

  Změní předka [reparent] zařízení na new_parent, přičemž provede všechny potřebné změny v sysfs a pro uživatelský prostor vygeneruje speciální událost KOBJ_MOVE.

• Síťovací subsystém byl důkladně označen kvůli automatické kontrole pomocí sparse.
• Některé hlavičkové soubory, které includovaly jiné hlavičkové soubory, už s tím skončily. Například <linux/fs.h> už neincluduje <linux/sched.h>. Tyto změny by měly urychlit kompilaci jádra, protože hodně includů nebylo nutných. Mohou ale způsobit problémy modulům spravovaným mimo jádro, pokud nemají v includech výslovně zahrnuty všechny hlavičky, které potřebují.

Bezpečné mazání a podpora koše

Pohled na manuálovou stránku příkazu chattr odhalí zajímavé funkce; uživatelé mohou u souborů nastavit speciální bity, které vyžadují, aby byl soubor buď nesmazatelný, nebo aby bylo vymazání "bezpečné" - což znamená, že obsah souboru z disku skutečně zmizí. Klíčové je zde slovo "vyžadují". Tyto bity existují již řadu let, ale málo - pokud vůbec některé - linuxových souborových systémů tyto funkce implementuje. Příznaky nesmazatelnosti a bezpečného vymazání jen čekají, jestli by takovou fajn funkci někdo neimplementoval. Někdy.

Možná už se to blíží, protože tento patch od Nikolaie Joukova přidává poměrně jednoduchou a přímočarou podporu těchto dvou příznaků do ext4.

Patch funguje takto: kdykoliv je ze souboru odstraněn poslední link, zkontrolují se bity nesmazatelnosti a bezpečného mazání. Je-li jeden z nich nastaven, bude soubor přesunut do adresáře .trash/<uid>/ v kořenovém souborovém systému. Každý uid adresář má omezený přístup, aby uživatelé nemohli zneužívat vymazaná data cizích. Nejsou tam žádné podadresáře, takže se ztratí informace o cestě; zachování původního umístění by mohlo přibýt v další verzi. Koliduje-li název souboru s jiným již vymazaným souborem v koši, připojí se na konec číslo.

To je ze strany jádra vše. Obnovení je zařízeno v uživatelském prostoru prostým přesunutím souboru zpátky z koše. Bezpečné vymazání však bude také prováděno v uživatelském prostoru. Speciální démon přepíše data souboru podle toho, jak to bude paranoidnímu uživateli nejlépe vyhovovat, a pak soubor vymaže. Možným doplňkem patche by byl upozorňovací mechanismus, který by vynutil spuštění démonu vždy při nedostatku místa na oddílu. V každém případě budou všechna pravidla týkající se bezpečného vymazávání v uživatelském prostoru.

Dalo by se podivovat nad tím, proč má být koš implementován v jádře. Desktopová prostředí přeci již nějaký čas mají koše k dispozici. Zdá se, že existují dva důvody, proč patch tuto funkci přidává. První je to, že s tímto přístupem k bezpečnému vymazávání je koš jako bonus bez další námahy. Důležitější však je, že řešení v uživatelském prostoru nemohou zachytit každý pokus o vymazání souboru. Ani ten nejpovedenější správce souborů nic nenadělá s příkazem "rm" napsaným v shellu nebo voláním unlink() z nespolupracující aplikace. Zachycování výmazu souborů v rámci jádra zajišťuje, že žádný soubor neproklouzne.

Moc lidí patch nekomentovalo. Jedna z otázek, které se objevily: proč to nedělat ve vrstvě VFS místo v ext4? Patch neobsahuje nic extra specifického pro ext4 a zařazení do vrstvy VFS by tuto funkci zpřístupnilo všem souborovým systémům - přinejmenším těm, které příslušné příznaky souborů podporují. Nikolai Joukov souhlasí s tím, že přesunutí funkce výše by bylo správné, takže v budoucnu pravděpodobně vyjde přepracovaná verze.

---

Následující obsah je © KernelTrap

Bezpečnostní riziko s hyper-threading

1. pro, originál

Na LKML se znovu vynořil patch umožňující vypnutí technologie hyper-threading při bootu. Patch byl vytvořen jako reakce na bezpečnostní riziko s hyper-threading, o kterém se na LKML poprvé diskutovalo v květnu 2005. Ben Collins vysvětlil: Původní patch tvrdí, že hyper-threading uživatele vystavuje nějakému bezpečnostnímu riziku v souvislosti s omezenými možnostmi hardwaru chránit paměť napříč vlákny. Arjan van de Ven oponoval: Tak to není. Předpokládám, že tím "útokem" jsou míněny starší verze OpenSSL, u kterých bylo teoreticky možné získat nějaké informace o klíči pomocí sledování keše v situaci, kdy je keš sdílená. V žádném případě nejde o "přímý" únik informací a OpenSSL už bylo od té doby opraveno.

Linus Torvalds s Arjanem souhlasil: Přesně tak. Hodně těchto "načasovaných útoků" může být trošku jednodušší provést na hyper-threadingových procesorech, ale i tak jsou pouze teoretické. Lidi se daleko víc bojí nereálných útoků, kterým nerozumí, a proto jim zni strašidelně, než aby si dělali starosti o to obyčejné ("Vážně bych jako heslo neměl mít jméno našeho zvířátka napsané na papírku přilepeném na monitoru? A opravdu jsem ho neměl prozradit jen proto, že mi ten hodný pán dal čokoládu?"). Myslím, že lidi tyhle SSL útoky tolik nafoukli proto, že znějí technicky a in. Alan Cox také souhlasil a dodal: Ta věc s SSL je irelevantní. Hlavním důvodem pro vypínání HT (obzvláště na procesoru s jedním jádrem) je to, že spousta úloh tak běží rychleji.

Správa jádra 2.4

4. pro, originál

Willy Tarreau nahradil Marcela Tosattiho v roli správce jaderné řady 2.4 v srpnu 2006. V reakci na sérii kompilačních oprav, které do LKML poslal Mariusz Kozlowski, Willy navrhl, aby byly všechny patche odloženy do vydání 2.4.34. Do té doby by měli být kontaktování správci příslušných subsystémů, aby se u každého z patchů rozhodlo, jestli má být začleněn. Schválené patche a ty, které zůstanou bez odpovědi, ale přesto je budeme považovat za relevantní, budou začleněny v období před vydáním verze .35, aby měli lidi čas nám dát vědět o případných konfliktech.

Willy pokračoval popisem postupu ke zjištění správců jednotlivých souborů: Správce hledejte v souborech samotných nebo v MAINTAINERS. Obecně se dá říci, že pokud se soubor za poslední tři roky nezměnil a jeho správce není jedním z těch, které vidíte pravidelně přispívat do konference, je dost reálná pravděpodobnost, že se jedná o neudržovaný soubor. Hlavní subsystémy (síťování, souborové systémy, architektury, ...) jsou většinou i nadále spravovány lidmi, kterým opravdu záleží na schválení patchů, než je přepošlou dále. Mívají však hodně práce, takže se ptejte stručně, aby mohli rychle odpovědět, jestli patch berou nebo ne. Dávejte mě do CC, abyste mi nemuseli přeposílat odpovědi. Většinou odpověď dostanete během týdne. Pokud se nepodaří najít správce, nebo pokud správce neodpoví, pak už je to moje práce.

Diskuse k tomuto článku

[Josef Kufner]

Hmmm... ten koš se mi celkem líbí. Kolikrát se mi stalo, že jsem si omylem smáznul jiný soubor než jsem chtěl. Jen doufám, že to bude dostatečně geniálně udělané

[xxxxxxxx]

jsem si omylem smáznul jiný soubor než jsem chtěl

To se nám dokonalejm stát nemůže. A když jo, tak to porno stáhnem znova

[PSIkappa]

No to by som chcel vediet, co sa stane, ak nastavim nejakemu dvd iso image v mojom homedire bit nezmazatelnosti a zmazem ho, ale moj / ma len 512 MB ?

[CIJOML]

pak si za jednoho z tech debilu, co jim uz neni pomoci ;) Kdyz to bude pod userem, mas porad 100 mega na disku, jinak... ;)

[Josef Kufner]

Mno, vy dva si nemáte co vyčítat

ps: omlouvám se za nulovou informační hodnotu tohoto příspěvku.

[Michal Ludvig]

Pocitam ze "/" znamena koren toho oddilu ne absolutni zacatek cesty. Takze jestli jouda smaze soubor /home/jouda/porno.iso a pritom ma /home na zvlastni partition tak se soubor presune do /home/.trash/1234/567890

[lm]

aj ty sa cudujes aki su ludia sprosti?

[Michal Kubeček]

Samozřejmě, ono přesunout soubor do jiného adresáře na témže filesystému a přesunout soubor na jiný filesystém jsou dvě diametrálně odlišné operace…

[Hynek (Pichi) Vychodil]

RTFA! Kde je tam cokoliv o nějakém /? Nikde se nic nekopíruje, prostě se do .trash/<uid>/ uloží nové direntry a nalinkuje na původní i-node a to umístění je v rootu původního svazku podobně jako lost+found na ext[23]. Kdyby se mělo někde něco kopírovat, tak by to do jádra těžko někdo dal. Ten soubor zůstane na původním svazku v původních blocích a s původním i-node.

[Tom.š Ze.le.in]

Další adresář v /? Nešlo by to někam jinam? A co na to FHS?

[pdp7]

Koš v UNIXU??? Trapnost! Jaka pitomost ty vyvojare napadne priste? Linuxovej svet se nakazil od Applu.

[Tomas Vesely]

Co je na koši špatného? Každému se nějaký ten soubůrek může smazat omylem. Navíc je to jen příznak, který lze využít, dle vlastního uvážení.

[pdp7]

Uff. To jsem si oddych. Tak to je fajn ze se ta funkce da vypnout.

[Michal Kubeček]

Místo vypnout by bylo přesnější napsat nezapnout. Plašíte úplně zbytečně…

[František Ryšánek]

> Tu mama hace el amor con mi perro!
>
zdá se mi to, nebo je ten citát nepatrně,
tak nějak skrytě mezi řádky,
zoofilně obscénní?

[jose17]

to má byť asi varianta na černošské yo mamma..

[pdp7]

Tak nejak. Budu si tu paticku muset zmenit, tahle je fakt trapna. Nechtel bych tim nikoho urazit.

[Lukáš Zapletal]

Tak to je smutný, že nedokážeš akceptovat, že se i UNIX vyvíjí...

[pdp7]

Co to je za blabol?? Jasne ze se UNIX vyviji, to beru. Ale kos je neco co jsem fakt nikdy nepotreboval a nikdy potrebovat nebudu. Jestli se to nekomu libi tak at si to pouziva, to je v poradku. Me se to ale hnusi.

Zdar pdp7

[Michal Kubeček]

Já také spoustu věcí, které v Linuxu jsou, nikdy nepoužil (třeba podporu drtivé většiny zařízení), ale netuším, proč bych je měl kvůli tomu označovat za trapnost nebo dokonce pitomost…

[Michal Vyskočil]

A přitom to ESR v Art of Unix Programming označuje za jeden z problémů Unixu — File Deletion Is Forever. I když k verzování z VMS to má zatím daleko. Ale VMS asi není pro hardcore unixáky

[pdp7]

Do dobre. Tak to neni pitomost, bude uzitecna vec pro spoustu lidi. Pro me ale NE! Kdyz mazu nejaky soubor, tak se proste nejdriv poradne rozmyslim a potom smazu. Proste KOS nepotrebuju. Tecka.

[Jan Olšan]

Na koši není nic špatného - je zbytečné mazat soubory půl roku předtím, než dojde volné místo. Mnohem lepší je hodit je do koše, odkud se vystřelí v okamžiku, kdy už je to třeba. Ten odklad, během něhož si to můžete rozmyslet je oběd zdarma /skoro úplně!/.

[stativ]

Až na to, že je rozdíl koš a koš. Tenhle slouží jenom jako ochrana souborů označených jako nesmazatelné, což ke nepovinný parametr.

[Michal Kubeček]

Proč by to měl FHS řešit? Řeší snad nějak existenci např. lost+found na ext2/ext3 filesystémech? (A ten navíc ani není skrytý.)

[Michal Vyskočil]

Navíc je to v / dotyčeného filesystému a ani FHS není nic do toho, co mám ve svém /home

Jenom mě napadlo. Co udělá taková sekvence?

cd /home/michal
mount /dev/cdrom .trash
chattr +i soubor
rm soubor
ls .trash
# ???

[Michal Kubeček]

Hodí chybu, že se snažíte smazat immutable soubor. :-)

Ale chápu, co jste měl na mysli. Řekl bych, že to bude v tom skutečném adresáři .trash na příslušném filesystému, takže prostě neuvidíte nic, dokud to CD neodmountujete.

[Tom.š Ze.le.in]

FHS: Software must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

Dá se argumentovat, že jádro vlastně není software nebo package, já vím. A popravdě řečeno, FHS je ode mne jen argumentační berlička - jde mi o to, že mám nějak radši co nejméně věcí v /, a je mi téměř jasné, že pokud se tohle ujme, tak v rámci tvorby základních adresářů si typická distribuce udělá i ten koš, i když pak třeba nebude používaný.

[Josef Kufner]

Myslím, že tohle hovoří o programech a podobných zvířátkách. Ale tohle bezpečné mazání dělá vpodstatě filesystém sám, takže se to na něj nevztahuje. Anebo naopak vztahuje a programy od teď nesmí mazat soubory.

[Zdeněk Štěpánek]

Tak na Kos se tesim. Ne ez bych to sam kdy potreboval, ale pro BFU a wokynkoidni uzivatele to bude myslim velky prinos a kdo to nechce, nemusi to pouzivat.

Do ted si kos bastli kazde desktopove prostredi posvym a to je otresny.

Zdenek

[Michal Kubeček]

Tak to já se těším víc na s než u, ale já jsem holt blázen… :-)

[b42]

Hmm, prelozit frame diverter jako odchylovac snimku mi prijde mirne zavadejici:) V tomto slovnim spojeni je frame urcite myslen jako ethernetovy ramec. Teda ne ze by na tom kdovijak zalezelo;)

Frame Diverter is mainly used for setting up a bridge with Squid running on it and transparently caching Web traffic between the LAN and the router. It's beeing extended to allow forwarding frames to other machines. It also allows layer 3+ switching

[Robert Krátký]

Díky, neznal jsem význam toho spojení, takže to bylo přeloženo naslepo.

[zde]

Dobrej nápad, konečně bude ten zbytečnej length field v UDP hlavičce k něčemu dobrej. Akorát nevím proč to implementovali jako novej IP protokol (0x88 místo 0x11), já bych se tvářil že jde o staré dobré UDP, jen s vylepšenou sémantikou.

[Mti.]

Mozna sem neco nepochopil, po ranu byvam pomalejsi ... ale ... smazu soubor a "neco" v userspace se postara o jeho paranoidni prepsani. Ok. To je reseni. Ale pokud budu mit soubor nepublikovatelnych, ale "relativne dobre" citelnych dat a ja ho zkratim, tak mi na harddisku zbyte nepolapitelny kus dat, ktere dokud nezaplnim disk proste neuklidim? (protoze to "neco" v userspace ten urizly konec v zivote neuvidi)

[Michal Kubeček]

To ano, prostě by i pak bylo potřeba takové soubory nezkracovat, ale jen prodlužovat a nakonec celé smazat. Stejně bych ale viděl raději, kdyby ty bloky přepisovalo samo jádro, pak by šlo realizovat i to, že by veškeré bloky, které uvolnil soubor s atributem s, byly přepsány, ať už to bylo kvůli smazání souboru, jeho zkrácení nebo třeba přesunutí.

[Josef Kufner]

A nebo by takovéto bloky mohly být přiřazeny nějakému souboru, který by pak userspace mohl zdemolovat dle své libosti.

[Michal Kubeček]

Mně se tam pořád nelíbí to dodatečné přepisování nějakým userspace démonem. To když ten démon zrovna z jakýchkoli důvodů nepoběží, nic se přepisovat nebude? A vůbec, garantuje systém, že když určitým způsobem přepíšu obsah souboru, přepíšou se skutečně právě ty bloky, které soubor používal, než jsem s tím začal?

[Filip Jirsák]

A vůbec, garantuje systém, že když určitým způsobem přepíšu obsah souboru, přepíšou se skutečně právě ty bloky, které soubor používal, než jsem s tím začal?

Vzhledem k existenci věcí jako ext3cow nebo tomu, že něco jako odpovídající bloky na disku nemusí vůbec existovat (NFS, FUSE), nejspíš to systém garantovat nebude...

[Michal Kubeček]

To jsem tak nějak předpokládal. Takže to fungovat nemůže…

[petr_p]

A proto sifrovat, sifrovat, sifrovat.

[Apple Rejp]

Co mi tedy v Linuxu fakt chybi je vyplazovani CDcka vyhozenim do kose. To by se rozhodne melo pridelat!

[keson]

To není moc intuitivní. Po přesunutí ikony CDčka do koše by se IMHO mělo dané CDčko fyzicky zlikvidovat. (měl jsem mechaniku, která to uměla

[Josef Kufner]

Nenene, po přesunutí ikony cédéčka na ikonu koše by měla mechanika cd vysunout, aktivovat vystřelovací mechanismus a hodit CD do připraveného koše. V levnější variantě bych byl ochotný akceptovat verzi se skluzavkou.

[Michal Kubeček]

Srandičky, srandičky. Na vlastní oči jsem viděl floppy mechaniku, která byla schopna vystřelit disketu do půlmetrové vzdálenosti. Protože půl metru stolu před počítačem nebylo, podle okolností buď trefila uživatele nebo disketa skončila na zemi.

[Robert Krátký]

Měli jsme v učebně síť Applů, z nichž asi dva dělaly přesně tohle. Protože se vysunutí provádělo softwarově (ty bedny ani žádné vysouvací tlačítko neměly), bylo možné nic netušícího uživatele překvapit dálkovově ovládaným vyplivnutím diskety na klávesnici.

[rastos]

Příznaky nesmazatelnosti a bezpečného vymazání jen čekají, jestli by takovou fajn funkci někdo neimplementoval. Někdy.

Niekomu nefunguje immutable flag na ext2(/ext3/ext4)?

[Michal Kubeček]

To je problém s českými překlady za každou cenu. V článku není řeč o atributu i (immutable) ale u (undelete).