PDA

Visualizza versione completa : Meltdown, Spectre e perché Microsoft mi ha convinto a desistere.


retalv
15-01-2018, 03.07.14
Come tutti ormai dovrebbero già sapere, il Google's Project Zero security team ha scoperto e pubblicato alcuni bugs presenti in praticamente tutte le CPU Intel prodotte dal 1995 ad oggi (seguite parzialmente anche da AMD) e nell'ultimo mese sia i produttori di sistemi operativi (Windows, Linux e Apple) sia i produttori di browser, sistemi virtuali come VMware (Oracle Virtualbox non pervenuta... hanno scoperto il cloud prima di fallire) e hardware si stanno prodigando per "mitigare" il problema in vari modi sia sui sistemi operativi sia su software (browser) e drivers per i propri hardware (vedi NVIDIA) che malgrado le relative CPU interne non siano affette da quei problemi, entrano pesantemente e direttamente in contatto con CPU e kernel delle nostre macchine.

Escludendo NVIDIA che vuole semplicemente mettersi al riparo da eventuali azioni legali visto il pesante e continuo colloquio tra la "nostre" macchine e i loro server (si risolve comunque disabilitando il domine-deus dei pacchetti di aggiornamento-statistiche-e-qualt'altro dal pacchettone dei drivers ;) rinunciando a un piccolo automatismo di aggiornamento a favore della sicurezza ... ed altro...) tutti gli altri cercano di "mitigare" il problema con patch al sistema operativo (utilizzando sistemi più o meno incisivi), ma si guardano dal dare risalto al fatto che tutte le loro mitigazioni non servono praticamente a NULLA senza un aggiornamento del BIOS da parte dei produttori di harware delle nostre matherboard: lo dicono, ma mantenendo sempre un basso profilo in modo che il clamore resti confinato e risulti "gestibile". L'unico che forse ha qualche possibilità è Linux con le modifiche al kernel (ancora però da venire visti gli intoppi con AMD) e il firmware aggiuntivo applicato ad ogni avvio.

Per fare un piccolo esempio, la mia ormai più che vetusta materboard ASUS ha ricevuto il primo aggiormanento BIOS nel dicembre 2010 e l'ultimo nel novembre 2012 e causa obsolescenza mai più ne riceverà, ovviamente...

Malgrado il clamore sensazionalistico a cui siamo abituati su TUTTI i media di informazione (sparala grossa ma cerca di essere il primo anche se racconti balle) questa sarebbe, ed è, una grossa falla che interessa principamente il mondo server, dove la mamma degli utenti imbecilli è perennemente incinta e non vede l'ora di farsi notare su sistemi informatici server spesso non presidiati.

Intendiamoci... anche un utente Desktop se è un tantinello sprovveduto può incappare in un incidente di percorso, ma considerando che gli attacchi possono essere eseguiti solo in locale o solo se il sistema è già compromesso da altri fattori che permettano l'accesso remoto, prima che a tutti noi succeda di farsi leggere dalla memoria la password di accesso all'home banking attendiamo veramente il prossimo allineamento dei pianeti (ho letto anche chi consiglia l'uso dell'autenticazione a due fattori "alla Gmail" o come spesso si usa in home banking già da anni... :asd:).

Il vero problema è che malgrado l'utente comune non si accorga praticamente di nulla, la CPU di un sistema Windows 10 con CPU abbastanza recente a cui è stata applicata la pezza (per Win 7 kb4056894) perde alcuni punti percentuali e ancora peggio per Win8 o Win7 con CPU vecchiotte, con più di una decina in termini di velocità di calcolo.

Da un paio di mesi avevo ricominciato ad aggiornare Windows 7 sul desktop (Windows 10 è solo sul portatile e visto come lo uso poco mi importa se perdo in velocità) ma visti gli sviluppi ho deciso nuovamente di interrompere gli aggiornamenti su una macchina che per il mio uso va ancora bene (i5 2500K) ma della quale non permetto a Microsoft di lasciar mangiare Mhz senza una motivazione logica se non un poco discreto lavaggio di coscienza.

Spero che quanto scritto possa essere utile per farsi una idea sui fatti. Se siete di parere avverso... il forum servirebbe proprio a questo... ;)

Morpheus-89
15-01-2018, 09.49.15
Io più che per i computer personali ho appunto qualche piccola apprensione per i server, ho diverse macchine virtuali in hosting, e non so se il fornitore (spero di si) abbia provveduto ad aggiornare il tutto per cercare di porre rimedio a Meltdown

borgata
15-01-2018, 10.45.42
@retalv
Gli aggiornamenti del sistema operativo sono sufficienti ad isolare da meltdown, che è forse la vulnerabilità più pericolosa per facilità di sfruttamento. Quindi sono decisamente consigliati.
L'impatto sulle prestazioni c'è ma solo in determinati contesti e tutto sommato non pesante come quello relativo all'isolamento completo. Per un utente consumer con tutta probabilità è abbastanza trascurabile nell'uso quotidiano.

La falla può essere sfruttata non solo in locale ma anche tramite browser (o altri software con accesso in rete), motivo per il quale sono uscite rapidamente delle patch anche per questi, che però sono solo in grado di mitigare il problema (ossia rendere più difficile l'exploit).

Queste sono delle falle molto gravi e purtroppo, su processori Intel, non troppo difficili da sfruttare. Io non prenderei la cosa alla leggera.
Certo che Intel, dopo il problema dell'ME/TXE, non ci sta facendo una gran bella figura ultimamente.

LoryOne
15-01-2018, 12.44.42
Ottimo articolo che consiglio di leggere: https://www.extremetech.com/computing/261792-what-is-speculative-execution
Siccome il contenuto è molto tecnico e rivolto ad un pubblico specializzato, vediamo "grosso modo" di aggiungere qualche info perchè l'articolo risulti più comprensibile a tutti.
1 - Un processore esegue una istruzione per volta e non esegue la prossima fino a che non è completata la prima, quindi più istruzioni ci sono da elaborare, più il processore deve funzionare velocemente: l'aumento della frequenza di clock era la soluzione più evidente, ma non la più performante a scapito di altre problematiche legate al surriscaldamento della componentistica interna.
2 - La potenza termica dissipata è nemica dei componenti elettronici, quindi quale soluzione adottare ?
Rivedere l'architettura per mantenere la frequenza di clock entro certi limiti ed aumentare la potenza elaborativa.
3 - Suddividere l'elaborazione di più istruzioni in un modulo a più stadi (le pipeline) sfruttando il più possibile i cicli di clock singolarmente
E veniamo al diagramma indicato:
4 - Le pipeline devono passare per forza di cose attraverso 4 stadi indicati che ricalcano il modo di operare del processore per quanto attiene l'acquisizione del dato, l'operazione da eseguire su di esso, la memorizzazione del suo stato e la prossima operazione da eseguire.
Nel grafico abbiamo 4 istruzioni che attraverso la pipeline giungono allo stato finale di elaborazione con un numero di cicli di clock ridotti rispetto a quelli necessari se privati delle pipeline.
Il processore, nell'unità di tempo, avrà sempre istruzioni e dati differenti da scomporre ed eseguire ed identificando quelle istruzioni che maggiormente vengono eseguite a scapito di altre, potrebbe risultare più veloce per certe operazioni che si presentano con maggiore frequenza.
Cosa mettere in esecuzione per prima nella pipeline è costituito dal branch prediction: L'esecuzione "azzeccata" in seguito al branch risulta speculativa, cioè non è detto sia sempre la scelta migliore.
L'articolo riporta un accuratezza del branch prediction pari al 95%, quindi quasi sempre.
Fin qui tutto bene, ma...come agisce internamente il processore in modo del tutto autonomo secondo specifiche architetturali ?
"The reason Meltdown causes such unique headaches for Intel is because Intel allows speculative execution to access privileged memory a user-space application would never be allowed to touch."
La ragione per cui Meltdown causa così tanti malditesta ad Intel è perchè consente l'esecuzione speculativa per consentire ad un applicazione in user-space di accedere a locazioni di memoria privilegiate, cosa che non normalmente non dovrebbe avvenire.
Come sarebbe a dire ? Non basta il S.O. che identifica privilegi utente e conseguenti accessi privilegiati a funzionalità precluse all'utente ma non al sistema, qualsiasi S.O. si tratti ?
Evidentemente no.
Si legge:
"Code that’s running under speculative execution doesn’t do the check whether or not memory accesses from cache are accessing privileged memory. It starts running the instructions without the privilege check, and when it’s time to commit to whether or not the speculative execution should be continued, the check will occur. But during that window, you’ve got the opportunity to run a batch of instructions against the cache without privilege checks. So you can write code with the right sequence of branch instructions to get branch prediction to work the way you want it to; and then you can use that to read memory that you shouldn’t be able to read."
Le operazioni che avvengono internamente ai processori Intel in materia di speculative execution, non eseguono il controllo sulla tipologia di informazioni presenti in cache, poichè non effettuano il distinguo tra memoria privilegiata e non nel lasso di tempo che intercorre tra il commit (quindi l'ultimo step) e l'inizio della nuova trafila. Pertanto è possibile scrivere codice che renda possibile accedere ad informazioni in memoria che non dovrebbero essere leggibili.
e poi ancora:
"The speculative prediction implementations of other CPU vendors don’t allow user-space applications to probe the contents of kernel space memory at any point"
L'implementazione della speculative execution da parte di altri produttori non consentono ad applicazioni in user-space di accedere ai contenuti della memoria protetta in nessuno punto, aggiungo quindi in nessuno step della trafila necessaria al completamento branch-prediction->speculative execution.

retalv
15-01-2018, 14.46.51
Stiamo andando troppo sul tecnico alla "Dott. Balanzone" ... trovo molto più interessante lo strato più alto con cui si esprime Microsoft...

https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/

...da cui ...

https://support.microsoft.com/en-us/help/4073757/protect-your-windows-devices-against-spectre-meltdown

... da cui ...

https://www.asus.com/News/YQ3Cr4OYKdZTwnQK

... ed è la stessa Asus a dire che per i suoi sistemi serve un aggiornamento BIOS per applicare il microcode al "silicio" ad ogni avvio. Peccato che per i vecchi sistemi/materboard non ci sarà alcun aggiornamento.

Capisco che ormai i browser che contano sono pochi, ma che debba scegliere forzatamente quelli canonici per tentare di arginare una falla della CPU ci riporta veramente ai minimi... rimane comunque una falla a livello locale che è attivabile da remoto previa vulnerabilità pregressa. Se sapete schivare le "cacche" del WEB schiverete anche questa... ;)

Forse (ci credo poco) ora che è pubblica proveranno ad usarla, ma francamente sembra più una trovata commerciale di qualche tipo... in 20 anni non è stata mai usata e figuriamoci se dovevano aspettare Google's Project Zero per scoprirla e usarla... :mm:

RunDLL
15-01-2018, 14.52.04
La preoccupazione più grossa riguardo ai server è se questi andranno incontro a notevoli rallentamenti, una volta fatti i dovuti aggiornamenti che siano a livello di sistema operativo o bios, di cui si parla tanto, dove tanto per cambiare ci sono opinioni opposte e discordanti.

LoryOne
15-01-2018, 17.06.42
Il calo prestazionale sui server sicuramente ci sara', ma in maniera proporzionale al carico di lavoro (presumo soprattutto CGI, SQL e TLS/SSL) ed al content switching che il processore sara' costretto a subire in ragione delle patches adottate, leggasi KAISER https://spectreattack.com/

Sicuramente, prima di ottenere il risultato sperato, il malware dovra' essere eseguito piu' volte perche' non esiste il colpo sicuro. Chiaramente, sara' piu' facile identificarne l'opera su un pc che non funga da server, piuttosto che uno che faccia parte di un cloud o un web server o un game server,ecc.

Infettare un pc con una classica mail, un utility in p2p, o attraverso una pagina web compromessa, resteranno metodologie efficaci come lo sono state fin'ora, cosi' come scalare i privilegi su un server mal configurato e/o non patchato con questa e con le precedenti patches: Quello che cambia in peggio e' la pericolosita' della minaccia che può mettere a nudo dati sensibili in una maniera del tutto nuova su hardware nuovo ma di "vecchia concezione", non certo da sottovalutare.
il dubbio più grande è: Davvero nessuno ha mai sfruttato tale possibilità, visto che è difficoltoso per un antivirus tenerne traccia ed impossibile farlo attraverso i log di sistema ?

Fossi Intel, rivedrei in parte il progetto architetturale visto che è proprio un problema hardware e nel mentre mi farebbe certo comodo che venissero adottate patches software per salvaguardare la linea produttiva ormai avviata e che sarebbe controproducente interrompere prima della revisione.
Una volta messo al corrente il produttore, poi dipende da lui non sottovalutare il problema

borgata
15-01-2018, 19.33.17
Io stavo leggendo l'articolo di arstechnica (https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/), che pare faccia ottimamente il punto della situazione.

Nel frattempo Google ha annunciato pubblicamente una patch per la seconda variante di Spectre che pare non porti a cali evidenti di prestazioni.

retalv
16-01-2018, 00.05.32
Al termine dell'articolo ventilano quanto predetto.

Fanno tutti dei bellissimi test sulle macchine più spinte impippandosene di quelle più vecchie di 2 anni e se le pezze non sceglieranno strade diverse che non rallentino le macchine, gli utenti datati saranno forse allettati a fregarsene e rimanere scoperti.

Metteteci che anche Microsoft delega i microcode agli OEM e il minestrone è completo.

Vedremo... ma a me sembra sempre più un bel modo per vendere nuovo hardware. Scommettiamo che tempo 4-6 mesi Intel uscirà con processori Meltdown-Spectre free? ;)

