Píseň k OpenBSD 5.5 a problém roku 2038

OpenBSD 5.5 vyjde 1. května. Oficiální píseň je už ale k dispozici. Nejnovější hudební hit z produkce OpenBSD je věnován problému roku 2038: Řekněte mi doktore, jaký bude rok, 1901 nebo 2038? OpenBSD 5.5 přijde s 64bitovým time_t na všech platformách. Píseň s názvem Wrap in Time lze stáhnout ve formátech MP3 a OGG.

16.4.2014 10:11 | Ladislav Hagara | Komunita

Komentáře

[Petr Tomášek]

Trapné

[Mti.]

Copak? "Prvni" se uz nenosi? Trapne je vydani verze, uprava time_t nebo jen kdyz nikdo nereaguje, tak vyvijis cinnost?

[Petr Tomášek]

Trapné je skládat písně na operační systém (jakékoliv písně na jakýkoliv OS).

time_t ať si upravjí, jak se jim zlíbí: pokud jim to nic nerozbije, tak proč ne...

[mankind_boost]

Proc je to trapne? O tom prece rozhodne konsenzus verejnosti, ne nejakej tomas, co si mysli, ze je pupek sveta.

[Rob0d]

A společnost je jako co za entitu, pupkáči?

[mankind_boost]

Společnost je soubor většího množství lidí, pupkáči.

[Rob0d]

No, alespoň ti to docvaklo

[ES]

Super Trapnej je jen nejakej Petr Tomášek

[Punny]

alespon to nepise jako anonym ;)

[2X4B-523P]

pravděpodobně jako pseudonym eš

[mankind_boost]

Blbec.

[Metla]

Hagara odložil všechny zábrany, stala se z něj bulvární špína první kategorie

[snajpa]

Jeste mu nadavej, ze tu na tom mrtvym portale aspon nekdo tvori obsah...

[David Jaša]

+1

I ty blogy už umřely a diskuse jsou přetrollené.

[Prcek]

Back in time .

[PanZvedavy]

je v planu i nejaka pisen k openSSL? Hadam neco z apokalypticke death-metal produkce by odpovidalo...

[x]

OpenSSL ale nedela tym okolo OpenBSD ;) Ale hromada oslu co v produktu na kterem zavisi tak 2/3 Internetu pouziva speky jako aktualni cas desktopu pro PRNG, eventy z win32 GUI plochy Nebo nechava uvnitr kod pro VMS, OS/2 a Jine siroce pouzivane platform ci neschopnost dat do kodu fix stary 2,5 roku o velikosti jednoho radku atd. atd.

[PanZvedavy]

vím, jen rýpu :)

[d.c.]

A v tomto pripade opravdu nepravem, protoze se *presto* lide z OpenBSD rozhodli, ze budou OpenSSL cistit. Zda se, ze nikdo jiny to neudela :)

[Andrej]

Zoufalé. Kdyby raději přišli s kernelem bez Giant Locku. Na 64-bitový time_t je čas, zatímco kernel s Giant Lockem do 21. století nepatří. Totéž platí o naprosto zastaralém zabezpečení.

[x]

Ono to SMP praci zvlada pomerne dost dobre, ze treba firewall vyuzije jedno CPU a I presto zvlada to na co jinde potrebuji hromadu CPU je na zamysleni v tech jinych projektech.

No a opet nekdo prisel s tou starou usmevnou pohadkou jak jedine ACL vsechno spasi :)

[snajpa]

Jsou lidi, co v zivote poradnej produkcni system nevideli, ale chytry delat budou, no :)

[x]

To byla reakce na koho vlastne? Ja jen, ze denne vidim HP-UX, Solaris, AIX, Linux (jeste se najdou i True64 a podobne), ale ACL ne a vyhyba se tomu jako cert krizi. Kdo neumi vyuzit tradicni Unix prava ve spolupraci s sudo a centralni spravou konfiguraci jako napr. Puppet a pouzitim mozku a ma dojem, ze komplikovanejsi ACL ho zachrani by mel obor radeji urychlene opustit a jit se venovat treba vareni nebo necemu podobnemu na co bude stacit.

OpenBSD's security model is more about -- as I phrase it -- keeping the bastards out, not controlling them (or hoping to control them) after they are in. Making life difficult for attackers once they get into your system is usually not going to be overly productive, and usually makes administration of the system much more difficult, which often creates NEW security problems of their own. While people like to talk about "Defense in depth" -- and it is not a bad idea -- your best goal is to keep the bastards on the outside of your systems, as once they are in, they can utilize anything you don't have perfectly bolted down to accomplish their goals (and yes, that statement puts me opposite a lot of people making a lot of money chasing down bad guys AFTER they inflitrate systems).

In the Real World: First thing most people do on an SElinux system is disable SELinux. At that point, all the RBAC "features" are now just pure glossy advertising -- worthless. For fear of breaking things, the Linux people have chosen to put a big on-off switch on SELinux...and so given a choice between fixing applications and turning off the switch...people just turn off the switch. ANY claimed benefits of SELinux are ONLY there if it is enabled and used properly.

REAL security is not a list of features, even if used.

The OS is just the tip of the security iceberg...or maybe more accurately, the base of it. You don't typically run an OS to run an OS. You run the OS to run applications, and if those applications are poorly written or poorly designed, there are limits to how much (if at all) the OS can help. The best OpenBSD can do is give you a good starting foundation.

Par reakci na uvadeny "odborny" rozbor vedouci k nutnosti ACL v systemu:

Sometimes the "add-on" security enhancements directly weaken system security

ACL, SELinux

velmi trefne

[Andrej]

In the Real World: First thing most people do on an SElinux system is disable SELinux.

Tohle je nějaká fikce. Nikdy, ani jednou a ani omylem mě nenapadlo vypnout SELinux. Proč bych to dělal? To by pak opravdu zabezpečení spadlo skoro až na úroveň OpenBSD. Pokud někdo vypne SELinux, dobře mu tak.

Je vtipné, jak se advokáti OpenBSD zoufale snaží obhájit absenci klíčové funkcionality, která v moderním systému prostě má být, v ostatních BSD variantách většinou je a pouze OpenBSD ji ze zásady nemá. Nejhorší případ je ovšem ten Giant Lock. Je úplně jedno, že to tu a tam funguje dobře i s Giant Lockem. Na router s několika 10 Gb/s síťovkami to zkrátka nemusí stačit, přestože každý jiný systém s rozumným (tj. ne tak extrémně blokujícím) kernelem by totéž zvládl v pohodě.

Ono to SMP praci zvlada pomerne dost dobre, ze treba firewall vyuzije jedno CPU a I presto zvlada to na co jinde potrebuji hromadu CPU je na zamysleni v tech jinych projektech.

Tohle by chtělo odkaz na konkrétní benchmark, který to dokazuje, nebo zkrátka nějaké rozumné podklady pro taková tvrzení. SMP práci zvládá OpenBSD „dobře“ pouze v userspace. Jakmile dojde na cokoliv, co by měl dělat kernel, například složitější routování s fitrováním a s několika sítovými kartami, pokročilé souborové systémy (které OpenBSD nemá), použitelnou virtualizaci (kterou OpenBSD nemá) nebo softwarový RAID (který OpenBSD téměř nemá), v podstatě všechny ostatní systémy (Linux, FreeBSD, Illumos/OpenIndiana) natrhnou OpenBSD prdel už jen tím, že příslušnou funkcionalitu zkrátka mají, pokud ne přímo výkonem. Ovšem ani u toho výkonu bych si nebyl tak jistý, že má OpenBSD navrch a že je důvodem k zamyšlení pro ostatní projekty. Ještě jsem neviděl benchmark, ve kterém by OpenBSD porazilo Linux, ať už na jednoprocesoru nebo na SMP.

[trekker.dk]

Nikdy, ani jednou a ani omylem mě nenapadlo vypnout SELinux.

Co napadlo a nenapadlo tebe není úplně relevantní v tvrzení o "most people"

[pta]

Misto tech irelevantnich plku co ma nebo nema mit "moderni system" dejte odkaz, ktery doklada tvrzeni ze

Na router s několika 10 Gb/s síťovkami to zkrátka nemusí stačit, přestože každý jiný systém s rozumným (tj. ne tak extrémně blokujícím) kernelem by totéž zvládl v pohodě.

. U klientu bezi Cisca i vlastni routery nad OpenBSD a nezaznamenali jsme zatim zadne vykonnostni problemy ani pri zatezovych testech. Na extra vytizenych uzlech jsou Junpery, ale ten rozdil je v jednotkach procent.

[x]

Ale jen ho nech, kdo vi, tak vi co to dokaze. Kdo ne tak se ohani nedostatkem benchmarku, prezentacemi o vse spasitelnem ACL a podobne.

[Andrej]

Jasně, kdo má někde na půdě nebo ve sklepě starý jednoprocesor, ten asi ví, co „to“ dokáže.

[Andrej]

Je obrovský rozdíl v tom, co stačí pro dané konkrétní nasazení a čeho lze v nejlepším případě na daném hardwaru dosáhnout. Mícháte tu nějak podivně obojí dohromady.

Jasně, údajně jste nezaznamenali výkonnostní problémy při nějakých blíže nedefinovaných zátěžových testech. A co z toho vyplývá? Řekl bych, že vůbec nic. Kdyby například výstupem toho zátěžového testu byl maximální dosažený throughput a OpenBSD by na stejném hardwaru dosáhlo výsledků srovnatelných s Linuxem, pak by celé tvrzení bylo relevantní pro tuto diskusi. Takhle to ale nedává smysl. Říkáte, že nějakému klientovi někdy někde stačilo OpenBSD. Vůbec neříkáte, jak jste síť testovali, jaký měla throughput, jestli se opravdu podařilo využít maximální dosažitelný bandwidth a tak dále.

Upřímně řečeno, jedna věc je jasná: Giant Lock vždy prohraje. Že OpenBSD někdy jednou někomu stačilo, tomu rád věřím, ale jakéhokoliv moderního hardware je pro něj škoda. Doba jednoprocesorů už je pryč.

[x]

Příloha:

• Netflix_BSD.jpg (91890 bytů)

No evidetne jsi se zatim asi moc nepotkal s opravdu velkym prostredim kde treba komercni monitorovaci produkt nefunguje spravne s SELinux a takovych prikladu je v praxi spousta. Jiste, je to chyba vendora, ale zkus to vysvetlovat tem klaunum v obleku co se ohani Powerpointem a rozhoduji. A SELinux se casto vypina i kvuli tomu, ze sam zpusobuje problemy, proti kterym ma chranit, ale to by jsi taky vedel pouzivat to v necem opravdu velkem.

Co to je pokrocily souborovy system? FFS1 i FFS2 jsou v pohode i na velke disky, prace s nima je bezproblemova, filesystem je stabilni a neztraci data (o coz by melo jit v prve rade). BTRFS se porad vyviji, ZFS poradne na Linuxu stale neni a jeho licence je komplikovana. A mnohem lepsi je stejne Hammer, ktery se mozna ve sve druhe verzi objevi prave i na OpenBSD, diky GSoC.

Co to je pouzitelna virtualizace? Qemu je, jinak jako guest funguje skvele v KVM a VMware minimalne a nyni i SmartOS. Na urovni site je virtualizace velmi dobra diky rdomains a na poradnem HW je i poradna virtualizace, cili LDoms na SPARC HW. A VirtualBoxem bych se az tak moc neohanel napr. kvuli bad emulation of HW on VirtualBox, ale toho je spousta jako napriklad dlouhodoby problem s navratem z X do console a dalsi. Jiste, na rychle vyzkouseni neceho je to fajn, ale sverit tomu neco produkcniho......... Takze jako host Qemu, ale to s limity, jinak neco poradneho LDoms. Zbytek guest v pohode. Jedno z pozitiv OpenBSD je, ze se nesnazi delat vsechno a vsechno blbe. Radeji jen neco (i kdyz toho je spousta) a poradne. Ale jinak doporucuju sledovat treba Bitrig nebo bhyve na FreeBSD, vkernel na DragonFlyBSD, obzvlastne uzasny rump na NetBSD atd.

Softwarovy RAID samozrejme OpenBSD ma a to velmi dobry softraid(4) vcetne skveleho full disk encryption kde by se ostatni meli hodne co ucit jak delat neco takoveho snadne pro uzivatele.

Vykon by mel byt hodne k zamysleni pro ostatni projekty, kazdy se tim ohani, vcetne tech vtipalku z OpenSSL, ale pak vidime kam to vede, ze Zatimco na OpenBSD mam vykon bez tech pruseru okolo. A ze nejaky system je treba o 10% rychlejsi mne absolutne nezajima, kdyz kvuli tomu ma mnohem slozitejsi administraci, mnohem vice nutnych aktualizaci a downtime a casteji se na nem neco pokazi nebo podporuje kdejakou blbost, ale kazda nedotazena.

Benchmark...... Tohle slovo mne vzdy rozesmeje. Napr. Phoronix je ma skvele, takove ty fajne, ktere rozebrali lidi okolo Dtrace a ukazali, ze treba misto CPU to meri disk a podobne vylomeniny. Benchmark je spousta uzasne teorie, ale jediny benchmark, ktery ma cenu je ten, ktery meri realne nasazeni systemu a ne nejakou teorii vycucanou z prstu. A takovych jsem videl jen par, protoze drtiva vetsina firem je bud za a) nechce platit, protoze jsou opravdu narocne na cas a prostredky nebo za b) by se ukazalo, ze pravda je na druhe strane. Tak se to radeji dela stylem 8 z 10 doporucuje.... :D

If you think micro benchmarks are worth anything you have a micro understanding of the problem. -- Marco Peereboom

The biggest flaw with all those great benchmark articles is that their often flawed and the people behind them are biased to show whatever they like to prove. In the end many of fefe's test programs did not actually measure what he assumed they would. -- Claudio Jeker

In the end it boils down to measuring the different OS on the hardware you will use for the task they should fullfill, nothing else matters in the end.

A obrazek na zaver. Od Netflix, ktery ".... uses if_lagg in their CDN – 32% of North American Traffic flowing through driver based on trunk(4) . Interne pouzivaji FreeBSD, ktere ma v sobe i Dtrace, to vzniklo v Sun, jeho autor pak delal v Joyent kde to dost posunul pro SmartOS, Illumos a FreeBSD a ed presel do Netflix. Spoustu zajimaveho se deje a Google (ten uz 3 roky po sobe jako top), Facebook a dalsi velci hraci nejsou jen tak pro nic za nic sponzori OpenBSD

[x]

Kdo tady neco mumlal o tom, ze SELinux se nevypina? Disabling SELinux on RHS nodes is not listed in prerequisites of installation guide

:D :D :D :D :D :D :D :D

[Ruža Becelin]

RHS 2.0 hmmm.

Doporucuju roadmapu k novejsim verzim, s SELinuxem se pocita v dalsich verzich.

[x]

Kde je ten pan, co se zaklina vsemocnymi benchmarky, ktere spasi cely svet IT? Asi jako tento z OpenSSL? :D :D :D

static const char rnd_seed[] = "string to make the random number generator think it has entropy";

What a benchmark !!! Testing sci-fi instead of reality :D

[snajpa]

Tim jsem Ti chtel jenom rict ze "zbytecny se rozcilovat nad takovejma komentama" a potvrdit, ze s tebou souhlasim

[pta]

+100

Ale nekterym lidem to proste nevysvetlite. Kde chybi rozum, nahrazuji ho pocity a symboly, se kterymi by identifikovali svoje predstavy.

Btw. hlavne po udalostech z posledni doby nechapu jak nekdo dobrovolne nasadi SELinux. Jedine ze by si ho sam zauditoval, ale u tak komplexniho bazmeku to povazuju za prakticky nemozne. A pak jeste hlidat updaty.

[x]

Tak lidi obecne se nezajimaji. Oracle se tim netaji, ze pro Solaris 11 pracovali na RBAC vyvojari od NSA, dokonce s nima meli na webu i videa z konferenci a tam rikali primo, ze do SELinuxu a nebo do RBAC implementovali vzajemne ruzne casti.

Jinak opevovat SELinux to chce hodne velkou mlhu pred ocima. Tak schvalne, vlezme si na Bugzillu RedHatu, dejme si Search, zadejme open bugy, ve vsech produktech a vyraz SELinux; vyzstup z vyhledavani.

Nejvice cloveka rozesmeje hned ten uvod po vyhledavani "This list is too long for Red Hat Bugzilla's little mind; the Next/Prev/First/Last buttons won't appear on individual bugs. ". Toz dobry produkt ten SELinux, stronk security :D :D :D :D :D

[mich]

Vtipné je, že o tom giant locku píšeš pod každou zprávičku o OpenBSD a ten odkaz už jsi minimálně jednou taky linkoval. Pochopili jsme, že nemáš OpenBSD rád, tak už se prosím zaměř na něco jiného.

[x]

The Linux kernel had a big kernel lock (BKL) from the introduction of SMP until Arnd Bergmann removed it in 2011 in kernel version 2.6.39[1][2] after the final remaining uses of the big lock had been removed or replaced by finer grained locking.

Takze Linux se ho zbavil poradne az v roce 2011, pricemz Linux sam vznikl v roce 1991. OpenBSD vzniklo v roce 1995, ma mnohem prisnejsi vyvojovy model, userland SMP je velmi kvalitni, na giant locku v kernelu se intenzivne pracuje a ma o rady mensi vyvojarskou a uzivatelskou zakladnu a i presto at pocitam jak pocitam, tak jsou vlastne jeste popredu kdyz to vsechno clovek da dohromady.

Ale je pro nej asi snadnejsi si proste plivnout. Strach dela divy

[trekker.dk]

No je vidět, že ani vy nemáte moc objektivní pohled, jinak byste bral do úvahy, že

a) BKL byl odstraňován postupně během několika let

b) podpora SMP je v linuxovém jádře až od roku 1996, kdy vyšel Linux 2.0

A ejhle, najednou to "popředu" už není tak popředu

Ok, dalo by se taky zmínit to, že v OpenBSD je podpora SMP až od roku 2004, ale tak nějak si nejsem jist, jestli zrovna tohle je něco, čím by bylo dobré se chlubit.

[pavlix]

Nicméně je stále velice zajímavé, jaké osipky mají z OpenBSD někteří linuxoví uživatelé i vývojáři, že je to nutí reagovat na zpráviču no nové verzi třeba takto. Pochopil bych to od frustrovaného každodenního uživatele OpenBSD, nikoliv od člověka, kterému v podstatě nemusí vadit, že si někde lidi hrajou s nějakými dalšími open source systémy.

[x]

a) a v OpenBSD snad neni taky postupne odstranovan? b) podpora SMP a funkcnost je dost rozdil

Jinak:

SMP se objevilo v 3.6 v roce 2004, ale do te doby bylo SMP dostupne na urovni userspace uz nejaky ten cas. SMP, ktere se objevilo v roce 2004 bylo pak v roce 2009 predelano na rthreads - PDF

A ejhle uz to taky neni tak jine

Nikdo tady prece nerika, ze SMP je k nicemu. Je treba taky v uvahu brat velikost projektu a to, ze nekde na dost veci SMP stale neni treba a o to lehci je pak nasledny prechod na SMP podporu, kdyz zaklad je dobre odladeny.

[Lol Phirae]

tak už se prosím zaměř na něco jiného.

Třeba na to, jak TdR vyrábí díry v OpenSSL?

[x]

Jestli nekomu prijde normalni, ze informace z privatniho klice (P R I V A T N I) si nejaky system pouzije pro nakrmeni vlastniho PRNG (ktery je pres 15 let stary :D) jen aby ziskal vice randomness, tak pak jiste OpenBSD vyrabi diry

[Jendа]

Ještě lepší.

[mich]

To by mě zajímal tvůj rozbor toho, proč si myslíš, že je ten commit špatně.

[Jendа]

