Spectre e Meltdown: Intel promette una soluzione modificando le CPU a livello di silicio entro fine anno

[DakmorNoland]

Originariamente inviato da coschizza

ma è un problema di tutti i bug li hanno le cpu amd arm ibm oracle quindi cosa resta fuori? non è che se lo dice intel allora gli altri hanno i bug e se non lo dice sono tutti sani. Invece vale l'oppoto amd ha detto che non era soggetta a una variante e invece non era vero e da questo le class action. Insomma chi mente?

Ad oggi è stata dimostrata l'effettiva sfruttabilità dei bachi solo su Intel per quanto riguarda Windows, AMD la prima variante solo su Linux e basta una ridicola patch del kernel per risolverla. La seconda variante è quasi impossibile da utilizzare.

Forse non ti è chiaro che Intel ha realizzato per anni dei colabrodo puntando solo sulle prestazioni, mentre AMD ha creato un'architettura 100 volte più sicura.

[nickname88]

Originariamente inviato da DakmorNoland

Ad oggi è stata dimostrata l'effettiva sfruttabilità dei bachi solo su Intel per quanto riguarda Windows, AMD la prima variante solo su Linux e basta una ridicola patch del kernel per risolverla. La seconda variante è quasi impossibile da utilizzare.

Forse non ti è chiaro che Intel ha realizzato per anni dei colabrodo puntando solo sulle prestazioni, mentre AMD ha creato un'architettura 100 volte più sicura.

Ma non è vero sia la prima parte che la seconda.

Ma da dove esce sta storia di Linux ? E' la prima e unica volta che la sento e solamente da te.
AMD è vulnerabile a spectre sia nella variante 1 e 2 indipendentemente dall'OS.

AMD quindi avrebbe pensato alla sicurezza ? Ma non diciamo cavolate, tutti mirano alla performance, ad AMD gli è semplicemente andata di cul0 e basta, tantè che ci sono voluti 10 anni per scoprire ste vulnerabilità. E il calo di performance è dato dalle implicazioni della patch via software, non dalla vulnerabilità in sè, se ti aspetti handicap paragonibili anche per la prossima serie mi sà che rimarrai deluso perchè il fix via hardware dovrebbe essere tutta un altra storia.

[calabar]

Originariamente inviato da nickname88;

Ma non è vero sia la prima parte che la seconda.

Fonte?
Per la prima parte ovviamente, la seconda è un'opinione.

[nickname88]

Originariamente inviato da calabar

Fonte?
Per la prima parte ovviamente, la seconda è un'opinione.

http://www.ansa.it/sito/notizie/tecn...806443643.html
https://www.techarp.com/articles/amd...ble-spectre-2/
https://www.phoronix.com/scan.php?pa...able-Variant-2
https://hardware.hdblog.it/2018/01/1...pyc-pathc-fix/

[calabar]

@nickname88
Mi chiedo se i link che hai postato tu li abbia letti. Riportare una fonte non significa sparare una serie di link ma argomentare una risposta avallandola con le fonti.

Guarda che così non ci fai una bella figura: stai dimostrando di essere poco informato e per di più stai usando toni aggressivi pur non avendo le basi per poter dimostrare la tua ragione.
Oltretutto stai selezionando solo le informazioni che ti sono giunte e che sono a favore di Intel, dimostrando quantomeno una certa "simpatia".

Tornando alla questione, inizia leggendo questo: https://www.amd.com/en/corporate/speculative-execution
Si tratta del comunicato AMD relativo alle vulnerabilità in questione ed è costantemente aggiornato (come puoi notare dalla data).

Il quadro che emerge è abbastanza chiaro: Intel e AMD non sono sullo stesso livello riguardo a queste vulnerabilità. Stavolta i problemi per Intel sono molto superiori, e questo credo sia abbastanza chiaro a chiunque abbia seguito la vicenda.
E questo non significa "AMD bravi Intel cacca", ma solo che in questa circostanza (per quanto rilevante) la situazione è meno rosea per Intel.

[DakmorNoland]

Originariamente inviato da calabar

E questo non significa "AMD bravi Intel cacca", ma solo che in questa circostanza (per quanto rilevante) la situazione è meno rosea per Intel.

Beh oddio proprio così no, però capisci che se vendi a palate e hai fatto un sacco di soldi e ogni anno tutto quello che fai è rilasciare processori che se va bene sono il 5% più veloci dell'anno prima, beh il minimo è che almeno tu lavori un po' sulla sicurezza. Ma Intel se n'è proprio fregata, pensando che non fosse possibile portare un attacco a livello così basso. Però loro secondo me sapevano che se mai qualcuno fosse riuscito, i loro processori non erano affatto sicuri a livello di architettura.

Non ricordo più il nome della tecnologia, ma hanno di fatto implementato all'interno delle ultime architetture una tecnologia per aumentare le prestazioni di un 25% sui carichi più pesanti, che però di fatto per come è strutturata è estremamente poco sicura.

Quindi per me hanno dimostrato di essere una società che vive solo con i ganci e non certo per la qualità dei propri prodotti.

Con questo non dico che AMD sia perfetta anzi! Ma per lo meno AMD visto che è in una posizione di difficoltà, sarebbe stata più giustificabile, Intel assolutamente no!

Originariamente inviato da nickname88

http://www.ansa.it/sito/notizie/tecn...806443643.html
https://www.techarp.com/articles/amd...ble-spectre-2/
https://www.phoronix.com/scan.php?pa...able-Variant-2
https://hardware.hdblog.it/2018/01/1...pyc-pathc-fix/

Ma dai! Ryzen è praticamente impossibile da attaccare con Spectre, comunque in uno dei link che hai messo c'è anche la risposta per quelli come te. Insomma ti sei screditato da solo.

Intel Fanboys Should Stop Throwing Stones
Some Intel fanboys are using this article as evidence that “AMD got caught lying” or “AMD CPUs are just as bad”. Well, let us address those claims.

AMD did not lie – In their original disclosure, they stated very clearly that “there is a near zero risk” of a Spectre 2 exploit working on an AMD CPU. We specifically mentioned and underlined that in the original article to stress that AMD was already aware that their CPUs are somewhat vulnerable to Spectre 2.
AMD CPUs are far less at risk – Even with this upgraded risk assessment, AMD CPUs are still much less vulnerable to Spectre 2 than Intel CPUs, and they are completely impervious to the Meltdown exploit. Because they are less vulnerable, AMD users have the option of not applying Spectre 2 patches that can have a significant performance impact.

Sottolineano addirittura che su AMD i rischi sono così remoti, che gli utenti possono anche decidere di non applicare la patch per la variante 2. Dai!!!

[Mister D]

Originariamente inviato da nickname88

Ma non è vero sia la prima parte che la seconda.

Ma da dove esce sta storia di Linux ? E' la prima e unica volta che la sento e solamente da te.
AMD è vulnerabile a spectre sia nella variante 1 e 2 indipendentemente dall'OS.

AMD quindi avrebbe pensato alla sicurezza ? Ma non diciamo cavolate, tutti mirano alla performance, ad AMD gli è semplicemente andata di cul0 e basta, tantè che ci sono voluti 10 anni per scoprire ste vulnerabilità. E il calo di performance è dato dalle implicazioni della patch via software, non dalla vulnerabilità in sè, se ti aspetti handicap paragonibili anche per la prossima serie mi sà che rimarrai deluso perchè il fix via hardware dovrebbe essere tutta un altra storia.

Scusami ma allora non segui bene la cosa:
https://googleprojectzero.blogspot.it/
During the course of our research, we developed the following proofs of concept (PoCs):

A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.

A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]

A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)

A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.

Mi pare abbastanza chiaro. Per ora google ha dimostrato che intel è bucabile a tutte le varianti e il PoC si basava su Haswell. Poi intel ha dichiarato che tutte le sue cpu sono vulnerabili da Nehalem in avanti. Anche se l'altro giorno ho provato io stesso su Q8200 e il test di microsoft mi ha confermato che è vulnerabile a tutte e tre e che dopo gli aggiornamenti è patchato tutto fuorché la variante 2 in attesa del bios per il microcodice cpu.

AMD invece è stata bucata SOLO per la 1. Poi in prima battuta amd dichiarava:
http://www.amd.com/en/corporate/speculative-execution
Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

E dopo alcuni giorni (dopo aver indagato ulteriormente magari) integrava la dichiarazione dicendo:
GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.

Poi se uno volesse approfondire di più questo articolo dice tutto:
https://arstechnica.com/gadgets/2018...t-performance/
In particolare:
Now the bad news
The branch predictor version of Spectre, however, is a different story. Microsoft warns that protecting against this specific problem "has a performance impact," and, unlike the Meltdown fixes, this impact can be felt in a wider range of tasks.