borgata
16-01-2018, 10.37.09
Beh, lo saranno di sicuro, dato che le piattaforme che verranno vendute saranno sicuramente già patchate, a discapito magari delle prestazioni. Ma prima che escano dei processori Intel immuni a queste vulnerabilità by design, ho idea che potrebbero passare diversi anni.

Nel frattempo AMD potrebbe avere una bella occasione per riguadagnare market share, dato che i loro processori sono interessati solo marginalmente dal problema.

retalv
16-01-2018, 11.54.31
Staremo a vedere, sarà il tempo a decretare cosa succederà realmente ...

... ma ricordo a me stesso l'episodio di quando Philips mise in commercio il primo LETTORE CD a 2.300.000,00£ c.a. nei negozi e poco dopo imparammo che il progetto FINITO era stato congelato (tenuto nel cassetto) nei 20 (venti) anni precedenti aspettando il momento propizio di calo delle vendite per il lancio sul mercato, come fanno da sempre le grosse aziende dei più disparati settori... strana coincidenza vero? ;)

borgata
16-01-2018, 12.52.09
Nel campo dei computer questo genere di pratiche sono molto, molto difficili da applicare.

La concorrenza, soprattutto oggi, c'è ed è agguerrita. Il mercato e le tecnologie si muovono molto velocemente. Avere un vantaggio e non usarlo significa rischiare di farsi raggiungere e perdere la propria posizione di vantaggio.
Le decisioni in questo campo vengono prese a lungo termine, occorrono in media cinque anni per progettare una nuova architettura e non si può rischiare di rimanere indietro, non può soprattutto un colosso come Intel che deve continuare a muovere enormi somme di denaro per andare avanti.

retalv
16-01-2018, 22.54.03
L'arte della guerra

http://www.sunzi.it/Sun%20Tzu%20(Sunzi),%20L%27arte%20della%20guerra.p df

"16. Dopo aver analizzato le situazione per rilevarne i vantaggi, il generale
deve creare le circostanze che contribuiscano a realizzare i suoi obiettivi,
schierando le truppe nel modo più opportuno.
17. Con l’espressione creare le circostanze, intendo che deve agire
rapidamente secondo ciò che è vantaggioso e assumere il controllo
dell’operazione militare nel suo insieme, organizzando le giuste mosse
tattiche.
18. Fondamentale in tutte le guerre è lo stratagemma."

Oggi parleremmo di keiretsu.

LoryOne
17-01-2018, 16.55.48
Se non ho capito un katsu correggimi: Quindi dici che è tutto pianificato con largo anticipo ?
L'arte delle guerra è essenzialmente pianificazione...
Magari ShadowBroker aveva avvertito senza rivelare nulla se non dietro corrispettivo: "sarà puro terrore" asserivano.

retalv
18-01-2018, 03.08.11
Non voglio per forza trovarci un complotto, ma la tempesta sembra proprio perfetta...

Non sono a conoscenza dello stato delle vendite sia lato consumer sia sul versante professionale/server ma a quello che ricordo (e credo di aver capito) negli ultimi 48-36 mesi i tempi di upgrade dell'hardware in generale si dovrebbero essere dilatati in modo sensibile. Se anche questo non fosse, quale modo migliore per incrementare le vendite è creare un bisogno, un'esigenza?

Quale modo migliore obbligare all'uppgrade miliardi di macchine per bugs più o meno difficilmente arginabili via software?
Se sono un datacenter, una banca o una semplice ditta con sever aperti verso l'esterno, il costo maggiore è aggiornare le macchine o il seppur remoto costo di una azione legale o perdita di guadagno per danni causa furto dati?

Ma non c'è poi bisogno di tralasciare il mondo consumer: preferiresti essere oppresso dal dubbio di lasciar leggere le tue PW del conto corrente ad un potenziale malintenzionato, scegli la strada di smettere di visitare i soliti siti porno e quelli non conosciuti per salvaguardare la sicurezza della macchina, o cerchi di cambiare macchina per continuare come sempre hai fatto? ;)

Volendo raccontare una possibile evoluzione della faccenda... da quello che ho potuto capire il produttore è da c.a. 20 anni che "sforna" CPU contenenti un errore concettuale di architettura relativo alla previsione non lineare delle operazioni di pipe (non sono un tecnico, quindi probabilmente mi esprimo ad capocchiam).

Ipotizziamo che nel 2008 si siano accorti dell'errore e siano corsi ai ripari avviando la riprogettazione dell'architettura della CPU: 9-10 anni sono sufficienti per farlo? Sei-dodici mesi sono sufficienti per riadattare le linee di produzione?

Oggi hanno bisogno di incrementare le vendite: fanno "trapelare" il problema alla più grossa impresa di comunicazione mondiale: dopo che è stato reso pubblico con plauso del mondo a chi lo ha rivelato, possono affermare in tutta tranquillità di non averne saputo nulla fino a quel momento lasciando l'utente finale con una mano davanti e una dietro ;). Aggiungi a questo il blando interesse dei produttori di sistemi operativi e OEM e il gioco è fatto.

Le macchine "fresche" risultano quantomeno "pachabili" per quanto abbiamo avuto modo di leggere in varie parti, ma quelle destinate all'obsolescenza con buon tornaconto per il produttore di CPU, i produttori di matherboard, i produttori di chipset, i produttori di memorie RAM ecc. ecc. dovranno essere sostituite, se non altro per poter dire in sede legale di aver fatto tutto il possibile per arginare il problema e far dormire un poco più tranquillo il mondo consumer.

"Come ... fa scoprire ad altri un problema che potrebbe affossarla aiutando il concorrente diretto?"

Non rimarresti fedele a una azienda multinazionale che dopo sei mesi dalla scoperta di un problema "reagisce" mettendo a disposizione dei propri clienti un nuovo prodotto (magari a prezzo maggiorato, vista l'urgenza) che risolve il problema e magari ha "qualcosa in più"?

Ovviamente tutto questo riguarda una ipotesi, possibile, ma sempre di ipotesi si tratta.

Ai posteri...

borgata
18-01-2018, 11.29.22
Ci sono anche aspetti molto negativi: un'enorme pubblicità negativa e esporsi al rischio di cause legali (già avviate diverse class action in USA). Siamo sicuri che il gioco valga la candela?

Tenendo poi conto che l'utente medio se potesse non aggiornerebbe il sistema operativo per non avere problemi, figurati quanti sentiranno l'esigenza di cambiare computer per questo.
Ovviamente rimane il settore Enterprise, ma anche io si rischia che questi si possano in qualche modo rivalere su Intel.

Tenendo poi conto che finora non esiste nulla che sia esente da queste vulnerabilità, ci sarebbe da aggiungere un pessimo tempismo. ;)

LoryOne
18-01-2018, 13.10.44
Cambiare hw si o no ?
Ragioniamo un attimo: Qualunque malware deve essere progettato per il S.O in uso che dal canto suo deve poter colloquiare con l'hw sottostante, quindi l'hw senza il software è completamente inutile in quanto non pilotabile.
Il S.O. si frappone tra le varie componentistiche hw in modo da coordinarne le funzionalità, al fine di dar vita ad un'azione concreta ritenuta utile dall'utilizzatore; Il S.O., però, ha natura virtuale, cioè non modifica in alcun modo l'hw sottostante, tranne che questo non subisca danno per usura o per vizio di fabbrica. Le azioni compiute dalle varie componenti hw sono prese in carico dal S.O. e messe in condizioni operative pre e post elaborazione, secondo precise specifiche sulle quali è possibile agire con un'operazione chiamata configurazione.
Se ne deduce che più un S.O. è configurabile, più è possibile agire sulla "presa in carico" della gestione delle operazioni svolte dall'hw sottostante e pilotate dal software, purchè le opzioni imposte siano coerenti con la funzione che ci si aspetta di ottenere.
Questo è valido fino a quando la colpa di un eventuale malfunzionamento scevra da danno causato da usura/vizio è imputabile al solo software perchè malconfigurato o configurato bene, ma bacato.
Siccome un S.O. da solo, anche se perfettamente funzionante, è inutile se non supportato da ulteriori componenti che ne amplino la fruibilità lato utente, al S.O. si affiancano le così dette utilities che altro non sono se non un ulteriore layer (o strato) virtuale che si frappone tra il S.O. e l'hw sottostante.
Ora: Che in ambito software si tratti di S.O. (o firmware), di utilities, di files archiviabili o di malware (anch'essi ricadenti tra le utilities), tutte le tipologie di layer virtuale elencate vanno installate e se installate devono essere memorizzate affinchè sempre fruibili.
Se ne deduce che fino a quando l'hw preposto svolge funzioni che sono perfettamente gestibili dagli strati virtuali che lo coordinano, senza eccedere attraverso essi, cioè sconfinando in ulteriori azioni non previste ne gestibili attraverso apposita configurazione, il connubio hw<->sw può considerarsi sicuro.
Questo è il punto fondamentale che fa della sicurezza nell'uso quotidiano dell'hw una professione, sia per quanto riguarda il produttore di software, sia per quanto riguarda l'utilizzatore; Ad entrambi è demandata la configurazione ed il controllo costanti degli apparati hw in uso o predisposti all'uso.
Ergo, si deve tenere costantemente aggiornati i software, verificarne la funzionalità e riconfigurarli se necessario, fornendo a monte nuove opzioni per la gestione ed il controllo fruibili a valle.
E' un obbligo, non una scelta.
Vero, verissimo, ma non troppo.
Fino a poco tempo fa (forse si o forse no), si è sempre imputata la colpa di un malfunzionamento (includendo anche la compromissione del sistema tra gli esiti) al software o alla configurazione dello stesso, ma laddove non sia possibile agire sull'hw perchè del tutto autonomo essendo slegato dal software installabile, configurabile, utilizzabile e controllabile, entra in gioco un altro attore: il produttore hw; Anch'egli è un professionista, altrochè se lo è.
Nel rimpallo di responsabilità alle quali ognuno degli attori coinvolti adduce scuse, giustificazioni più o meno plausibili a sua discolpa e nel mentre trova soluzioni per mettersi al riparo da danni post-rivelazione, trova posto l'hacker...un ulteriore professionista che sfrutta i punti deboli degli altri attori in gioco per metterli alla prova ed evidenziarne le carenze progettuali/funzionali.
L'operato di un hacker è un danno o un apporto benefico alla comunità dell I.T. ?
Si badi bene al fatto che un hacker opera in modi del tutto indipendenti dalla consapevolezza o meno nell'agire di chi costituisce il suo bersaglio, quindi possono verificarsi casi in cui è la sola distrazione di quest ultimo a vanificarne ogni sforzo posto in essere nell'assicurare il funzionamento regolare dell'apparato che amministra con professionalità e competenza, sia esso un semplice utente casalingo un sysadmin, un webmaster, un netadmin, ecc.
Perchè, dunque, essere costretti a cambiare hw la dove un pizzico di attenzione in più a tutti i livelli basterebbe a scongiurare l'attacco ?
Tirando le somme:
- Tieniti sempre aggiornato
- Fai attenzione a come usi l'apparato e come lo configuri per l'uso altrui
- Non è necessario, anche se consigliato cambiare l'hw.

retalv
18-01-2018, 16.05.26
Ci sono anche aspetti molto negativi: un'enorme pubblicità negativa e esporsi al rischio di cause legali (già avviate diverse class action in USA). Siamo sicuri che il gioco valga la candela.

Intel assicura i propri prodotti come error-free?
Intel ha venduto silicio con pregiudizi di funzionamento?
Con tutto il rispetto per chiunque legga, ci riteniamo esperti di marketing?
Abbiamo notizie che Intel non abbia partecipazioni incrociate con AMD?
In questa ottica (pensaci bene prima di rispondere) sei sicuro che esista un perdente e un vincitore in questa guerra?

;)

borgata
18-01-2018, 17.20.38
Sicuri al 100% no, ma se le avesse diventerebbe una questione da AntiTrust, che in USA è piuttosto agguerrita. Per cui ne dubito.
Al più si potrebbe dire che Intel possa avere interesse a mantenere a galla AMD per non incorrere nelle ire dell'antitrust, ma visto che AMD è in netta ascesa grazie ai nuovi processori, beh, direi che non è questo il caso.

I bug ovviamente esistono e ne saltano fuori di continuo, ma qualcosa di questa portata è anomalo e mette seriamente a rischio la sicurezza dei propri clienti.
Inoltre le patch possono incidere in maniera così pesante sulle prestazioni che ci sono tutte le premesse per far causa ad Intel (del resto io compro un hardware per avere certe prestazioni, se di colpo mi si dimezzano per un errore del produttore, indovina con chi me la prendo? ;) )

retalv
28-01-2018, 03.00.18
La scorsa notte, Microsoft ha rilasciato KB407813040 , che è stato specificamente progettato per disattivare il codice bacato identificato da Intel nelle patch Meltdown/Spectre.

Microsoft dice:

'Intel ha segnalato problemi con il microcodice rilasciato di recente inteso per indirizzare la variante Spectore 2 (CVE 2017-5715 Branch Target Injection) - in particolare Intel ha osservato che questo microcodice può causare "riavvii più elevati del previsto e altri comportamenti imprevedibili del sistema" e poi ha notato che situazioni come questo potrebbe causare "perdita o corruzione dei dati". La nostra esperienza è che l'instabilità del sistema può in alcune circostanze causare la perdita o la corruzione dei dati.

Mentre Intel verifica, aggiorna e distribuisce il nuovo microcodice, stiamo rendendo disponibile un aggiornamento fuori banda oggi, KB4078130, che disabilita specificamente solo la mitigazione rispetto a CVE-2017-5715 - "Vulnerabilità di iniezione di destinazione filiale". Nei nostri test questo aggiornamento è stato trovato per prevenire il comportamento descritto.

