Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Aktuální verze jádra je 2.6.18.1, vydaná 16. října. Obsahuje docela dost oprav problémů, které byly odhaleny v 2.6.18.
Byla vydána také verze 2.6.17.14 s menším počtem oprav. Bylo to pravděpodobně poslední jádro řady 2.6.17.x.
Adrian Bunk vydal s několika novými opravami 2.6.16.30-rc1.
Aktuální předverze je 2.6.19-rc2, vydaná 13. října. Kromě několika oprav je tam i velká změna prototypu zpracovávačů přerušení a první začleněná verze vývojového souborového systému ext4. Podrobnosti v dlouhém changelogu.
Od vydání -rc2 bylo do hlavního git repozitáře zařazeno dalších asi 250 patchů - téměř všechno opravy.
Aktuální verze -mm stromu je 2.6.19-rc2-mm1. Mezi nedávné změny patří obecná podpora zařízení s podsvícením a aktualizace FUSE. Byla přidána nová funkce round_jiffies(), která zaokrouhluje časovou hodnotu na další celou vteřinu. Účelem je docílit sjednocení opakujících se časovačů, což sníží počet potřebných přerušení časovačů.
No ne, kdo by si pomyslel, že natažení 6 megabajtů neznámého kódu do jádra a X serveru nemusí být dobrý nápad? Skoro jako by spouštění kódu pod rootem mohlo znamenat nějaké bezpečnostní riziko nebo co.
Funkce pci_set_mwi() umožňuje na PCI sběrnici režim MWI (memory write and invalidate = zápis do paměti a zneplatnění). Pokud zařízení na druhém konci umí pracovat s MWI, dosáhne se určité optimalizace. MWI režim však nemusí být možné zapnout, i když to ovladač vyžaduje; nemusel by ho totiž podporovat hardware sběrnice. Pokud není MWI nastaven, nebývá to obyčejně problém; jen je vše trochu pomalejší. Volající ovladač by však přesto mohl chtít vědět, jestli bylo volání úspěšné, takže Matthew Wilcox funkci nedávno opravil, aby při selhání vracela -EINVAL.
Ukázalo se, že tohle je jeden ze záškodnických patchů, které v poslední těžce zkoušely Vaio Andrew Mortona. Nějaký kód kontroloval výsledek pci_set_mwi(); jakmile funkce začala doopravdy vracet výsledek operace, volající kód selhal. Ale, jak bylo řečeno výše, nenastavený režim MWI skoro nikdy nepředstavuje problém. V reakci na tento sled událostí Alan Cox prohlásil:
Základní chybou je, že někdo označil pci_set_mwi jako must-check [kontrola nutná], což je problém pro většinu ovladačů, které tu funkci používají. Pokud odstraníte "must check", bude po problémech (a zmizí i tisíce dalších falešných varování).
Dá se předpokládat, že Alan má tedy na svědomí například tento kód z drivers/ata/pata_cs5530.c:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
compiler_warning_pointless_fix = pci_set_mwi(cs5530_0);
__must_check využívá gcc atribut warn_unused_result; v hlavním jádře to bylo poprvé využito ve verzi 2.6.8. Je-li funkce označena jako __must_check, kompilátor vypíše výrazné varování vždy, když je funkce volána, aniž by byl zpracován její návratový kód.
Využívání __must_check je jedním z kroků na dlouhé cestě k automatickému odhalování potenciálních chyb. Je to určeno pro funkce, jejichž návratové hodnoty skutečně vyžadují kontrolu - dobrým příkladem je copy_from_user(). Pokud tato funkce selže a volající kód si toho nevšimne, bude pokračovat s více méně náhodnými daty. Podobné potíže se objevují v uživatelském prostoru; viz nedávné bezpečnostní problémy vzniklé kvůli tomu, že si aplikace s vyššími právy nekontrolovaly výsledek volání setuid(). V některých případech je ignorování návratové hodnoty skutečně neomluvitelné a __must_check je dobrý způsob, jak nesprávné použití funkce objevit dříve, než to způsobí opravdové problémy.
V posledních jádrech však počet __must_check funkcí poněkud narostl: je to většina sysfs, PCI, kobject a ovladačového API. V některých případech (jako u pci_set_mwi()) je to i u funkcí, jejichž návratové hodnoty volající kód nezajímají. Má to za následek podloudné berličky v kódu, nová varování a skutečnou chybu, při které kód, jež by nemusel selhat, selže v reakci na chybový návratový kód.
Přesto není podle Andrew Mortona dobré ignorovat chybovou návratovou hodnotu z funkce jako pci_set_mwi():
Vy, coby autoři ovladačů, _nevíte_, co v současné době pci_set_mwi() dělá, a co dělá na každé z platforem, nebo co bude dělat v budoucnu. Pokud jako autor ovladače zkoušíte hádat, co se v rámci pci_set_mwi() děje, překračujete hranici vrstvy. Třeba byl bridge za běhu odstraněn. Nebo pokus o nastavení MWI způsobil synchronní PCI chybu. Jako příklad vám mohou posloužit různé implementace pci_ops.read(), které mohou selhat z nejrůznějších důvodů.
Diskuze se nakonec stočila k tomu, co je patrně hlavní otázkou: jak by měla být jaderná API navržena, aby správně vracela návratové informace? Jeden z návrhů říkal, že by pci_set_mwi() měla být upravena tak, aby vracela buď nulu nebo jedničku - podle toho, jestli je provoz v MWI režimu možný nebo ne. Záporný návratový kód by měl být vracen pouze pokud dojde k nějaké drastické chybě na PCI sběrnici. Zatím nebyl začleněn patch, který by to implementoval, ale zdá se pravděpodobné, že tento konkrétní problém bude řešen touto cestou.
Širší diskuze o tom, jak by měly být zpracovávány chyby, však asi teprve začíná. Během času se ustálilo množství de-facto konvencí pro jaderná API, ale zpracování chyb žádná pravidla nemá. Andrew by tedy rád mluvil o tom, jak se chovat k různým druhům chyb. Konkrétně navrhuje pravidlo, které říká, že záporný chybový kód nesmí být nikdy ignorován. Případy, ve kterých takový výsledek není relevantní (čehož je příkladem pci_set_mwi()), jsou známkou, že je nutné API navrhnout znovu.
Jaderná rozhraní se tedy patrně začnou měnit tak, aby nebyly chybové kódy vraceny v situacích, kdy je vše v pořádku. Pokračovat bude i boj s množstvím varování, ve kterých se ztrácejí skutečné chyby. S trochou štěstí to povede k bezpečnějším rozhraním a robustnějšímu jádru.
Systémové volání sysctl() mělo těžký život. Začalo jako nápad importovaný z BSD; umožňuje uživatelskému procesu upravovat různé parametry jádra pomocí sady číselných indexů. Lidi však brzy přišli na to, že textové rozhraní založené na souborovém systému (/proc/sys) se používá mnohem snadněji. Hierarchii /proc/sys lze upravit z prostředí shellu a ovládat skripty - nikdo se nemusí starat o sysctl čísla. Uživatelů sysctl() je tedy velmi málo a už dlouho je považováno za zastaralé. Novější jádra při použití sysctl() zobrazí varovnou hlášku.
Jádra 2.6.19-rc to berou ještě o krok dál: ve většině konfigurací sysctl() úplně zmizí. Pouze pokud je nastavena volba "embedded", je možné zapnout sysctl(). To vše je v souladu s plánem na odstranění, podle kterého by mělo být sysctl() zrušeno v lednu 2007.
Jenže sysctl() je součástí uživatelského API, které by nemělo být nikdy měněno. Odstranění této funkce by porušilo často opakovaný slib, že toto rozhraní bude stabilní. Někteří vývojáři si na změnu API začali stěžovat. Ozvaly se hlasy volající po stáhnutí plánů na odstranění a navrácení sysctl() do běžných konfigurací. Alan Cox k tomu řekl: Přidali jsme to, podporovali jsme to, tak to tam máme. Do dokumentace jen strčíme zmínku "používejte raději /proc".
Už jsou k dispozici patche, které sysctl() obnovují, i když žádný nebyl zatím začleněn. Zdá se, že nepanuje shoda o tom, jestli by odstranění sysctl() skutečně uživatelským aplikacím způsobilo problémy. Starší C knihovny to používají, ale tyto knihovny se při selhání pokusu o využití sysctl() zachovají správně a aplikace fungují normálně. Linus požádal o příklad aplikace, která skutečně přestane bez sysctl() fungovat; zatím se ale neobjevil žádný. Rozhraní, která skutečné systémy nepoužívají, odstraněna být mohou, takže pokud někdo brzy nepřijde s opravdovým problémem, sysctl() bude pravděpodobně pokračovat v nastoupené cestě z jádra.
Následující obsah je © KernelTrap
16. říj, originál
Nedávná zpráva od Rapid7 oznamuje: Linuxový binární ovladač grafických karet nVIDIA obsahuje chybu, kvůli které může dojít k přetečení bufferu, což útočníkovi umožní spouštět libovolný kód jako root. Chybu lze zneužít jak lokálně, tak vzdáleně (přes vzdáleného X klienta nebo když X klient navštíví útočníkem upravenou webovou stránku). K této zprávě je jako důkaz přiložen funkční "root exploit" [exploit = kód schopný zneužít chybu]. Zpráva dále sděluje, že binární ovladače pro FreeBSD a Solaris jsou pravděpodobně stejně zranitelné, a varuje: Jsme toho názoru, že binární ovladače nVIDIA jsou i nadále nepřijatelným bezpečnostním rizikem, což podporuje velký počet reprodukovatelných neopravených pádů, které byly hlášeny ve veřejných fórech a databázích chyb.
Chad Loder z Rapid7 vysvětlil, že nVIDIA už o chybě nějakou dobu ví: Odkaz v naší zprávě ukazuje na nejstarší diskuzní vlákno, ve kterém zaměstnanec nVIDIA veřejně chybu přiznává. I když je to už z roku 2004, je pravděpodobné, že existovala ještě dříve. Ohledně veřejného oznámení exploitu Chad řekl: Očekávám (nebo doufám), že nVIDIA chybu v binárních ovladačích rychle opraví. Nevím nic o jejich vývojovém procesu nebo o tom, kde na jejich žebříčku priorit stojí linuxové ovladače. Vypadá to ale, že většině uživatelů Linuxu vůbec nevadí chyby v kusech binárního kódu od výrobců hardwaru, takže nVIDIA nemá příliš důvod své postupy měnit.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Unauditable je česky neznámý?Není. Ale vzhledem ke kontextu mi to přišlo jako vhodný překlad. Nechtělo se mi do toho svižného citátu vkládat jazykolamy jako "nezkontrolovatelný", "neprozkoumatelný" nebo "neprověřitelný".
Podobně bych přeložil "memory write and invalidate" spíš jako "zápis do paměti a zneplatnění" než "zápis do paměti a zrušení".
6.11.2006 22:31
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