There are a range of tools available to software and operating system developers. There are processor-level changes and a software-level change, and a mix of solutions may be needed. These new features also interact with other processor security features.

We have known since last week that Intel is going to release microcode updates that will change the processor behavior for this attack. With microcode updates, Intel has enabled three new features in its processors to control how branch prediction is handled. IBRS ("indirect branch restricted speculation") protects the kernel from branch prediction entries created by user mode applications; STIBP ("single thread indirect branch predictors") prevents one hyperthread on a core from using branch prediction entries created by the other thread on the core; IBPB ("indirect branch prediction barrier") provides a way to reset the branch predictor and clear its state.

AMD's response last week suggested that there was little need to do anything on systems using the company's processors. That turns out to be not quite true, and the company is said to be issuing microcode updates accordingly. On its current processors using its Zen core—Ryzen, Threadripper, and Epyc—new microcode provides equivalents to IPBP and STIBP. On prior generation processors using the Bulldozer family, microcode has added IBRS and IBPB.

Zen escapes (again)

Why no IBRS on Zen? AMD argues that Zen's new branch predictor isn't vulnerable to attack in the same way. Most branch predictors have their own special cache called a branch target buffer (BTB) that's used to record whether past branches were taken or not. BTBs on other chips (including older AMD parts, Intel chips, ARM's designs, and Apple's chips) don't record the precise addresses of each branch. Instead, just like the processor's cache, they have some mapping from memory addresses to slots in the BTB. Intel's Ivy Bridge and Haswell chips, for example, are measured at storing information about 4,096 branches, with each branch address mapping to one of four possible locations in the BTB.

This mapping means that a branch at one address can influence the behavior of a branch at a different address, just as long as that different address maps to the same set of four possible locations. In the Spectre attack, the BTB is primed by the attacker using addresses that correspond to (but do not exactly match with) a particular branch in the victim. When the victim then makes that branch, it uses the predictions set up by the attacker.

Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address. This seems to be a product of good fortune; AMD switched to a different kind of branch predictor in Zen (like Samsung in its Exynos ARM processors, AMD is using simple neural network components called perceptrons), and the company happened to pick a design that was protected against this problem.

Quindi riassumendo AMD ha lavorato bene (di culo? Volontariamente? Non possiamo saperlo ergo evitiamo di affermare con assoluta sicurezza cose di cui purtroppo non potremo mai sapere) sulla BPU di Zen tanto che il microcodice opzionali attiverà SOLO metodi equivalenti a IBPB e STIBP mentre su tutte le altre architetture passate di AMD (da excavator in ritroso) come per tutti gli intel come per gli ARM verranno attivate tutte le protezioni compresa la IBRS.
Per le prestazioni per ora si sa solo che che una volta attivate tutte le protezioni, come sugli intel, il calo è abbastanza significativo in alcuni task ma anche senza test su ryzen mi pare evidente che se già devo attivare 2 protezioni su 3, ryzen avrà meno perdita di prestazioni e che si può certamente dire che AMD (a culo? volontariamente?) ha un'implementazione delle predizioni migliore sotto l'aspetto della protezione alla variante 2 di spectre.
Spero di esserti stato d'aiuto a capirci un po' di più.

[DakmorNoland]

Originariamente inviato da Mister D

Spero di esserti stato d'aiuto a capirci un po' di più.

Guarda che secondo me hai scritto troppo difficile per la maggior parte della gente, poi l'inglese chi vuoi che lo sappia??

Comunque al di la dell'ironia ti ringrazio perchè dei pezzi me li ero persi anch'io.

Mi sembra che gli utenti AMD possano stare piuttosto tranquilli.

Ma la variante 2 non era quella che colpiva solo l'hypervision e che coinvolge server e macchine virtuali annesse? Quindi all'utente medio penso interessi poco-niente.

[Mister D]

Originariamente inviato da DakmorNoland

Guarda che secondo me hai scritto troppo difficile per la maggior parte della gente, poi l'inglese chi vuoi che lo sappia??

Comunque al di la dell'ironia ti ringrazio perchè dei pezzi me li ero persi anch'io.

Mi sembra che gli utenti AMD possano stare piuttosto tranquilli.

Ma la variante 2 non era quella che colpiva solo l'hypervision e che coinvolge server e macchine virtuali annesse? Quindi all'utente medio penso interessi poco-niente.

Da quello che si può capire leggendo come avviene la vulnerabilità e vedendo i test direi che non è vero che colpisce solo i server, bensì è vero che i server subiscono le maggiori perdite perché i loro task per es, fanno più syscall al kernel e isolare completamente il kernel (sto parlando di meltdown per es) è evidente che porti ad uno "spreco" di cicli per fare il refresh delle pagine di tabulazione degli indirizzi di memoria virtuale. Questo peserà di più quanto più si faranno chiamate al kernel e i datacenter si è visto che perdono performance di più che in altri usi generici.
Per spectre 2 dai test sia di computerbase o di techspot invece a seconda del task generico si perde dal 2/3% fino al 15-20% (se ricordo bene era il rendering la parte peggiore insieme alle operazioni di I/O su ssd).
https://www.techspot.com/article/155...mance-windows/
https://www.computerbase.de/2018-01/...erheitsluecke/

[[A]okyZ]

Originariamente inviato da nickname88

http://www.ansa.it/sito/notizie/tecn...806443643.html
https://www.techarp.com/articles/amd...ble-spectre-2/
https://www.phoronix.com/scan.php?pa...able-Variant-2
https://hardware.hdblog.it/2018/01/1...pyc-pathc-fix/

Adesso che la tua figura l'hai fatta (link che smentiscono categoricamente le cazzate dette), come si dicevano ai bei tempi:

Puoi tonartene nel tombino. Grazie.

[nickname88]

Originariamente inviato da DakmorNoland

Beh oddio proprio così no, però capisci che se vendi a palate e hai fatto un sacco di soldi e ogni anno tutto quello che fai è rilasciare processori che se va bene sono il 5% più veloci dell'anno prima, beh il minimo è che almeno tu lavori un po' sulla sicurezza. Ma Intel se n'è proprio fregata, pensando che non fosse possibile portare un attacco a livello così basso. Però loro secondo me sapevano che se mai qualcuno fosse riuscito, i loro processori non erano affatto sicuri a livello di architettura.

Non ricordo più il nome della tecnologia, ma hanno di fatto implementato all'interno delle ultime architetture una tecnologia per aumentare le prestazioni di un 25% sui carichi più pesanti, che però di fatto per come è strutturata è estremamente poco sicura.

Se gli Intel fixati non avranno questi cali cosa dirai ?
Che hanno cambiato micro-architettura in meno di un anno ?

Ma dai! Ryzen è praticamente impossibile da attaccare con Spectre, comunque in uno dei link che hai messo c'è anche la risposta per quelli come te. Insomma ti sei screditato da solo.

Si la risposta di un utente.

Originariamente inviato da [A]okyZ

Adesso che la tua figura l'hai fatta (link che smentiscono categoricamente le cazzate dette), come si dicevano ai bei tempi:

Puoi tonartene nel tombino. Grazie.

Quale figura, risulta solamente che è difficilmente vulnerabile non che sia completamente immune.

[nickname88]

Originariamente inviato da Mister D

Scusami ma allora non segui bene la cosa:
https://googleprojectzero.blogspot.it/
During the course of our research, we developed the following proofs of concept (PoCs):

A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.

A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]

A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)

A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.

Mi pare abbastanza chiaro. Per ora google ha dimostrato che intel è bucabile a tutte le varianti e il PoC si basava su Haswell. Poi intel ha dichiarato che tutte le sue cpu sono vulnerabili da Nehalem in avanti. Anche se l'altro giorno ho provato io stesso su Q8200 e il test di microsoft mi ha confermato che è vulnerabile a tutte e tre e che dopo gli aggiornamenti è patchato tutto fuorché la variante 2 in attesa del bios per il microcodice cpu.

AMD invece è stata bucata SOLO per la 1. Poi in prima battuta amd dichiarava:
http://www.amd.com/en/corporate/speculative-execution
Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

E dopo alcuni giorni (dopo aver indagato ulteriormente magari) integrava la dichiarazione dicendo:
GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.

Poi se uno volesse approfondire di più questo articolo dice tutto:
https://arstechnica.com/gadgets/2018...t-performance/
In particolare:
Now the bad news
The branch predictor version of Spectre, however, is a different story. Microsoft warns that protecting against this specific problem "has a performance impact," and, unlike the Meltdown fixes, this impact can be felt in a wider range of tasks.

There are a range of tools available to software and operating system developers. There are processor-level changes and a software-level change, and a mix of solutions may be needed. These new features also interact with other processor security features.

