abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 01:01 | Zajímavý software
Rich Geldreich, bývalý vývojář Valve, vydal první stabilní verzi 1.0 bezeztrátového kompresního algoritmu a knihovny LZHAM (GitHub). Komprese s LZHAM je srovnatelná s LZMA, dekomprese je ale 1,5 až 8 krát rychlejší. Rich Geldreich pracuje na LZHAM již více než 3 roky. Předchozí vývoj probíhal na Google Code. [Phoronix]
Ladislav Hagara | Komentářů: 27
včera 14:32 | Zajímavý software
Byl vydán Cool-Retro-Term ve verzi 1.0.0. Jedná se o emulátor terminálu, který napodobuje vzhled a chování starých CRT terminálů. Původně byl emulátor vyvíjen pod názvem Cool-Old-Term. V září loňského roku byl přejmenován na Cool-Retro-Term (CRT). Ukázka vlastností a nastavení na YouTube.
Ladislav Hagara | Komentářů: 18
včera 14:31 | Zajímavý software
Byl vydán Fossil 1.30. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Ladislav Hagara | Komentářů: 8
včera 14:30 | Zajímavý projekt
Článek na Opensource.com představuje Biicode, multiplatformní balíčkovací systém pro programovací jazyky C a C++ inspirovaný balíčkovacími systémy jako Pip pro Python, Gem pro Ruby nebo Pub pro Dart. [LWN.net]
Ladislav Hagara | Komentářů: 13
23.1. 20:09 | Pozvánky
29. ledna 2014 večer se v Brně koná první DevOpsClub – otevřené setkání lidí, kteří se pohybují okolo vývoje, nasazování a provozu aplikací.
Věroš | Komentářů: 0
22.1. 23:59 | Nová verze
Vývojový tým OpenSSL vydal verzi 1.0.2 kryptografické knihovny OpenSSL. Jedná se o první verzi z nové větve 1.0.2. Větve 0.9.8 a 1.0.0 budou podporovány do konce letošního roku. Větve 1.0.1 a 1.0.2 do konce následujícího. Vydána byla také nová verze konkurenční knihovny LibreSSL. Nejnovější verze 2.1.3 řeší například bezpečnostní problém CVE-2015-0206.
Ladislav Hagara | Komentářů: 9
22.1. 23:24 | Bezpečnostní upozornění
Byl vydán Adobe Flash Player ve verzích 16.0.0.291 a 11.2.202.438. Dle bezpečnostního upozornění APSB15-02 je opravena závažná bezpečnostní chyba CVE-2015-0310 v současnosti zneužívaná k cíleným útokům. Nainstalovanou a doporučenou verzi Adobe Flash Player, spolu s odkazem ke stažení, lze zjistit na stránce About Flash Player.
Ladislav Hagara | Komentářů: 6
22.1. 23:23 | Nová verze
Google Chrome 40 byl prohlášen za stabilní. Nejnovější stabilní verze 40.0.2214.91 pro Windows, Mac a Linux opravuje především 62 bezpečnostních chyb. Řada z nich byla odhalena pomocí nástrojů AddressSanitizer a MemorySanitizer.
Ladislav Hagara | Komentářů: 0
22.1. 01:00 | IT novinky
Společnost WhatsApp představila WhatsApp Web, webové rozšíření své proprietární multiplatformní aplikace WhatsApp Messenger umožňující výměnu zpráv a multimediálních souborů mezi vlastníky chytrých telefonů. Nejedná se o náhradu mobilní aplikace, ale pouze o její rozšíření. Uživatel se přihlašuje naskenováním QR kódu. Telefon musí zůstat připojen k internetu. Aktuálně je podporován pouze prohlížeč Google Chrome. Na podpoře dalších prohlížečů se pracuje. [OMG! Chrome!]
Ladislav Hagara | Komentářů: 33
21.1. 16:38 | Pozvánky
SatoshiLabs a Paralelní Polis organizují víkendový hackathon zaměřený na kryptografii pojmenovaný /crypto^HACK. Bude se konat 6.–8.2. (pátek–neděle) v Praze v prostorech Paralelní Polis. Na místě budou po dobu celého konání akce k dispozici mentoři ze SatoshiLabs. Více informací se nachází na stránkách akce, případně na facebookové události.
STiCK | Komentářů: 5
Disketu jsem naposledy použil během
 (41%)
 (3%)
 (12%)
 (41%)
 (3%)
