Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Aktuální předverze je (3. 10. 2007) 2.6.23-rc9, vydaná 1. října. Tato -rc verze nebyla v plánu, ale od -rc8 bylo začleněno tolik dalších oprav, takže se Linus rozhodl pro ještě jedno kolečko.
Od vydání -rc9 přibylo do hlavního repozitáře asi dvanáct patchů.
Aktuální verze -mm stromu je 2.6.23-rc8-mm2. Mezi nedávné změny patří opožděná podpora alokování pro ext4 a několik oprav. Andrew poznamenal, že -mm má teď skoro 32 MB patchů oproti hlavnímu stromu - předzvěst toho, co se chystá pro 2.6.24.
Pohled dopředu: vypadá to, že vývojový cyklus 2.6.24 začne sloučením i386 a x86_64. Více informací o 2.6.24 najdete v začleňovacím plánu Andrew Mortona. Do další verze se pravděpodobně dostane práce na správě paměti, další anti-fragmentační patche, přiškrcování zápisu podle jednotlivých zařízení, LSM ne-moduly, souborové kvalifikace, další randomizace rozložení paměti, kontrolní skupiny (dříve kontejnery), jmenné prostory PID, jaderné značkovače a mnoho dalšího. Nezapomeňte, že tento dokument obsahuje pouze patche, které začlení Andrew; hlavní část kódu přijde přímo od správců subsystémů.
Nesmíme ignorovat, když nám někdo řekne "něco je tu špatně", jen proto, že to on sám neumí vyhodnotit. Často je to tak, že když nakonec prohlásíme "nevíme, co se to děje", tak je to _naše_ chyba. Také se nesmíme schovávat za požadavky typu "prosím, proveďte těchto 10 jednoduchých kroků, 2× rekompilujte jádro, 10× restartujte, potrvá to jen půl dne, a pak se ozvěte, až budete mít ty podrobné debugovací údaje".
-- Ingo Molnár
Včera jsem s úžasem zíral na tu čekající hromadu sysfs patchů. Čtyřicet sysfs patchů a asi dvacet patchů pro ovladačové jádro a vrstvu kobject. Na to, že jde o jeden z hlavních kusů jaderné infrastruktury, která už je na místě čtyři nebo pět let, je to pořádný závar. To není dobré znamení. Teda, není to tak vážné, jako kdyby, řekněme, vývojáři plánovače procesoru neustále přepisovali ten svůj kód.
Totiž, moment...
Vzhledem k bezpečnostním otázkám, které se mě týkají [my threat model], a tomu, na kolik si cením svůj čas, je život moc krátký na SELinux.
-- Ted Ts'o
Už jsou to skoro tři roky od chvíle, kdy Sven-Thorsten Dietrich poslal sadu vylepšení pro realtime. Původní kód byl později nahrazen realtime preempcí od Ingo Molnára a dalších, ale i tak si zasluhuje uznání za nastartování vývoje, který pokračuje dodnes. Po třech letech byly mnohé části realtime preempce začleněny do hlavního jádra, a to včetně podpory dynamického tiku, přepsaného subsystému přerušení, mutexů, dědičnosti priorit, časovačů s vysokým rozlišením a dalších věcí. V tuto chvíli už všichni používáme jádra, která využívají kód z projektu pro podporu realtime preempce.
Začleňování částí kódu realtime preempce však ještě není dokončeno. Pohled na oznámení k verzi 2.6.23-rc8-rt1 ukazuje, že tam čeká skoro 400 samostatných patchů. Podívejme se tedy, co ještě zbývá k začlenění.
Jádrem této sady patchů zůstává kód realtimových mutexů. Je-li jádro nastaveno pro realtime provoz, zařídí troška (vylepšené, ale pořád strašidelné) preprocesorové magie, že se spinlocky nahradí realtimovými mutexy, které mají jiné vlastnosti. Především jsou realtimové mutexy plně preemptivní a mají dědičnost priorit. Když jsou jaderné spinlocky těmito mutexy nahrazeny, zbývá už v jádře jen málo míst, která by mohla způsobovat nekontrolovatelné latence.
Začlenění realtime mutexů by teoreticky neměl být problém; nepoužívají se, pokud nejsou výslovně zvoleny při konfiguraci jádra, a předpokládá se, že většina uživatelů takovou konfiguraci nezvolí. Tak zásadní změna základního mechanismu vzájemného vyloučení však zákonitě vzbudí nedůvěru. Takže se o začlenění zatím ani neusilovalo a je pravděpodobné, že si do hlavního jádra nejdříve najde cestu většina ostatních částí realtime stromu.
Kód, který by mohl dostat přednost, je patch s vláknovými rutinami pro obsluhu přerušení. Když jsou tyto rutiny ve vláknech, je možné je plánovat společně s většinou ostatních systémových aktivit a odstraňuje se další potenciální zdroj latence. Může to také vylepšit robustnost systému a zjednodušit hledání chyb v kódu přerušení. Takže tento patch by mohl být začleněn a možná i nastaven jako výchozí chování - i když vždycky zůstane určitý malý počet obsluh přerušení, které bude nutné spouštět přímo.
V realtime stromu je i patch, který přesouvá veškeré zpracovávání softwarových přerušení do dedikovaných vláken. Další patch obsluhovacím vláknům hardwarových přerušení umožňuje zpracovat čekající softwarová přerušení a pak teprve uvolnit procesor. Tato optimalizace odstraňuje nutnost přepnutí kontextu na samostatné vlákno softwarového přerušení, aby mohla být ta přerušení doručena.
Jedním z problémů realtime patchů byla spolupráce s mechanismem read-copy-update. Stávající kód vyžaduje, aby byla preempce vypnuta, pokud existují reference na RCU-chráněné datové struktury - ale vypnutí preempce zhatí záruky, které se realtime kód snaží poskytovat. Řešením je poněkud komplikovanější implementace preemptivního RCU.
Do realtime stromu se dostaly patche od Nicka Piggina pro podporu bezzámkové keše stránek [lockless pagecache]. Provádějí několik nízkoúrovňových změn ve správě paměti a kódu radix stromů, aby mohly být některé operace s keší stránek prováděny bez zamykání. Tento kód už je v oběhu nějakou dobu, ale do hlavního jádra se nedostal, i když se zdá, že by mohl v mnoha situacích opravdu pomoci se škálovatelností. Další patch (od Petera Zijlstry) se zbavuje zamykání v kódu kmap(), což zlepšuje latence u systémů, které používají vysokou paměť.
Ještě jeden patch už je dlouhou dobu mimo hlavní jádro - a asi to tak zůstane: /dev/rmem od Teda Ts'o. Toto zařízení umožňuje přímý přístup k fyzické paměti - funkce, která je vyžadována u všech systémů, které chtějí splňovat realtimové podmínky Javy. Nakolik je moudré nechávat javovské programy, aby se vrtaly ve fyzické paměti, to není téma, nad kterým by bylo nutné déle hloubat.
Realtime strom obsahuje širokou paletu nástrojů pro odhalování částí jádra, které způsobují přílišné latence. Tento kód byl během let často využíván k zjišťování a rozebírání jaderného kódu, jenž zbytečně zatěžoval procesor. Tyto patche se zdají jako dobrý kandidát pro zařazení do jádra - zvláště vzhledem k nedávným diskuzím o přidávání více nástrojů. Prvním krokem k řešení problémů je mít možnost je měřit.
Není mi jasné, proč realtime strom obsahuje i letitý realtime bezpečnostní modul, který byl již před lety definitivně odmítnut. Je označen jako zastaralý - ale pořád tam je.
Strom však obsahuje i dost dalších změn. Například není možné s realtime jádry používat SLUB alokátor, takže strom obsahuje upravenou verzi slab alokátoru, který nahrazuje na přerušeních založené jednoprocesorové zamykání sadou zámků pro jednotlivé procesory. Globální files_lock bylo odstraněno ve prospěch pevně zamčených seznamů pro jednotlivé procesory. S vytvářením takových seznamů pomáhá nově přidaný typ zamčený list [locked-list]. Kód taskletů byl přepraován kvůli lepšímu využití vláken, ale patch pro odstranění taskletů tam není. Kromě toho je tam docela dost patchů specifických pro architektury, které přidávají různé funkce (např. clockevents) a opravují chyby.
I přes všechno začleňování do hlavního jádra, které probíhalo v uplynulých dvou letech, je v realtime stromu prostě hodně kódu. Plán zní začlenit většinu z toho v ne příliš daleké budoucnosti, ale kdy by to mělo být, to není jasné. Někteří vývojáři realtime patchů navíc budou pravděpodobně dost vyrušeni spojením i386 a x86_64 v rámci vývojového cyklu 2.6.24, takže se jim možná nebude moc dařit kód začleňovat.
Simplified Mandatory Access Control Kernel [jádro se zjednodušenou povinnou kontrolou přístupu] je bezpečnostní modul určený k zabezpečení linuxových systémů prostřednictvím přidání pravidel pro povinnou kontrolu přístupu (vizte Smack: zjednodušená kontrola přístupu). Podobně jako SELinux, i SMACK připojuje k procesům, souborům a dalším systémovým objektům štítky a implementuje pravidla popisující, jaký druh přístupu jednotlivé kombinace štítků umožňují. Na rozdíl od SELinuxu byl však SMACK navržen především pro snadnou administraci.
Třetí verze SMACKu vedla k zajímavé diskuzi. Andrew Morton ji odstartoval:
O bezpečnosti vím tak málo, že nemohu být ani nebezpečný. Pročetl jsem si tu srpnovou diskuzi o první verzi a vyrozuměl jsem, že byl kód přijímán kladně a sám o sobě vypadá dobře. Ale SELinux by mohl být nakonfigurován tak, aby dělal něco hodně podobného.
Nepřipadá mi, že by to "ale" mohlo být bráno jako důvod, proč SMACK nezačleňovat. Spíš si říkám, že bychom to mohli začlenit a počkat, jestli to lidé začnou používat.
Andrew navrhl SMACK přijmout do jádra 2.6.24. Trochu se diskutovalo o jednotlivých částech patche (některým vývojářům se líbí síťové CIPSO nálepky více, jiným méně), ale nevypadá to, že by někdo nějak zvlášť proti začlenění SMACKu protestoval. Obecně je to považováno za dobře napsaný kód, který dává z bezpečnostního hlediska smysl.
S jedinou předvídatelnou výjimkou: kdykoliv se uvažuje o začlenění nového bezpečnostního modulu, vývojáři SELinuxu bývají proti. Tentokrát přišel s obecnou připomínkou James Morris: SMACK by byl už druhým uživatelem systému Linux security module (LSM) [linuxový bezpečnostní modul]. To by znamenalo, že už by bylo prakticky nemožné LSM z jádra odstranit. James tvrdí:
Pokud LSM zůstane, nikdy nebude bezpečnost v jádře brána vážně. Vývojáři aplikací budou mít k dispozici několik bezpečnostních schémat a buď si nabijí ve snaze je podporovat všechna, nebo je, a to je pravděpodobnější, budou ignorovat. Vývojáři jádra pořád nebudou mít dostatek informací, aby věděli, co ty LSM háčky [hooks] v jejich kódu mají dělat, což nakonec povede k potížím se správou a potenciálním bezpečnostním problémům.
Programátoři SELinuxu by patrně byli raději, kdyby byl SELinux jediným bezpečnostním systémem, který Linux podporuje, aby se mohlo veškeré vývojářské úsilí zaměřovat na jeho vylepšování.
Problém je samozřejmě v tom, že ani po několika letech, kdy byl v jádře pouze SELinux, to nevypadá, že by existovaly zástupy vývojářů aplikací, kteří by na podpoře SELinuxu pracovali. Představa, že budou všechny aplikace obsahovat soubor s pravidly pro SELinux, se nenaplnila. Trochu se pokročilo s přípravou vysokoúrovňových nástrojů pro správu selinuxových pravidel a vývojáři Fedory a Red Hatu odvedli dost práce ve snaze vytvořit distribuci pro obecné použití s omezenou sadou pravidel, ale i přesto zůstává pro většinu lidí SELinux prostě moc komplikovaný. Na stroji s RHEL možná SELinux funguje rovnou po instalaci, ale jakmile admninistrátor narazí na problém, je dost pravděpodobné, že prostě SELinux vypne.
Vývojáři SELinuxu by pravděpodobně argumentovali tím, že tyto problémy lze řešit koncentrací na jediný bezpečnostní systém. Místo vytváření konkurenčních zjednodušených systémů by bylo lepší implementovat přístupy jako AppArmor nebo SMACK v rámci SELinuxu a SELinux tím vylepšit. Tito vývojáři také tvrdí, že natahovatelné [pluggable] bezpečnostní moduly povedou (podobně jako natahovatelné plánovače) pouze k rozdělení vývojového úsilí a zabrání vytvoření opravdu univerzálního řešení:
Opravdu chcete lidi podporovat v přípravě vlastních bezpečnostních modulů místo práce na společné bezpečnostní architektuře a jediném vyváženém řešení (což, mimochodem, nemusí znamenat SELinux, ale určitě by si z něj mohlo něco vzít)? Stejně jako u natahovatelných plánovačů, i LSM přístup zabraňuje sdílení a nutí uživatele si vybrat.
Reakcí na to je argument, že existuje mnoho bezpečnostních prostředí a různých uživatelských potřeb; nic nenapovídá tomu, že by jediný bezpečnostní přístup mohl fungovat ve všech situacích. A i kdyby byl takový jednotný přístup možný, stejně by bylo obtížné přesvědčit vývojáře, aby se na něm shodli. Ted Ts'o k tomu napsal:
Skutečný problém s bezpečností je to, že, jak říká Linus, neexistují žádná "definitivní čísla". Místo toho máme různé skupiny požadavků lišící se v tom, co je pro ně platný threat model --- a to se bude lišit podle prostředí, způsobu využití serverů a také podle toho, jak schopný je protivník, který se snaží do systému proniknout --- a nakolik jsou uživatelé ochotní dělat kompromisy mezi bezpečnostní a pohodlím.
Architektura LSM byla výsledkem úplně prvního jaderného summitu, kde Linus prohlásil, že si nechce vybírat mezi různými způsoby - místo toho chtěl, aby bylo jádro schopné podporovat všechny bezpečnostní systémy. Jeho postoj se od té doby nezměnil; pořád si nevšiml, že by se schylovalo ke všeobecné shodě o bezpečnostních přístupech, takže chce, aby byl Linux v tomto ohledu i nadále pružný. Napsal k tomu:
Takže LSM zůstane. Žádné pokud, ale, možná nebo cokoliv jiného.
Až začnou vývojáři bezpečnostních věci předkládat rozumné argumenty a na něčem se shodnou, tak se to změní. Ale upřímně, spíše čekám, že dřív bude v pekle sněžit a prasata budou hnízdit na stromech, než k tomu dojde. Ale co, doufat můžu.
Takže se zdá, že cesta k začlenění SMACKu do 2.6.24 je volná. Jakmile se to stane, nebylo by velké překvapení, kdyby se ozvali s žádostí o začlenění vývojáři modulů AppArmor a TOMOYO Linux; ostatně, patche TOMOYO Linux byly právě znovu poslány do LKML. Přes přání jeho vývojářů bude nakonec SELinux muset o pozornost, vývojáře, distributory a uživatele bojovat s ostatními bezpečnostními přístupy. V dohledné budoucnosti nebude mít Linux žádný Jediný Správný Bezpečnostní Modul.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
20.10.2007 20:02
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Ona ta mlčící - a neúčastnící se - většina zas nemusí být hloupá 
No, kolega mi říkal, že jeho kamarád prý má kamaráda, který SELinux umí... Akorát teda nevím, co to přesně znamená. Já třeba taky umím SELinux. Vypnout.
)
Mimochodem, nekde jsem cetl, ze prave SELinux byl duvodem, proc RHEL dostal nedavno nejakou vysokou bezpecnostni certifikaci..takze asi existuji lide, kteri v nem vidi prinos.
Co se tyce notebooku tak vypinam pri instalaci...
18.10.2007 21:19
michich | skóre: 51
| blog: ohrivane_parky
Zdalo se mi to prilis slozite. Fakt, ze vznikaji veci jako SMACK me v tomto zdani jen utvrdil... Takze je fajn videt, ze jsou lidi, co to dokazou pouzivat
O potrebnosti a uzitecnosti neceho jako SELinux se vubec nepru, tyhlety bezpecnostni udelatka jsou bezva, jen proste SELinux je takovej... na vypnuti
což, mimochodem nemusí znamenat SELinuxTady bych dal čárku i za mimochodem, nebo bych nepsal čárky vůbec.
Programátoři SELinuxySELinuxu?
19.10.2007 10:08
michich | skóre: 51
| blog: ohrivane_parky
RT kernel má o něco málo menší celkový výkon. Náhrada spinlocků mutexy není zadarmo.No, "o něco málo menší celkový výkon" mi príde ako kvantitatívny rozdiel, ktorý bude za niekolko mesiacov bohato kompenzovaný nárastom výkonu hardvéru, zatiaľ čo "byť realtime" mi príde byť ako kvalitatívny rozdiel, ktorý nie je nahraditeľný ničím iným. A preto sa ďalej pýtam: - Čo presne zamená "o něco málo menší celkový výkon"? - Nakoľko významná a potrebná je fičúra "byť realtime"?
19.10.2007 14:06
michich | skóre: 51
| blog: ohrivane_parky
Čo presne zamená "o něco málo menší celkový výkon"?V některých benchmarkách je pokles v jednotkách procent, v jiných více. Vím o jednom databázovem benchmarku, kde byl pokles o 30%, ale bylo to před nějakým časem a je možné, že od té doby došlo ke zlepšení.
Nakoľko významná a potrebná je fičúra "byť realtime"?Jak v pro kterou aplikaci. Někde je to naprosto zbytečné a jinde nezbytné.
RT linux nenasazovat nikde, kde to neni potreba, je to dost nebezpecny nastroj, napr na server bych to nedaval nikdy.Tak si potom lámem hlavu nad tým, ako môže byť Solaris tak úspešne nasadzovaný na serveroch.
24.10.2007 08:15
michich | skóre: 51
| blog: ohrivane_parky
RT linux nenasazovat nikde, kde to neni potreba, je to dost nebezpecny nastroj,V čem podle tebe spočívá to nebezpečí?
napr na server bych to nedaval nikdy.Ani kdyby jeho účelem bylo třeba doručování zpráv s minimálním a předvídatelným zpožděním?
Napr tim lze zpusobit DOSTohle bys měl nějak rozvést, jinak je to jenom FUD.
20.10.2007 20:21
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Říkáte, že je vhodné vše překládat? Mně by stačil label. Zřejmě se pohybuju častějš v anglofonním prostředí.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz