Bude příští kernel napsaný v Go?

Tesim sa na jadro napisene v javascripte.

svet je uz teraz ovela dalej https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg - v js sa da napisat cela VM :)

Ja som to skor myslel ironicky.
Ten clanok je viac menej hypovany ako samotne Go.
Ono je to ako program prepisat z C do javy a vyhlasit, ze buffero werflow tu nejstvuje, tak je to bezpecne co je omyl. Je to len pomalsie a ma to inu kategoriu zranitelnosti.

Serioznich vedeckych praci ktere se ukazaly byti totalnim blabolem sem uz videl stovky. A tahle k nim naprosto zjevne patri.

Kolik ze radku kodu ma kernel? Joaha, o par radu vic (cca 20M) , takze celkovej rozdil vykonu ... bude taky o par radu jinde.

Apropos, kdykoli je v nazvu clanku na konci otaznik, odpoved zcela vzdy zni NE!

Tak nevím, jestli zjištění že "v jazyce který neumožňuje memory related bugy je méně memory related bugů" implikuje "kernel bude bezpečnější", na nějaké závěry by to chtělo několik let být v focusu bug hunterů, pak teprve by porovnání dávalo nějaký smysl.
Cena 10% výkonu dolů taky není zanedbatelná, i když ve stínu Spectre/Meltdown je to drobnost.

Ostatně php je taky memory safe jazyk, a že by byly v něm psané weby nějak extra bezpečné se říct nedá.

ale o to jde, ne? Zrušit celou kategorii bugů dříve než se odhalí.

Bezpečnostní problémy v PHP nepramení z PHP, ale z jeho použití, buď přes ně protlačím data, která se pak spustí až na prohlížeči, tj. s PHP to nemá moc společného. Nebo nechám zapsat soubor, který zase s PHP spustím, opět to není tak moc zranitelnost samotného jazyka. Tyhle chyby se ale dají velice efektivně odchytit přes review, race condition, memory related bugy se už daleko hůře ručně objevují a spousta objevených CVE v kernelu z poslední dobu je z fuzzy testování.

Tak moment, to že dám do cookie "group=admin", případně (např.) chybná podmínka takže se do procesu namapuje R/W celá dostupná RAMka je problém použití jazyka, ale a[-1]=0 je zranitelnost jazyka?
Pardon, to mi připadá jako hraní se slovíčky, aby preferované řešení vypadlo jako lepší (neříkám že není, jen mě trochu vadí hypování a co je staré to je špatné), ale ve finále je výsledek stejný, dojde patrně ke kompromitaci.

Navíc tu jsou sociální faktory, třeba nižší laťka pro schopnosti programátora v jazyce, který za něj chodí i na záchod, se může dost negativně projevit na kvalitě výsledného kódu, takže sice jsme se vesele zbavili celé kategorie chyb, ale bezpečnost to nějak zvlášť neposílilo.

BTW: Zkusil někdo vymyslet třeba side channel timing útok na garbage collector, jaká data tak můžou utéct? (tedy něco co ve standardním kernelu není - takže potenciální pole neorané a pravděpodobně dosud neznámá nová kategorie bugů).
Nemyslím že by analýza podobných nechtěných následků byla triviální.

"Nemyslím že by analýza podobných nechtěných následků byla triviální."
Naopak, cim vic takovych samoseroucich se veci v kodu mas, tim hur se potencielni chyby odhalujou, protoze ve finale vlastne nikdo nevi, co to dela a kdy to dela a proc to dela, takze kdyz pak nekdo na neco narazi ...

Bejvaly casy, kdys moh prikaz po prikazu prelozit danou vec do asm, a vedel si, ze vicemene totez vypadne i z kompilatoru. Takze si vedel co to ve finale bude delat. Dneska mas kompilator kterej se snazi myslet za tebe, mas cpu kterej se snazi myslet za tebe, maz jazyky ktery za tebe chodej na ten hazlik, takze vysledek je, ze uz vlastne nikdo nevi, co to bude ve finale delat.

Tak hlavně aby na ten jazyk byla dostupná dokumentace na úrovni což se moc o PHP říct nedá..

Jeden příklad za všechny.

Tenkrát jsem potřeboval zapsat data do souboru po ukončení načítání dané stránky.
Ze začátku to bylo lehký. Použil jsem "register_shut­down_function" a myslel jsem, že je hotovo.
No a v dokumentaci se už třeba nikde nepíše, že se po zavolání fce mění aktuální cesta na nějaký základní s*it..

Opravdu krásně ztracených 15 minut něčím co by mohlo být v dokumentaci..

PS: Pro ty z Vás, kteří neumí číst a myslí si, že haním PHP, tak omyl, jen jeho dokumentaci...

php nema dokumentaci, ale forum, kde se vsichni dohaduji jak to vlastne funguje.

@Grammar nazi

39 livejournal.com/~sin­de1/ 12 years ago

If you want to do something with files in function, that registered in register_shut­down_function(), use ABSOLUTE paths to files instead of relative. Because when script processing is complete current working directory chages to ServerRoot (see httpd.conf)

[http://php.net/manual/en/function.register-shutdown-function.php, 2018]

Naopak bych řekl, že jsem viděl spoustu horších dokumentací.

A nechcete si ty žabomyší války o PHP jít řešit na fórum? U každé diskuze na rootu dominuje nějaké off-topic téma, které už bylo diskutované snad 100x a lidi pořád baví to psát znovu a znovu :)

Jenze ono to neni 10%. Kdyz implementujes veskerou funcionalitu kterou ma kernel, tak to bude rozdil v nasobcich. Viz vejs, i kdybys to prepocital jen na rozsah kodu, tak to mas rekneme 100k vs 20M => 200x ... (neda se to samo takhle uplne vynasobit, ale ten rozdil bude naprostro tristni).

A jak sam pises, budou v tom jiny chyby, prevazne jeste mnohem zaludnejsi.

A ty drivery nebezej a nic nedelaj ... takhle to vidis?

Mistni squadra negramotnych blbu totiz nezvlada ani scitat, a ten vykon se nebude scitat ale nasobit ... protoze on bude o tech 10% poamelejsi taky... trebas filesystem, takze ... se na nej bude o to dyl cekat. O 10% pomalejsi bude sitovani ... atd atd atd atd.

V daném případě dával mnohem větší smysl Rust, i když v době HW bugů a backdoorů je to tak pro falešný pocit bezpečí. Jsem zvědav kdy svět pochopí, že je opravdu potřeba open-source HW.

OSS HW jednak asi nic neřeší - viz. to Supermicro, infikace při výrobě.... Dále se zdá, že je okonomicky neživotaschopný. Pokusů bylo docela dost, ale nic se nechytlo.

To si hodně lidí myslelo i když vznikal open-source SW. Já moc nevidím v HW rozdíl, jen se to ještě nerozjelo tak, aby firmy spolupracovali na vývoji HW tak jak to teď dělají v oblasti SW. Vidím to do budoucna ale pozitivně.

Jenze opensource SW si muzes uz dlouhy desitky let s nulovejma nakladama zacit psat doma na kolene.

Kdezto do vyroby HW musis nejdriv nalejt hromady penez, aby ti to nasledne nekdo kdyz to vypada zivotaschopne skopiroval a vyrobil to za 1/10, protoze jaksi uz nema ty naklady.

To je pravda, psal jsem to unáhleně, ale to porovnání v tom článku je hodně povrchní:

1. There are a number of kernels in Rust, but none were written with the goal of comparing with C as an implementation language.

2. There is no consensus about whether a systems programming language should have automatic garbage-collection. For example, Rust is partially motivated by the idea that garbage collection cannot be made efficient; instead, the Rust compiler analyzes the program to partially automate freeing of memory. This approach can make sharing data among multiple threads or closures awkward.

3. A language without a compiler as good as Go’s, or whose design was more removed from the underlying machine, might perform less well. On the other hand, a language such as Rust that avoids garbage collection might provide higher performance as well as safety, though perhaps at some cost in programmability for threaded code.

Ať si každý udělá vlastní závěr.

Ty body samotné jsou jen výcuc z toho paperu, kde zmiňují Rust. Já jsem to právě nechtěl nějak extrémně analyzovat tak proto mám radši, když si závěr udělá každý sám, přečíst si to celé neuškodí. Na můj vkus ten paper obsahuje poměrně silné tvrzení typu "A language without a compiler as good as Go’s", atd...

Tech 1500 radku v asembleru neni uplne malo, zejmena pokud to je kus asemleroveho kodu tady, kus tam. Neni pak uz jedno, jaky vyssi jazyk pouziju tam, kde asembler neni treba?

Vzhledem k tomu, že to je prototyp a tak nemohl projít dlouhým kolem optimalizací financovaných z nejrůznějších koutů světa jako Linux, je ta 10% ztráta výkonu úplně luxusní zjištění.

Hmmm, kdoví jak po bezpečnostních auditech ...

Jo a taky to luxusne vubec nic neumi, takze 10% je naopak naprosta tragedie, melo by to bejt radove rychlejsi.

