Na konferenci LinuxDays 2025 byl oficiálně představen nový router Turris Omnia NG.
Přímý přenos (YouTube) z konference LinuxDays 2025, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
V únoru loňského roku Úřad pro ochranu osobních údajů pravomocně uložil společnosti Avast Software pokutu 351 mil. Kč za porušení GDPR. Městský soud v Praze tuto pokutu na úterním jednání zrušil. Potvrdil ale, že společnost Avast porušila zákon, když skrze svůj zdarma dostupný antivirový program sledovala, které weby jeho uživatelé navštěvují, a tyto informace předávala dceřiné společnosti Jumpshot. Úřad pro ochranu osobních údajů
… více »Google Chrome 141 byl prohlášen za stabilní. Nejnovější stabilní verze 141.0.7390.54 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Za nejvážnější z nich (Heap buffer overflow in WebGPU) bylo vyplaceno 25 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
eDoklady mají kvůli vysoké zátěži technické potíže. Ministerstvo vnitra doporučuje vzít si sebou klasický občanský průkaz nebo pas.
Novým prezidentem Free Software Foundation (FSF) se stal Ian Kelling.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za září (YouTube).
Vyšla kniha Počítačové programy a autorské právo. Podle internetových stránek nakladatelství je v knize "Významný prostor věnován otevřenému a svobodnému softwaru, jeho licencím, důsledkům jejich porušení a rizikům „nakažení“ proprietárního kódu režimem open source."
Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
/boot
). Nedávno jsem si do stanice koupil NVMe tabletku a moje idea je přemigrovat sistém. Konfigurace cílové migrace: Plně zašifrovaný UEFI boot z NVMe s tím, že boot bude UEFI ->následně Grub2 který bootne btrfs raid 1 mezi oddíly na NVMe tabletce a SSD disku. Přemýšlím o cestách k cíli.Řešení dotazu:
Taky kernel + initramdisk může být plně šifrovaný (protože GRUB podporuje LUKS). Jediný povinně nešifrovaný oddíl je FAT32 UEFI oddíl, na kterém pak stačí mít pouze moduly GRUBu a jinak nic.
Legacy boot má spoustu nevýhod a (negativních) důsledků, které sahají daleko za pouhý způsob hledání bootovacího média. Takže něco takového bych ani náhodou, ba ani omylem nedělal.
Řekl bych, že web se o tom už rozpovídal víc než dost, takže nemusím já.
Všeho všudy zmíním jako kuriozitu, že dokonce i Snowdenova oblíbená instituce se o tom rozpovídala. Tak kdoví, třeba má v tom UEFI tajný univerzální backdoor. (Který by ovšem bylo snazší dostat do nějakého starého BIOSu, takže to asi nebude ono.)
Masakr!
encfs
za něco svého. Já šifruji hlavně kvůli tomu, aby vyhozený/reklamovaný/odložený/kdovíjaký disk neobsahoval citlivá data – beru to tak, že kdyby měl někdo přístup k mému počítači, tak si s ním může dělat cokoliv – HW keyloggeru, který se dá celkem snadno sehnat, Secure Bootem nezabráním.
encfs
nepoužívám a nikdy jsem ho ještě nepoužil. Z FUSE mám pořád takový pocit že to kolečko jádro-userspace-jádro-userspace-… je moc dlouhé. Proti FUSE jako takovému nic nemám, ale pro každodenní používání mi nepřipadá vhodný.
grub-mkimage(1)
). Funguje to podobně jako initrd vestavěný do jádra – předáte tomu skriptu obraz disku (memdisk) nebo konfigurační soubor a vygeneruje bootovatelný obraz GRUBu. Pro Leagcy BIOS tam je velikostní limit. Bylo to něco kolem 32 kiB.
Bohužel ne. Tady má předřečník tentokrát pravdu, pokud jde o výkon.
Vůbec nejde o rychlost dešifrování kernelu. To je celkem „okamžité“, protože je to celkem běžná symetrická šifra, která se klidně přečte i bez HW akcelerace. (A ano, GRUB (zatím) nepoužívá AES-NI.)
Jde o PBKDF (Password-Based Key Derivation Function). Ta je naschvál pomalá. Většinou se totiž počítají cca statisíce (někdy miliony) hashovacích iterací po nějakou předem stanovenou dobu (implicitně 2 sekundy, pokud se nepletu), než se dojde od člověkem čitelného hesla k LUKS klíči od slotu (který potom následně odemyká master klíč).
Cílem je, aby slabá hesla neznamenala nutně slabé klíče ve slotech. Nevýhodou je, že samotný výpočet PBKDF pak může být klidně časově náročnější než čtení mnoha set MB kernelu + initramdisku.
No a problém je, že když s AES-NI (nebo jinou akcelerací) ty statisíce iterací PBKDF proběhnou (dejme tomu) za dvě sekundy (nebo co si nastavíš v cryptsetup luksAddKey
/ cryptsetup luksFormat
), tak bez HW akcelerace (tedy v GRUBu) bude tentýž výpočet PBKDF a otevření slotu trvat ultra-hyper-dlouho.
Moje zkušenost na skoro dnešním HW (8. generace notebookových procesorů Intel) je, že 2-sekundová PBKDF bude v GRUBu trvat kolem 15 sekund. To je dlouho, ve srovnání s tím, co se očekává od bootu z SSD.
Na starším hardware (4. generace notebookových procesorů Intel) jsem musel ten čas pro PBKDF snížit (u všech používaných slotů; jinak to nemá ten očekávaný efekt) na 500 milisekund, což byla kdysi dávno původní implicitní hodnota. Jinak se totiž v GRUBu stalo, že GRUB dosáhl nějakého svého interního timeoutu (který se nastaví nevímjak; na to jsem nepřišel) a tvrdil, že nemůže odemknout žádný slot, i když měl platné heslo.
Takže tady souhlasím s výhradami ohledně výkonu: Dokud GRUB nebude umět AES-NI (neřkuli vícevláknovost, která je hlavní feature u LUKS2 a PBKDF2), bude tohle kámen úrazu. Na desktopovém hardwaru není co řešit. Nicméně na notebooku, hlavně když bootuje v úsporném režimu na baterii, to může být problém.
nevim co myslis to migraci z klasickeho boot na systemd, pokud init tak to asi s diskem nesouvisi, pokud neco kolem zavadece, tak sicherboot pouziva systemd-boot, kdy sicherboot je v podstate "jen" sada skriptu co ti pripravej vlastni klice, pripravej polozku boot menu pri instalaci/aktualizaci jadra/initramfs s vygenerovanou a podepsanou tvejma klicema efi binarkou obsahujici kernel+initramfs...myslím tím tohle. System je Arch a initramfs stavím podle hooků v této tabulce ve sloupečku "busybox init". Jak jsem psal je to vlastně mnohaletá konfigurace přepisovaná s jednoho systému na druhý. Nicméně pokud chci z initramfs současně otevřít více než jeden device potřebuji přejít z hooku
encrypt
na sd-encrypt
(to je potřeba abych se dvou device odemkl dva zašifrované oddíly a z nich udělal btrfs RAID 1 a tím pádem je třeba změnit celé generování initramfs a samozřejmě potřebuji to udělat "správně" abych si nenaběhl do situace, kdy mi systém nenajede a mám v něm jen zašifrované disky. (Ano, hlavičky i kliče mám jinde bezpečně uloženy, ale byla by to otrava.)
Navíc sicherboot pracuje s jinak nazvaným initramfs než pracuje Arch, takže pro jeho použití budou třeba ještě další změny. Ta situace, kterou popisuje Andrej, tedy mít v /efi podepsaný Grub, který odemkne disk, hodí Grub menu, po grub menu natáhne jádro a initramfs ze zašifrovaného /boot, a ze zapečeného kliče v initramfs si jádro odemkne disk ještě jednou a jede dál, mi připadá jako přímočará a jediná nevýhoda je pomalejší odemykání, díky tomu že grub nepoužije HW akceleraci.
To je sice všechno pravda, ale pak zase nemůžu mít ultra-tajný kernel + initramdisk, protože je "jenom" podepsaný a každý se na něj může podívat. Všechno má svá pro a proti.
Že současná podpora LUKS v GRUBu potřebuje reimplementaci, to je celkem jasné. PBKDF2 se tam prakticky nedá vypočítat, takže i když GRUB teoreticky LUKS2 podporuje, tohle omezení zatím nepřekonal.
Všechno dohromady (Sicherboot + rychlé otevirání LUKS + tajný kernel) by se asi dalo zařídit pomocí Sicherboot + kexec(), ale konfigurace by byla značný voser, pokud na to není nějaký hotový toolchain.
Tiskni
Sdílej: