Un bug hardware affligge la memoria virtuale delle CPU Intel

Guarda che io non ho nessunissimo problema a spiegare i dettagli tecnici, ma se riempi i tuoi messaggi di faccine sarcastiche, frecciatine, e prese in giro, come hai fatto ieri sera/notte, poi non puoi certo pretendere che ti tratti coi guanti bianchi.

Comunque visto che quest'ultimo tuo messaggio è, diciamo, abbastanza pacato, rimango sullo stesso binario e passo alla spiegazione.

La questione, peraltro, è abbastanza semplice. Col nuovo microcodice Intel ha (anche!) introdotto una serie di [U]nuove[/U] (lo sottolineo) funzionalità che i s.o. possono utilizzare per controbattere agli attacchi di cui stiamo parlando. Ovviamente ce ne sono di apposite (come quella che hai riportato) proprio per la variante 2 di Spectre.
Un s.o., quindi, avendo bisogno di utilizzarle, deve per forza di cose o caricare il nuovo microcodice (che, quindi, le metterà a disposizione), oppure affidarsi al BIOS per questo. Il nuovo microcodice è condizione necessaria per poter implementare e far funzionare i meccanismi di difesa contro questi attacchi.

Ma, al contempo, Intel ha introdotto anche (!) delle modifiche interne in alcune parti del microcodice, per mitigare/eliminare già di per sé (quindi senza l'aiuto di alcun s.o.) alcuni specifici scenari (ma non tutti, ovviamente: altrimenti non ci sarebbe bisogno dell'aiuto del s.o.). Da cui la frase che ho riportato ieri, che lo dimostra.

Dunque possiamo dire che lo stesso microcodice ha una duplice funzione: mitigare/eliminare alcuni scenari E aiutare il s.o. in altri.

Questo perché Spectre (e Meltdown, che ha contributo anch'esso a spalancare le porte per tutta una serie di nuovi possibili attacchi) è un tipo di attacco molto complesso, che non si riduce soltanto a un paio di scenari, ma ci sono diversi casi che si possono sfruttare, pur rimanendo nelle "grandi famiglie" (chiamiamole così per semplificare) delle due varianti che sono state pubblicate.

Spero di essere stato chiaro. E buona giornata a tutti.

Prima di tutto faccio una premessa: se ho utilizzato toni sarcastici e faccine è stato perché sono stato preso diciamo "un po' a pesci in faccia" da te. In ogni caso il tuo approccio nell'ultimo messaggio mi fa piacere e lo prendo come un buon proposito per seppellire l'ascia di guerra che accetto ben volentieri.
Detto questo io capisco bene la tua spiegazione. Però non mi è riuscito di trovare nessun riscontro scritto e mi sembra che nemmeno tu lo abbia fornito. Il ragionamento che fai è logico, ti dico però che, disabilitare via registro la patch di spectre oltre ad evitare problemi di stabilità e incompatibilità come affermato da Microsoft , dai test che ho effettuato riporta le prestazioni della cpu come se si fosse in presenza di un sistema con BIOS senza microcodici e senza software di mitigazione, pur essendo in realtà i microcodici presenti. Non pretendo che questa sia la verità per tutti però è quella che ho potuto verificare per la mia situazione spendendoci tempo e pazienza.
Buona giornata anche a te

Grazie.

Questo succede perché perché le sole modifiche al microcodice per Spectre non impattano molto le prestazioni, trattandosi di casi/scenari molto particolari, e non comuni.

E', invece, quando il s.o. utilizza le nuove funzioni del microcodice per mettere in atto le difese a tutto campo (quindi coprendo tutti gli scenari) che si assiste a un calo prestazionale che può essere consistente (variabile in base al tipo di codice eseguito, ovviamente) e "palpabile".

EDIT. Aggiungo qualche dettaglio tecnico. Le modifiche al microcodice non possono, purtroppo (o forse è meglio così: dipende dai punti di vista), andare a cambiare cose come il funzionamento del branch predictor, perché molte funzionalità di un microprocessore sono "hard coded". Si tratta, cioè, di roba "fissata" e immodificabile.
Il microcodice serve, invece, per operazioni più complesse, che non è conveniente implementare con logica "fissa".

Dunque l'aggiornamento al microcodice può risolvere soltanto alcuni limitati scenari per le suddette funzionalità. Dove, cioè, può arrivare. Per il resto, purtroppo, non si può fare altro se non cercare di mitigare via software (magari col supporto di nuove funzionalità estese del processore grazie al nuovo microcodice. SE possibile, ovviamente) quel che si può, chiedendo aiuto al kernel.

Ti ripeto che il tuo ragionamento è logico. Però continuo a trovare riscontri che mi sembrano portare a conclusioni differenti dalle tue.
A me sembra di capire che la V2 spectre preveda una soluzione hardware disabilitabile via software tramite registro come affermato da Microsoft. Per la V1 spectre invece NON funziona la mitigazione tramite hardware e l'unica alternativa e la via software. La soluzione dei microcode credo riguardi quindi la sola v2 e la sola v2 è disattivabile via registro, mi sembra quindi di capire che la questione dei microcode impatti solo su quello e non su altro e che quindi una volta disattivata via software/registro tutti i possibili impatti relativi al microcode vengano annullati.
Riporto testualmente da anandtech: Unfortunately these hardware changes won’t mitigate Spectre variant 1. And admittedly, I haven’t been expecting Intel (or anyone else) to figure that one out in 2018. The best mitigations for Spectre v1 will remain developer-focused software techniques that avoid putting sensitive data at risk.
Quanto sopra scritto mi sembra quindi in contrasto con quello che dici quando affermi che nei microcode ci sono soluzioni per problemi legati ad altre varianti di spectre oltre alla v2 ma ovviamente posso sbagliarmi.
Per una più corretta comprensione della questione il link è questo: https://www.anandtech.com/show/12533/intel-spectre-meltdown

Non mi riferivo ad altre varianti di Spectre v2, ma ad altri scenari in cui è possibile sfruttare lo stesso tipo di vulnerabilità.
Giusto per fare un esempio, il microcodice aggiornato è in grado automaticamente di mitigare un attacco di tipo Spectre v2 in particolari contesti/scenari in cui si utilizzi la tecnologia SGX di Intel.
Queste protezioni sono già abilitate di default, e non necessitano di essere attivate via software dal s.o.. Inoltre non mi pare di aver letto che siano disabilitabili.

Quanto alla possibilità di disabilitare via software la soluzione hardware, questo riguarda le nuove funzionalità che il microcodice aggiornato mette a disposizione per affrontare questo tipo di vulnerabilità (dunque è ALTRA roba).
Normalmente sono abilitate (e dunque utilizzabili, ma... SE, appunto, il s.o. decide di usarle), ma è possibile disabilitarle e, dunque, non poterne più far uso. Ed è proprio a questo che si riferisce Microsoft.

Come vedi sono due cose diverse, sebbene entrambe richiedano (e siano insite) nel nuovo microcodice.

Capisco quello che vuoi dire ma, se parliamo della sola v2 spectre, a me sembra di capire che la disabilitazione indicata via registro da microsoft la riguardi per intero. Non fosse così ma fosse solo parzialmente vorrebbe dire continuare ad avere gli eventuali problemi di instabilità, compatibilità, performance, ecc. ecc. e Microsoft lo avrebbe specificato dicendo che la disabilitazione della v2 è solo parziale.
Prendendo spunto poi dal tuo esempio sulla tecnologia SGX anche li mi sembra che ci sia il lato software come riportato qui https://www.theregister.co.uk/2018/03/01/us_researchers_apply_spectrestyle_tricks_to_break_intels_sgx/ dove in particolare si dice: Intel says it will update its SGX SDK later this month to allow software attestation to detect the presence of Spectre mitigations. Enclave code will need to be rebuilt and redeployed using the updated development kit to be protected from malicious sysadmins
Ne deduco che il solo microcode non basti.

Per chiarire la faccenda ho recuperato la documentazione tecnica di Intel in cui vengono riportate tutte le modifiche architetturali e micro-architetturali che sono state implementate coi nuovi firmare.

Nello specifico, da pag. 9:

[I][INDENT]"2.5.1.1 IBRS: Basic Support
[B]Processors that support IBRS provide the following guarantees [U]without any enabling by software[/U][/B]:
• The predicted targets of near indirect branches executed in an enclave (a protected container defined by Intel® SGX) cannot be controlled by software executing outside the enclave.
• If the default treatment of SMIs and SMM is active, software executed before a systemmanagement interrupt (SMI) cannot control the predicted targets of indirect branches executed in system-management mode (SMM) after the SMI."[/INDENT][/I]

da cui, come si vede nella parte che ho evidenziato, questo tipo di miglioramenti non necessita di alcuna abilitazione, poiché sono già operativi di base.

Infatti è netta la differenza con quelle elencate subito dopo:

[I][INDENT]"2.5.1.2 IBRS: Support [B]Based on [U]Software Enabling[/U][/B]"[/INDENT][/I]

In linea teorica, e come dicevi, potrebbero esserci delle instabilità dovute al loro funzionamento poiché tale funzionalità risultano già immediatamente operative (e, da quel che ho letto, a me non sembra disabilitabile; al contrario delle altre).

Comunque si tratta soltanto di un paio di cose rispetto a tutto il resto (che rappresenta la parte più consistente).

Molto interessante, grazie per il link

Leggendo velocemente, mi è sembrato di capire che con SgxPectre, la cui scoperta è stata successiva alla revision del documento da te linkato, l'effetto del basic support nei microcode non è più sufficiente per prevenire questa ennesima variante di spectre, di qui la necessità di aggiornare l'SGX SDK per chiudere anche dal lato software.

There is a fix: Intel's microcode update that introduced indirect branch restricted speculation (IBRS), which flushes the branch prediction history at the enclave boundary.
However, an evil sysadmin at, for example, a cloud provider could revert the patch, and “there is no means for the enclave code to reliably detect if IBRS is enabled.” This means enclave code running on a remote cloud machine can be snooped on by BOFHs, when the whole point of SGX is to securely run code on a faraway box.
https://www.theregister.co.uk/2018/03/01/us_researchers_apply_spectrestyle_tricks_to_break_intels_sgx/

In ogni caso spero che non saltino fuori ulteriori criticità di questa portata e che le sorprese siano finite, almeno per il momento.