We have known since last week that Intel is going to release microcode updates that will change the processor behavior for this attack. With microcode updates, Intel has enabled three new features in its processors to control how branch prediction is handled. IBRS ("indirect branch restricted speculation") protects the kernel from branch prediction entries created by user mode applications; STIBP ("single thread indirect branch predictors") prevents one hyperthread on a core from using branch prediction entries created by the other thread on the core; IBPB ("indirect branch prediction barrier") provides a way to reset the branch predictor and clear its state.

AMD's response last week suggested that there was little need to do anything on systems using the company's processors. That turns out to be not quite true, and the company is said to be issuing microcode updates accordingly. On its current processors using its Zen core—Ryzen, Threadripper, and Epyc—new microcode provides equivalents to IPBP and STIBP. On prior generation processors using the Bulldozer family, microcode has added IBRS and IBPB.

Zen escapes (again)

Why no IBRS on Zen? AMD argues that Zen's new branch predictor isn't vulnerable to attack in the same way. Most branch predictors have their own special cache called a branch target buffer (BTB) that's used to record whether past branches were taken or not. BTBs on other chips (including older AMD parts, Intel chips, ARM's designs, and Apple's chips) don't record the precise addresses of each branch. Instead, just like the processor's cache, they have some mapping from memory addresses to slots in the BTB. Intel's Ivy Bridge and Haswell chips, for example, are measured at storing information about 4,096 branches, with each branch address mapping to one of four possible locations in the BTB.

This mapping means that a branch at one address can influence the behavior of a branch at a different address, just as long as that different address maps to the same set of four possible locations. In the Spectre attack, the BTB is primed by the attacker using addresses that correspond to (but do not exactly match with) a particular branch in the victim. When the victim then makes that branch, it uses the predictions set up by the attacker.

Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address. This seems to be a product of good fortune; AMD switched to a different kind of branch predictor in Zen (like Samsung in its Exynos ARM processors, AMD is using simple neural network components called perceptrons), and the company happened to pick a design that was protected against this problem.

Quindi riassumendo AMD ha lavorato bene (di culo? Volontariamente? Non possiamo saperlo ergo evitiamo di affermare con assoluta sicurezza cose di cui purtroppo non potremo mai sapere) sulla BPU di Zen tanto che il microcodice opzionali attiverà SOLO metodi equivalenti a IBPB e STIBP mentre su tutte le altre architetture passate di AMD (da excavator in ritroso) come per tutti gli intel come per gli ARM verranno attivate tutte le protezioni compresa la IBRS.
Per le prestazioni per ora si sa solo che che una volta attivate tutte le protezioni, come sugli intel, il calo è abbastanza significativo in alcuni task ma anche senza test su ryzen mi pare evidente che se già devo attivare 2 protezioni su 3, ryzen avrà meno perdita di prestazioni e che si può certamente dire che AMD (a culo? volontariamente?) ha un'implementazione delle predizioni migliore sotto l'aspetto della protezione alla variante 2 di spectre.
Spero di esserti stato d'aiuto a capirci un po' di più.

E per curiosità dove c'è scritto che la vulnerabilità AMD non colpisce su Windows ?

[Mister D]

Originariamente inviato da nickname88

E per curiosità dove c'è scritto che la vulnerabilità AMD non colpisce su Windows ?

