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 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 3
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 2
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (16%)
 (2%)
 (0%)
 (2%)
 (69%)
 (12%)
Celkem 51 hlasů
 Komentářů: 2, poslední dnes 18:09
    Rozcestník

    Jaderné noviny - 27. 6. 2007

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

    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: 48
    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.