Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Současný vývojový kernel má označení 4.7-rc4, vydán byl 19. června. Linus řekl, že je „celkem malý“ a neobsahuje „nic moc znepokojujícího“. Vývojový cyklus postupuje kupředu s obvyklými druhy změn. „Statistiky vypadají úplně normálně: dvě třetiny tvoří ovladače, zbytek jsou z poloviny aktualizace architektury a z poloviny všechno ostatní (menší aktualizace souborových systémů, nějaká dokumentace a drobné patche)."
Stabilní aktualizace: minulý týden žádné nevyšly.
Výkon není něco, co by se dalo přidat potom. Pokud první verze patche není dost výkonná, neměli bychom ji považovat za hotovou.
Všechna zařízení s Brillo – včetně těch již uvedených na trh – budou používat jádra sestavená z jediného společného stromu, který následuje aktuální LTS upstream. To eliminuje jednu z kombinačních testovacích proměnných (verze jádra), protože bude stejná na všech zařízeních. Vzhledem k tomu, že aktualizace jádra každého zařízení bude třeba tak jako tak testovat, na vyžadovaném testování každého zařízení se nic nemění, naopak získáme funkce, bezpečnostní aktualizace a opravy chyb při mnohem menším vloženém úsilí.
Jaderný tým Brillo bude ve společném jádře Brillo průběžně doplňovat změny LTS jádra z ustreamu a záplaty pro Android; také bude pomáhat s přísunem patchů pro porty konkrétních výrobců. Ti již nebudou muset trávit čas backportováním upstreamu a změn specifických pro Android do několika stromů a verzí jádra pro různé konkrétní produkty.
-Projekt Google Brillo plánuje dělat věci zdánlivě jinak.
Zásobník v linuxovém jádře je dost možná slabým místem návrhu systému. Je tak malý, že jaderný vývojáři si neustále musejí dávat pozor, co na zásobník ukládají, aby nedošlo k jeho přetečení. Jenže ono k tomu dochází i tak, i když široko daleko není žádný útočník, který by se snažil přetečení zásobníku si vynutit – a jak nedávno demonstroval Jann Horn, útočníci mají důvody o to usilovat. Pokud k přetečení dojde, jádro je tak špatně umístěno, že problém nezaregistruje, natož že by mohlo nějak reagovat. V průběhu historie jádra se zásobník příliš nezměnil, ovšem poslední práce mají potenciál učinit zásobník o poznání robustnějším.
Každý proces má svůj vlastní zásobník, který používá, běží-li v jádře. V současných jádrech má tento zásobník 8 KB nebo (na 64bitových systémech) 16 KB paměti. Zásobník se nachází v přímo mapované paměti jádra, takže musí být fyzicky souvislý. Tento požadavek může být problematický sám o sobě, protože jak dochází k fragmentaci paměti, může být nalezení dvou nebo čtyř fyzicky souvislých stránek složité. Využití přímo mapované paměti také vylučuje použití ochranných stránek (guard pages) – nepřístupných stránek, které by zachytily přetečení zásobníku – protože přidání ochranné stránky by vyžadovalo zabrání skutečné fyzické stránky paměti.
V důsledku neexistuje přímá indikace v případě, že k přetečení dojde. Místo toho přetékající zásobník prostě přepíše jakoukoli paměť, která se nachází pod alokovaným rozsahem (pod proto, že zásobník na většině architektur roste směrem dolů). Přetečení se dá detekovat umístěním kanárků na zásobník a vývojářské nástroje umožňují sledovat využití zásobníku. Ale pokud je na produkčním systému přetečení vůbec detekováno, bývá to většinou příliš pozdě po dané události a poté, co došlo ke škodám neznámého rozsahu.
Aby toho nebylo málo, velmi důležitá datová struktura – struktura thread_info – je umístěna ve spodní části zásobníku. Takže pokud dojde k přetečení jaderného zásobníku, jako první bude přepsána právě struktura thread_info, která poskytuje přístup téměř ke všemu, co jádro o běžícím procesu ví. Asi netřeba dodávat, že tohle činí přetečení zásobníku pro útočníky o to zajímavějším: je těžké odhadovat, co se bude nacházet v paměti pod zásobníkem, ale vlastnosti struktury thread_info jsou dobře známé.
Snad nikoho nepřekvapí, že jaderní vývojáři velmi tvrdě pracují na tom, aby přetečením zabránili. Podrobně zkoumají (obvykle pomocí automatických proměnných) alokace na zásobníku a rekurze obecně není povolena. Ale překvapení mohou mít mnoho podob, od nedbalé deklarace proměnných po nečekaně hluboko zanořená volání funkcí. K takovým problémům je zvláště náchylný subsystém úložišť, kde se mohou libovolně kupit souborové systémy, technologie úložišť a síťový kód. Tento typ překvapení vedl k rozšíření zásobníku na jádrech architektury x86-64 na 16 KB ve vydání 3.15, jenže zásobníky nelze zvětšovat donekonečna. Protože pro každý proces v systému existuje jeden zásobník, každé zvětšení velikosti se projeví podstatně vícekrát.
Problém s přetékáním zásobníku zřejmě bude ještě nějakou dobu pro vývojáře výzvou, ale jádro by mělo umět reagovat lépe, když už k přetečení dojde. Klíčem k řešení tohoto problému je, jak ukazuje sada patchů pro virtuálně mapované zásobníky Andyho Lutomirského, změna způsobu alokace jaderných zásobníků.
Téměř veškerá paměť, ke které jádro přistupuje přímo, je přístupná skrze adresy v přímo mapovaném rozsahu. Tento rozsah je velkým kusem adresního prostoru, který je mapován do fyzické paměti jednoduše, lineárně, takže v praxi to vypadá, jakoby jádro pracovalo přímo s fyzickými adresami paměti. Na 64bitových systémech se takto mapuje veškerá paměť; naopak 32bitové systémy nedovedou takto mapovat veškerou paměť, která se na současných systémech nachází, takže je třeba to dělat poněkud složitěji.
Linux je ovšem systém s virtuální pamětí, takže jádro používá pro přístup k paměti virtuální adresy i v přímo mapovaných oblastech. Jak už to bývá, jádro rezervuje další rozsah adres pro virtuálně mapovanou paměť; tento rozsah se použije, dojde-li k mapování paměti pomocí vmalloc(), a tak se nazývá „rozsah vmalloc“ (vmalloc range). Alokované oblasti v tomto rozsahu jsou spojovány po stránkách za chodu a nejsou fyzicky souvislé. Tradičně se tato oblast používá k získání relativně velkého kusu paměti, který musí být virtuálně souvislá, ale může být fyzicky rozptýlená.
Neexistuje (téměř! – viz níže) žádný důvod, proč by zásobníky jádra měly být fyzicky souvislé, takže by v zásadě mohly být alokovány jako jednotlivé stránky a mapované do rozsahu vmalloc. Tím by se odstranilo jedno z největších použití (fyzicky souvislých) alokací v jádru, díky čemuž by systém při fragmentované paměti byl robustnější. Také by to umožnilo umístění nepřístupných ochranných stránek kolem alokovaných zásobníků bez zbytečného plýtvání pamětí (protože vše, co je potřeba, je položka v tabulce stránek), což by jádru umožnilo okamžitě detekovat přetečení alokovaného zásobníku. Andyho patch dělá právě toto – alokuje jaderné zásobníky v rozsahu vmalloc. Když už byl u toho, přidal také elegantní zacházení s přetečením: zobrazí se řádná chybová hláška a dojde k zabití příslušného procesu.
Sada patchů sama o sobě je relativně jednoduchá, většina patchů se zabývá nepříjemnými specifiky jednotlivých architektur, což je potřeba, aby patch set správně fungoval. Vypadá to na významné vylepšení jádra, recenze jsou vesměs pozitivní, ačkoliv zůstává několik zásadních, leč nevyřešených problémů.
Jedním z nich je výkon. Podle Andyho se alokováním zásobníku v rozsahu vmalloc prodlouží vytvoření procesu pomocí clone() o 1,5 µs. Některé druhy zátěže jsou mimořádně citlivé na režii spojenou s vytvářením procesů a touto změnou by utrpěly, takže se asi není čemu divit, že na to Linus reagoval slovy, že „tento problém je třeba vyřešit dřív, než dojde k začlenění.“ Andy si myslí, že většina režie by se dala vyřešit zrychlením vmalloc() (který nikdy nebyl pořádně optimalizován na výkon). Linus místo toho navrhl udržovat malou cache, složenou z předem alokovaných zásobníků, pro každý procesor. V každém případě dal jasně najevo, že chce, aby se regrese vyřešila ještě před začleněním.
Další možná režie, kterou se dosud nepodařilo přesně změřit, je nárůst počtu výpadků při překladu. Přímo namapovaná oblast využívá mapování obrovských stránek, takže se celé jádro (všechen kód, data a zásobníky) vejde do jediného záznamu v TLB (translation lookaside buffer). Rozsah vmalloc naopak vytvoří nové okno s využitím mapování jednotlivých stránek. Vzhledem k tomu, že reference na jaderné zásobníky jsou běžné, je možnost TLB miss reálná, pokud se k těmto zásobníkům přistupuje skrze rozsah vmalloc.
Mezi další podstatné detaily patří to, že ačkoliv alokace z rozsahu vmalloc obsahují ochranné stránky, k jejich umístění dochází až po alokaci. Při běžné paměti na haldě dochází právě zde k překryvům. Protože však zásobníky rostou směrem dolů, dojde k překryvu paměti už před alokací. V praxi to znamená, že dokud je ochranná stránka umístěna na začátek rozsahu vmalloc, současný kód zajistí, aby se ochranné stránky nacházely mezi každými dvěma alokacemi, takže by starší stránka měla být právě tam. Ale vzhledem k tomu, že ochranné stránky jsou jedním z hlavních cílů této sady patchů, bude zapotřebí nějakých vylepšení, abychom si mohli být jisti, že se budou nacházet vždy na začátku každého zásobníku.
Paměť mapovaná do rozsahu vmalloc má jedno specifické omezení: nedá se jednoduše použít pro I/O s přímým přístupem k paměti (DMA). To proto, že I/O očekává paměť fyzicky souvislou, a proto, že funkce mapování virtuálních adres na fyzické neočekávají adresy v tomto rozsahu. Dokud se žádný jaderný kód nepokouší provádět DMA ze zásobníku, nemělo by jít o problém. DMA ze zásobníku je problematický také z jiných důvodů, ale ukazuje se, že v jádře se nachází kód, který tak přesto činí. Ten bude potřeba před nasazením patche do praxe opravit.
A konečně, jádra s touto sadou patchů budou schopna detekovat přetečení jaderných zásobníků, ale stále zde zůstává problém se strukturou thread_info, která se nachází vespod každého zásobníku. Překryv, který přepíše pouze tuto strukturu a nikoliv zásobník jako celek, nebude detekován. Řešením je strukturu thread_info zcela odstranit z jaderných zásobníků. Současná sada patchů toto zatím neumí, ale Andy slíbil, že se na tento problém podívá, jakmile patche budou přijaty.
Přijetí můžeme očekávat, jakmile se podaří vyřešit současné problémy. Přidání schopnosti detekovat přetékající zásobníky a nakládat s nimi eliminuje zásadní vektor útoku a učiní z Linuxu bezpečnějším a robustnějším systémem. Na takové změny si těžko stěžovat.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Současný vývojový kernel má označení 4.7-rc7, vydán byl 19. června.
Já vím, že si čtenáři stěžovali, že jsou překlady pozadu, ale realitu byste předbíhat nemuseli. :-) Verze 4.7-rc7 ještě nevyšla, 19.6. vyšla -rc4.
Zásobník se nachází v přímo mapované paměti jádra, takže musí být fyzicky souvislý. Tento požadavek může být problematický sám o sobě, protože jak dochází k fragmentaci paměti, může být nalezení dvou nebo čtyř fyzicky souvislých stránek složité.To je teda navrhovali dost špatně :-/. Resp se to jeví jako pěknej hack, když to při přechodu na vícestránkové stacky neudělali robustně.
V důsledku neexistuje přímá indikace v případě, že k přetečení dojde.Znamenám si, pokud někdy vymyslím CPU architekturu, tak přidám range check registry
.
Paměť mapovaná do rozsahu vmalloc má jedno specifické omezení: nedá se jednoduše použít pro I/O s přímým přístupem k paměti (DMA). To proto, že I/O očekává paměť fyzicky souvislou, a proto, že funkce mapování virtuálních adres na fyzické neočekávají adresy v tomto rozsahu.Jo když byli v Intel tak hloupí (nebo naopak marketingově vychcaní), že při přechodu na PCI neudělali nějakou scatter gather DMA engine jednotku ...
Jo když byli v Intel tak hloupí (nebo naopak marketingově vychcaní), že při přechodu na PCI neudělali nějakou scatter gather DMA engine jednotku ...Ono nejde jen o Intel, ale i o ostatní architektury, na kterých Linux běhá.
(to se tu tuším jednou Ponkrác rozčiloval, že DMA umí každej, ale bez ní to je ta pravá inženýřina). Minimálně to měly Sun workstationy se SPARCem (jedna PCI karta od nich to vyžaduje, bez DMA enginu to jede přes PCI tak maximálně 1MBps). Dokonce i blbej microblaze může mít DMA engine .
7.7.2016 12:44
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
).
Jde o to, že některé PCI zařízení busmaster nemají (není povinný) a tak do nich musíš hezky cpát data byte po bajtu přes CPU.
8.7.2016 23:41
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
9.7.2016 22:42
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Mám dva x86 "počítače" spojené PCI mostem. Ten sice umí na obou stranách bus master, ale jen jako reakci na zápis/čtení z druhé strany.A v cem je problem? Na jedne strane poslu blok dat, na strane druhe prijmu, pres PCI bus-master DMA.
Veškeré přenosy musí tedy obstarávat CPU.Snad jen kontrolovat, vetsina toku by mela jit mimo CPU.
Na SPARCu ale byla speciální jednotka, která umožňovala zahájit přenos z jedné adresy na jinou.Tim mate na mysli konkretne co? Sbus, ktery byl nakonec nahrazen PCI? IMHO, SPARC DMA engine standardne pripojeny na Sbus neumel scatter/gather transfery.
Neříkám, že by to musela být ISA implementace (to fakt ne, omezení na 0-16MB v RAM apod.), ale i na blbé memcpy by se taková jednotka hodila.A proc? Na male bloky dat je optimalizovane memcpy (treba nad AVX2) vetsinou lepsi nez DMA, uz jen proto ze operuje nad cim dale vetsimi CPU cache a ne nad pomalou DDR a nemusite se starat o cache coherence. Velke datove transfery jsou zalezitosti I/O na PCIe se zabudovanym radicem, a pokud nekdo potrebuje kopirovat velke bloky v pameti beze zmeny pres CPU, ma nejspise hloupe navrzenou aplikaci.
A v cem je problem? Na jedne strane poslu blok dat, na strane druhe prijmu, pres PCI bus-master DMA.Ten bridge je jen pasivní překlad z jedné domény do druhé (žádné sdružování do bloků apod.). Procesor neumí vygenerovat přenos bloku dat, ale zapisuje jen slovo po slově. Takže místo třeba 1x 256B bloku se provede 64x 32bit transakcí. Transakce 32bit slova po slově dosáhne tak stěží 2MBps dohromady v obou směrech. S univerzálním DMA enginem by se posílaly bloky bezproblému.
Snad jen kontrolovat, vetsina toku by mela jit mimo CPU.To by byla DMA, když je to memcpy na x86, tak je to prostě kopírovací smyčka, kde to dělá CPU.
Volani po dedikovanem DMA zarizeni ...Tak ten DMA engine by klidně mohl bejt v čipsetu jako PCI device. Vtip je prostě v tom, že jediné zařízení, co neumí blokovej busmaster je CPU (s vyjímkami jako cache linka do RAM, ale to vlastně není PCI). Jj I/OAT, ale to je až v Xeonech, PCI bylo už v posledních 486 (SiS496/7 umí obsáhnout celej 4GB prostor).
Tim mate na mysli konkretne co? Sbus, ktery byl nakonec nahrazen PCI? IMHO, SPARC DMA engine standardne pripojeny na Sbus neumel scatter/gather transfery.Hele tak to přesně nevím, ale ta karta je SunPCI II a měla do toho Sunu přidávat podporu pro Windowsy
. Je to normální PCI 64bit karta a funguje teda i na x86 kompu. Akorát ty přenosy jsou příšerně pomalý, pokud se maj posílat třeba komunikační pakety. Povrchně jsem zkoumal původní SPARC platformu a prej to mělo DMA engine, co prostě mohla říct sem do RAM zkopíruj 64kB dat z tohodle PCI regionu. To, že by to fungovalo i na PCI je pak logický předpoklad, aby ta karta vůbec mohla efektivně komunikovat.
A proc? Na male bloky dat je optimalizovane memcpy (treba nad AVX2) vetsinou lepsi nez DMA, uz jen proto ze operuje nad cim dale vetsimi CPU cache a ne nad pomalou DDR a nemusite se starat o cache coherence.To je pravda, ale neznamená to, že to nejde udělat lépe. Mě teda přišlo, že se třeba pakety kopírujou v kernelu všude možně.
a pokud nekdo potrebuje kopirovat velke bloky v pameti beze zmeny pres CPU, ma nejspise hloupe navrzenou aplikaci.No právě, že s inteligentním DMA přenosem můžeš třeba transponovat matici
(proto furt nadávám na PXA Xscale, protože tam ani nešlo pootočit obraz na LCD o 90 stupňů - leda pixel po pixelu přes CPU).
10.7.2016 15:50
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Ten bridge je jen pasivní překlad z jedné domény do druhé (žádné sdružování do bloků apod.). Procesor neumí vygenerovat přenos bloku dat, ale zapisuje jen slovo po slově. Takže místo třeba 1x 256B bloku se provede 64x 32bit transakcí. Transakce 32bit slova po slově dosáhne tak stěží 2MBps dohromady v obou směrech.Vam stale nedochazi, ze problem je na strane PCI zarizeni, ktere potrebuje prenaset velke bloky dat a pritom podporuje jen 32 bitovy prenos, ktery ma velkou rezii, a implementuje zlomek toho, co je mozne implementovat nad PCI a co zvlada i nejhloupejsi sitova karta za 10 dolaru. Soude podle toho, co popisujete, je lepsi propojit vase PC kabelem pres dve sitove karty a vas PCI bridge odnest do recyklacniho centra.
S univerzálním DMA enginem by se posílaly bloky bezproblému.CPU jadro je velmi univerzalni, flexibilni a plne programovatelny DMA engine a jejich pocet v soucasnych procesorech utesene roste.
Mě teda přišlo, že se třeba pakety kopírujou v kernelu všude možně.A mne prijde, ze se kopirovani snazi omezit.
No právě, že s inteligentním DMA přenosem můžeš třeba transponovat maticiPsal jsem:
Volani po dedikovanem DMA zarizeni je ozivovani konceptu, ktery se moc neosvedcil mimo specialisovane architektury.a transponovat matici behem DMA prenosu je pomerne specializovana vec a opet bych to na PC hodil na AVX, pripadne na GPU. Pouzivam programovatelne DMA enginy na TI platformach jiz deset let, takze tusim co to prinasi v praxi, a proto jsem spise proti tomu, aby se to davalo do univerzalniho PC jako genericky blok. To ze ani Intel neni schopen v kernelu udrzovat dlohodobe plne funkcni podporu I/OAT me obavy jen potvrzuje.
10.7.2016 17:23
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
10.7.2016 17:57
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
10.7.2016 21:29
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Vam stale nedochazi, ze problem je na strane PCI zarizeni, ktere potrebuje prenaset velke bloky dat a pritom podporuje jen 32 bitovy prenos, ktery ma velkou rezii, a implementuje zlomek toho, co je mozne implementovat nad PCI a co zvlada i nejhloupejsi sitova karta za 10 dolaru.Tak já bych taky radši, kdyby měl ten bridge vlastní buffer a busmasteroval si bloky. Ale už to, že existuje (a další verze implementoval dokonce Intel) ukazuje, že má PCI nedostatky.
Soude podle toho, co popisujete, je lepsi propojit vase PC kabelem pres dve sitove karty a vas PCI bridge odnest do recyklacniho centra.Přesně tak, taky to bylo ze začátku o řád rychlejší
. Bohužel ten bridge je velmi rozšířený a je skoro všude.
CPU jadro je velmi univerzalni, flexibilni a plne programovatelny DMA engine a jejich pocet v soucasnych procesorech utesene roste.Bohužel stále ne na x86 desktopu/notebooku
.
A mne prijde, ze se kopirovani snazi omezit.Nedostatečně
.
a transponovat matici behem DMA prenosu je pomerne specializovana vec a opet bych to na PC hodil na AVX, pripadne na GPU.V případě RAM→GPU je AVX plýtvání procesorového času. A GPU s rotací bitmapy je lepší mít rozdělenou na dva modulární HW.
9.7.2016 22:45
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz