Spectre / opcionális nagyfelbontású timerek

Security-all

Pár napja Zsugabubussal dumáltunk arról, hogy lehet-e a Spectre ellen védekezni a nagyfelbontású timerek tiltásával.

Akkor abban maradtunk, hogy érdekesen nézne ki, ha ezeket en-bloc kivennénk a rendszerből, de nekem azóta is az forog a fejemben, hogy ha nem is egyszerűen kivenni, de pl. globálisan tiltani és privilegizált user által processzenként engedélyezni, azt nem lehetne?

A programok többségének nincs rájuk szüksége, tehát szerintem globálisan lehetne tiltani és amelyiknek meg igen, ott a megfelelő jogosultságok birtokában folyamatszinten engedélyezni.

Vélemények? Lehet jó? Totál szamárság? Működhetne, de...?

  • 1377 megtekintés

( BandiG v | 2018. 01. 16., k – 13:16 )

Hogy az OS-en futo programoktol (szelektiven) elveszed, az lehet egy plusz vedelmi reteg, de a mindennapos privilegium emeles/infoleak hibak vilagaban csak egy folt a lyukacsos csonakon. Az igazan nagy baj itt a virtualizacios szeparacion valo atjarkalas, amit csak az egesz OS-tol valo elvetellel tudnal megoldani.

Raadasul nem is kell nagy felbontasu ora, hianyaban egyszeruen tobbet/okosabban kell atlagolni.

Igen, sajnos javascripten is már megvan a "megoldás" a letiltott nagyfelbontású timerekre.
Egy másik thread-en (js-ben webworker-rel lehet csinálni) egy változóban amilyen gyorsan csak lehet inkrementálni egy integer változót, majd a fő threaden ennek az értékét a megfelelő pontokon kiolvasni. Még ha nem is pontos időmérő (jitterel, fokozatosan elcsúszik), arra pont jó hogy egy memóriahozzáférés idejét praktikusan elegendően kis hibaaránnyal ki lehessen mérni.
---
Régóta vágyok én, az androidok mezonkincsére már!

Egy rövid karesgéléssel még nem sikerült belefutnom example kódba. A Meltdown ill Spectre publikációkban említik, mint felmerült és elvetett védekezési lehetőséget.

Itt találtam egy hoszasabb magyarázatot (ez elsőre valami podcast leiratának tünik):
https://www.grc.com/sn/sn-600.txt

Browsers years ago in response to those attacks which we covered on the podcast, they decided, okay, we're not going to give JavaScript super granular timing information. The browsers, both Firefox and Chrome, reduced the resolution of the API, which captures the current instant in time from infinity. It used to be the resolution of the clock. So it was nanoseconds. They reduced it to five microseconds. So they deliberately removed resolution so that JavaScript could not determine as accurately as it originally could what time it was. So once again, not to be daunted, our clever engineers said, okay, fine. We don't have accurate timing. But is the five microseconds itself accurate?

And it turns out that Chrome and Firefox differ a little bit. Chrome is a little trickier. They fudge the actual timing event. It still has five microseconds' resolution. But they delay it a couple different amounts in order to, like, further obscure the actual moment of that five microseconds event. Firefox didn't do that. So, for example, in Firefox the way you solve this problem is you query the API until the timer ticks. So that gives you tick alignment. Then you perform the operation that you want to time, in this case a read or a write of a certain location because you're wanting to probe the cache. And as soon as you get control back from that operation, you start doing something, you start counting how many times you can go in a loop until the next timer tick.

And so what happens is essentially the five microsecond resolution puts fenceposts. And you align yourself with one fencepost at five microseconds, do something, and the moment you get back, you spin until the next fencepost, until the next value, the next five microsecond tick occurs.

[...]

There's another approach using WebWorkers, which essentially extends the JavaScript API to a multithreaded environment, where you're able to say, you go off and do this. Oh, and you also - the workers, in order to coordinate, they have a region of shared memory, memory that they can both see.

So the WebWorker, you give it the task of simply spinning up a counter in the shared memory as fast as it can. Now you have your own timer, which you're able to use, which is, again, much higher resolution than the deliberately blunted resolution of the JavaScript timer in order to determine how long something took to occur.

Amint látható többféle megoldás is van, a webworker nem is feltétlen kell. Ha az órának csak felbontását csökkentik le (mondjuk lemaszkolják az alsó biteket), attól még az értékének ugrásszerű lépései pontos frekvenciával történnek, ezt pedig lehet esemény-illesztésre használni egy szálon belül is. A Chrome-ban ezért még szándékosan jitterelik is órát. Viszont a webworker-es megoldásnak tudomásom szerint ezidáig nincs hatékony ellenszere.
---
Régóta vágyok én, az androidok mezonkincsére már!