La patch è disponibile solo dal catalogo di aggiornamento (https://www.catalog.update.microsoft.com/Search.aspx?q=KB4078130) ed è la stessa patch per tutte le versioni di Windows.

Leggere la relativa pagina del supporto tecnico (https://support.microsoft.com/it-it/help/4078130/update-to-disable-mitigation-against-spectre-variant-2)...

Hanno dato un'occhiata alla patch e...

Questo aggiornamento imposta i valori del Registro di sistema ... documentati settimane fa per disabilitare la mitigazione CVE 2017-5715 in Windows. Questo aggiornamento non viene visualizzato nell'elenco degli aggiornamenti installati. Questo aggiornamento richiede i privilegi di amministratore.

Se hai evitato le patch Meltdown/Spectre di questo mese, non devi fare nulla. D'altra parte, se salti in trincea, questo potrebbe impedirti di perdere alcuni dati.

Microsoft continua a dire:

A partire dal 25 gennaio, non ci sono rapporti noti che indicano che questa variante Spettro 2 (CVE 2017-5715) è stata utilizzata per attaccare i clienti. Raccomandiamo ai clienti Windows, laddove appropriato, di riabilitare la mitigazione rispetto a CVE-2017-5715 quando Intel riporta che questo comportamento imprevedibile del sistema è stato risolto per il proprio dispositivo.

È molto probabile che quando Intel fornirà il clear per Spectre variant 2, farà parte di un'altra patch.

Morale della storia: aspettate e (parere personale) se avete Win7 smettete di aggiornare. ;)

borgata
28-01-2018, 11.17.58
Giusto un chiarimento: le correzioni al microcodice fornite da Intel per per impedire(mitigare) Spectre2 non è fornito via patch del sistema operativo, ma tramite aggiornamento bios.
Chi ha sistemi più vecchi di qualche anno fa, probabilmente non se ne deve neppure preoccupare al momento! :asd:

cippico
31-01-2018, 19.12.31
purtroppo mi sono perso in questa vicenda,nel senso che non ho potuto seguire bene...
io che ho un processore amd athlon 2 x4 630 che rischio corro in caso di NON installazione patch...capendo chiaramente quali sono quelle proposte scaricabili da winupd...

grazie

borgata
31-01-2018, 20.02.42
L'entità del rischioè difficile da prevedere, sicuramente avresti un sistema vulnerabile se non prendessi i dovuti provvedimenti.
Trattandosi di un processore AMD, sei sicuramente al riparo dalla terza variante (Meltdown), ma vulnerabile a Spectre.
La prima variante di Spectre dovresti poterla arginare con un aggirnamento del sistema operativo e senza significativi impatti prestazionali.
Per la seconda variante temo rimarrai vulnerabile, perchè, oltre la patch per il sistema operativo, occorre un aggiornamento del microcodice che al momento viene distribuito tramite un aggiornamento del bios, che per un sistema così vecchio non arriverà mai.
La buona notizia è che secondo AMD le possibilità di sfruttare la seconda variante di Spectre sui propri processori è assai remota.
Esiste poi una soluzione software per Spectre 2 resa nota da google, Reptoline, che pare possa risolvere il problema di Spectre2 con un impatto sulle prestazioni molto limitato. Da vedere se e quando verrà implementata su Windows.

Ad ogni modo ciò che emerge dalla situazione attuale è che siamo in pieno fermento, con tappabuchi temporanei che creano grossi problemi e sono poco precisi, causando problemi prestazionali maggiori di quanto dovrebbero.
Probabilmente, se non si ha motivo di pensare di essere in immediato pericolo, conviene aspettare che soluzioni migliori siano messe a punto.

cippico
01-02-2018, 17.36.03
ti ringrazio molto per ottima spiegazione...

per ora quindi meglio non pasticciare con le patch...certo...potendole riconoscere...
solitamente le installo singolarmente,solo quelle relative alla sicurezza e non tutto il pacchetto mensile...
poi faccio winupd e controllo eventuali mancanze...l'importante e' poter vedere cio' che ogni patch va a riparare...spero sia segnalato nelle delucidazioni di ogni patch da scaricare guardando il sito microsoft...
non vorrei toppare e installare mettendo a rischio rallentamento l'intero pc :wall:

sempre grazie a tutti e ciaooo :Oh-yea:

retalv
01-02-2018, 21.56.27
purtroppo mi sono perso in questa vicenda,nel senso che non ho potuto seguire bene...

Ciao @cippico, cerco di farti un quadro in termini semplici della situazione su come la vedo io...

Meltdown, Spectre e tutto il cucuzzaro sono fragilità nelle architetture delle moderne CPU (per Intel parliamo degli ultimi 20 anni di produzione, AMD non so...).

Le vulnerabilità riguardano la "possibilità" di leggere (in maniera più o meno semplice) aree della memoria cache (interna al processore) della CPU che non dovrebbe essere possibile leggere da un processo estraneo al processo a cui la cache mantiene i dati. I motivi per cui è possibile la lettura esulano questa nota.

Per effettuare la lettura della cache e carpire dati interessanti (parliamo di PW et similia) bisogna operare in locale: questo non significa che devo avere accesso alla tastiera della macchina, ma semplicemente che il reader-transmitter deve risiedere sulla macchina o nella memoria gestita dal browser, alla stregua dei vari "virus moderni" che abbiamo col tempo imparato a conoscere, ma con l'aggiunta (pare) di varie altre cosette (javascript?) attive sulla macchina o nel software di comunicazione.

Già questo basterebbe per comprendere il reale impatto delle vulnerabilità su un desktop allestito con un minimo di granu-salis (altra storia sono i WEB server, i server con accesso a internet e il cloud): aggiungo anche che non è noto un uso di queste vulnerabilità negli ultimi 20 anni.

Come al solito il modo di veicolare e sfruttare le suddette vulnerabilità è l'uso di browser che ne permettano lo sfruttamento: ormai quasi tutti i browser sono stati aggiornati e alcuni (leggi Pale Moon) lo erano da tempo (a volte "vecchio è bello").

Moonchild Productions sull'argomento dichiarava...
"Pale Moon ha già impostato la granularità per i timer delle prestazioni in modo sufficientemente approssimativo nell'ottobre 2016, quando è diventato chiaro che questo potrebbe essere utilizzato per eseguire attacchi basati su temporizzazione hardware e fingerprinting. Pale Moon inoltre, in base alla progettazione, non consente la condivisione della memoria buffer tra i thread in JavaScript, quindi l'attacco "SharedArrayBuffer" non è possibile.
Anche così, aggiungeremo alcune modifiche aggiuntive alla difesa alla prossima versione 27.7 per essere assolutamente sicuri che non ci sia spazio per nessuno di questi tipi di attacchi basati sulla temporizzazione hardware in futuro."

La versione attuale di Pale Moon è la 27.7.1.

Per valutare il reale impatto di queste vulnerabilità basta fare alcune semplici considerazioni: una workstation/desktop/laptop usa saltuariamente nella vita reale di tutti i giorni alcune passwords e di queste solo pochissime (se compromesse) possono creare un reale problema all'utente. In altre parole sono veramente poche le situazioni in cui un attaccante abbia un reale impatto nella vita reale di un client (a meno che per "impatto" non si intenda la compromissione della password di YouPorn o WinTricKs): quelle poche che le avrebbero (es: HomeBanking, pw aziendali) hanno da tempo o la doppia chiave (usa e getta) per le operazioni dispositive o l'obbligo di un cambio pw in tempi ridotti.

A mio parere ci vuole comunque un disadattato a cercare quel tipo di informazioni in un PC di casa/ufficio, a meno si abbia a che fare con spionaggio industriale, controspionaggio, antimafia e via discorrendo...

Poi certo... tutto può succedere... come per esempio che mi cada il soffitto in testa mentre scrivo questo post...

...
...

... ma fortunosamente sono ancora vivo e continuerò a vivere decentemente anche senza avere la possibilità reale di "mitigare" queste vulnerabilità, con un sonoro pernacchio :p al novello re Sole che ha trovato il modo di far aggiornare le macchine più vecchie di 2 anni! ;) Capisci a mè!

Malgrado le imprecisioni che avrò sicuramente scritto, spero di averti dato una visione più chiara e non catastrofistica sull'argomento.

NOTA: Luigi XIV detto il re Sole.
Luigi XIV obbligò la nobiltà francese a trasferirsi a Versailles e a seguire la moda estremamente sfarzosa, costosa e volubile da lui imposta con lo scopo di affossare l'economia dei feudatari rendendoli inermi, costantemente sotto controllo e impossibilitati ad uno scontro di forza col sovrano e a manovre eversive di reale impatto.

retalv
02-02-2018, 00.53.57
Sicuri al 100% no, ma se le avesse diventerebbe una questione da AntiTrust, che in USA è piuttosto agguerrita. Per cui ne dubito.
Al più si potrebbe dire che Intel possa avere interesse a mantenere a galla AMD per non incorrere nelle ire dell'antitrust, ma visto che AMD è in netta ascesa grazie ai nuovi processori, beh, direi che non è questo il caso.

I bug ovviamente esistono e ne saltano fuori di continuo, ma qualcosa di questa portata è anomalo e mette seriamente a rischio la sicurezza dei propri clienti.
Inoltre le patch possono incidere in maniera così pesante sulle prestazioni che ci sono tutte le premesse per far causa ad Intel (del resto io compro un hardware per avere certe prestazioni, se di colpo mi si dimezzano per un errore del produttore, indovina con chi me la prendo? ;) )

Sorry, questa me l'ero persa/dimenticata ... :)

L'antitrust centra con le partecipazioni incrociate quanto un Ferrari con un Kg di pere: chiunque è libero di acquistare azioni di una ditta senza per questo fare cartello con quella ditta. Le motivazioni delle partecipazioni incrociate sono diverse e riguardano la diversificazione, la diminuzione dei rischi, il peso decisionale nell'azienda, la raccolta di informazioni (disponibili al solo azionariato) ecc. ecc.. Se segui un poco il mercato finanziario anche solo di casa nostra ti accordi che il filo di Arianna con cui sono legate le aziende è molto lungo, frastagliato e apparentemente incongruente... ma solo apparentemente.

Ripeto, il bug esisteva "a loro insaputa", quindi che piaccia o no e fino a che non potrà essere dimostrato che sapevano ma hanno ignorato il problema...

Le CPU hanno funzionato normalmente fino a dicembre? Si. - Tutto il resto è noia...
Il S.O. e/o la patch rallentano la macchina? Aggiorna con una CPU più veloce e spera che il BIOS/UEFI della MB venga aggiornato con il microcode che sforno. - Tutto il resto è noia...

Vuoi "sparare" la CPU con un obice, e questa "carogna" smette di funzionare? ;) Hai sbagliato acquisto. - Tutto il resto è noia...


Posso continuare, ma il finale sarà sempre quello. ;)

Ma a parte tutto questo, non ti sembra strano che i bug dei vari sistemi operativi non vengano resi noti per difendere le macchine fino all'aggiornamento successivo e salti fuori dopo 20 anni un bug hardware e Intel (che a quanto ricordo è stata informata 20gg prima) non chieda a chi lo ha scoperto di non divulgarlo fino all'attuazione delle opportune contromisure? :dntknw: Ti sembra logico tutto questo?

cippico
02-02-2018, 17.53.36
infatti...
piu' che altro mi interessava riconoscere e non installare aggiornamenti deleteri... :Oh-yea:

ciaooo a tutti

borgata
03-02-2018, 00.36.24
Avevo scritto un lungo post prima che il forum me lo mangiasse... pazienza.

A mio parere retalv stai ampiamente sottovalutando le possibilità di sfruttamento di queste vulnerabilità (che non sono bug: i processori operano come previsto, il problema è che non si era tenuto conto che in questo modo era possibile violarne la sicurezza). Quello che rimarrà sarà un bacino enorme di macchine che nonostante tutto questo patchare rimarranno vulnerabili e saranno preda dei vari kit di maleware creati per gli attacchi di massa.

Per quanto riguarda l'idea che questa possa essere una macchinazione di Intel per rendere obsoleti i vecchi processori e così venderne nuovi, a mio parere non ce ne sono proprio le premesse: Intel si è pesantemente esposta sia sul lato dell'immagine che giuridico, perchè quando ci sono in ballo tanti soldi, stai sicuro che le motivazioni per trascinarli in tribunale si trovano (e difatti sono da subito partite diverse class action).

LoryOne
04-02-2018, 10.16.25
infatti...
piu' che altro mi interessava riconoscere e non installare aggiornamenti deleteri... :Oh-yea:

ciaooo a tutti

Quando si parla di Meltdown e Spectre, bisogna fare un distinguo tra quelle che sono le potenzialita' dannose di un malware che le sfrutti e quelle reali e tangibili.
La prima e' un dato di fatto, la seconda necessita che il malware sia installato o che agisca comunqe in locale.
L'attivita' di prevenzione si basa sullo scongiurare le potenzialita' con o senza risultati tangibili d'infezione.
E' cosa risaputa che la colpa di un eventuale danno possa essere imputata sia a chi fornisce un servizio infetto (Cloud, websites, webapps,ecc) sia a chi mette a rischio la propria sicurezza in maniera del tutto autonoma (mail infetta), ma in quale percentuale imputabile all'una o all'altra parte, e' tutto da dimostrare caso per caso.
Se e' vero com' e' vero che non tutti i processori di differenti produttori sono sfruttabili con risultati differenti in base alle differenti varianti del malware, e' altrettanto vero che, indipendentemente dal S.O. installato e dal malware che agisce nel suo contesto, Intel sia il produttore che ha venduto la maggior parte di processori operanti sia su server, sia su client.
Conoscendo le potenzialita' del danno a monte dell'infezione, si deve ponderare in quale ambito il processore incriminato operi e quale sia il carico di lavoro che svolge in quell'ambito, poiche' il calo prestazionale se patchato via software e' un dato di fatto: Se a cio si aggiunge che su quel server e' possibile ospitare il malware e che da quel server puo' essere trasmesso, le criticita' aumentano.
Quindi cippico, tutto dipende da alcuni fattori:
- Che uso ne fai del PC
- Quali conoscenze hai in materia di propagazione dell'infezione e metodologie per scongiurarla
Se lo usi per navigare sul web, o per giocare in rete, o per scrivere lettere/fogli di calcolo e' difficile che noti il rallentamento, ma se lo usassi per attivita' in cui la lettura/scrittura sul disco avvenisse in maniera pesante, allora noteresti il calo prestazionale.
Per quanto attiene le potenzialita' d'infezione, quelle ci sono, ma sono le stesse attribuibili ad un qualsiasi altro malware; Cio che cambia e' il danno

retalv
04-02-2018, 17.09.11
... che non sono bug: i processori operano come previsto, il problema è che non si era tenuto conto che in questo modo era possibile violarne la sicurezza...

Vuoi farmi "coglionella"? ;)

Vulnerabilità è ovunque ci sia un difetto di progettazione con mancanza di controlli di sistema, il bug è la stessa cosa a livello software. Vogliamo fare i sofisti?

Hanno fatto in modo che venisse generata una eccezione in modo da bloccare l'accesso alle aree di memoria di un processo da parte di un altro processo e poi permettono il pre caricamento delle aree di memorie in cache prima dei controlli di sicurezza e senza considerare l'applicazione di un modello statistico sulla velocità di lettura dei dati in cache tramite l'indirizzamento indiretto.

E' come far usare il denaturante generale dello stato senza Bitrex (componente chimico brevettato dal gusto quasi identico al fiele) e meravigliarsi poi se i bambini che lo hanno bevuto sono diventati ciechi per colpa del metanolo in esso contenuto...

Per quanto riguarda l'idea che questa possa essere una macchinazione di Intel per rendere obsoleti i vecchi processori e così venderne nuovi, a mio parere non ce ne sono proprio le premesse: Intel si è pesantemente esposta sia sul lato dell'immagine che giuridico, perchè quando ci sono in ballo tanti soldi, stai sicuro che le motivazioni per trascinarli in tribunale si trovano (e difatti sono da subito partite diverse class action).

Assolutamente senza volerti offendere, ma lasciamelo dire in modo bonario ...
"Anima candida..!" :rolleyes:

Infatti... pare che il CEO, Brian Krzanich, durante un incontro con gli analisti per l’annuncio dell’ultima trimestrale del 2017: “Attueremo dei cambiamenti a livello hardware che risolveranno i rischi di Spectre e Meltdown su prodotti futuri in arrivo più avanti quest’anno”

Tradotto: entro il 2018 modificheranno l'architettura delle nuove CPU per annullare i rischi, il che porterà ad avere nuove matherboard che possano ospitarli entro i primi 6 mesi del 2019...

In questa ottica, tu, io e chiunque abbia una CPU più vecchia di 5 anni non ce lo faremmo un pensierino per toglierci il problema considerando che alla fine il costo dell'operazione non sarà poi così esorbitante..? O ci imbarchiamo in una class action? :asd:

Riguardo le class action non basta farle partire... bisogna anche vincerle... ;)


Per quanto attiene le potenzialita' d'infezione, quelle ci sono, ma sono le stesse attribuibili ad un qualsiasi altro malware; Cio che cambia e' il danno

Ecco... questo riguarda il grano salis a cui facevo riferimento prima... potremmo definirlo un moderno Keylogger, ma di sistema. :asd:

borgata
04-02-2018, 18.52.15
Vulnerabilità è ovunque ci sia un difetto di progettazione con mancanza di controlli di sistema, il bug è la stessa cosa a livello software. Vogliamo fare i sofisti?
No, il bug può essere sia a livello software che hardware. Si parla di bug quando le cose non funzionano come dovrebbero, in questo caso invece funzionano esattamente come progettato, solamente che non erano state progettate per bene, dato che non si è tenuto conto di un possibile sfruttamento di queste caratteristiche per violare la sicurezza del sistema ;)

In ogni caso voleva solo essere una precisazione, non modificava certo il succo del discorso.

Ovviamente gli esempi che si trovano in rete e spiegano il funzionamento di queste falle sono molto semplificati, la realtà è molto più complessa. Per questo era piuttosto difficile anche solo concepire come sfruttare queste falle. Del resto il problema è saltato fuori oggi dopo vent'anni, non è un caso.

Assolutamente senza volerti offendere, ma lasciamelo dire in modo bonario ...
"Anima candida..!"
Nessuna offesa, ma ti dico con molta franchezza che non mi ritengo tale. A mio parere un'ipotesi del genere sarebbe semplicemente molto improbabile.

Se proprio vogliamo buttarla sul complottismo secondo me è molto più probabile che Intel si sia resa conto da tempo del problema ma abbia preferito le prestazioni alla sicurezza, contando sul fatto che nessuno avrebbe tirato fuori un exploit. E invece Project Zero li ha messi con le spalle al muro.
Del resto può essere piuttosto conveniente acquisire un vantaggio sulla concorrenza a scapito della sicurezza, quando questa ha un costo prestazionale elevato ;)

Il vero problema di queste vulnerabilità comunque è il comportamento di Intel a riguardo: a parte il cercare di minimizzare il problema e di fare tutta l'erba un fascio (come se i problemi degli altri fossero della stessa entità dei propri), le soluzioni proposte da Intel di fatto non tappano le falle ma forniscono gli strumenti per farlo. E questo significa che rimarrà in giro tanto software che sarà vulnerabile.
Non so se hai letto le esternazioni di Linus Torvalds (che, al solito, non le manda a dire), ma la sua indignazione era dovuta proprio al modo in cui Intel sta affrontando il problema.

Tradotto: entro il 2018 modificheranno l'architettura delle nuove CPU per annullare i rischi, il che porterà ad avere nuove matherboard che possano ospitarli entro i primi 6 mesi del 2019...
Le motherboard non c'entrano nulla, la vulnerabilità sta nei processori. E già da tempo si sapeva che questa generazione di motherboard sarebbe stata incompatibile con la prossima generazione.
Del resto nulla di diverso dal solito, Intel taglia la compatibilità con le schede madre ad ogni cambio di microarchitettura, stavolta ha fatto solo un po' peggio cambiandola per una semplice revisione (ma i motivi sono altri).

In questa ottica, tu, io e chiunque abbia una CPU più vecchia di 5 anni non ce lo faremmo un pensierino per toglierci il problema ...
Secondo me stai ampiamente sopravvalutando la percezione di questo problema da parte della massa d'utenza: se ne sbatteranno quasi tutti.
Guarda per esempio il topic in cui si chiede consiglio su un portatile... in cui ad un certo punto è saltato fuori che l'utente voleva Intel. Di certo non per la sicurezza, visto il momento! :asd:

Oltretutto se uno vuole stare molto più al sicuro già oggi c'è una bella alternativa, i Ryzen di AMD. E non deve neppure aspettare fine anno (quando saranno in uscita anche i Ryzen basati su Zen2 a 7nm, che pare potranno essere ancora più competitivi grazie a frequenze molto più alte). Intel rischia una certa emorragia di utenti.

