Jaderné noviny 267

29. 7. 2004 | Leoš Literák | Jaderné noviny | 5317×

Časovač s vysokou přesností (HRT). Podpora RSA Crypto API v řadě 2.6. Linux 2.6.7. Kdy používat GCC Built-Ins.

Do konference přišlo celkem 2195 emailů, nejvíce jich poslali Greg KH, Andrew Morton a William Lee Irwin III.

Časovač s vysokou přesností (HRT), 33 e-mailů

Geoff Levand informoval konferenci o dostupnosti patchů pro POSIXový časovač s vysokou přesností (high-res timer) pro jádro 2.6.6. Základem pro tyto patche je hrtimers-2.6.5-1.0.patch George Anzingera ze stránky http://sourceforge.net/projects/high-res-timers/.

William Lee Irwin III reagoval s tím, že žije v domnění, že patche George Anzingera již byly do řady 2.6 začleněny. Jiný autor otvrdil, že aplikační rozhraní v kernelu již je, nicméně patche umožňující získat rozlišení na úrovni deseti mikrosekund nebyly začleněny.

Podpora RSA Crypto API v řadě 2.6, 12 e-mailů

Joy Latten se zeptal:

Pracuje někdo na implementaci RSA šifrování do cryptoapi kernelu? Pokud ne, uvažuji o vytvoření takového projektu ...

Kartikey Bhatt odpověděl, že by se rád k takovému projektu připojil. Kristian Sorensen také napsal:

Projekt Umbrella (umbrella.sf.net) také potřebuje mít možnost používat kryptografii s veřejným klíčem uvnitř linuxového kernelu (i když pouze pro verifikaci podpisu). Plánujeme proto implementovat RSA nebo ElGamal (portací z GPG) do kernelu. Nicméně pokud tento projekt vznikne, bude nás velmi zajímat. Na podzim pak budeme schopni přispět nějakými hodinami programování .

Jinde se James Morris zeptal, zda se Joy a spol. snaží vytvořit obecné asymetrické kryptografické API. Sergey odpověděl:

Je samostatné generické asymetrické crypto API skutečně nutné?

Model užití cryptoapi je nastavit klíč před (de)šifrováním. Takže není důvod mít public_key_alg se samostatnými funkcemi public_encrypt a private_encrypt, protože toto rozlišení je implikováno během použití metody setkey. Proto plánujeme prostě přidat další crypto_alg pro rsa_1024.

Tom St. Denis odpověděl:

Jako základ digsig modulu budeš potřebovat mít možnost:

1. importovat veřejný klíč
2. uvolnit veřejný klíč z paměti (není důvod plýtvat dynamickými zdroji jako jsou velká čísla, když už nejsou používána)
3. podepisovat/ověřovat/šifrovat/dešifrovat, což vede k exptmod a PKCS #1 [v2.0] doplňování [padding]

Rozhraní přesně napodobující symetrickou stranu skutečně nebude fungovat na 100%. Například symetrické operace obvykle nehavarují. Také metody ověřování/dešifrování mohou selhat natvrdo [kvůli nedostatku paměti na haldě] či naměko [invalidní paket]. Dávalo by více smyslu navrhnout jednoduché API pro kryptografii s veřejným klíčem, než mrzačit API pro symetrické šiforvání do něčeho kompatibilního.

Mimochodem, byl jsem kontaktován, zda mám zájem o uskutečnění tohoto projektu a nabízím svou public domain knihovnu LibTomCrypt. Navrhuji portovat ji jako kernel modul (po odstranění věci, jež nejsou potřeba, jako je symetrické šifrování) a uvolnit pod GPL.

Linux 2.6.7, 40 e-mailů

Linus Torvalds ohlásil Linux 2.6.7 s tím, že nejvíce pozornosti si zaslouží jednořádková oprava obtěžující výjimky plovoucí řádky. Tomas Szepe napsal, že airo.ko z 2.6.7 (oproti verzi 2.6.6) neumožňuje uživateli nastavit ESSID via "echo myessid >/proc/driver/aironet/ethX/SSID". A dodal, že takové změny by se neměly provádět uprostřed stabilní řady.

Alexander Viro zaslal krátký patch s komentářem, že takovýmto změnám se říká chyby. Kromě toho originální verze byla chybová a snadno zneužitelná, takže oprava byla skutečně potřeba. Tomas vyzkoušel záplatu a potvrdil její funkčnost.

Kdy používat GCC Built-Ins, 17 e-mailů

Arjan van de Ven napsal, že

gcc 3.4 získalo podporu pro několik typických bitops jako zabudovaných direktiv. Jejich použití má oproti inline asm několik výhod:

• gcc může do nich lépe optimalizovat konstanty
• gcc může lépe přeuspořádat pořadí kódu
• gcc může alokovat registry

Otázka zní, zda považujeme tuto cestu za přínosnou či ne. Abych pomohl diskusi, přikládám patch, který v závislosti na verzi překladače umožní funkci ffz() používat tyto direktivy gcc. Než s tím ale budu pokračovat ... má to cenu?

Ze začátku se ozývaly hlasy podpory, než Linus Torvalds napsal:

Pokud se jasně neprokáže, že kód gcc je lepší, pak to NEMÁ cenu.

Přidání takové podpory vede k zvýšeným nárokům na údržbu, protože stále musíme podporovat staré verze gcc a architektury, kde GCC optimalizuje HŮŘE než my. A upřímně, pochybuju, že najdeš jediný případ, kdy GCC udělá znatelně lepší práci.

Jinými slovy, pravidla ohledně GCC builtinů jsou:

• používejte jen ty, jež jsou dost staré na to, aby je měla dostupná většina uživatelů (nejlépe všichni). Hlavním důvodem je, že gcc mívá chyby a často dělá předpoklady, které pro kernel neplatí (například "je v pořádku používat rutiny knihoven").
• používejte je, pouze pokud prokážete znatelné vylepšení. Teoretické argumenty prostě neplatí.

Až dosud jediným případem, jež měl cenu, byly věci kolem memcpy() a i zde byly původní makra, jež dělaly téměř stejnou práci (ale byly tak škaredé, že stálo za to provést změnu).

---

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

       

Komentáře

[Zdeněk Štěpánek]

Zdravim

Jak uz par let ctu jaderne noviny tak posledni dobou, zejmena od cca 2.6.3 se mi zda ze z kernelu se stava ponekud bordel ze se jako stabilni verze vypousteji verze kde nekdo udela nejakou chybu, v pristim release se to opravi, proste zmatek, testovaci kod. Myslim ze by se kluci meli zamerit vic na sladeni kernelu jako celku a nepoustet se ve stabilni rade do nejakych pokusu.

Jakej na to mate nazor vy?

Zdenek

[r09]

pri vyvoji vzdycky vznika bordel

[Leoš Literák]

Take mam pocit, ze jako QA oddeleni pro kernel slouzi distributori.

[rastos]

However, according to this KernelTrap article, active development will now continue in the mainline 2.6 tree, and the final stabilization will be left up to the companies that provide Linux distributions. (slashdot.org)

[HonP]

No dyt oni zadne vyvojove cili 2.7.x jadro nemaji, ne? Posledni je 6tka a konec.

[Milan Jurik]

Ale tak to je vzdycky, dokud si Linus neprestane hrat se "stabilni" radou, nelze ji povazovat za stabilni. I kdyz z jednoho omylu bych nedelal hned velike halo. Smula je, ze zrovna tohle byl opravdu jen detail, deji se tam mnohem nebezpecnejsi veci.

[Abraxis]

Ted jsem cetl nekde clanek z nejake linuxove konference, ze v podstate muzeme ocekavat v 2.6 VELKE zmeny a ze 2.7 se bude otevirat az v pripade, kdy ty zmeny budou ZASADNI (co to bude, tezko rict) a ze kdo chce stabilni jadra, tak ma pouzivat distributorska.

[Zdeněk Štěpánek]

Zdravim

No ja jakozto slackwarista mam tim padem bud na vyber obstarozni (no flame) 2.4.2x nebo 2.6.7 coz zase neni oficialni jadro distribuce ale testing, takze na to se jejich rada nevztahuje. Takze ja si teda nejak moc nevyberu.

Zdenek

[d.c.]

Donedavna platilo: bud rad, ze pouzivas vanilla kernel, distributori stejne jen pridavaji spoustu nedostatecne testovanych "vylepseni", ktera jim davaji zdani konkurencni vyhody.

Proto mi pripada ponekud nezodpovedne nechavat zrovna na distributorech stabilizaci vydani jadra. Ackoliv Linus tim muze myslet jine distributory, nez my obycejni lide - nekolik opravdu velkych firem pouziva a udrzuje sve distribuce. Jenze pro zakazniky od milionu vyse.