BootHole - virtually every Linux distribution is affected

Rekoh, zavisi od jezika. C je takav pa takav, ne trpi sloppy progamiranje... no ono sto je najveci problem je da trazi bas takvo programiranje.

Ivan:"Sta qratz, ko jos proverava koliko bajtova pokusavas da alociras... i to jos u bootloaderu :-) Smejali se ljudi Intel-u kad u Management Engine-u rade to isto, ironija bi bila da je u smejavac ekipi bio neko i od GRUB dev-ova :-)"

Pa hm, koliko treba da alociras da probijes heap? Mislim ovo bas i nema smisla. Osim ako neko ne uvali takav kod, mislim ovo je vise kao debug varijanta nego nesto sto bi islo u release...
Ok niko ne spori da C programer nikad ne provera na NULL, na array bound i slicno...

To zavisi ko vodi tim. Prvo, unit testove obicno pisu sami developeri (obicno juniori) ne QA, QA team obicno pise funckionalne / acceptance testove, ako imas jako dobar QA team koji cine zapravo programeri onda pisu i integracione testove..... Drugo, sve i da imas programera u QA team-u, koji pogadja k'o snajper, zasto bi ga, aman, selio u dev team? MNOGO ti je korisniji u QA timu. :)

Psihologija grupe... Gledaj, ovaj proces treba da vodi promeni kulture. Kultura nije "idemo u kafanu, zovemo to team building" ili "idemo na meditaciju da nam se uskladi chi dok pijemo almond latte chai" - vec da promenis kako se razmislja o procesu rada. Bitan deo toga je da sve bude pokriveno testovima - i da sve radi. Dobro postavljen tim navija da nesto radi - ali to nesto su i testovi. :) Sustina je da se tim usmeri da radi kao tim. Ovo zahteva ceo devops proces, realno fuziju timova, kao i blameless post mortem - cilj je da ljudi dobiju motivaciju ne "da sve radi" vec "da sve poprave". Da budu odgovorni (idealno i ponosni) prema kvalitetu onoga sto proizvode - i trude se da isporuce najbolje moguce. Ovo nije jednostavan proces, ne radi se za mesec dana - ali daje super rezultate. Samo trazi vreme i posvecenost....

Old gold likovi nisu ovde problem, stavise takvi likovi su pure gold ako znas da ih hendlas, ali lako mogu da postanu i single point of failure.... Opet, sve zavisi od toga da li znas sta radis i kako to radis. Ako su dovoljno matori pomoci ce i oni sami da budu korisni i nece dozvoliti da budu SPOF vec ce sami da rade kako treba. Ima i likova koji su bezobrazni i koji namerno to prave od sebe (koje imo dobar management izbaci napolje sto pre).

Ono sto treba razumeti je, a to je i Ivan vise puta pricao: Odgovornost za uspeh je na managementu. Pojedinacni programeri su zamenjljivi i sustinski nebitni kao pojedinci, tim mora da funkcionise bez obzira na to. Odgovornost za uspeh snosi management i oni su duzni da obezbede i da je projekat dobro postavljen i da postoji proces i kultura. U komercijalnim projektima board drzi ceo rizik i odgovara vlasniku / akcionarima. Na zalost, u mnogo F/OSS projekata nema management-a i zato je sve ostalo kako jeste - i zato ovakvi problemi. Razlog zasto je Linux kernel super projekat je sto je Linus odlican tech manager, ne odlican programer. Mozda malo nekonvencionalan, sigurno ne "sensitive", ali efikasan.

edit: Ovo je @dejanet - isece me Bane. :)

---

https://www.zdnet.com/article/...across-multiple-linux-distros/

I kako se slabo testira sledi....

Mislim da FOSS programeri QA rade tako sto puste kod u divljinu a onda useri otkrivaju regresije :P

A tamo na linku neko zamenjuje "free(ptr);" sa "if(ptr) free(ptr);", što je konačna potvrda da Ivan Dimkovic ne zna šta priča.

Komanda "man 3 free" daje


Dakle, to "if(ptr)" ispred "free(ptr);" je pleonazam.

---