PS; certo che le class action bisogna vincerle, ma stai certo che se partono la possibilità che questo avvenga l'hanno intravista. ;)

retalv
05-02-2018, 01.05.51
No, il bug può essere sia a livello software che hardware. Si parla di bug quando le cose non funzionano come dovrebbero, in questo caso invece funzionano esattamente come progettato, solamente che non erano state progettate per bene, dato che non si è tenuto conto di un possibile sfruttamento di queste caratteristiche per violare la sicurezza del sistema ;)

In ogni caso voleva solo essere una precisazione, non modificava certo il succo del discorso.

Scherzi? Non è un errore di progettazione creare un sistema di sicurezza che non riesce a fare fino in fondo quello che deve? Certo se aspettavano che lo scoprissi io che sto a un visionario informatico quanto un pesce rosso, avrebbero aspettato che il sole diventasse una gigante rossa... ;)

Ovviamente gli esempi che si trovano in rete e spiegano il funzionamento di queste falle sono molto semplificati, la realtà è molto più complessa. Per questo era piuttosto difficile anche solo concepire come sfruttare queste falle. Del resto il problema è saltato fuori oggi dopo vent'anni, non è un caso.

Quindi quelli di Pale Moon sono dei genietti visionari o ci hanno preso per caso?

Se proprio vogliamo buttarla sul complottismo secondo me è molto più probabile che Intel si sia resa conto da tempo del problema ma abbia preferito le prestazioni alla sicurezza, contando sul fatto che nessuno avrebbe tirato fuori un exploit. E invece Project Zero li ha messi con le spalle al muro.
Del resto può essere piuttosto conveniente acquisire un vantaggio sulla concorrenza a scapito della sicurezza, quando questa ha un costo prestazionale elevato ;)

Ma quale complotto, questa è un'operazione commerciale e il fatto di aver reso pubblico il problema non fa altro che darne conferma.

Il vero problema di queste vulnerabilità comunque è il comportamento di Intel a riguardo: a parte il cercare di minimizzare il problema e di fare tutta l'erba un fascio (come se i problemi degli altri fossero della stessa entità dei propri), le soluzioni proposte da Intel di fatto non tappano le falle ma forniscono gli strumenti per farlo. E questo significa che rimarrà in giro tanto software che sarà vulnerabile.
Non so se hai letto le esternazioni di Linus Torvalds (che, al solito, non le manda a dire), ma la sua indignazione era dovuta proprio al modo in cui Intel sta affrontando il problema.

Chiamali fessi... chissà perché lo fanno...
Le ho lette le esternazioni e sai a Intel quanto interesano? ;)

Le motherboard non c'entrano nulla, la vulnerabilità sta nei processori. E già da tempo si sapeva che questa generazione di motherboard sarebbe stata incompatibile con la prossima generazione.
Del resto nulla di diverso dal solito, Intel taglia la compatibilità con le schede madre ad ogni cambio di microarchitettura, stavolta ha fatto solo un po' peggio cambiandola per una semplice revisione (ma i motivi sono altri).

Centrano perché di fatto saranno da cambiare e le dovrà cambiare anche chi non voleva cambiare CPU. Mi pareva ovvio il motivo per cui le ho tirate in ballo...

Secondo me stai ampiamente sopravvalutando la percezione di questo problema da parte della massa d'utenza: se ne sbatteranno quasi tutti.

Credo che sia tua la sottovalutazione di quanto faccia correre le persone la paura indotta. Aspetta, è ancora presto: tutti quelli che hanno la tendinite al polso destro e hanno imparato a usare il mouse con la sinistra ;) non sanno nemmeno che esiste il "problema", ma chi di dovere penserà a mettere il sale sulla coda all'utenza a tempo debito... scommettiamo un caffè virtuale? (Scusa ma in Sardegna non vengo.) ;)

Fatturato Intel 2016: 59,38 miliardi USD
Fatturato AMD 2016: 4,27 miliardi USD

Fine 2017: fatturato Intel in crescita, fatturato AMD in caduta libera.

L'unica preoccupazione di Intel è questa... fatturato soli chips SAMSUNG 69 miliardi USD ... di cosa stiamo parlando? ;)

LoryOne
05-02-2018, 09.41.42
Scherzi? Non è un errore di progettazione creare un sistema di sicurezza che non riesce a fare fino in fondo quello che deve?
Purtroppo no, non è possibile neppure progettarlo un sistema di sicurezza quale s'intende un antivirus , poichè il codice che da origine alla falla progettuale sfruttabile è del tutto lecito e non scindibile dalle comuni operazioni di accesso alla memoria lecite/illecite.
L'unica cosa che si può fare o che si è già fatto è :
- Aggiungere al kernel codice di verifica e controllo che ne rallenta inevitabilmente l'operatività.
- Virtualizzare il più possibile i browser nell'esecuzione di codice JavaScript
- Attendere che lo script malevolo sfruttabile, al quale può essere associata una firma, da quel momento diventi riconoscibile.
Il problema legato alla class action ai danni di Intel, è dovuto al fatto che se si mettono assieme le problematiche legate alla sicurezza di Meltdown e Spectre, il quadro che ne deriva è che i processori Intel (con produzione vecchia di addirittura 10 anni e più) risultano i più vulnerabili alle diverse varianti rispetto alla controparte AMD.
Un po come dire che Intel ha venduto per anni processori fallati, privilegiando le performances rispetto alla sicurezza operazionale delle sue unità di processo centrale ad un costo tale che, a valle della problematica esposta, non giustifica il prezzo corrisposto da ogni utente che l'abbia acquistate, soprattutto in ambito server.
Intel minimizza, però ammette il problema ed attraverso Brian Krzanich fa intendere che saranno poste in essere modifiche architetturali contro Meltdown/Spectre, ma SOLO su prodotti di futura commercializzazione.
Ergo...la problematica è hardware.

borgata
05-02-2018, 10.23.17
Scherzi? Non è un errore di progettazione creare ...
Esattamente: è un errore di design, ma non un bug.
Un bug è quando facendo 2+2 anziché ottenere 4 ottengo 5. Se però ottengo 4 e 4 ti permette di fare cose non previste, allora non si chiama bug.
Ripeto, era solo una puntualizzazione, nulla di davvero importante in questo discorso.

Quindi quelli di Pale Moon sono dei genietti visionari o ci hanno preso per caso?
Quelli di palemoon avevano solo supporto che per come lavora l'IMC si poteva essere vulnerabili. Ma qui non solo la questione è differente (non riguarda direttamente l'IMC) ma non era stato sviluppato neppure un "proof of concept" che mettesse in mostra il problema, era solo un'ipotesi.

Ma quale complotto, questa è un'operazione commerciale e il fatto di aver reso pubblico il problema non fa altro che darne conferma.
Beh, questo genere di cose si chiamano complotti, al di la dell'accezione legata alla fantasia di alcune teorie che può essere data al termine. :)

Centrano perché di fatto saranno da cambiare e le dovrà cambiare anche chi non voleva cambiare CPU. Mi pareva ovvio il motivo per cui le ho tirate in ballo...
Ripeto, l'incompatibilità delle schede madre era già prevista da tempo ed è in linea di massima operazione abituale per Intel ormai da parecchie generazioni. La questione di cui stiamo trattando non cambia nulla in tal senso.



Fine 2017: fatturato Intel in crescita, fatturato AMD in caduta libera.
In realtà AMD ha concluso per la prima volta da molto tempo l'anno fiscale in positivo e in forte crescita, grazie ai nuovi prodotti del 2017, e la situazione non potrà che migliorare nel prossimo anno.

Scusa ma in Sardegna non vengo
Ehehe ma perchè, è un bellissimo posto dove passare le vacanze! ;)

retalv
06-02-2018, 02.23.24
Ehehe ma perchè, è un bellissimo posto dove passare le vacanze! ;)
Certo, ma non ci vengo uguale... ;)

In realtà AMD ha concluso per la prima volta da molto tempo l'anno fiscale in positivo e in forte crescita, grazie ai nuovi prodotti del 2017, e la situazione non potrà che migliorare nel prossimo anno.
Hai ragione i dati 2017 sono diversi.
Fatturato 2017: Intel 62,8 mld, AMD 5,33 mld
Utile operativo: Intel 5,4 miliardi di dollari, AMD 82 milioni di dollari ... c'è proprio da fare festa, l'utile operativo è meno di 1/5 riferito ai rispettivi fatturati... quando recuperano le passività pregresse?

Ripeto, l'incompatibilità delle schede madre era già prevista da tempo...
Ripeto, non centra una cippa se è previsto che si cambi la scheda madre ad ogni nuova CPU, quello che non era previsto era di dover cambiare la CPU senza averne bisogno, la qual cosa si porta dietro anche la scheda madre. Se hai comprato A + B e dopo anni per qualche motivo sei "costretto" a ricomprare A è ovvio che dovrai comprare anche B che non è più compatibile con la nuova A e diventa anch'essa costrizione.

Beh, questo genere di cose si chiamano complotti...
Fatti coraggio allora... è da quando hai cominciato a spendere denaro che sei vittima di complotti. Uno specifico abbastanza vecchio riguarda le sigarette, quando aggiungevano direttamente nicotina, poi altri componenti di concia del tabacco (ad azione nettamente più blanda della nicotina ma legali) per "fidelizzare" il consumatore ed incrementarne la dipendenza. Più in generale quello che tu chiami complotto è semplicemente creare un'esigenza, quello ch fanno o tentano di fare tutti i giorni le campagne pubblicitarie, ad esempio...