(EC)DSA leakne klíč, když podepíšeš dvě různé zprávy se stejnou hodnotou m. (strana 122 a dál) Tomuto lze zabránit buď volením m náhodně (tento postup se již v praxi opakovaně neosvědčil) nebo použitím digestu podepisované zprávy jako m (nebo jeho zamixováním do entropy poolu, což je nejspíš to, co se odstraněný kód snaží dělat - předpokládám, že dgst je to, co jdeme podepisovat). To vede na deterministic dsa signature. Po aplikování diskutovaného patche podle mě hrozí leaknutí klíče skrze stejná m, pokud se nepodaří dostatek entropie nasbírat odjinud.

[mich]

Tomuto lze zabránit buď volením m náhodně (tento postup se již v praxi opakovaně neosvědčil)

V obou případech šlo o chybu v PRNG. Nejsem znalec OpenBSD, ale myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.

nebo použitím digestu podepisované zprávy jako m (nebo jeho zamixováním do entropy poolu, což je nejspíš to, co se odstraněný kód snaží dělat - předpokládám, že dgst je to, co jdeme podepisovat).

Je už sice skoro půlnoc, ale řekl bych, že mixováním dgst do m ztráciš právě tu náhodnost, proto ta úprava. Pokud nemáš dostatečnou entropii, jak ti pomůže zamíchat do ní známou hodnotu?

[Jendа]

Nejsem znalec OpenBSD, ale myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.

Nevěřím :)

Je už sice skoro půlnoc, ale řekl bych, že mixováním dgst do m ztráciš právě tu náhodnost, proto ta úprava. Pokud nemáš dostatečnou entropii, jak ti pomůže zamíchat do ní známou hodnotu?

Jenže mně nejde o to, aby m byla náhodná, nepredikovatelná nebo tak něco - mně jde o to, aby byla pro každou různou zprávu jiná.

[mich]

Já ti nevím. RFC 6979 sice popisuje jak používat deterministické DSA a ECDSA, ale nejsem si jistý, že ta implementace v OpenSSL (před změnou samozřejmě) byla košer. Není to jen o tom prostě přihodit podepisovaný hash ke generování náhodné hodnoty, ale jde o to, jak se při tom generování použije. Předávat ten hash jen jako parametr RAND_seed se mi nezdá správné. Ale uznávám, že v kontextu SSL by možná bylo lepší použít deterministickou implementaci popsanou ve zmíněném RFC než spoléhat na systémový PRNG.

[Lol Phirae]

myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.

No, a já zase myslím, že veškeré jejich úpravy jsou k hovnu, protože podobným stylem se prostě nedá pracovat. K čemu mi bude forknutá knihovna, která spoléhá na specifické implementace něčeho v OpenBSD? Jako vyházet podporu všech OS, co se mi prostě nelíbí, a přepsat to tak, že to bude (možná) fungovat pouze v OS, který používá (když budu optimistický) tak pár desítek tisíc lidí, to je opravdu úžasný přístup k vylepšování něčeho, co má být univerzálně použitelné. No, hlavně že si TdR užil několika orgasmů při sepisování těch commit messages.

[mich]

Tak před čtyřmi dny odstranili podporu FIPS. Důvod ke změnám jako je tahle mi také uniká. Nevím, jestli si myslí, že upstream jejich změny přebere, protože po jejich překopání to bude vážne fungovat jen na OpenBSD.

[x]

Duvod je presne tento FIPS mode is not coming back a maji 100% pravdu. Kez by tak prozreli i dalsi.

[mich]

Jo ještě jedna drobnost. Ty dva odkazy na PRNG faily se týkají generování klíčů. Tan kód je ale o vytváření signatury, takže to spolu nesouvisí. Signaturu můžeš vytvářet deterministicky, ale pro generování klíčů stále potřebuješ dobrý PRNG.

[Jendа]

Ty dva odkazy na PRNG faily se týkají generování klíčů.

Ne, ten bitcoinový je leak klíče přes podepsání dvou transakcí.

Btw. zajímalo by mě, jestli měl Debianí bug taky vliv na DSA podepisování, moc se o tom nemluví.

[Lol Phirae]

RAND_seed is now DEPRECATED

To bude slušnej matroš, patrně rovnou z Amstru.