Nedeljko sa time vidis koliki je kvalitet tih programera :P
Ziasta if(ptr)free(ptr) nije nikakva ispravka, osim naravno ako ti sam ne implementiras free :)
Mislim mi ne znamo da li se ta verzija free koja je u grubu oslanja na klasican free ili je custom implementacija?

@nkrgovic

Sve sto si napisao je "by the book", stos je sto ne funkcionise najbolje.
Test driven development ili kako se vec zove je po mom skromnom misljenu i osecaju, losa stvar, jer mesa odgovornosti i generise neefikasan proces. Ekvivalent u programiranju ti je code duplication i krsenje separation of concerns ili koji je vec pravi izraz. To je ono sto programerski um misli o tome.

To da sve treba biti pokriveno testovima i da to treba da dokaze ispravnost rada aplikacije je nonsens, plus ako veliki deo tih testova pisu ljudi koji su progrmirali tu aplikaciju, pa to druze treba zabraniti zakonom uz krivicne sankcije :)
Mislim da je u vecini oblasti to i zabranjeno zakonom (gradjevinarstvo, masinstvo, bankarstvo..)

Sto se organizacije, timova, psihologije grupe itd. tek tu nema nikakvih smislenih odgovora, pa se kao resenje pominje promena kulture, motivacija, korisnost pojedinca.... pa ide dug csv, te na kraju imamo i code of conduct i slicne ludorije. Stos je sto ove i srodne metodologije nemaju organizacione i procesne odgovore, pa su delegirali pricu na opsta mesta spomenuta gore. Zasto nemaju odgovore, pa zato sto su te metodologije prepisane iz druge industrije-automobilske i iz druge kulture - japanske, plus ljjudi koji su se bavili i bave se ovom pricom apsolutno pojma nemaju o organizacionim naukama.

Kazes da su programeri zamenjivi i nebitni, ok, praksa govori drugacije. Menadzment, programeri, qa, admini, dizajneri, knjigovodstvo itd.. svi imaju proporcionalne zasluge ucescu u kreiranju, kvalitetu i prodaji proizvoda. Da li ce se sysadmin ili manadzement baviti kvalitetom aplikacije, hmm tesko, mnogo tesko.

To se lepo vidi po velikim firmama, koje su deo testiranja prepustule masama korisnika, a kao rezultat potpunog sloma tog procesa o kojem pricamo.

Branimir Maksimovic


Da, ubacivanje "if(ptr)" ispred "free(ptr);" i pisanje funkcije koja radi samo to je neznanje koje samo troši dodatne CPU cikluse. Međutim, nisi obratio pažnju na kontekst, a to je

Dakle, Ivan Dimkovic smatra da treba lupiti šamar čoveku koji ne stavi "if(ptr)" ispred "free(ptr);" i sa takvim "znanjem" C programiranja ovde pametuje.

Druga stvar: Malopre nakucah kod koji opisuje neizbežne situcacije u C programiranju. Dakle, tu nikakav analizator ne sme da vrišti jer sledeći kod nema čistiju zamenu kada je C u pitanju. Prilažem ga kao fajl.

Treba se samo malo poigrati direktnim pristupom poljima strukture ili napraviti bag u funkcijama za operacije datim tipom, pa dobiti buffer overflow, koji nijedan analizator neće da detektuje. Ovo je sasvim realno programiranje, štaviše neizbežna situacija u većini C programa.

Da ne pričamo o složenijim situacijama, kao što je custom alokacija. Ovo je nešto najprostije što treba u svakodnevnom C programiranju.

Dakle, ovde prosipaju pamet ljudi koji nemaju iole svežeg iskustva u profi programiranju. Nego, "Postoje moćni alati, superprocedure.", te ovo, te ono.

---

@dejanet:

Ovo o cemu pricam nije tdd. Tdd je stranputica, jer tera ljude da prave kod koji prolazi testove - a ne sisteme koji rade. :)

Ne kazem da pisu ISTI ljudi - samo da unit testove pisu programeri. Obicno mladji, kao deo ucenja... u svakom slucaju neki drugi.

A sto se tice kulture, odgovornosti i zamenjljivosti: Svi su zamenjljivi. Poenta je samo da je odgovornost ovaj "put your money where your mouth is" proces. Onaj ko je ulozio pare snosi odgovornost. Moze na druge da prenese ovlsacenja ali na kraju dana on je odgovoran i on gubi. :) Ne zaboravi, konacni sud kvaliteta aplikacije/proizvoda je prodaja, a to utice na novac koji ide u dzep onoga ko je novac dao. Zato je samo on nezamenjljiv i zato on snosi rizik i zato on u kranjoj liniji brine o kvalitetu.

Kultura je... nesto sto se pravi i neguje. Nije naivno. Sustina je da se mora generisati primerom. Ne postoji "metodologija", nema tog psihologa, HR-a ili koga vec ko moze da donese kulturu - to mora da postoji u timu, mora da ide odozgo nadole i mora da se prenosi licnim primerom. Apsolutno svi su bitni, to stoji - ne shvataj me pogresno. Sustina je da svako to mora i da oseti, bukvalno junior dev, koga uvedes u projekat i das mu da pise unit test za neki nov kod, on mora da shvati da je to sto on radi deo neceg veceg i da je i tu bitan kvalitet. To sto je on zamenjljiv ga ne cini nebitnim, to nije isto.... Odlican si primer dao, bukvalno je knjigovodja ultra-bitan i on mora toga da bude svestan. Cela ova prica je jako teska za svesti je u par recenica na forumu.... I da, code of conduct i slicno nemaju blage veze sa ovime. Sa ovime ima veze da, ako nesto ne radi, CTO i CIO su prvi koje budi telefon, onda oni sedi nocu i resavaju problem. Takve stvari. To je code of conduct, responsibility i leading by example. I da, dobar CIO i CTO ne treba da imaju taskove u procesu rada, oni su "directors" koji usmeravaju taskove i prave policies, ali, when s... hits the fan, oni su prvi na liniji, vode primerom. Nadam se da sam bar malo jasan. Mnogo je BS-a u ovoj prici, mnogo "knjiga" i "ideja" kao sto kazes iz drugih kultura i industrija, a ovo je tesko opisati u jednom pasusu....

---

Moras praviti testove, po moguctstvu automatizovane, a to je vec posao koji zahteva ljude za to. Ako to nemas imas situaciju sa FOSS programima, kada na svaki apdejt drhtis da li ce ti se sistem uopste
butovati( ili nece) ili ces imati GUI (ili neces) ;)
Sto se tice test driven developmenta, kada se prvo pisu testovi, pa tek onda korisni kod, ne znam, to se zove i extreme programming i slicno, sve u nadi da ce biti manje bagova. Nije
to nastalo tek tako, nego sto je softver kompleksniji imas tih bagcica sve vise i vise i to je kao neki samo ime kaze extremni pokusaj da se to eliminise. Nisam nikada video neki
dokaz da to daje ploda i da se projekti zapravo na taj nacin ciste od bagova. Elem, sam otkrijem dobar deo svojih bagova, al dok neko drugi ne isproba ispadne da ima jos gro toga :P

Ovo ti je memleak. Treba uvesti tmp kao rezultat i onda osloboditi originalni dest->text ili javiti gresku.

@Branimir Makcimovic

Razgovaraš sa zidovima.

Čuj, u 2020 godini u ozbiljnim sistemima ne može da se desi šta? Svetska pandemija? Očigledno može.

Eto, vidiš. Imao sam memleak, koji

1. Ja nisam našao.

2. valgrind nije našao.

3. Kompajlirano je gcc-om i clang-om sa "-Wall -Wextra -pedantic -ansi" i ništa.


Možemo da testiramo razne alate za statičku analizu.

Clang-Tidy and Clazy:




Toliko o statičkoj analizi.

_{[Ovu poruku je menjao Nedeljko dana 02.08.2020. u 00:29 GMT+1]}

---

Oooh, Nedeljko... ovo stvarno nisam ocekivao :-)

Hajde da predjemo na neku zamisljenu situaciju, lica iz iste nemaju veze sa stvarnim ljudima i tako to...

Imamo nekog iii teee "menadjera" koji nema pojma o "ceu" (ali je cuo da je mnogo mocna stvar) - covek voli da se prosipa nekim buzzwordima tipa CI/CD, fuzzing, linteri, sanitizeri, dza bu. Zvuci kao da zna o cemu prica ali, ocigledno, pojma nema.

Imamo, takodje, i senior programera (u najmanju ruku) - nazovimo ga picajzla, covek je PhD matematike, zna C uzduz i popreko, ako ga probudis u 2 AM, moze da ti kaze sve UB-ove u C standardu i tako tako. Starija picajzla jako dobro zna da C free nece da se u*ere ako mu bacis null pointer, cak je vrlo raspolozen da citira svoj mali dzepni man().

Divno, situacija cista k'o dan, jel da?

Hajd da vidimo malo mi to.

Za pocetak, predmet ove diskusije je GRUB (ocigledno jako dobro ime, larve se mogu naci na napustenom izmetu) i njegovi nesrecni dani kada su uspeli da s*ebu Internet sa sampionskim bagom koji je bio samo uvertira za nalazenje jos sampionskih bagova.

Ali iiteee menadjer "pametni" je izabrao drugi commit, ovaj, https://git.savannah.gnu.org/c...8287ed3af32fffe8aaf33cdff52f6b

Koji je naseg starijeg programera picajzlu naterao da "baci K&R (pardon, C99) knjigu" na glupog iii teee menadjera! Ako mu je rekao!

Steta sto je picajzla Sr. propustio da primeti da je neki jadni GRUB programer morao da ubaci nazad ocigledno suvisan kod koji, po nasem iskusnom picajzli, cak jos trosi i resurse (o ovome cemo da se pozabavimo na kraju).

Kako to? Neko u GRUB timu je primetio da nisu bas sigurni da na svim host OS-evima kompajleri nece za*ati stvar i puci unutar free() poziva sa null pointerom.

Sticajem okolnosti, takvi kompajleri postoje - jedan mobilni OS svakako nije cenio C specifikaciju. Cak i neki malo ozbiljniji OS-evi o kojima stariji picajzla sigurno jako dobro zna. Ali, verovatno, umesto jedne komparacije (koju ce mocni ISO, C99 i man() opremljeni kompajleri sa konformantnom free() f-jom verovatno optimizovati i pretvoriti u nop :-) stariji picajzla je verovatno spreman da se raspravi sa celim svetom i objasni im da ne umeju da citaju man(), a ni ISO specifikacije. Go, picajzla, go!

...

OK, GRUB mozda mora da se nosi sa kojekakvim nestandardnim varijantama, neko ce reci, ali ako je kod "garantovano ISO C" ili POSIX ili sta god, onda je Dr. Picajzla definitivno u pravu i itteeeee menadjer prica iz svoje g*zice?

Da, definitivno je Dr. Picajzla u pravu, trebalo bi ga poslati na sledeci svetski kviz UB-a i tajni ISO C-a!

Ali... u hladnom i iskvarenom svetu punom sampiona i idiota, insistirati na defanzivnoj proveri pointera u kodu koji je sigurnosno kritican je prilicno dobra ideja, kaze ii tee menadjer.

Mozda iiteee menadjer pojma nema o Ceeu, cak bi mozda pomenuo i jos nekih buzzword-a tipa FMEA, ali ko bi lud verovao da neko to koristi u danasnjoj sw. industriji. Cak i teorijski, taj buzzword je za menadjera i njegove kolege menadjere kad se zapiju posle sastanaka, pa necemo uopste ulaziti u to.

Za nas smrtnike je sasvim dovoljno sledece kao savet za picajzlin tim: instaliraj fckin linter i postene sanitizer-e u proces kreiranja izvr.. pardon (menadjer glas) "artefakta ba!".

A, da, i zameniti picajzlu Sr. (tj. realocirati coveka na nesto pametno) sa nekim proceduralnim grunt-om koji ce da ubija za propustenu proveru ako vec alatka za analizu udari Turingov zid. Sta bi rekao nas 'ajzla na to? Tako sljaka vojska a ne neki intelektualni tim? Da, vojska... znaju par stvari sa radjenjem kompleksnih operacija u svetu punom "naroda", pardon - GRUB dev-ova. Ako 'oces radis disertaciju, zanemari sve ovo... ako 'oces softver za narod i sa narodnim komponentama? Poslusaj glupog menadjera, covek mozda zna kako da ustedi kintu i zivce kasnije.