Un bug è quando facendo 2+2 anziché ottenere 4 ottengo 5. Se però ottengo 4 e 4 ti permette di fare cose non previste, allora non si chiama bug. Ripeto, era solo una puntualizzazione, nulla di davvero importante in questo discorso.
Invece è molto importante, perché l'unica differenza tra un pallottoliere (2+2=4) e la central processing unit è la sezione logica. Nel primo è esterna (chi lo sta usando), nel secondo è pre-generata. Un "errore di design" come lo chiami tu è un errore di programmazione (voluto o fortuito) relativo alla logica di sicurezza che vuole proteggere dati sensibili riguardanti la computazione stessa.

Se la logica di sicurezza funziona avremo risultato VERO, ma se la logica è per qualche motivo fallace e permette il superamento anche parziale di se stessa, malgrado la logica di funzionamento continui a dare risultato VERO (fa quello per cui è stata scritta sul silicio) la logica intrinseca non fornisce il medesimo stato della logica operativa, alias fornisce FALSO (2+2<>4).

Da quel poco che ho capito, il microcodice è un interprete scritto in codice macchina che si interpone tra l'hardware e l'architettonica del computer. A grandi linee mi risulta essere, in questo caso, una patch tale e quale a quelle che vengono applicate ai software, solo che avendo a che fare con silicio immodificabile si è costretti ad operare in un livello esterno alla CPU.

Se da una macchina virtuale interagisci nelle aree di memoria delle altre senza aver impostato i permessi lo chiami BUG, se lo fa la CPU lo chiami vulnerabilità? Se per correggere un problema di logica di un software applichi una patch e per un problema di logica di una CPU applichi un microcodice, dove sta la differenza?

-----------------------------

Non sono un tecnico quindi non riesco a controbattere efficacemente alle vostre argomentazioni sulla cosa, ma mi piacciono le similitudini: anche questa volta vorrei farvene una... vi farà passare qualche secondo... ;)

In un Comune d'Italia (il classico utente di PC) viene deciso di acquistare un nuovo e moderno autobus (CPU) equipaggiato di guida autonoma. L'addetto porta l'autobus ad uno dei due capolinea, carica la mappa della città, definisce il percorso, le fermate obbligatorie e quelle a sola richiesta e il secondo capolinea, quindi avvia il sistema e scende dall'autobus.

La guida autonoma si collega ai satelliti per avere le coordinate sulla propria posizione, analizza la mappa e sceglie il percorso in modo da coprire l'intero tracciato di fermate e raggiungere il capolinea opposto quindi analizza i limiti di velocità imposti dal codice stradale cittadino per ottenere una stima sui tempi di percorrenza.

L'autobus chiude le porte e si avvia alla prima fermata. A questa salgono due uomini e una ragazza (Word, PDFCreator ed Excel): vidimano il biglietto e si mettono a sedere presi nei loro impegni.

L'autobus raggiunge la seconda fermata. A questa salgono altre due donne (KeePass e Malwarebytes) e scende uno degli uomini (Word): tutte vidimano il biglietto e si siedono.

L'autobus raggiunge la terza fermata. Salgono altre due donne (VirtualBox e Syncovery) ma nessuno scende.

Alla quarta fermata nessuno sale e nessuno fa richiesta per scendere. L'autobus prosegue.

Alla quinta fermata sale un ragazzo assieme a due donne (VMware Workstation e Firefox) ma nessuno scende. Il ragazzo è zoppicante e Firefox lo aiuta a salire. Le donne vidimano il biglietto: VMware Workstation si siede dietro alla donna della terza fermata (VirtualBox), ma davanti a KeePass. Il ragazzo non vidima alcun ticket (abbonato?) e senza dare nell'occhio si avvicina alle tre donne.

Alla sesta fermata la guida autonoma si accorge che uno dei passeggeri non ha ancora vidimato il biglietto/abbonamento. Il progettatore della guida autonoma ha considerato l'eventualità di un viaggio a scrocco, quindi la soubroutine avverte la centrale operativa della presenza di un "portoghese" a bordo (eccezione o come la volete chiamare), carica altri 8 passeggeri e prosegue nella corsa.

Settima fermata e l'autobus si ferma ma non apre le porte di discesa-salita: la logica di programmazione obbliga lo stazionamento in attesa degli accertatori del titolo di viaggio.
Il ragazzo, che aveva appena sfilato il borsellino dalla borsa di KeePass, comincia ad avere paura e fa cose che a mente lucida non avrebbe mai fatto: prende ad ostaggio le due donne a lui più vicine VirtualBox e VMware Workstation minacciandole con un coltello a serramanico di 12cm!

Lui non sa che entrambi sono incinte: VirtualBox presa dalla concitazione sviene e questa sarà la sua fortuna ma VMware Workstation, donna più matura, cerca di far ragionare il ragazzo. Questo, ormai fuori di testa, trafigge al fianco la donna semplicemente per farla stare zitta. Vedendo quello che succede, Firefox che è una ragazza di 20 anni, sviene. Malwarebytes che è guardia giurata ma disarmata non ha giurisdizione in quella situazione e vedendo il coltello in pugno al ragazzo rimane inerme. Il ragazzo resosi finalmente conto di ciò che ha appena fatto, rompe il vetro che funge da uscita di sicurezza e fugge. Dopo pochi minuti l'autobus viene raggiunto dagli accertatori del titolo di viaggio che non possono fare altro che constatare quello che è appena accaduto e a loro volta chiamare le forze dell'ordine.

I presenti non possono che raccontare l'accaduto: Firefox si riprende dallo svenimento, e VMware Workstation prende la strada dell'obitorio. Le forze dell'ordine eseguono le rilevazioni del caso avviando l'ovvia ricerca dell'assassino. Dopo 8gg dal fatto KeePass si presenta in questura per la denuncia di azioni fraudolente sul suo conto corrente.

-----------------------------

La dichiarazione del produttore dell'autobus riguardo l'accaduto fu ...

"Ci rammarichiamo di non aver saputo preventivare una escalation di situazioni avverse e nel futuro attueremo i provvedimenti del caso per prevenire il ripetersi di situazioni similari. Teniamo però a precisare che il sistema intrinsicamente non ha fallito e potremmo dire che in qualsiasi momento della vicenda 2 + 2 ha sempre dato come risultato 4. Esprimiamo il nostro cordoglio ai parenti delle vittime."

Ecco... vorrei che ora qualcuno spiegasse ai figli di VMware Workstation e a KeePass che quanto successo è imputabile a un "errore di design" o vulnerabilita di sistema e che VMware Workstation è (purtroppo) un "danno collaterale" all'errore di design, insomma che qualcuno spiegasse loro che sarebbe bastato aver implementato un design lungimirante. :mm:

In altre parole, il sistema ha funzionato perfettamente e non esiste un bug del sistema ma il bug era solo nella LOGICA del progettista e della direzione aziendale dell'azienda che ha ponderato come più "importante" il sicuro recupero di quell'euro di biglietto (velocità processore) al posto di una seppure poco probabile "svolta avversa".

LoryOne
06-02-2018, 12.23.30
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ì.

retalv
06-02-2018, 16.05.05
Tratto da qui: https://meltdownattack.com/

Grazie.


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ì.

Vero.

Quando scrivevo "a pappagallo" di venti anni senza evidenze mi mettevo a ridere... non è mai stato usato solo perché nessuno se n'è accorto... ma dai..! :asd: sarebbe come credere che nessuna agenzia ha mai usato soluzioni analoghe solo perché nessuno se n'è reso conto.

Leggevo che anche la famiglia dei Qualcomm® Snapdragon™ è affetta da questi "problemini" e che il peggiore è il 845 che può vantare tutto il cucuzzaro.

Immagino che i device più a rischio siano proprio questi semplicemente perché solitamente online H24 con Android. Vuoi usare lo smatphone per tutto..? Il piatto è servito!

borgata
06-02-2018, 16.48.26
Entrambi gli attacchi fanno uso del side channel (canale di comunicazione tra address space) ...
Giusto un appunto. Il "side channel" non è un canale di comunicazione che viene utilizzato nell'attacco, ma una tecnica di attacco che sfrutta le peculiarità hardware di un sistema per violarlo ("side channel" quindi nel senso di "con metodi alternativi").

In questo caso si parla di "Cache timing side-channels", ossia di metodi di attacco che utilizzano le temporizzazioni della cache.

Hai ragione i dati 2017 sono diversi.
Fatturato 2017: Intel 62,8 mld, AMD 5,33 mld
Utile operativo: Intel 5,4 miliardi di dollari, AMD 82 milioni di dollari ... c'è proprio da fare festa, l'utile operativo è meno di 1/5 riferito ai rispettivi fatturati... quando recuperano le passività pregresse?
Beh, non vorrai paragonare i risultati finanziari di un colosso come Intel con quelli di un'azienda di dimensioni molto minori come AMD.
La situazione di AMD fino a poco tempo fa era critica: un debito a lungo termine di due miliardi in scadenza, fondo cassa al limite e bilancio in rosso da anni. Adesso ha finalmente chiuso l'anno in positivo, ha un fondo cassa adeguato per non soffocare a causa del debito ed è in crescita grazie ai suoi prodotti. Direi che la situazione è rosea oltre le previsioni che si potevano fare fino a non molto tempo fa.

Ripeto, non centra una cippa se è previsto che si cambi la scheda madre ad ogni nuova CPU, quello che non era previsto era di dover cambiare la CPU senza averne bisogno, la qual cosa si porta dietro anche la scheda madre.
Beh, certamente.
Ma sono abbastanza sicuro che ben pochi sentiranno l'esigenza di aggiornare il proprio computer, per lo meno in ambito consumer. In ambito enterprise dipenderà da quanto le patch incideranno sulle prestazioni.
E poi, come dicevo, rimane sempre il "problema" AMD che oggi, a differenza del recente passato, offre prodotti competitivi su cui chi aggiorna potrebbe indirizzarsi.

Più in generale quello che tu chiami complotto ...
Non sono io a chiamarli complotti, è semplicemente il loro nome, ed è slegato dall'accezione di complotto inteso come "teoria strampalata".
Anche qui comunque non mi sembra il caso di insistere sui termini, l'importante è capirsi.

Invece è molto importante, ...
Non è importante nel senso che alla fine si tratta di una questione di lana caprina. Colloquialmente puoi chiamarlo bug se vuoi, ma tecnicamente è sbagliato (e certamente non ci strapperemo i capelli per questo).

In questo caso si sta creando un sistema talmente complesso che è estremamente difficile determinare tutte le possibilità che la combinazione dei vari fattori può dare. Il sistema si comporta come progettato, chi l'ha progettato però non ha previsto (o l'ha previsto e se ne è fregato) che potesse essere utilizzato in modo tale da violare la sicurezza del sistema.

Inciso: ll microcodice è un po' il "software dell'hardware", ossia un software che agisce a bassissimo livello e viene preso in pasto direttamente dalla logica in hardware. Esempio tipico: un'istruzione complessa viene tradotta dal microcodice in più semplici istruzioni implementate in hardware.
Processori molto semplici (come i primi RISC) non avevano microcodice ma eseguivano tutte le istruzioni direttamente in hardware.
Il vantaggio del microcodice è la possibilità di aggiornarlo per correggere dei bug o dei problemi di design del processore, o persino migliorarne le capacità. Lo svantaggio è che di norma le funzionalità hardware sono più efficienti (ma allo stesso tempo istruzioni troppo semplici rendono complesso il software, e istruzioni troppo complesse in hardware hanno un elevato costo implementativo).

Se da una macchina virtuale interagisci nelle aree di memoria delle altre senza aver impostato i permessi lo chiami BUG, se lo fa la CPU lo chiami vulnerabilità?
Ancora una volta: no.
Dove stia il problema non è importante, la differenza tra bug e difetto di design sta nel tipo di problema, non nel "luogo" in cui si verifica. Vulnerabilità è generico, si può essere vulnerabili per esempio sia a causa di un bug o di un difetto di design.
Se io mi aspetto un risultato e ne ottengo un altro è un bug. Se io ottengo il risultato che pensavo di ottenere ma questo mi crea problemi, è un difetto di design.

Perdonami se non leggo la metafora! :D

retalv
06-02-2018, 17.12.05
Non sono io a chiamarli complotti, è semplicemente il loro nome, ed è slegato dall'accezione di complotto inteso come "teoria strampalata".
Ma anche no. Il "complotto" generalmente è tale quando lo sgami prima che sia portato a termine, quando è andato a segno prende vari altre definizioni, ad esempio truffa.

Se io mi aspetto un risultato e ne ottengo un altro è un bug. Se io ottengo il risultato che pensavo di ottenere ma questo mi crea problemi, è un difetto di design.

Bene, mi aspettavo che certe aree di memoria non potessero essere lette. Per un errore di design possono leggerle. Quindi è un bug. :rotfl:

borgata
06-02-2018, 17.24.07
Bene, mi aspettavo che certe aree di memoria non potessero essere lette. Per un errore di design possono leggerle. Quindi è un bug. :rotfl:
In realtà quelle aree di memoria non vengono lette, ma è possibile leggere una copia di dati normalmente non accessibili in cache tramite un "side channel attach" basato sulle temporizzazione della cache.
Quindi è un difetto di design! :p

Per capire di che tipo di vulnerabilità stiamo parlando, è come se io riuscissi a leggere un dato nel registro di un processore monitorando la temperatura in una certa area del chip.
Non mi pare di poter dire che il chip sia buggato per questo, eppure sono in grado di leggere il dato e violare la sicurezza, cosa che ovviamente non era prevista.
Del resto il processore funziona correttamente, non ho solo pensato che qualcuno poteva leggere un dato misurando la temperatura.
L'esempio è un po' fantasioso (ma neppure troppo!), ma era giusto per far capire perchè non si parla di bug.

Ma anche no. Il "complotto" generalmente è tale quando lo sgami prima che sia portato a termine, quando è andato a segno prende vari altre definizioni, ad esempio truffa.
Francamente non ho mai sentito una definizione del genere.
Ho dato quindi un'occhiata alle definizioni dei vari dizionari online e non mi pare si accenni a nulla del genere. Hai sotto mano una fonte autorevole?

borgata
06-02-2018, 17.31.54
Quando scrivevo "a pappagallo" di venti anni senza evidenze mi mettevo a ridere... non è mai stato usato solo perché nessuno se n'è accorto... ma dai..! :asd: sarebbe come credere che nessuna agenzia ha mai usato soluzioni analoghe solo perché nessuno se n'è reso conto.
Io non penserei solo alle agenzie governative (nel qual caso si potrebbe anche pensare a qualcosa di voluto), ma anche a cybercriminali che ovviamente si sono ben guardati dal diffondere notizia di questa gallina dalle uova d'oro.

É proprio a causa di questo rischio che il problema è stato rivelato pubblicamente, perchè l'unico modo per essere sicuri è quello di porre rimedio al problema, non certo nascondere la testa sotto la sabbia.
Del resto, come avevo già scritto, ormai è noto che la "security by obscurity" non funziona.

Leggevo che anche la famiglia dei Qualcomm® Snapdragon™ è affetta da questi "problemini" e che il peggiore è il 845 che può vantare tutto il cucuzzaro.
Il problema affligge praticamente tutti i processori ARM ad alte prestazioni, ossia quelli che fanno uso di esecuzione speculativa.
Questo significa che buona parte dei processori top di gamma da varie generazioni a questa parte sono vulnerabili (chi più chi meno), mentre quelli con core a basso consumo sono "by design" immuni (essendo processori in order).

retalv
06-02-2018, 19.31.24
Francamente non ho mai sentito una definizione del genere.
Ho dato quindi un'occhiata alle definizioni dei vari dizionari online e non mi pare si accenni a nulla del genere. Hai sotto mano una fonte autorevole?

Fonte autorevole..? Su internet..?

Comunque non c'è bisogno di accennarlo, è intrinseco nella definizione stessa... un monarca non lo "complotti" ma semmai lo destituisci tramite un complotto o ancor meglio una cospirazione.

http://www.treccani.it/vocabolario/complotto/
http://www.treccani.it/vocabolario/congiura/
http://www.treccani.it/vocabolario/cospirazione/

Devoto - Oli
Vocabolario della lingua italiana

Complotto
Intrigo rivolto copertamente a dano di enti o persone determinate.
Complottare
Tramare, macchinare di nascosto a danno dell'autorità o del prossimo.
Cospirazione
Concorso di persone o di energie (non necessariamente ostili) a un determinato fine (non necessariamente dannoso).

LoryOne
07-02-2018, 08.41.19
Giusto un appunto. Il "side channel" non è un canale di comunicazione che viene utilizzato nell'attacco, ma una tecnica di attacco che sfrutta le peculiarità hardware di un sistema per violarlo ("side channel" quindi nel senso di "con metodi alternativi").

In questo caso si parla di "Cache timing side-channels", ossia di metodi di attacco che utilizzano le temporizzazioni della cache.

Puntualizzazione più che corretta, direi tecnicamente doverosa, che sviscera ancora più a fondo la problematica. :)

LoryOne
07-02-2018, 11.10.31
cut..
Inciso: ll microcodice è un po' il "software dell'hardware", ossia un software che agisce a bassissimo livello e viene preso in pasto direttamente dalla logica in hardware. Esempio tipico: un'istruzione complessa viene tradotta dal microcodice in più semplici istruzioni implementate in hardware. cut...


Concordo.
Pensiamo ad un processore come un foglio sottile che contiene transistors, resistenze, condensatori e diodi, tutti uniti da piste che consentono alla corrente di scorrere tra le componenti hw e fornire tensioni e correnti in uscita distinte da quelle in ingresso, che costituiscono un output per uno stadio ed un input per un altro a catena: Pensiamo anche che, per produrre un'operazione complessa, sia necessario scomporre tale operazione in più istruzioni basilari da dare in pasto alla logica circuitale per coordinare adeguatamente i componenti hw interessati; Ogni processore, quindi, possiede la conoscenza di molte operazioni basilari per eseguire molte operazioni complesse, ma se opportunamente istruito su quali e quante istruzioni basilari impiegare per svolgere più operazioni con un unica istruzione, il suo set d'istruzioni si riduce a favore di una sola chiamata per svolgerne diverse altre.
Chiamiamo lo "spezzone di codice" che si frappone fra l'istruzione unica invocata che compie diverse operazioni e quelle basilari impegnate, microcodice. Se il microcodice può subire un update o un upgrade, è possibile correggere "al volo" il comportamento del processore nell'eseguire l'istruzione invocata.

borgata
08-02-2018, 00.50.18
Comunque non c'è bisogno di accennarlo, è intrinseco nella definizione stessa...
Beh oddio... non mi pare affatto! :eek:
Del resto, anche tu subito dopo scrivi:
... un monarca non lo "complotti" ma semmai lo destituisci tramite un complotto o ancor meglio una cospirazione.
Il monarca è stato destituito in seguito ad un complotto, quindi anche se il complotto è giunto a compimento sempre di complotto si parla.
Direi che il chiamarsi complotto non dipenda affatto ne dall'esito ne dal momento in cui lo si cita, ossia se prima o dopo il suo compimento (a parte i discorsi sul revisionismo storico dei vincitori, ovviamente :asd: ).

Comunque è solo un termine, non credo pregiudichi il discorso che stavamo facendo.

PS: beh dai, anche in rete trovi fonti autorevoli, il sito web della treccani per esempio lo considero tale in questo contesto. :)