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í
×
včera 19:55 | Zajímavý článek

Byly zveřejněny (pdf) podrobnosti o kritické bezpečnostní chybě CVE-2017-12542 v HPE iLO 4 (Integrated Lights-Out), tj. v proprietárním řešení společnosti Hewlett Packard Enterprise pro vzdálenou správu jejich serverů. Bezpečnostní chyba zneužitelná k obejití autentizace a k vzdálenému spuštění libovolného kódu byla opravena již v květnu loňského roku ve verzi 2.53.

Ladislav Hagara | Komentářů: 1
včera 17:55 | Zajímavý projekt

CSIRT.CZ informuje o CTF (Capture the Flag) platformě ZSIS CTF s úlohami pro procvičování praktických dovedností z oblasti kybernetické bezpečnosti a upozorňuje na soutěž Google Capture the Flag 2018, kde je možné vyhrát zajímavé ceny.

Ladislav Hagara | Komentářů: 0
včera 17:00 | Komunita

Byly zveřejněny prezentace a videozáznamy přednášek z prvního československého setkání síťových operátorů CSNOG konaného 11. a 12. června v Brně a semináře IPv6 2018 uskutečněného 6. června v Praze.

Ladislav Hagara | Komentářů: 0
včera 16:11 | Komunita

Svobodný unixový operační systém FreeBSD slaví 25 let. Přesně před pětadvaceti lety, tj. 19. června 1993, byl vybrán název FreeBSD.

Ladislav Hagara | Komentářů: 0
včera 15:11 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Nadace Blender Foundation informuje, že od společnosti Google dostala šestistránkový návrh nové smlouvy (pdf). Zdá se, že podmínkou další spolupráce je zapnutí reklam na kanálu, tj. zpeněžení obsahu.

Ladislav Hagara | Komentářů: 21
včera 01:55 | Nová verze

Byla vydána verze 1.13 multiplatformního open source textového editoru Brackets (Wikipedie, GitHub). Přehled novinek v oficiálním oznámení a v poznámkách k vydání. Brackets je nově dostupný také jako balíček ve formátu Flatpak z oficiálního repozitáře Flathub.

Ladislav Hagara | Komentářů: 3
18.6. 18:44 | Komunita

Oficiální YouTube kanál Blenderu je již několik dní blokován. Důvody jsou zatím nejasné. Pravděpodobně chyba YouTube. Dění lze sledovat na Twitteru Tona Roosendaala.

Ladislav Hagara | Komentářů: 18
18.6. 17:55 | Zajímavý software

Na GitHubu byly pod open source licencí LLVM zveřejněny zdrojové kódy překladače programovacího jazyka C++ Zapcc vycházejícího z Clangu/LLVM. Překlad pomocí Zapccu je díky lepšímu kešování obvykle několikrát rychlejší než překlad pomocí Clangu. V březnu loňského roku byl vydán Zapcc ve verzi 1.0.

Ladislav Hagara | Komentářů: 0
18.6. 17:22 | Pozvánky

Červnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 21. 6. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: F-Droid, aneb svobodný software do vašeho mobilu. Kromě toho budou k vidění i vývojové desky HiFive1 se svobodným/otevřeným čipem RISC-V.

xkucf03 | Komentářů: 1
15.6. 22:44 | Zajímavý článek

Na blogu projektu NeoPG (GitHub), kryptografického softwaru vycházejícího z GnuPG, byly zveřejněny 4 příspěvky detailně popisující aktuální bezpečnostní problémy v GnuPG a souvisejících softwarových produktech. V prvním příspěvku je ukázáno, že je možné vytvořit zprávu, o které budou Earlybird, Evolution, Mutt nebo Outlook tvrdit, že jí dešifrovali a přitom ale zpráva vůbec zašifrována nebyla. V druhém příspěvku je popsána

… více »
Ladislav Hagara | Komentářů: 8
Jak čtete delší texty z webových stránek?
 (78%)
 (22%)
 (4%)
 (7%)
 (2%)
 (11%)