Přiznám že jsem neměl čas studii číst, ale trochu bych se pozastavil nad těmi procenty. Je myšleno o 10% větší režie jádra nebo o 10% horší aplikační výkon. Pokud to první, je to super, pokud to druhé tak to zdaleka tak super není, protože to velmi snadno může znamenat, že režie jádra vzrostla klidně o 1000%...

Píšou tam "application throughput", takže celkový výkon aplikace.

@ivossz

"Tato práce do určité míry vyvrací zažité stereotypy o nezbytnosti použití low level jazyka (například C) pro tvorbu systémového jádra. Sami výzkumníci v závěru připouštějí, že v oblastech, kde je požadavek na bezpečnost, je použití vyššího jazyka velmi přínosné. Použití jazyka Go by zabránilo zneužití 40 z celkově 65 CVE linuxového jádra z roku 2017, pro které existuje patch. Samotné Go, na kterém Biscuit závisí, mělo v letech 2016–2018 celkem 14 CVE."

Zprávu jsem nečetl, nedostanu se k tomu dříve než o víkendu, ale zarazilo mne toto tvrzení, protože mi nepřipadá že by s rozkvětem HLL klesaly počty CVEček, často to záleží na důslednosti programátora či designera a taky jádro je v podstatě kritické místo nasazení takže ... Co ty si o tom myslíš?

@bez přezdívky

No proto mě ty věty s těmi CVE a to sebejisté prohlášení zaujalo. A přesně proto si to chci porostudovat. Kernel nedělám ani se nechystám, ale ten kus abstraktu který jsem četl mě zaujal sám o sobě ...

@ivoszz

Ty mínusy jsou kvůli tomu nicku ;-) ale já je jako přihlášený stejně nevidím ... :-D

Teoreticky je to další vrstva > další zdrojový kód > další potenciál pro vznik chyb (třeba implemntačních). Tak to prostě bývá. Zvýší ze zájem, zvýší se záběr, počety funkcionalit, termíny, více vývojářů různých stylů .... a už to jede. Tak to možná myslel. Ale to je těžko říct. Dokud to nevystaví světu a tlaku na 10 let, tak se dá těžko soudit jak to dopadne. Proto se to i mě zdá hodně sebevědomé. Takových proklamací už tu pár bylo.
Každopádně jazyky dalších vrstev postupně přicházejí - od pár dírek na válečku až po ... a zároveň i úměrně s požadavky uživatelů a možnostmi HW, takže by to byl logický (po)krok. Stejně určitě jednou přijde.
Určitě je dobře že někdo něco takového zpracoval i kdyby výkonostní ztráta vyšla 50% protože jinak bysme byli pořád pouze v rovině spekulací.Pokud nic nezanedbali tak nějaký závěr a přínos to prostě je tak nebo tak.

@ivoszz

:-) to "do určité míry vyvrací" skutečně není zas tak sebevědomé, seběvědomé mi připadlo spíš to co vyplívá z toho odstavce, tedy že
"Sami výzkumníci v závěru připouštějí, že v oblastech, kde je požadavek na bezpečnost, je použití vyššího jazyka velmi přínosné."
- sebevědomé ve vztahu k těm výzkumníkům. Myslím že na takové polo-opatrné tvrzení má každý právo, sám na to nemám nijak podložený názor, ovšem to by ta práce IMO musela být o něčem jiném s jinými důkazy myslím ...

Takové tvrzení "(Java je 4x rychlejší než Go)" je IMO na stejné úrovni jako by členové automotoklubu hodnotili auta podle maximálky napsané na tachometru

Jako programatora ve vsemoznejch (moznejch i nemoznejch) jazykach me jima hruza, kdyz si predstavim, ze jadro OS, na kterym delam (Linux) je napsany v C. Jima me hruza, kdyz aplikace, ktery pouzivam jsou napsany v C. Nebo nedejboze v C++.

@Black Sheep

A co teprve pokud jsou ty jiné jazyky které používáš napsané v C/C++

Mas na mysli kompilatory/in­terprety? To uz casto (nastesti) neni pravda.

@Inkvizitor

A taky to často je pravda ...

Baví se dva studenti: "Když si představím jakej já jsem inženýr, tak mám strach jít k doktorovi!" ;-)

Porovnani je zajimave, ale GC do jadra je velmi silena myslenka. Jadro potrebuje presne vedet, kdy se neco uvolnuje a neco nacita. V opacnem pripade bude system nenazrany co se tyka pameti a pomerne nederministicky. Spusti se GC a co ted ? Pockame ?

A co na to Potter.. tedy Lenártek Poetteringovic ?