Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Ja nemam nic prot live patchingu, pokud ovsem bude deterministicky, coz v soucasnosti neni. Pokud potrebuji provoz 24/7, mam HA...
Ja nemam nic prot live patchingu, pokud ovsem bude deterministicky, coz v soucasnosti neni.
Šlo by to nějak rozvést?
"nelze zarucit, co se stane" zní příliš mlhavě a neurčitě na to, aby takovému tvrzení šlo přikládat nějakou váhu. Má-li vás brát někdo vážně, bude potřeba aspoň naznačit nějaký konkrétní problém, ne jen trousit mlhavé náznaky typu "nev(ěd)í co riskují", "nelze zaručit, co se stane" atd.
A nezapomínejte také na to, že co je v mainline, je hodně odlišné od toho, co se používá ve SLE12 a RHEL7. V podstatě je to tak, že obě implementace vznikly nezávisle na sobě a základní problém (jak se vypořádat s tím, když je nějaký task v nahrazované funkci nebo se do ní může vrátit) řeší každá jinak. Do mainline se pak dostal společný framework, nad kterým by pak v ideálním případě mohl být postaven jak kgraft, tak kpatch. V každém případě lze ale těžko na základě diskuse o upstreamovém kódu šmahem odmítnout live patching, který se nabízí zákazníkům.
Promiňte, ale tohle je pořád stejné mlžení, náznaky, strašení, ale žádný konkrétní problém.
Je pravda, live patching kód, který je v současné době v mainline, neřeší konzistenci. Ale to neznamená, že ji neřeší live patching, který se nabízí zákazníkům SLE nebo RHEL. Stejně tak je pravda, že ne pro každý fix lze vytvořit live patch. To ale neznamená, že se v takovém případě zákazníkům dá nespolehlivý nebo dokonce nefunkční live patch.
Takže vás prosím, abyste buď popsal konkrétní problém a konkrétní riziko, nebo přestal trousit mlhavé a neurčité poznámky a silácké výkřiky o "nesmyslu", o tom, jak je něco "o hubu" a o tom, že zákazníci "nev(ěd)í co riskují".
ale dokud nebude platit ze starejadro+live patching = starejadro->reboot->novejadro, tak to je proste o hubu
To nebude platit nikdy. To totiž v úplnosti neplatí ani bez patchování, tj. nabootujete-li dvakrát stejné jádro, nedostanete v paměti úplně totéž.
Navic live patching resi problem, ktery se da vyresit mnohem elegantneji (HA)
Řeší podobný problém, ale ne úplně stejný. Ne všechno lze řešit pomocí HA nástrojů a ani ty nejsou úplně bez problémů.
Ted se divam, ze od RHEL 7.2 je kpatch podporovan pro Premium SLA, je kolem toho dost vagni popis, takze otazka je, jestli se to nenabizi, jenom aby se to nabizelo.
Pokud to v té nabídce je, tak to tam je. "Premium SLA" budou zákazníci s většími kontrakty, takže tam se stejně přesné podmínky budou domlouvat individuálně. Co se SLE týká, existují zcela reální zákazníci a dostávají zcela reálné patche, takže to v žádném případě není "jen aby se to nabízelo".
(I kdyz doufam, ze jednou bude, protoze to je fakt vec!)
Konkretni riziko jsem popsal
Nepopsal. Nevidím tu popsaný žádný konkrétní scénář, při kterém dojde k problému, nevidím aspoň základní popis toho problému.
stejne jako ji popsali vyvojari jadra, to uz jsem uvedl driv.
Kdybyste uvedl odkaz na konkrétní e-mail, mohli bychom se bavit o tom, co je v něm. Mohli bychom se bavit o tom, jestli se ten problém týká jen toho, co je v mainline, nebo jestli se vztahuje i na kgraft/kpatch a jestli náhodou nepopisuje zrovna ten typ patche, o kterém se ví, že ho v současné implementaci udělat nejde. Takhle se není o čem bavit, pořád z vás padá jen neurčité a mlhavé strašení.
nemam rad reci obchodniku, ze kdyz to nabizi, tak to musi prece fungovat, a vy prece nedelate v sales, tak nechapu, proc se bavit na tehle urovni
Nic takového jsem netvrdil. Vy jste začal s tím, jestli se to nenabízí jen tak na oko, já reagoval, že existují reální zákazníci a dostávají reálné patche.
Live patching v soucasne podobe na soucasnem jadre je nederministicky a nezarucuje mi, ze jadro bude funkcni stejne tak, jako kdyz nabootuju nove ciste jadro. To je fakt a reci o tom, co mam v pameti po dvou rebootech, jsou k nicemu.
Nejsou k ničemu. Tak, jak jste to napsal, to prostě neplatí ani bez patche, takže se nedá očekávat, že to tak bude s patchem. Konkrétní implementace - a to je to, co se nabízí zákazníkům, ne základní framework v mainline - konzistenci řeší.
na druhou stranu nebudu tvrdit, ze to je svaty gral, co zaruci 100% dostupnost systemu, ktery bude zaroven 100% opatchovany, tak to totiz zakaznici chapou a pak se jim musi vysvetlit
Zákazníci vědí - a je jim to jasně vysvětleno - že live patche se poskytují pouze pro kritické bezpečnostní chyby a že ani pro ty to v konkrétních případech nemusí být technicky realizovatelné.
Jinak, zkuste se trochu zamyslet nad celou vetou, na kterou jsem reagoval a pochopite, proc je to totalni nesmysl.
Raději se vy pokuste zamyslet nad tím, co jste napsal. Nejdřív jste kernel live patching jako takový označil za "nesmysl", poté jste dokonce tvrdil, že zákazníci "nev(ěd)í co riskují". Ale napsat konkrétně, co vlastně podle vás riskují, opakovaně odmítáte.
Live patching není žádný svatý grál řešící všechny problémy světa. Je to služba, která řeší určitý problém (poptávka tu byla dlouho před nabídkou) v určitých situacích. Není to kouzelný proutek, ale stejně tak to není "nesmysl" ani něco, co z principu nemůže fungovat.
a pak se jim musi vysvetlit, ze stejne jako neopatchuju openssl/glibc/apache bez restartu, tak ani jadro ne
Kernel live patching na SLE reálně funguje, a to už i v produkci. To není navoskovaný papír, to je reálný produkční provoz. User space live patching se nenabízí, ale i tady existuje poptávka a řeší se, zda a za jakých podmínek by to bylo možné realizovat.
Řešení Live Patching pro SUSE Linux Enterprise Server umožní podnikovým uživatelům systému Linux aktualizovat operační systém, aniž by jej museli restartovat.
Nechapu, proc se tohohle nesmyslu porad nekdo drzi...
Tak jestli SUSE dokaze opatchovat operacni system bez restartu (o kritickych bezpecnostnich chybach se nic nepise), tak to se omlouvam.
No ja myslim, ze uz se v tom nebudem hrabat, protoze se stejne nikam nedostanem (a to rikam s respektem k vam), tak preji pekny den a zase nekdy
Tak jestli SUSE dokaze opatchovat operacni system bez restartu (o kritickych bezpecnostnich chybach se nic nepise), tak to se omlouvam.
Pokud se chcete mermomocí hádat o slovíčka, tak musím konstatovat, že ta citovaná věta je pravdivá; sice se tam nepíše nic o kritických bezpečnostních chybách (což je ovšem jen naše volba), ale stejně tak se tam nepíše nic o tom, že lze takto provádět všechny aktualizace.
No ja myslim, ze uz se v tom nebudem hrabat, protoze se stejne nikam nedostanem
Pokud popíšete konkrétní problém (ať už přímo nebo odkazem), můžeme se pobavit o tom, jestli je pro kgraft relevantní (sice nedělám na kgraftu, ale základní principy znám a kdyby bylo nejhůř, člověk, který na něm v současnosti pracuje nejvíc, sedí ve stejné místnosti). Bez toho ale ta diskuse opravdu nemá smysl.
Tiskni
Sdílej: