ugrás a tartalomhoz

Spectre, Meltdown

inf · 2018. Jan. 28. (V), 10.56
Bár relatív régi, gondoltam nyitok neki témát, hátha még valaki nem értesült ezekről a sebezhetőségekről. link
‹ A secure boot hogyan működik? dm-crypt - btrfs - raid1 ›
 ■
1

Itt vannak patchek: link, de

inf · 2018. Jan. 28. (V), 12.01
Itt vannak patchek: link, de gondolom az automatikus update-el is lejönnek idővel.
2

Videón

vbence · 2018. Jan. 28. (V), 15.50
Ha valakit érdekel, hogy is működik valójában, ebben a videóban értelmesen elmondák. (Kevés ilyet találni).

https://www.youtube.com/watch?v=I5mRwzVvFGE
3

Én odáig eljutottam, hogy a

inf · 2018. Jan. 28. (V), 16.36
Én odáig eljutottam, hogy a speculative evaluation miatt akár olyan műveleteket is végrehajthat a CPU, amire nincs meg a jogkör (pl más alkalmazás memóriájának az olvasása?), mert a jogosultság ellenőrzés előfordulhat, hogy a művelet végrehajtása utánra kerül. Gondolom a CPU cache-ébe az ilyen végrehajtások után automatikusan beteszi az eredményt, hátha szükség lesz rá, hogy ne kelljen újra lefuttatni az egészet. Ami nem világos, hogy onnan hogyan tudják kiolvasni.

szerk:
Közben megnéztem a spectre pdf-ét, kiderül belőle, hogy a cache olvasására is megvannak a megfelelő technikák.
The main difference between the two techniques is the mechanism used for evicting the monitored cache line from the cache. In the Flush+Reload technique, the attacker uses a dedicated machine instruction, e.g., x86’s clflush, to evict the line. In Evict+Reload, eviction is achieved by forcing contention on the cache set that stores the line, e.g., by accessing other memory locations which get bought into the cache and (due to the limited size of the cache) cause the processor to discard the evict the line that is subsequently probed.


Megnéztem, a win7 és a firefox automatikusan telepítette a frissítéseket ezzel kapcsolatban, és úgy tűnik, hogy teszik a dolgukat. Legalábbis a js exploit példakód, amit találtam nem működött.
4

Idevágó rész

vbence · 2018. Jan. 28. (V), 19.19
Timecoddal:
https://www.youtube.com/watch?v=I5mRwzVvFGE&feature=youtu.be&t=7m55s

Úgy "csempészi ki" az értéket az elvileg végre nem hajott ágból, hogy a kiolvasott titkos bájtot az eldobott ágban címzésre használja, pl kiolvas 25-öt egy területről amiről nem szabadna neki, ezután megcímzi a 25*N-edik lapot a memóriában. A program normál flow-jában ellenőrzi, melyik memóriaterülethez mennyi ideig tart a hozzáférés (hanyadik lap volt már cache-elve), és a 25-öshöz gyorsabb lesz a hozzáférés mint a többihez.
5

HT

Hidvégi Gábor · 2018. Jan. 29. (H), 11.20
Kíváncsi vagyok, a Hyperthreading túléli-e ezt a botrányt.
6

Nem kell igazából HT a

BlaZe · 2018. Jan. 29. (H), 22.21
Nem kell igazából HT a támadáshoz, és az igazi problémát itt nem is a desktop userek, hanem főleg a virtualizált környezetek tapasztalják. A patchek megoldják a problémát, a user gyakorlatilag nem tapasztal teljesítménycsökkenést, és tud profitálni a HT-ből. Virtuális környezetben, vagy nagyon kihegyezett célkörnyezetben viszont nagyon nagy impactje is lehet a patcheknek (többtíz százalékos visszaesés is akár). Persze ahol nem update-elik a patchet, ott ez persze veszélyforrás.

Úgyhogy szerintem a HT túléli a botrányt. Számomra az a kérdés, hogy mekkora teljesítmény visszaeséssel tudják majd architektúra szinten javítani a hibát és hogy mikor.
7

A HT miatt én sem aggódnék,

hóhér · 2018. Jan. 29. (H), 22.56
A HT miatt én sem aggódnék, de a userek biztosan nem fogják megérezni? Modern víruskeresők hogy működnek? Amik sandboxot használnak... mert én tartok tőle, hogy azok ugyanúgy lassulni fognak, ahogy a virtuális gépek.
Vagy nem...
8

Kimutatható a lassulás

BlaZe · 2018. Jan. 29. (H), 23.59
Kimutatható a lassulás desktopon is, egész biztos. Lehet mondjuk X%-kal tovább fut egy víruskeresés/ellenőrzés, de ez nem feltétlenül kell blokkolja a usert. Meg ott nincs SLA, virtuális környezetben meg azért előfordul. Illetve akár drágíthatja is a virtualizációs költségeket, mert már több node-ot kell használjon ugyanahhoz a loadhoz. A latency érzékeny feladatoknál meg aztán még izgibb dolgok lehetnek...
9

HT

Hidvégi Gábor · 2018. Jan. 30. (K), 09.30
Bocsánat, pontatlanul fogalmaztam.

A botrányon az Intel és a processzorgyártók botrányát úgy általában értettem.

A HT azért érdekes, mert egy virtuális magról van szó benne, ami megosztott erőforrásokat (cache, busz) használ a fizikai maggal.
10

Igen, de a probléma az, hogy

BlaZe · 2018. Jan. 30. (K), 11.14
Igen, de a probléma az, hogy a processzek olyan memóriaterületet is el tudnak érni, amihez nincsen jogosultságuk, és a CPU-nak ezt meg kéne akadályozza. Ez HT-től függetlenül létező dolog, alapvető address space izolációs gond van. Ezért nem gondolom, hogy a HT ne élné túl.
11

HT

Hidvégi Gábor · 2018. Jan. 30. (K), 12.54
A HT-nek valószínűleg nincs köze a Spectre-höz. Csak arra szerettem volna rávilágítani, hogy a HT-ben a megosztott erőforrások miatt esetleg - a Spectre-höz hasonlóan - át lehet kukkantani más processzek memóriaterületére, cache-ébe.
12

Ami a cache-be bekerül, az

BlaZe · 2018. Jan. 30. (K), 14.49
Ami a cache-be bekerül, az látható minden mag számára, nem csak a HT pár számára. És nem csak HT szálat, de egyéb processzt is lehet bármikor ugyanarra a magra migrálni, ami nem feltétlenül kell egy teljes cache flush-sel járjon.

Az alkalmazások saját virtuális címtérben dolgoznak, amit még fel kell oldani fizikai címre. Hiába címzed meg ugyanazt a címet két processzből, más fizikai cím lesz mögötte, más tartalommal. Akkor is, ha cache-ben esetleg ott van az, amit szeretnél "ellopni".

Persze HT esetén is kiderülhet még bármi implementációs/design gubanc, de maga a HT nem szabadna ilyet okozzon a fentiek miatt.
13

Ezzel kezdtek

Hidvégi Gábor · 2018. Jan. 31. (Sze), 10.04
Már volt ilyen bug, igaz, hogy 2005-ben.
14

Ezt most találtam

Hidvégi Gábor · 2018. Feb. 1. (Cs), 09.28
Hetes pont:
Indirect branch poisoning is even more challenging to mitigate in software. It might be possible to disable hyperthreading and flush branch prediction state during context switches, although there does not appear to be any architecturally-defined method for doing this
(A Spectre elleni védekezésről szól.)