Non c'è scritto infatti. Ma tu sei partito con il chiedere da dove nascesse la storia di linux e nasce dal fatto che il team di google ha realizzato i PoC in linux magari perché era più veloce e immediato per loro dimostrare il problema. Tutto qui. Il fatto che poi si estenda ad altri OS mi pare lapalissiano dato che si tratta di vulnerabilità che riguardano COME unità della cpu operano (quindi hardware). Ergo teoricamente riguarda ogni OS. Teoricamente perché poi dipende dall'implementazione dell'OS: magari un OS non sfrutta alcune operazioni della cpu ergo può essere libero da quelle vulnerabilità ma non è questo il caso visto che Microsoft ha subito dichiarato di essere vulnerabile pure lei.
Ma gli altri utenti ti stavano dicendo altra cosa: che la vulnerabilità per ora su amd era stata dimostrata solo su una configurazione linux con settaggi non def (come riportato da Project zero). Non che non fossero vulnerabili su windows.
Si può essere vulnerabili ma avere meno rischio perché sfruttare tale vulnerabilità (cioè eseguire un exploit) è più difficile. Questo è quello che AMD ha detto fin'ora e che è stato confermato indirettamente da Project Zero visto che per es la variante 2 non è mai stata sfruttata su macchine con cpu AMD.
Sono due cose differenti anche se è sottile la differenza. Un po' come il rischio di un pericolo (in sicurezza ma anche in generale) è formato dalla moltiplicazione di probabilità che il pericolo accada per la sua pericolosità.
In questo caso si può dire che Intel ha un rischio al pericolo di vulnerabilità di spectre 2 più alto rispetto ad AMD perché la probabilità che questo accada è più alta ma la pericolosità è identica per entrambe.
Ti faccio un esempio terra terra:
Pericolo di folgorazione da energia elettrica.
1) casa con impianto a norma, nessun filo scoperto e impianto di massa a terra verificato
2) casa senza impianto a norma, fili scoperti e nessuna verifica dell'impianto di massa a terra.
La pericolosità è uguale per entrambi perché se entri in contatto con la 220V alternata le conseguenze sono identiche sia per chi abita 1) o 2) ma la probabilità che si verifichi in 1) è molto più bassa che in 2).
Così per intel e amd su spectre 2.

[Mister D]

Originariamente inviato da nickname88

Se gli Intel fixati non avranno questi cali cosa dirai ?
Che hanno cambiato micro-architettura in meno di un anno ?

cut...

Gli diremo che sono stati bravi, anche se ti posso assicurare che modificare il preditore di diramazione (BPU) o come la cpu implementa l'esecuzione speculativa non è proprio cosa da poco, sia in termini di effetti negativi post modifica sia in tempistiche.
Poi faccio notare che intel e gli altri sapevano ben prima di inizio gennaio del problema ergo magari hanno già pianificato di modificare il tutto con ice lake dove ci sarà il cambio microarchitetturale (e penso che il CEO intel anche se dirlo palesemente si riferisca a questo).
Purtroppo causa problemi sui 10 nm (prima implementazione cannon lake è ormai saltato) e questo ha costretto intel a:
- introdurre i 14++ per coffee lake
- buttarsi sui 10+ (seconda implementazione ottimizzata) per realizzare ice lake.
Sapendo delle vulnerabilità e che si poteva patchare il tutto via software e microcodice con un po' di penalità (variabile a seconda del task) mi sa che hanno deciso di andare avanti con coffee lake e rimandare la correzione a ice lake.
Idem per AMD che a maggior ragione avendo meno probabilità ma anche meno effetti negativi (IBRS vs IBPB) sulle patch per spectre 2 su ryzen, avrà portato avanti ryzen 2 (pinnacle ridge sui 12 aka 14+) mantenendo l'arch invariata e portando poi su ZEN 2 (ryzen 3) le correzioni hardware da apportare per essere completamente immune.
Quindi per me vedremo le prime cpu post vulnerabilità ai primi del 2019 (sul finire del 2018 se ce la fanno) con ice lake da una parte e matisse dall'altra.
Io mi sono fatto questa idea

[nickname88]

Originariamente inviato da Mister D

Non c'è scritto infatti. Ma tu sei partito con il chiedere da dove nascesse la storia di linux

Io chiesi dove nasce la storia del fatto che la vulnerabilità lato AMD si presenti SOLO su Linux.
CHe si presentasse anche su Linux lo sapevo già.

[rockroll]

Originariamente inviato da nickname88

Ed ecco che tutte le dicerie sul fatto che era necessaria una nuova microarchitettura va in fumo, idem la storia del diverso accesso alla memoria.

Che dal momento in cui li tireranno la nuova serie, non ci sarà più il rischio per i loro prodotti della discriminazione dovuti a ciò. E per le aziende non ci sarà più la convenienza di non rinnovare gli accordi commerciali.

Anzi nel momento in cui usciranno potranno anche vantarsi che la loro CPU è la più sicura al mondo visto che al momento sia le nuove AMD di 2°Gen che ARM sono ancora vulnerabili.

Insomma, da questa situazione di indubbio handicap risaputa da tutti, Intel ne uscirebbe alla grande, addirittura con vantaggi sulla controparte?

Non mi va di dire oltre contro chi è in palese difficoltà, vedo che a chiarirti le idee hanno già pensato altri direi più documentati e credibili di te.

[nickname88]

Originariamente inviato da calabar

