slacky.eu

ponce ha scritto:

Meskalamdug ha scritto:a)Fare uscire la 15
b)Distribuire gcc7 come fix per 14.2,con tutti gli eventuali pacchetti da ricompilare,questa è la soluzione più scomoda
ma anche la più sicura.

non credo che sarai accontentato, almeno in tempi brevi: per la 15 credo manchi ancora un po' (e' probabile che ci vada a finire anche kde5, oltre alle varie ricompilazioni che probabilmente saranno fatte per spectre) e patchare la 14.2 e' improponibile, andrebbe ricompilata quasi tutta, non sono mai stati fatti interventi massivi in quel senso su una stabile.

E le altre distro stabili che tu sappia,a che punto sono?

che io sappia, nessuna di loro ha aggiornato il compilatore nel loro ramo stabile, ma magari mi sono perso qualcosa...

rik70 ha scritto:Uhm... io non è che c'ho capito molto di questa storia. Il test da questo risultato:

Codice: Seleziona tutto

Kernel is Linux 4.9.78-riklts #1 SMP Sun Jan 28 15:45:08 CET 2018 x86_64
[...]
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)

Dunque vulnerabile solo alla variante 1 o mi son perso qualcosa?

che compilatore e' stato usato per compilare il kernel dove hai fatto girare il test?

Secondo: quali sarebbero gli aggiornamenti firmware rilasciati da intel che causerebbero riavvii del sistema e perdita dati?

alcuni firmare specifici inclusi nella loro release 20180108, infatti sono tornati alla 20171117.

ponce ha scritto:che io sappia, nessuna di loro ha aggiornato il compilatore nel loro ramo stabile, ma magari mi sono perso qualcosa...

Quindi ci troviamo con tutte le distro linux vulnerabili?
Magari anche da remoto

ponce ha scritto:che compilatore e' stato usato per compilare il kernel dove hai fatto girare il test?

gcc (GCC) 7.2.1 20180116 su Archlinux.

ponce ha scritto:alcuni firmare specifici inclusi nella loro release 20180108, infatti sono tornati alla 20171117.

Ok, grazie.

Meskalamdug ha scritto:Magari anche da remoto

direttamente da remoto non credo, essendo le vulnerabilita' relative alle pagine di memoria per usarle dovranno prima ottenere un account locale...

rik70 ha scritto:gcc (GCC) 7.2.1 20180116 su Archlinux.

allora non c'e' poi tutta questa differenza nell'usare slackware current, no?

ponce ha scritto:allora non c'e' poi tutta questa differenza nell'usare slackware current, no?

Esatto, mi sa che vado di upgrade
Tu dici che Pat non sarà costretto ad aggiornare anche le versioni attuali?

Tornando poi sulla questione: ma è già stato rivelato qualche exploit che sfrutta queste vulnerabilità?
E sopratutto: intel sarà costretta in qualche modo (giustizia americana?) a "richiamare" le CPU difettose - almeno le ultime - e sostituirle con delle nuove?
Questa storia secondo me è una bomba a orologeria.

ponce ha scritto:

Meskalamdug ha scritto:Magari anche da remoto

direttamente da remoto non credo, essendo le vulnerabilita' relative alle pagine di memoria per usarle dovranno prima ottenere un account locale...

Meltdown, la vulnerabilità specifica delle CPU Intel, e Spectre versione 1 permettono exploit dimostrati tramite javascript, quindi tramite browser. Per Meltdown c'erano esempi di exploit tramite javascript già il giorno dopo l'annuncio ufficiale.

Spectre 2 in teoria può riguardare i browser, ma è molto difficile da effettuare con successo, perché bisogna conoscere con esattezza la struttura della memoria allocata. Di fatto Spectre 2 è possibile solo in un ambiente controllato. Spectre 1 si mitiga solo con patch specifiche dei programmi affetti. Meltdown con l'aggiornamento del microcodice della CPU.

La grossa differenza tra Meltdown e Spectre è che Meltdown consente di scalare i privilegi e leggere tutta la memoria, anche quella del kernel. Spectre 1 si limita al processo corrente, mentre Spectre 2 ad altri processi, ma solo se si conosce come è allocata la memoria nei processi attaccati. Spectre 1, mi autocito da pagina 1, è pericoloso solo per gli interpreti di codice (purtroppo ce n'è uno anche nel kernel, anche se è disabilitato di default) e le macchine virtuali.

Segnalo che ho trovato un ottimo "tester" per spectre.
Fa un "attacco" sul vostro pc,se è vulnerabile riporta nell'output
"The Magic Words are Squeamish Ossifrage."
messo in colonna,altrimenti dei semplici "?"

https://github.com/Eugnis/spectre-attack

conraid ha scritto:

Codice: Seleziona tutto

# ./spectre.out 
Putting 'The Magic Words are Squeamish Ossifrage.' in memory, address 0x400d70
Reading 40 bytes:
Istruzione non consentita

Mi sembra di capire che la tua cpu sia immune.
Che cpu è?

non credo che questo codice sia efficace per testare la copertura da spectre v2 (l'unica implementata, al momento): a quel che sembra funziona solo attaccando il solito processo (non legge la memoria di un altro processo).

https://github.com/Eugnis/spectre-attack/issues/19

ponce ha scritto:non credo che questo codice sia efficace per testare la copertura da spectre v2 (l'unica implementata, al momento): a quel che sembra funziona solo attaccando il solito processo (non legge la memoria di un altro processo).

https://github.com/Eugnis/spectre-attack/issues/19

Come ho già fatto notare, l'attuazione di Spectre v2 ha come prerequisito imprescindibile che l'aggressore conosca esattamente la struttura della memoria del processo attaccato. È praticamente impossibile da effettuare, se non con attacchi molto specifici per obiettivi molto specifici ed è a tutt'oggi indimostrato in casi reali, anche simulati.

Meskalamdug ha scritto:

conraid ha scritto:

Codice: Seleziona tutto

# ./spectre.out 
Putting 'The Magic Words are Squeamish Ossifrage.' in memory, address 0x400d70
Reading 40 bytes:
Istruzione non consentita

Mi sembra di capire che la tua cpu sia immune.
Che cpu è?

Intel(R) Core(TM)2 Duo CPU T7100

Da altri test risultava vulnerabile. Ora ho kernel e gcc aggiornati però.

per esempio il tool di Intel restituisce questo:
Tra l'altro come installo i drive mcode?
la vecchia modalità, anche se c'è compilato il supporto, da errore e infatti nel dmesg ho

quindi ho copiato come indicato nel readme ma poi