E jbg, ako menadjer se*e sve vreme... onda drzati se pameti. GRUB ekipi odlicno ide :-)

Konacno, za kraj, jos jedan komentar koji bi menadjeeer dao 'ajzli starijem:



Oh :-) Ali umisljeni menadjer je mozda cuo za neke mnogo pametne kompajlere koji ce nop-ovati (jel se tako kaze, a? pita menadjer) proveru koja je nepotrebna ako posle ubacuju optimizovanu free f-ju (koja i ovako i onako radi proveru)? Ili to ne umeju da urade, pih!

Ali po strani brojanje CPU ciklusa ili cak uzimanje u obzir nekompatibilnih C biblioteka, 'cajzla sr. propusta da vidi sasvim drugu vrednost provere u ovom slucaju.

Mozda zato sto 'CajzlaEx ceo svet vidi kroz svoje PhD naocare, umesto kao nesto mnogo ruznije i gluplje... jbg.

Profesionalna miopija.

---

Poslednjih godina vidim ogroman problem (ironije li, postavih juce post o testiranju), ljudi u OGROMNIM resenjima ne pisu testove. Aj' mogu da razumem za neke igranke, pravis nesto za sebe za 2 dana da ti zavrsi posao i nece biti u ne znam ni ja kakvoj produkciji... ali znam timove ljudi, njih recimo 2 radi front, njih 2 radi bekend, devops je neko ko ima malo znanja oko pajplajna eventualno da odradi deploy, neko takodje malo zna da optimizuje queryje i NIKO ne pise proklete testove. Pitah tako drugara koji je bio teamlead u firmi koja je uzimala projekte "sto pre da ih zavrsi" kako rade testiranje i to jer mi je bilo nerealno kojom brzinom zavrsavaju projekte, kaze mi "ko jos ima vremena za testove"... onda se vraca 5x projekat na doradu, pa pi*de sto rade jedan projekat gde je trebalo da budu u plusu ako ga odrade za 3 meseca godinu dana i odu u minus jer projekat ne pokriva troskove developmenta...

Sa druge strane razumem i da vise niko ocigledno nema vremena da obucava mlade programere o "best practices" pa ni sami ne vide poentu testiranja, al' kad sam u situaciji da ja i jos jedna osoba radimo bekend, pa prvo apsolutno nemam pojma da li ce moj kod kad se uklopi s njegovim da radi bez testova, em nemam pojma kako ce ovi sto rade front da citaju sta sam ja radio i vide funkcionalnost ako ne pisem testove. Primera radi, pre nove godine, bio veliki projekat, nas 3 na bekendu, vidim ne pisu testove, ok ajde necu da smaram, nisam teamlead, necu da drukam, radim ogromnu kolicinu koda koja mora da se istestira, pritiskaju nas sa vremenom, ovi rade lezerno i sve ide "po ps-u", ja stiskam zube i pitam se sta ce biti kad se odradi merge... odradim merge svog koda, jedini pisao testove, phpunit poludeo od gresaka, nastane opsti haos, teamlead se hvata za glavu, zove ovoga, zove onoga... prvo ispalo da sam ja napravio haos sto sam pisao testove, posle se naravno ispostavi da apsolutno neke stvari ne mogu da se uklope, a ovi sto rade front nisu imali pojma kako da gadjaju njihove endpointe jer im ni dokumentaciju nisu pisali kad vec nisu testove...

I tako se otprilike napravi od necega sto je potencijalno do jaja aplikacija jedna velika propast na kojoj treba da se radi 2x vise vremena dalje umesto da se koristilo 5% vremena da se pisu testovi kad vec i mi u bekendu moramo da koristimo bar postmana da vidimo sta smo uradili. Kako je krenulo to da se vise stiska s vremenom nego radi na kvalitetu samog programiranja tako su i programi postali busni ko nista.

E sad, GRUB je opet open source, kapiram da se testira, nisam gledao codebase ali verujem da moze da se zakrpi, samo sta raditi sa zilijardama racunara gde je on u produkciji? Pricamo samo o serverima.

A sto se passworda tice i koriscenja tudjih aplikacija... napravite "nivoe" po kojima cete koristiti iste sifre. Od ozbiljnosti aplikacije koristim odredjenu sifru i to je to. Bitno da mi se one top-level nikad ne provale i to je to, da l' ce neko da mi udje na twitter i pise statuse to me apsolutno zabole dokle god ne moze da mi otvara mail i payment aplikacije.

Enkapsulacija. SOLID. Testiranje. I nema brige. Umesto sulude teorije koje ima na svim fakultetima kod nas, zasto ne ubaciti predmet SOLID? Uce ljude da programiraju, uce ih ovo uce ih ono, sto ne posvetiti jedan semestar jednom predmetu i nauce ih neke stvari koje ce im SIGURNO trebati ako zele da programiraju i rade negde? Koja firma ce da primi ikoga ko ne zna to da postuje?

---

@Ivan Dimkovic

To nema veze sa operativnim sistemom (mada OS API ima tu funkciju) jer OS API može da bude bilo kakav.

C API mora da bude po standardu. Dakle ako OS API funkcija ne vrši tu proveru, C bibliotečka funkcija za taj OS mora da je vrši.

E, sad, šta ako C kompajler ne valja, a ima takvih? Onda smo u mnogo većem problemu, jer taj kompajler pravi ko zna kakve se gluposti, i to nikakve metode testiranja i debagovanaj ne mogu da reše. Taj se problem može rešiti isključivo promenom kompajlera.

---

Oh Nedeljko :-)



Sta ako ne mozes da promenis std. biblioteku?

Nista, baci projekat u djubre :-) Ko zna, mozda projekat bude neki softver za matori Unix koji, sticajem okolnosti, ne postuje tvoje standarde sta bi C API trebao da radi.

Baci taj Unix? Moze, kao i celu nuklearnu elektranu ili avion ili banku oko njega.

Znas sta ce da desi? Fina ekipa iz elektrane ce da ti se zahvali na savetu i lepo te isprate napolje, a onda ce da zaposle nekog ozbiljnog ko ce da stavi if() workaround.

Pitam se da li je WebOS sredio taj problem (PalmOS je, takodje, voleo da pukne ako mu podmetnes null u free() pice), ali bar WebOS uredjaje mozes da zamenis lakse od reaktora.

Ako si sad smislio da zamenis C biblioteku na projektu - odlicna ideja, koja ce ti odmah izleteti iz glave kad ukapiras da moras da razmenjujes stvari sa drugim bibliotekama koje su, sto mu gromova, kompajlirane sa falicnom std bibliotekom i... macka je pojela izvorni kod (hoce i to da se desi).

Mada ne znam koliko je uopste pametno na postojecem projektu da insistiras na zameni toolchain-a ako je to neka matora konstrukcija gde ne znas sta ce da eksplodira levo ili desno.

I dalje preferiras sve to umesto, u najgorem slucaju, suvisnog if()-a? Svaka cast na standardima!

---

Kontrolu nuklearne elektrane praviti šupljim kompajlerom, koji ima ko zna koliko iznenađenja.

Sjajna ideja! Černobilj, pa Fukušima, pa Dimkovićev projekat.

---

Moj projekat? Nisam ja pisao Unix v7 (ali, hvala, to je definitivno kompliment), mislim da se zalis na pogresnom mestu :-)

Unix v7 sam samo uzeo kao primer sistema gde si imao free() koji ce da se zagrcne sa null pointerom.

https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/v7vol1.pdf

Imas na strani 297 malloc()/free() upustvo... nema nista o null pointerima.

Netware, takodje, hoce da krahira ako mu bacis null ptr u free().

Bastards!

---

Opet, nema veze sa OS-om, već sa kompajlerom.

http://www2.cs.uregina.ca/~hil...C%20Programming%20Language.pdf

Strana 209:


Dakle, uzmi bolji kompajler. Nekada si uz DOS dobijao neki GW Basic, Q Basic, ali za kršteno programiranje si nabavljao nešto ozbiljnije.

O čemu mi ono beše pričamo? O GRUB-u i 2020-toj godini? UNIX v7 (to su beše 70-te)? NetWare?

---