Fonte?
Per la prima parte ovviamente, la seconda è un'opinione.

Originariamente inviato da DakmorNoland

Ad oggi è stata dimostrata l'effettiva sfruttabilità dei bachi solo su Intel per quanto riguarda Windows, AMD la prima variante solo su Linux e basta una ridicola patch del kernel per risolverla. La seconda variante è quasi impossibile da utilizzare.

Forse non ti è chiaro che Intel ha realizzato per anni dei colabrodo puntando solo sulle prestazioni, mentre AMD ha creato un'architettura 100 volte più sicura.

Ho ottenuto risposte ben diverse dal thread apposito.
A quanto pare le cavolate non sono uscite dalle mie dite ma da quelle di altri.

Originariamente inviato da zappy

quella frase dice solo che hanno realizzato la prova con un kernel linux speciale e con un procio AMD.
Non dice che è vulnerabile solo linux, non dice che è vulnerabile solo amd.
Dice che la loro prova l'hanno fatta a quel modo.

Originariamente inviato da FedNat

Non sta scritto da nessuna parte. Come ti era stato già detto (mi pare da Mister D) nei paper che descrivevano la vulnerabilità i ricercatori affermavano di aver realizzato dei Proof of Concept che per i processori AMD funzionavano solo su Linux con configurazione del Kernel non standard.

Infatti è quello che ho detto: Al momento della rivelazione della vulnerabilità i ricercatori, per quanto riguarda le CPU AMD, erano risuciti a realizzare una PoC solo su Linux con configurazione del Kernel particolare. A tale data non avevano una PoC su Windows (sempre per CPU AMD, su Intel è un'altra storia)

Originariamente inviato da GmG

https://www.amd.com/en/corporate/speculative-execution

colpisce sia windows che linux

Originariamente inviato da tallines

Anche in questo link non c'è scritto assolutamente che la vulnerabilità colpisce solo su Linux e non su Windows

[nickname88]

Originariamente inviato da rockroll

Non mi va di dire oltre contro chi è in palese difficoltà, vedo che a chiarirti le idee hanno già pensato altri direi più documentati e credibili di te.

Infatti il post subito sopra lo dimostra quanto erano informati.

[FedNat]

Originariamente inviato da nickname88

Infatti il post subito sopra lo dimostra quanto erano informati.

Guarda che Quello che ti ho scritto io te lo aveva già detto Mister D proprio in questo thread.

Inoltre, per precisare una mia frase da te evidenziata, una PoC di Spectre 2 per AMD su Windows non mi risulta sia ancora stata prodotta. Probabilmente la cosa è teoricamente possibile (altrimenti non avrebbero realizzato le patch) ma molto difficile da implementare. Quindi anche DakmorNoland, dal punto di vista pratico, ha abbastanza ragione.

Non capisco poi perché quoti Calabar che aveva anche lui scritto quello che nuovamente scritto io.

Sembra sempre che tu non legga quello che ti viene scritto

[nickname88]

Originariamente inviato da FedNat

Guarda che Quello che ti ho scritto io te lo aveva già detto Mister D proprio in questo thread.

Inoltre, per precisare una mia frase da te evidenziata, una PoC di Spectre 2 per AMD su Windows non mi risulta sia ancora stata prodotta. Probabilmente la cosa è teoricamente possibile (altrimenti non avrebbero realizzato le patch) ma molto difficile da implementare. Quindi anche DakmorNoland, dal punto di vista pratico, ha abbastanza ragione.

Non capisco poi perché quoti Calabar che aveva anche lui scritto quello che nuovamente scritto io.

Sembra sempre che tu non legga quello che ti viene scritto

E' stato detto esplicitamente che la vulnerabilità colpisce solo Linux e Windows no ( nonostante non esista alcun articolo che lo affermasse ). Poi decidi tu che giro fare per rispondere.


Tu scrissi questo :

Infatti è quello che ho detto: Al momento della rivelazione della vulnerabilità i ricercatori, per quanto riguarda le CPU AMD, erano risuciti a realizzare una PoC solo su Linux con configurazione del Kernel particolare. A tale data non avevano una PoC su Windows (sempre per CPU AMD, su Intel è un'altra storia)

Probabilmente la cosa è teoricamente possibile (altrimenti non avrebbero realizzato le patch)

Quindi la vulnerabilità su Windows c'è o non c'è ?
La ragione può averla solo uno, non è un argomento a libera interpretazione.