Visualizza messaggio singolo
Vecchio 06-02-2018, 12.23.30   #36
LoryOne
Gold Member
WT Expert
 
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.503
LoryOne è un gioiello raroLoryOne è un gioiello raroLoryOne è un gioiello raro
Rif: Meltdown, Spectre e perché Microsoft mi ha convinto a desistere.

Tratto da qui: https://meltdownattack.com/

What is the difference between Meltdown and Spectre?
"Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory."
Qui si sta parlando del kernel del S.O.
Liberamente tradotto, Meltdown rompe quei meccanismi che mantengono le applicazioni al di fuori della possibilità di leggere indirizzi di memoria arbitrari. Arbitrari significa TUTTO l'address space.
Il kernel address space e lo user address space sono tenuti distinti dal S.O. che quando carica il sistema DEVE necessariamente avere i privilegi al di sopra dell'admin, ossia SYSTEM.
"Consequently, applications can access system memory."
Di conseguenza, le applicazion in user space possono bypassare i meccanismi di protezione del kernel per leggere memoria in kernel space.
Fin qui sembrerebbe tutta colpa del S.O., eppure è qui che casca l'asino: è la logica operazionale interna del processore che lo consente, bypassando il S.O.
Ecco perchè deve essere aggiunto codice al kernel per prevenire cio che il processore consente al di la dei limiti imposti dal sistema.
Microcodice e patch del S.O. devono lavorare in tandem, poichè l'uno non esclude l'altro.
"Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location."
Spectre mette a disposizione ad applicazioni diverse, di accedere ad address space in memoria che diviene condivisa tra le applicazioni <<e aggiungo che sempre grazie al S.O. dovrebbe essere distinta>>. Entrambi gli attacchi fanno uso del side channel (canale di comunicazione tra address space) per ottenere le informazioni tra locazioni di memoria accessibili.
Fin qui sembrerebbe tutta colpa del S.O., eppure è qui che casca l'asino: è la logica operazionale interna del processore che lo consente, bypassando il S.O.
Ma allora il software non c'entra nulla ?
Si, eccome: Uno script fa uso di istruzioni che mettono il processore in condizione di fare uso della sua logica funzionale fallata, pertanto accedono ad informazioni che il S.O. considera protette e che invece non lo sono più a causa del processore.

Torvalds dice ad Intel che il suo microcodice è spazzatura, è colpa dell'hw, ma il kernel viene rivisto ed appesantito. Lo stesso fa Microsoft, che però non può dare addosso ad Intel.
Intel asserisce che quel che è fatto è fatto, si rivedrà la logica operazionale nel processo di produzione futuro per le future CPU.
Nel mezzo si pone AMD che invece non risulta fallace per lo stesso numero di varianti che affliggono Intel e che, per tale motivo, potrà essere in posizione di vantaggio nel futuro acquisto da parte dell'utenza...Mah, previsioni un po troppo rosee, visto che non è immune al 100% ed il processo produttivo è avviato anche per lei.
Porre un rimedio al volo lato software è la "soluzione" (chiamiamola palliativo) nell'immediatezza della circostanza.
Al momento, non si evidenziano colpi riusciti, ma se ci fate caso chiunque, in tutti questi anni, potrebbe aver scritto codice all'apparenza innocuo (magari anche considerato spazzatura) per applicazioni considerate lecite senza nemmeno rendersi conto di aver sollevato l'eccezione e non essere stato in grado di sfruttarla...oppure si ?: I processori incriminati, sono anni che si comportano così.
___________________________________

Practice feeds Skill,Skill limits Failure,Failure enhances Security,Security needs Practice
LoryOne non è collegato   Rispondi citando