Celkem 213 hlasů
 Komentářů: 36, poslední 18.6. 21:16
    Rozcestník

    Jaderné noviny - 27. 6. 2007

    18. 7. 2007 | Robert Krátký | Jaderné noviny | 4454×

    Aktuální verze jádra: 2.6.22-rc6. Citáty týdne: Linus Torvalds, Randy Dunlap. Odstranění taskletů. Linuxové bezpečnostní ne-moduly a AppArmor. Shrnutí změn v interním API v jádře 2.6.22.

    Obsah

    Aktuální verze jádra: 2.6.22-rc6

    link

    Aktuální předverze je (27. 6. 2007) 2.6.22-rc6, vydaná 24. června. Těší mě, že se po vydání -rc5 věci zklidnily, takže tu máme skutečně jen opravy chyb a zvláště regresí. Vypadá to, že tento vývojový cyklus už se blíží ke konci; seznam známých regresí se zkracuje. Jako vždy najdete spoustu podrobností v dlouhém changelogu.

    Od vydání 2.6.22-rc6 bylo do hlavního git repozitáře začleněno asi 30 patchů; jsou to všechno opravy, většinou v kódu USB pro jednotlivé architektury.

    Minulý týden nevyšly žádné nové -mm verze ani starší jádra.

    Citáty týdne: Linus Torvalds, Randy Dunlap

    link

    Upřímně řečeno, osobně uvažuji o odstranění "checkpatch.pl". Je to jen náckovské snění. Třeba ten natvrdo vyžadovaný 80znakový limit, to prostě není správné.

    -- Linus Torvalds

    Potíž je podle mne v tom, že jsou patche čím dál tím méně kontrolovány, ačkoliv by bylo potřeba je kontrolovat více a více. Andrew je jeden z mála, kdo kontroluje spousty patchů. Neměl by to však mít na krku jen on. Takže pokud by Andrewovi pomohlo trochu automatizace, bylo by to fajn. Tedy, dokud se lidé nevzbouří.

    -- Randy Dunlap

    Odstranění taskletů

    link

    Tasklety jsou metodou pro pozdržené spouštění úloh v jádře; byly přidány během vývojové řady 2.3, aby mohly zpracovávače přerušení [interrupt handlers] plánovat práci, která má být provedena v blízké budoucnosti. Tasklet je v podstatě funkce, která má být zavolána (s datovým ukazatelem) v softwarovém přerušení, jakmile je to možné. V praxi bude naplánovaný tasklet (pravděpodobně) spuštěn, když jádro 1) dokončí běh zpracovávače přerušení nebo 2) přepne zpět do uživatelského prostoru. Protože tasklety běží v režimu softwarového přerušení, musí být atomické - žádné spaní nebo reference na uživatelské prostředí atd. Práce, kterou lze provádět v taskletech, je tedy dost omezena, ale i tak jsou v jádře velmi používány.

    A s tasklety je ještě jeden problém: protože běží jako softwarová přerušení, mají vyšší prioritu než kterýkoliv jiný proces v systému. Tasklety tedy vytvářejí neomezené latence, což se vývojáři, kteří se snaží latence snižovat, už dlouho pokoušejí odstranit. Objevily se pokusy, jak problém zmírnit; pokud jádro se softwarovými přerušeními neudrží krok, vyhodí je nakonec do procesu ksoftirqd a nechá je, ať se porvou v plánovači. Specifické tasklety, u kterých bylo zjištěno, že způsobují latenční problémy - například zpracovávač zpětného volání RCU - byly trochu umravněny. A realtimový strom tlačí veškeré zpracovávání softwarových přerušení do samostatných procesů, které lze plánovat (a využít na ně preempci) jako všechno ostatní.

    Steven Rostedt nedávno navrhl jiný přístup: proč se těch taskletů nezbavit úplně? Od doby, kdy byly tasklety vyvíjeny, už jádro získalo jiné a pružnější způsoby odkládání práce; konkrétně pracovní fronty fungují velmi podobně jako tasklety, ale bez mnoha nevýhod, které jsou s tasklety spojeny. Protože pracovní fronty používají dedikované pracovní procesy, může na ně být uplatněna preempce a nemají stejné latenční problémy jako tasklety; jako bonus poskytují kontext procesů, který pracovním funkcím umožňuje (v případě potřeby) spát. Steven tvrdí, že pracovní fronty jsou natolik schopné, že tasklety už nejsou potřeba.

    Stevenův patch tedy rozhraní pročišťuje a z RCU taskletu dělá samostatné softwarové přerušení nezávislé na mechanismu taskletů. Pak je vyhozen kód taskletů a nahrazen obalovým rozhraním [wrapper interface], které pod sebou schovává pracovní fronty. Výsledkem je jádro bez taskletů, aniž by bylo nutné přepisovat všechen kód, který tasklety používá.

    Proti odstranění taskletů se nikdo moc nebouří, i když je jasné, že před zařazením takové změny bude nutné provést hodně výkonnostních testů. Skoro nikomu se však nelíbí obalové rozhraní; je to přesně takový způsob poslepování věcí kvůli kompatibilitě, kterému se snaží zabránit pravidlo "žádné stabilní interní API". Je tedy vyvíjen tlak na zahození obalu a převedení všech uživatelů taskletů na pracovní fronty. Není třeba říkat, že jde o velký kus práce; a není také žádné překvapení, že by se mohl najít někdo, kdo by byl v pokušení se tomu vyhnout. Ať tak či tak, současnou podobu patche je možné testovat; pokud by nahrazení taskletů způsobovalo problémy, tento patch je odhalí, než si někdo dá tu práci a převede všechny uživatele taskletů.

    Další otázka, na kterou je nutné mít odpověď, zní: přinese převod taskletů na pracovní fronty lepší zpracovávání přerušení, nebo by se mělo uvažovat o širších změnách? Místo přepínání kontextu do procesu pracovní fronty by možná systém vytěžil lepší výkon, kdyby prostě zpracovávač přerušení spustil jako vlákno. Realtimový strom to přesně takhle dělá už dlouho: všechny (OK, skoro všechny) zpracovávače přerušení běží ve vlastních vláknech. Vývojáři realtime plánují tento kód začlenit během následujících několika vývojových cyklů.

    Podle současných plánů by vláknové zpracovávače přerušení pravděpodobně byly konfigurovatelné při kompilaci. Ale kdyby vývojáři věděli, že zpracovávače přerušení poběží v kontextu procesů, mohli by prostě potřebné zpracování provést v rámci zpracovávače a mechanismu pro pozdržení práce se zbavit úplně. Takový přístup by nemusel fungovat s každým ovladačem - u některých zařízení by bylo riziko příliš velké latence při reakci na přerušení - ale v mnoha případech se nabízí možnost situaci výrazně zjednodušit a zpřehlednit. Kód by nebyl jen jednodušší, ale dokonce i výkonnější.

    Zdá se tedy, že na odstranění taskletů se skutečně pracuje. V rámci příprav se Ingo Molnar zaměřil na možné výkonnostní problémy:

    Takže k tomu následujícímu odlišnému přístupu: všichni, kdo máte tasklet v kódu, u kterého je důležitý výkon, se prosím ozvěte. Sami taková místa budeme aktivně hledat. Můžeme je buď převést na softwarová přerušení, nebo je přesunout zpátky do kontextu hardwarových přerušení. Jakmile to bude hotovo - a pochybuji, že to bude více než 1 - 2 místa - tak můžeme najednou převést všech těch dalších 110 míst na nudné, ale kompatibilní řešení, při kterém jsou prováděny v globálním kontextu vláken.

    To je docela jasná výzva k činu pro každého, komu záleží na možných výkonnostních dopadech této změny na nějakou konkrétní část jádra. Pokud myslíte, že nějaký kód potřebuje rychlejší reakci na pozdrženou práci, než může poskytnout mechanismus založený na pracovních frontách, teď je ta pravá chvíle neodkládat odpověď na Ingovu žádost.

    Linuxové bezpečnostní ne-moduly a AppArmor

    link

    Pokud již dění kolem vývoje jádra nějakou chvíli sledujete, budete vědět, že LSM API (Linux security module API - rozhraní pro linuxové bezpečnostní moduly) je přinejmenším kontroverzní. Mnozí si myslí, že nesplnilo svůj úkol - umožnit vývoj konkurenčních přístupů k zabezpečení linuxového systému; jediný významný bezpečnostní modul v jádře je SELinux. Přitom však lze rozhraní LSM snadno zneužívat; protože umožňuje vložení háčků [hooks] do téměř libovolné systémové operace, může být jinými moduly využíváno k poskytování funkcí, které s bezpečností nesouvisejí. LSM symboly jsou většinou exportovány jako pouze-GPL, ale i tak je možné, aby binární moduly LSM operace zneužívaly - a zjevně už to některé dělají.

    SELinux hacker James Morris o tomto problému přemýšlel a také si všiml, že bezpečnostní moduly, které jsou součástí jádra (SELinux a ten malý modul, který implementuje kvalifikace [capabilities]), není možné z běžícího jádra vyjmout. Takže položil otázku, proč mít vůbec modulární rozhraní? Poslal patch, který z LSM dělá statické API, jež neexportuje žádné symboly. Je-li tento patch aplikován, musejí být potřebné bezpečnostní "moduly" zakompilovány přímo do jádra; už neexistuje způsob, jak je přidat za běhu.

    Objevilo se pár nesouhlasných názorů, ale nevypadá to, že by někdo přišel s opravdu vážným důvodem, proč by mělo být možné bezpečnostní moduly odstraňovat za běhu. Naopak někdo poukázal na to, že snažit se udržovat rozumnou bezpečnost na systému, kde jdou odstraňovat moduly, je skoro nemožné. Tento patch má tedy slušnou šanci se do jádra dostat. Jedinou otázkou tak je, jestli mají vývojáři pocit, že je nutné poskytnout dlouhou dobu před začleněním jako varování vývojářům a uživatelům bezpečnostních modulů, jež nejsou součástí jádra.

    Jeden takový modul je AppArmor - bezpečnostní mechanismus licencovaný GPL, který je distribuován Novellem. AppArmor zůstává mimo jádro, zatímco se jeho vývojáři snaží reagovat na připomínky, které byly během let vzneseny. Byl představen nový AppArmor patch; v němž byla spousta věcí opravena, ale jeden ze zásadních bodů zůstává: AppArmor pro prosazování pravidel stále používá mechanismus založený na názvech cest. Takový přístup se vývojářům nelíbí - hlavně těm z tábora SELinuxu - protože jsou přesvědčeni, že názvy cest jsou ze své podstaty nebezpečná metoda. Z jejich pohledu je jediný bezpečný způsob kontroly přístupu k objektům přidání značek přímo na objekty.

    Už to vypadalo, že byl tento spor vyřešen na jaderném summitu v roce 2006, kde bylo rozhodnuto, že používání názvů cest není dostatečný důvod pro odmítání AppArmor. To však lidem nezabránilo ve stěžování, když se nedávno objevil nový přístup založený na názvech cest (TOMOYO Linux). Pokud se AppArmor do hlavního jádra dostane, bude to přes námitky vývojářů, kteří tvrdí, že uživatelům poskytuje falešný pocit bezpečí.

    Andrew Morton by tuto záležitost chtěl dohodnout mimo konferenci; napadají ho dvě alternativy:

    a) nechat stranou technické otázky a překousnout začlenění jako službu SUSE a jejich uživatelům (obě skupiny jsou pro nás důležité); nechali bychom to jako konkrétní lekci z kapitoly "jak nevyvíjet jaderné funkce" [...]

    b) nechat to venku a vyžadovat od SUSE, ať nese nákladové a kvalitativní důsledky správy mimo jádro. I tak to bude dobrá lekce o tom, "jak nevyvíjet jaderné funkce".

    Andrew však pravděpodobně nechce dávat konkrétní lekce k vývoji jaderného kódu žádným z těchto způsobů; uzavřel tedy žádostí:

    Ach jo. Nestavte nás už prosím do této situace. Než něco začnete prodávat zákazníkům, dostaňte to nejdřív do jádra, OK? Není to žádná velká věda.

    Na summitu v roce 2006 se Linus jasně vyjádřil, že používání názvů cest mu připadá rozumné. To, společně s faktem, že je AppArmor široce distribuován, napovídá, že dříve či později si tento modul cestu do jádra najde - i kdyby už to nebylo ve formě modulu.

    Shrnutí změn v interním API v jádře 2.6.22

    link

    Vývojový cyklus 2.6.22 se pomalu blíží ke svému závěru, což znamená, že už by mělo být bezpečné se pokusit vyjmenovat významné změny interního API.

    • Byl začleněn bezdrátový stack mac80211 (dříve "Devicescape"), takže je k dispozici kompletně nové API pro vytváření bezdrátových ovladačů - především těch, které vyžadují podporu MAC.

    • Funkce eth_type_trans() teď nastavuje pole skb->dev, což je stejný postup, jaký používají podobné funkce pro jiné typy linků. Kvůli tomu byla změněna spousta ethernetových ovladačů - bylo odstraněno (teď již) zbytečné přiřazení.

    • Hlavičková pole ve struktuře sk_buff byla přejmenována a už nejsou typu union. Síťovací kód a ovladače teď mohou používat skb->transport_header, skb->network_header a skb->skb_mac_header. Pro vyhledání specifických hlaviček v paketech jsou k dispozici nové funkce: tcp_hdr(), udp_hdr(), ipip_hdr() a ipipv6_hdr().

    • Ještě z oblasti síťování: paketový plánovač byl přepracován, aby používal hodnoty ktime místo jiffies.

    • SLUB alokátor byl začleněn jako experimentální (prozatím) alternativa ke kódu slab. SLUB API obecně odpovídá slabu, ale trochu se změnil způsob řešení nulových alokací.

    • Další změny již byly uvedeny v souhrnu, který se objevil v článku Jaderné noviny - 9. 5. 2007.
           

    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ář

    18.7.2007 01:25 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    zpracovávače přerušení [interrupt handlers]
    Ehm, rutiny {obsluhy|pro obsluhu} přerušení? Případně jen obsluha přerušení, tam, kde není kladen důraz na konkrétní kus kódu.
    18.7.2007 12:35 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Ehm, rutiny {obsluhy|pro obsluhu} přerušení? Případně jen obsluha přerušení, tam, kde není kladen důraz na konkrétní kus kódu.
    No jo, mně se ty zpracovávače také moc nelíbí, ale používám je v JN už poměrně dlouho a nikdo zatím nekřičel, tak jsem se nechal ukolébat... Díky za nápady.
    18.7.2007 13:16 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Já to taky zas tak poctivě neprocházím, tak jsem si toho zatím nevšiml. ;-)
    18.7.2007 03:04 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Dvoje jaderné noviny během tří dnů? Děkujeme velice.
    Quando omni flunkus moritati
    18.7.2007 08:33 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Njn, konecne to spravne tempo. :-D
    18.7.2007 12:36 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Snažím se jen dohánět zpoždění :-)
    18.7.2007 20:41 Creator of Myths
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    To jako ze si budu moct precist v ceskych Jadernych novinach aktualni veci misto toho, co se delo pred mesicem? To by bylo opravdu skvele! :-)
    18.7.2007 21:24 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Úplně aktuální věci to nebudou nikdy, protože bych to jednak nestíhal, ale také jsem se s provozovatelem LWN dohodl, že vždy počkám alespoň týden, protože bych jinak zpřístupňoval překlad obsahu, který by v tu chvíli byl na LWN dostupný pouze pro předplatitele.
    19.7.2007 09:26 Creator of Myths
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Rozdil jednoho tydne beru jako v podstate aktualni. Rozhodne je to neco jineho nez mesic, behem ktereho jsou vyvojari schopni udelat spoustu zmen.
    18.7.2007 22:42 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Ale takhle mám alespoň dobrý pocit z toho, že na problémech v kernelu zmíněných v českých Jaderných novinách se už nejméně měsíc pracuje :-)
    Petr (DotaZ) Jakubec avatar 20.7.2007 13:27 Petr (DotaZ) Jakubec | skóre: 5
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    taky mi mesicni zpozdeni nijak nebrani v klidnem spanku :-)

    3 mesicni by uz mi prislo jako zastarale ale mesic je jeste OK.

    ja ta aktualni povazuji 14dnu i mesic zpozdeny preklad uplne bez problemu.

    jo a DIKY za nej!
    21.7.2007 12:39 Martin Doucha | skóre: 23 | blog: Yet another blog
    Rozbalit Rozbalit vše Jedna drobnost v překladu
    Větu "That thing is just a nazi dream." bych přeložil spíš jako "Ta věc [checkpatch.pl] je sen všech nácků.", Linus komentuje kvalitu toho skriptu a ne svoje představy.
    21.7.2007 14:59 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jedna drobnost v překladu
    Linus komentuje kvalitu toho skriptu a ne svoje představy.
    Nemyslel jsem to tak, že jde o jeho představy. IMHO "náckovské snění" znamená to, o čem snívají náckové.
    21.7.2007 20:29 Martin Doucha | skóre: 23 | blog: Yet another blog
    Rozbalit Rozbalit vše Re: Jedna drobnost v překladu
    Ale věta "Je to jen náckovské snění." se tak dá pochopit.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.