Celkem 1995 hlasů
 Komentářů: 58, poslední včera 18:11
    Rozcestník
    Reklama
    Autoškola testy online Levný benzín

    Jaderné noviny - 28. 11. 2007

    28. 12. 2007 | Robert Krátký | Jaderné noviny | 3184×

    Aktuální verze jádra: 2.6.24-rc3. Aktuální verze jádra: 2.6.23.9. Citát týdne: Donnie Berkholz. Přiškrcení množství exportovaných symbolů. kmemcheck - kontrola neinicializované paměti. Aktualizace systémových volání: indirect(), timerfd(), hijack().

    Obsah

    Aktuální verze jádra: 2.6.24-rc3

    link

    Aktuální předverze je (k 28. 11. 2007) i nadále 2.6.24-rc3. Opravy dále velmi rychle proudí do hlavního git repozitáře; 2.6.24-rc4 musí být na spadnutí.

    Aktuální verze -mm stromu je 2.6.24-rc3-mm2. Mezi nedávné změny patří nové API timerfd (vizte níže), několik změn ovladačového jádra a aktualizovaná verze bezpečnostního modulu SMACK.

    Aktuální stabilní verze řady 2.6 je 2.6.23.9, vydaná 26. listopadu. V této verzi je pár desítek důležitých oprav.

    Starší jádra: 2.6.22.14 vyšlo 21. listopadu.

    Citát týdne: Donnie Berkholz

    link

    Linuxové jádro by potřebovalo, aby každou změnu doprovázela dokumentace -- část patche by vždy měla mířit do adresáře Documentation/.

    -- Donnie Berkholz

    Přiškrcení množství exportovaných symbolů

    link

    Jaderný mechanismus pro nahrávání modulů neposkytuje modulům přístup ke všem částem jádra. Místo toho musí být každý symbol, který je určen pro použití natahovatelnými moduly, výslovně exportován prostřednictvím jedné z variant makra EXPORT_SYMBOL(). Smyslem tohoto omezení je limitovat dosah modulů a poskytnout relativně dobře definované modulové API. V praxi však exportování moc omezováno není, takže jsou modulům k dispozici tisíce symbolů. Natahovatelné moduly mohou přistupovat k mnoha symbolům, jejichž užitečnost je zjevná (třeba printk() nebo kmalloc()), ale dostanou se i k obecným symbolům typu edd, tpm_pm_suspend(), vr41xx_set_irq_trigger() nebo flexcop_dump_reg().

    Některým vývojářům dělá přílišné exportování symbolů právem starosti. Chybně exportované symboly mohou vést autory modulů ke špatným rozhraním; například exportování sys_open() vývojáře aktivně ponouká k otevírání souborů přímo v jádře, což téměř nikdy není dobrý nápad. Ale jakmile jsou symboly jednou exportovány, může být těžké je přestat exportovat. Ačkoliv oficiální stanovisko zní, že interní jaderné API se může měnit kdykoliv, pravda je taková, že přinejmenším někteří vývojáři se zdráhají dělat problémy externím modulům, když se tomu dá vyhnout.

    Jako aktuální příklad může posloužit init_level4_pgt - nízkoúrovňový symbol exportovaný pouze architekturou x86_64. Aktuální -mm strom ten export odstraňuje, kvůli čemuž přestává fungovat proprietární modul NVIDIA. Andrew Morton to odstranění popisuje jako fikaný způsob, jak zúžit počet testerů, abychom nedostávali tolik hlášení o chybách. Přestože mnoho vývojářů dává hlasitě najevo, že jim nezáleží na binárních modulech, i tak je dost velká pravděpodobnost, že tohle odstranění exportu (symbolu, který by opravdu neměl být globálně přístupný) kvůli zmiňovanému problému neprojde až do hlavního jádra.

    Každopádně je už dlouho patrný zájem o pročištění modulárního API, i když se tomu zrovna moc lidí nevěnovalo. Čas od času někdo ukáže na některý ze snadných terčů: symbolů, které jsou exportovány jen proto, aby bylo možné modularizovat další kousky kódu hlavního jádra. Například celá sada symbolů TCP stacku (věci jako __tcp_put_md5sig_pool()), které mají přesně jednoho uživatele: modul IPv6. Omezení těchto jednoúčelových exportů by mohlo výrazně zeštíhlit modulární API, aniž by bylo těžší hlavní jádro modularizovat.

    Andi Kleen navrhl patch implementující jmenný prostor pro modulové symboly, který by měl umožnit právě takové zeštíhlení. S tímto patchem mohou být symboly exportovány do specifických "jmenných prostorů", které jsou dostupné pouze schváleným modulům. Termín "jmenný prostor" v tomto případě zrovna moc nesedí; pořád bude jen jeden globální jmenný prostor, v rámci kterého budou muset být všechny exportované symboly unikátní. Tyto "jmenné prostory" jsou spíše speciální zóny, jež obsahují symboly, které nejsou globálně přístupné. Fungují jako pouze-GPL exporty, které omezují dostupnost symbolů určité podskupině modulů.

    Pro vytvoření omezeného exportu je běžná deklarace EXPORT_SYMBOL() změněna na:

        EXPORT_SYMBOL_NS(namespace, symbol);
    

    Kde namespace je název omezeného jmenného prostoru. Takže když se vrátíme k příkladu s TCP, tak Andiho patch obsahuje množství změn jako:

        -EXPORT_SYMBOL(__tcp_put_md5sig_pool);
        +EXPORT_SYMBOL_NS(tcp, __tcp_put_md5sig_pool);
    

    Všimněte si, že není žádná _GPL verze; všechny symboly exportované do konkrétního jmenného prostoru jsou automaticky brány jako pouze-GPL.

    Druhou částí rovnice je umožnění přístupu ke jmennému prostoru. K tomu slouží:

        MODULE_NAMESPACE_ALLOW(namespace, module);
    

    Taková deklarace (jež se musí objevit v modulu, který exportuje symboly do namespace) říká, že daný module může přistupovat k symbolům v určeném jmenném prostoru. Andiho patch vytváří tři jmenné prostory (tcp, tcpcong pro moduly kontrolující zahlcení a udp), čímž z globálního jmenného prostoru odstraňuje asi 30 symbolů.

    Řada vývojářů tento patch přivítala, protože v něm vidí krok vpřed ve snaze o racionalizaci API natahovatelných modulů. Je to také bráno jako způsob, jak externím modulům zamezit používání symbolů, které by používat neměly. Kromě toho se tím snižuje počet rozhraní, která musí být udržována stabilní v situacích, kde nejsou změny přípustné (například u enterprise jader). A konečně, jmenné prostory symbolů umožňují trochu exporty organizovat a dokumentovat, kdo je má používat.

    Ne všichni však souhlasí. Především Rusty Russell má obavy, že patch věci zbytečně komplikuje a ztíží práci vývojářům externích modulů. Rusty:

    Například když dáváš všechny udp funkce do jmenného prostoru "udp", co nám to přinese? Co bude jednodušší spravovat? Všechny ty funkce začínají na "udp_": dělá snad lidem potíže uhádnout, k čemu jsou určené?

    Pokud chceš opravdu omezit "veřejná rozhraní", pak by bylo mnohem jednodušší přímo říct, co smějí externí moduly používat.

    Herbert Xu to vidí podobně:

    Ty symboly jsou exportovány proto, že je potřebují protokoly. Kdyby nebyly každému přístupné, bylo by těžké začít s psaním novým protokolů...

    Takže přinejmenším s ohledem na ten síťový kód začínám spíš souhlasit s Rustym: je-li symbol využíván více než jedním modulem z jádra, je dost pravděpodobné, že budeme chtít, aby byl exportován pro všechny.

    Ačkoliv se zdá, že tyto hlasy jsou v menšině, mají docela velkou váhu. Nechce se mi tedy hádat, jestli bude patch začleněn, a pokud ano, tak v jaké podobě. Dříve nebo později se však něco v této oblasti stane, protože snaha o pročištění modulárního API jen tak nezmizí.

    kmemcheck - kontrola neinicializované paměti

    link

    Používání neinicializované paměti může vést k opravdu nepříjemným chybám. Když máte štěstí, tak jádro slítne a v tracebacku nechá rozluštitelnou stopu, která zaneřádila slab [slab poisoning] (0x5a5a5a5a nebo něco podobného). Jindy se však stane nějaká zakuklenější nepravost a budete nuceni dlouho hledat jednu hloupou chybu. Nebylo by lepší, kdyby jádro prostě umělo detekovat odkazy na neinicializovanou paměť a nahlas v tu chvíle zařvat?

    Patch kmemcheck, který nedávno poslal Vegard Nossum, nabízí právě to - i když možná trochu těžkopádným způsobem. Jádro se zapnutou funkcí kmemcheck nebude asi vhodné pro produkční nasazení, ale mělo by dobře umět hledat paměť, která ještě nebyla nastavena na užitečnou hodnotu.

    Kmemcheck je poměrně jednoduchý patch; používá následující přístup:

    • Každá alokace paměti je zachycena na úrovni alokátoru stránek. Pro každou alokaci je požadovaný řád navýšen o jeden, což velikost alokace zdvojnásobí. Dodatečné ("stínové") stránky jsou inicializovány nulami a drženy schované.

    • Alokovaná paměť je vrácena volajícímu, ale bit "present" [přítomna] je v tabulkách stránek smazán. Každý pokus o přístup k takové paměti tedy způsobí výpadek stránky.

    • Jakmile dojde k výpadku, kmemcheck (pomocí nechutného kódu specifického pro jednotlivé architektury) zjistí přesnou adresu a velikost zkoušeného přístupu. Jde-li o zápis, budou odpovídající bajty ve stínové stránce nastaveny na 0xff a operaci bude povoleno dokončit.

    • Pro přístupy kvůli čtení jsou otestovány odpovídající bajty stínových stránek; jsou-li některé z nich nula, kód usoudí, že jde o snahu přečíst neinicializovaná data. Pak je vypsán traceback stacku, aby se přišlo na to, kde k tomu přístupu dochází.

    Je zřejmé, že provozování kmemcheck bude mít negativní vliv na výkon. Výpadek stránky při každém přístupu do paměti slabu prostě nemůže být rychlý. Zdvojnásobení velikosti každé alokace si také vezme svoje, včetně vlivu na keš, která bude muset pracovat s dvakrát tak velkým množstvím paměti. Ale když běží jádro v debugovacím režimu, tak se to dá vydržet.

    Vegard poslal ukázkový výstup, který ukazuje, jak systém reaguje na čtení z neinicializované paměti. Dá-li se tomu výstupu věřit, tak přistupování k neinicializované paměti není v současných jádrech nic exotického. Pokud se ukáže, že některé z odkazů, na které teď bylo upozorněno, jsou opravdu chyby, tak už se kmemcheck osvědčil, i kdyby si nikdy nenašel cestu do hlavního jádra.

    Aktualizace systémových volání

    link

    indirect()

    link

    Když se minulý týden diskutovalo o navrhovaném systémovém volání indirect(), stěžovali si někteří vývojáři, že je to opravdu nepěkné rozhraní. Od té doby se diskuze přenesla na rozhraní systémových volání obecně, ale moc nápadů, jak vylepšit indirect(), z toho nevzešlo.

    Zatím vede alternativa, kterou navrhoval H. Peter Anvin: raději než k rozšiřování systémového volání používat indirect(), to je lepší prostě vytvořit nové volání s požadovanými parametry. Pak může být většinou stará implementace nahrazena jednoduchým kouskem kódu, který volá novou verzi s výchozími hodnotami u nových parametrů. Je to jednoduchý přístup, který snadno zachovává binární kompatibilitu, aniž by měl za běhu velkou režii. Protože čísel systémových volání je dostatek, mohlo by se takto postupovat ještě dlouho.

    Správa zvyšujícího se počtu systémových volání však něco stojí; každé z těch systémových volání je součástí uživatelského API, které už musí fungovat navždy. indirect() nová systémová volání nepřidává. Za předpokladu, že budou parametry přidávány opatrně (s výchozími hodnotami nula), pak by mělo být celkem snadné se vyhnout potížím s API.

    Existují však omezení toho, kolik parametrů lze k systémovým voláním přidat; na většině systémů se to pohybuje kolem šesti. Pokud chce nějaké systémové volání více parametrů, musí se pouštět do nepříjemností s nepřímými bloky. Vytváření nových systémových volání s dodatečnými parametry zvýší počet případů, ve kterých bude toto nepřímé zpracování parametrů potřeba. Takže přístup využívaný voláním indirect() bude nakonec stejně v nějaké podobě nasazován.

    Klíčovým argumentem je však stále mechanismus sysletů/threadletů. Možnost udělat z kteréhokoliv volání asynchronní volání je velmi lákavá, ale aby to šlo provést, jsou potřeba ještě nějaké další informace - přinejmenším místo, kam výsledek volání uložit. Asynchronní systémová volání v Linuxu jsou, z praktického hlediska, druh nepřímého volání. Navrhované rozhraní indirect() vypadá, že by mohlo být pro asynchronní volání dobře využito - i když přesné API ještě nebylo stanoveno.

    V důsledku toho je pravděpodobné, že se indirect() v nějaké podobě nakonec do jádra dostane - přesto je však ještě dost času na to, aby někdo přišel s lepším nápadem.

    timerfd()

    link

    Když se tu naposled mluvilo o timerfd(), bylo právě vypnuto v jádře 2.6.23 kvůli stížnostem na své rozhraní. Od té doby se toho moc nestalo, takže téměř určitě nebude ani v 2.6.24. Přesto se však na tomto systémovém volání pracovalo a byl představen návrh nového API. Tato verze má tři systémová volání, z nichž první je timerfd_create():

        int timerfd_create(int clockid, int flags);
    

    Parametr clockid systému říká, které hodiny se mají použít: CLOCK_MONOTONIC nebo CLOCK_REALTIME. Parametr flags byl přidán nedávno; v současné době se však nepoužívá a musí být nula. Je tam kvůli předpokladu, že někdo někdy bude chtít chování nějak upravit, takže je lepší se vyhnout potřebě nepřímé verze, dokud to jde. Návratová hodnota z timerfd_create() je popisovač souboru, který je možné předat funkci read() nebo kterékoliv variantě poll(). Nejprve by však měl být časovač asi naprogramován pomocí:

        int timerfd_settime(int fd, 
                            int flags,
    		        const struct itimerspec *timer,
    		    	struct itimerspec *old_timer);
    

    fd je popisovač souboru získaný z timerfd_create(). Je-li časovač nastaven na absolutní čas, pak flags obsahuje TFD_TIMER_ABSTIME. A timer je doba vypršení časovače. Pokud old_timer není NULL, tak bude umístění, na které je ukazováno, nastaveno na předchozí hodnotu časovače.

    Hodnotu časovače je také možné získat pomocí:

        int timerfd_gettime(int fd, struct itimerspec *timer);
    

    Hodnota vrácená v *timer bude aktuální nastavení časovače přiřazeného k fd.

    Tato nová verze API nebyla moc komentována, takže bude asi začleněno něco podobného. Normálně už by bylo příliš pozdě na přidání změny do 2.6.24, ale log patchů v 2.6.24-rc3-mm2 říká "Asi 2.6.24?". Takže jeden nikdy neví. Pokud to nebude začleněno brzy, skoro určitě se to dostane do 2.6.25.

    hijack()

    link

    Systémové volání hijack() je i nadále vyvíjeno v rámci relativně tichých konferencí jaderných subsystémů. Toto volání se chová podobně jako clone() v tom smyslu, že vytvoří nový proces. Na rozdíl od clone() však hijack() způsobí, že nový proces sdílí zdroje s určeným třetím procesem, místo s předkem. Existuje hlavně proto, aby bylo snadné vstupovat do různých jmenných prostorů.

    Rozhraní hijack() je skoro beze změny:

        int hijack(unsigned long clone_flags, int which, int id);
    

    Zadaná hodnota id je interpretována podle which, který má tři možné hodnoty:

    • HIJACK_PID říká, že id je ID procesu; nově vytvořený proces bude sdílet zdroje (včetně jmenných prostorů) s určeným procesem.

    • HIJACK_CG říká, že id je otevřený popisovač souboru tasks v cílové kontrolní skupině. V takovém případě jádro vyhledá proces v určené kontrolní skupině a ten je použit pro sdílení zdrojů a jmenných prostorů.

    • HIJACK_NS je nejnovější možnost; podobně jako u HIJACK_CG jde o otevřený popisovač souboru označující kontrolní skupinu. V tomto případě však nový proces zdědí pouze danou kontrolní skupinu a přiřazené jmenné prostory. Tato verze je určena pro vstup do prázdné kontrolní skupiny (když tam nejsou žádné procesy, po kterých dědit).

    Toto nové systémové volání vůbec nebylo představeno na linux-kernel; je dost možné, že v současné podobě tam svůj první výstup nepřežije. Přinejmenším bude asi požadována změna názvu (na něco trochu více popisného, co by, pokud možno, nezpůsobilo, že se uživatelé objeví na seznamu podezřelých osob výzvědných služeb). Je však zřejmé, že plná implementace kontejnerů v Linuxu bude jednou potřebovat nějaké systémové volání enter_container().

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    28.12.2007 11:04 M.
    Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
    Linuxové jádro by potřebovalo, aby každou změnu doprovázela dokumentace -- část patche by vždy měla mířit do adresáře Documentation/. To jim to trvalo, než na to přišli :-D
    Jakub Lucký avatar 28.12.2007 19:27 Jakub Lucký | skóre: 40 | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
    Andrew Morton to odstranění popisuje jako fikaný způsob, jak zúžit počet testerů, abychom nedostávali tolik hlášení o chybách.
    Andrew ví, že se neustále Linux a Windows porovnávají podle počtu bugů... A chce to vyřešit po svém ;-)
    If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
    28.12.2007 20:19 Andrei Badea | skóre: 5 | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
    Překlad toho citátu mi nějak nesedí. Originál zní:
    The Linux kernel requires that any needed documentation accompany all changes requiring said documentation -- part of the source-code patch must apply to the Documentation/ directory.
    Což se IMHO dá přeložit spíše jako:
    Linuxové jádro vyžaduje, aby každý patch, který je potřeba zdokumentovat, tu dokumentaci rovnou obsahoval -- část patche musí měnit adrešář Documentation".
    Heureux qui, comme Ulysse, a fait un beau voyage.
    30.12.2007 15:32 fsckya
    Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
    no ja zasnu, zda se, ze ani po novem roce neupgraduji svuj 2.6.22.9 kernel, ty novejsi verze jsou ponekud mne iritujici, zamerne z nich jsou odstraneny symboly, cimz je nasledne zpusobena nefunkcnost nejpouzivanejsich proprietarnich modulu. Andrew Morton je mamrd !
    stativ avatar 31.12.2007 18:36 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Jaderné noviny - 28. 11. 2007
    Řekl bych, že to spíš mělo být tvůrci proprietárních modulů jsou mamrdi.
    Ať sežeru elfa i s chlupama!!! stativ.kx.cz

    Založit nové vláknoNahoru

    ISSN 1214-1267   Powered by Hosting 90 Server hosting
    © 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.