Un bug hardware affligge la memoria virtuale delle CPU Intel

[cdimauro]

Originariamente inviato da MiKeLezZ

Chi ci dice i prossimi prodotti (Cannonlake mi pare) saranno esenti?
Sono già in stampa da un pezzo, è probabile quelli esenti saranno i prossimi ancora.

A parte il fatto che di Cannonlake ormai si sono perse completamente le tracce (IMO vedremo direttamente Ice Lake, di questo passo), in genere è sufficiente un nuovo tape-out (circa 3 mesi) per sistemare questo tipo di problemi, per cui è plausibile che verrà commercializzata direttamente la versione fixata.

Comunque oramai è sicuro il calo del 5% su un po' tutto, in pratica è come tornare indietro di una generazione di processore...

Sembra che i cali siano ben più contenuti con le applicazioni reali.

[tallines]

Originariamente inviato da ulukaii

Mmh, quindi parrebbe che hanno rilasciato un nuovo modulo per il controllo (1.0.1). A quel punto non so se è meglio tenerli "affiancati" oppure disinstallare il precedente

Uninstall-Module SpeculationControl

e poi installare quello nuovo.

PS: ho appena disinstallato il vecchio e resintallato il nuovo (1.0.1) e ti confermo anche che lanciandolo l'errore è ora sparito

Come hai fatto ?

Se puoi dirmi i comandi che hai dato

[cdimauro]

Originariamente inviato da Marco71

...segno che tutta la teoria informatica e matematica delle validazioni funzionali "esaustive" o pseudo tali delle microarchitetture dei cpu non sono servite ne servono a niente...da Pentium in poi...per Pentium 4 solo una validazione esaustiva della fpu proprio per il motivo accennato sopra (FDIV bug). Le cpu sono enormi macchine a stati "finiti" e se non hai il "tempo" di poterle verificare in modo esaustivo con tutte le possibili combinazioni di operandi, modi di indirizzamento, istruzioni ecc. non c'è verso...arrivano le lunghissime sequenze di errata...
E questa è oltre la capacità (sembra almeno sia così) di correzione tramite aggiornamento in fase di cold boot o riavvio a caldo del microcodice di sistema.
Ormai la complessità è fuori controllo...nessuno è più sicuro di poter creare una cpu che in fondo alla storia sia immune da deviazioni dal comportamento nominale di progetto.
"Curiosamente" un problema a carico del TLB delle cpu Core 2 venne già corretto a tempo debito..
Sono curioso di vedere bene "di cosa si tratta"...nel dettaglio...
Le penalizzazioni spero vengano ridimensionate.

Marco71.

Le CPU, come le applicazioni, sono divenute molto complesse, e una verifica formale del loro funzionamento è praticamente impossibile, se non per core microscopici.

Dubito che in futuro la situazione possa migliorare.

D'altra parte è anche vero che vogliamo sempre migliori prestazioni, per cui... ce le cerchiamo.

[ulukaii]

Originariamente inviato da tallines

Come hai fatto ?

Se puoi dirmi i comandi che hai dato

Prima ho fatto la disinstallazione del modulo già installato (1.0.0):

Uninstall-Module SpeculationControl

Poi ho reinstallato quello nuovo (1.0.1):

Install-Module SpeculationControl

Quindi il solito per le policy (con relativa conferma):

Set-ExecutionPolicy -ExecutionPolicy Bypass

Rilanciato il modulo per il controllo:

Get-SpeculationControlSettings

Infine, ripristinato le policy (con relativa conferma):

Set-ExecutionPolicy -ExecutionPolicy Restricted

[cdimauro]

Originariamente inviato da WarDuck

Non c'è mai stato bisogno. Si tratta di un trucco adottato per migliorare le prestazioni, e fino ad oggi questo ha funzionato alla grande, perché si faceva affidamento ai meccanismi di protezione hardware.

Se un bug hardware della CPU fa si che questi meccanismi di protezione hardware vengano meno, c'entra poco l'architettura del SO, sia esso monolitico o microkernel.

Senz'altro, ma i microkernel delegano il più possibile le operazioni alla userland, quindi in linea teorica si dovrebbero effettuare meno syscall, e dunque questa problematica dovrebbe incidere meno.

[Gyammy85]

Ho aggiornato...prove al volo con superpi e doom, mi sembra non sia cambiato niente

[s-y]

devo dirmi favorevolmente sorpreso dal servizio al riguardo che hanno appena dato al tg1
ovviamente tutto molto semplificato, ma senza fare il buglione che hanno fatto molti altri

[insane74]

Originariamente inviato da cdimauro

A giudicare dalle pagine che descrivono il problema e dagli esempi mostrati per sfruttare la falla, dubito che uno script Javascript sia in grado di sfruttarla in maniera così semplice.

Per le macchine server che girano in ambiente virtualizzato sì, sicuramente, perché non hai il controllo degli eseguibili (malware) che potrebbero far girare.

Ma in ambito desktop la vulnerabilità è sfruttabile passando dai soliti attacchi da remoto che consentono di eseguibile codice malevolo, e dunque da un insieme di ben note applicazioni "a rischio": browser, office, lettori PDF, ecc..

Penso che con Windows a 64 bit si potrebbe risolvere il problema prendendo opportune precauzioni, anche senza far ricorso alla patch. Comunque devo investigare se anche Linux a 64 bit opera allo stesso modo.

EDIT. Ovviamente mi riferisco alla variante 3 delle vulnerabilità: quella che consente di leggere la memoria del kernel. Per le varianti 1 e 2 praticamente tutti i processori ne sono affetti.

Si quando ho scritto quel post negli articoli si parlava appunto anche di “exploit sfruttabile anche da script javascript” ma poi leggendo nel dettaglio link successivi la cosa sembra un po’ più complessa da implementare.

[alexx88]

un link diretto del download per WIN 10 64Bit ? Grazie

[cdimauro]

Originariamente inviato da Ryddyck

... http://www.blackhat.com/docs/us-16/m...-Intel-TSX.pdf

Scusami, ma quale sarebbe il problema? E' così che funziona la memoria transazionale, e questo a prescindere dalla specifica implementazione, e persino dall'architettura in esame (altre ISA hanno tecnologie simili a TSX di Intel).

Quindi, cosa ci sarebbe di sbagliato in TSX? E cosa proporresti per risolvere la problematica in oggetto (attaccare KASLR, e in generale ASLR)?

[AnthonyTex]

Quindi per "fixare" la vulnerabilità "spectre" si ha bisogno di un update del Bios? Campa cavallo

[tallines]

Originariamente inviato da ulukaii

Prima ho fatto la disinstallazione del modulo già installato (1.0.0):

Uninstall-Module SpeculationControl

Senza scrivere 1.0.0, giusto ?

Originariamente inviato da ulukaii

Poi ho reinstallato quello nuovo (1.0.1):

Install-Module SpeculationControl

Anche qui senza scrivere 1.0.1

Originariamente inviato da ulukaii

Quindi il solito per le policy (con relativa conferma):

Set-ExecutionPolicy -ExecutionPolicy Bypass

Rilanciato il modulo per il controllo:

Get-SpeculationControlSettings

Infine, ripristinato le policy (con relativa conferma):

Set-ExecutionPolicy Undefined

Ho fatto come hai detto .

Al posto degli ultimi tre comandi si poteva dare

anche solo questo o no ? > Get-SpeculationControlSettings

Grazie ulukaii

Questo è il risultato, come è andata ?





I tre asterischi dei suggerimenti dicono

- il primo che devo fare l' update del Bios ok

- il secondo che devo installare gli ultimi updates di Windows, with support for speculation control mitigations

- che trovo andando nel link del terzo asterisco, ammazzatèoooo........

PS > comunque se prima dell' aggiornamento, tutte le voci erano False, quindi ok

adesso dopo aver aggiornato alla build 16299.192, la voce Hardware requires kernel VA shadowing è su False, come prima e va bene

sono uscite 4 voci > True :

- una è la scritta in verde

- una è l' ultima delle cinque righe, scritta in rosso

- e due nella lista

[Amorph]

Originariamente inviato da alexx88

un link diretto del download per WIN 10 64Bit ? Grazie

qui li trovi tutti http://www.catalog.update.microsoft....px?q=KB4056892

[Averell]

Originariamente inviato da AnthonyTex

Quindi per "fixare" la vulnerabilità "spectre" si ha bisogno di un update del Bios?

è si, cosi' sembra ...


Quanto poi realmente siamo esposti nel frattempo nonostante l'applicazione della patch (parlo di MS e i sistemi Windows), boo

[VanCleef]

Configurazione in firma...

PS C:\WINDOWS\system32> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is enabled: False

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: False

Suggested actions

 * Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation.
 * Install the latest available updates for Windows with support for speculation control mitigations.
 * Follow the guidance for enabling Windows support for speculation control mitigations are described in https://support.microsoft.com/help/4072698


BTIHardwarePresent             : False
BTIWindowsSupportPresent       : False
BTIWindowsSupportEnabled       : False
BTIDisabledBySystemPolicy      : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired              : False
KVAShadowWindowsSupportPresent : False
KVAShadowWindowsSupportEnabled : False
KVAShadowPcidEnabled           : False

[Averell]

Originariamente inviato da tallines

Questo è il risultato, come è andata ?

10 gg di riposo e brodino a pranzo e cena

[albertus82]

Originariamente inviato da Amorph

qui li trovi tutti http://www.catalog.update.microsoft....px?q=KB4056892

Io sono sul branch for business, versione 1703, e sto scaricando https://www.catalog.update.microsoft...px?q=KB4056891

[tallines]

Originariamente inviato da Averell

10 gg di riposo e brodino a pranzo e cena

Ehhh va bene

Penso che già l' aggiornamento del Bios, basti,

comunque la voce principale è su False

Pensa che prima dell' aggiornamento, il Report era identico a quello di VanCleef

Però anche VanCleef ha le stesse Suggested actions, che mi sono uscite nell' ultimo report e che nel mio primo Report non c' erano...........

Il Report prima dell' aggiornamento è questo >

https://www.hwupgrade.it/forum/showp...&postcount=247

A te come è andata ?

[ThEbEsT'89]

Originariamente inviato da Averell

per me è questa:



https://twitter.com/epakskape/status/948781605790695424



Cioè:
no BIOS nuovo no party

Buonanotte allora, vorrà dire che a parte le ultimissime generazioni gli altri per essere al 100% sicuri dovranno aggiornare la piattaforma

Meno male che Spectre da quello che leggo pare essere più di difficile implementazione, quasi roba teorica.

[cdimauro]

Originariamente inviato da akumasama

Non possono fixare l'hardware ovviamente, quindi l'unica è coprire rilasciando aggiornamenti del Kernel.
Un "vero" fix richiederebbe un rework completo del Kernel, che non è ragionevole aspettarsi in tempi brevi (ammesso che avvenga mai).

Forse non serve questa patch né un rework completo del kernel. E' una cosa su cui sto rimuginando da un po', guardando gli esempi che spiegano come funziona la falla, in quest'articolo, che è quello che ha messo in luce la famigerata variante 3 AKA Meltdown.

Ci penso ancora un po', leggendo qualche altra pagina che parla dell'argomento, e se sarà il caso provvederò a rendere pubblica l'idea in modo che possa essere implementata nei kernel dei vari s.o..