Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/spectre-e-meltdown-due-bug-di-sicurezza-che-sconvolgono-il-mondo-dell-informatica_73328.html

Meltdown e Spectre stanno facendo parlare molto di sé in queste ore: i due bug coinvolgono in maniera diversa i processori, con il secondo che è presente su tutte le CPU sul mercato. Un bel grattacapo per cui non esistono soluzioni definitive

Click sul link per visualizzare la notizia.

Ma stiamo scherzando? Se devo convivere con un calo delle prestazioni allora loro devono convivere con un rimborso. :mad:

Io ho fatto un acquisto per avere certe prestazioni e questo per me è un danno.

http://it.euronews.com/2018/01/05/falla-nei-processori-intel-crolla-in-borsa

Ripercussioni anche in borsa dopo la scoperta della falla nei processori dei computer di tutto il mondo. Le azioni Intel sono affondate del 5%, quelle di AMD sono aumentate del 10%.

why? E' un problema generalizzato.

Seguo la vicenda con molto interesse! :eek:

CUT

Ripercussioni anche in borsa
CUT

http://www.ilsole24ore.com/art/finanza-e-mercati/2018-01-05/intel-ceo-ha-venduto-azioni-39-milioni-appena-ha-saputo-bug-080652.shtml?uuid=AEHRHFcD
Ma pensa un po'... che furbone... :rolleyes:

Segnalo il primo POC:

http://cxsecurity.com/issue/WLB-2018010039

Spectre Information Disclosure Proof Of Concept

In particolare mi pare che acceda a un array tramite una misurazione di tempo (latenza):

time1 = __rdtscp(&junk); /* READ TIMER */
junk = *addr; /* MEMORY ACCESS TO TIME */
time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */

C'ho capito poco ma mi pare che misurando il tempo riesca ad accedere a un array

http://www.ilsole24ore.com/art/finanza-e-mercati/2018-01-05/intel-ceo-ha-venduto-azioni-39-milioni-appena-ha-saputo-bug-080652.shtml?uuid=AEHRHFcD
Ma pensa un po'... che furbone... :rolleyes:

Chiamalo fesso. :D

Piuttosto, non si spiego il "volo" delle azioni AMD. In maniera meno grave, ma sono anch'esse "bacate".

Il 2018 è iniziato in maniera molto movimentata.

Ma stiamo scherzando? Se devo convivere con un calo delle prestazioni allora loro devono convivere con un rimborso. :mad:

Io ho fatto un acquisto per avere certe prestazioni e questo per me è un danno.

Nei pc moderni il calo è minimo.

Sicuramente minore al calo che c'è ad ogni vs di w10.

Rimane il dubbio su come argineranno il problema sulle prossime cpu, cpu che sono già pronte a livello progetturale e che andranno pesantemente modificate.

http://it.euronews.com/2018/01/05/falla-nei-processori-intel-crolla-in-borsa

Ripercussioni anche in borsa dopo la scoperta della falla nei processori dei computer di tutto il mondo. Le azioni Intel sono affondate del 5%, quelle di AMD sono aumentate del 10%.

Ma anche no, verificare i dati prima di pubblicarli è troppo difficile?

Nei pc moderni il calo è minimo.

Sicuramente minore al calo che c'è ad ogni vs di w10.

Rimane il dubbio su come argineranno il problema sulle prossime cpu, cpu che sono già pronte a livello progetturale e che andranno pesantemente modificate.

A ogni versione di w10 non hai nessun calo anzi l’opposto o nel peggiore dei casi nessun miglioramento. Non diciamo leggende sentite sulla rete, basta un test per smentirle ma sarebbe troppo facile vero?

Quello che mi chiedo, non si puó monitorare tramite un update del kernel chi prova a sfondare il suo settore di ram e bloccarlo?

A. Mo di firewall?

why? E' un problema generalizzato.

Non è esattamente cosi. Intel è coinvolta molto di più di AMD e ARM.
I dettagli dei due bug sono spiegati bene anche con video esempi qui https://spectreattack.com/. Meltdown che impatta sulle prestazioni (agisce tra sistema operativo e applicazioni) e Spectre che non impatta sulle prestazioni (agisce tra applicazioni). Al momento solo Intel è vulnerabile ad entrambi i bug e questa è la lista delle architetture di CPU coinvolte https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr mentre AMD https://www.amd.com/en/corporate/speculative-execution e ARM https://developer.arm.com/support/security-update sono vulnerabili solo a Spectre. In particolare, Intel è vulnerabile a tutte e tre le varianti, ARM solo a due mentre AMD solo a una. Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

Ma anche no, verificare i dati prima di pubblicarli è troppo difficile?
Intel stock
2 gennaio - 5 gennaio : -5.17%
AMD stock
2 gennaio - 5 gennaio : +17.90%

verificato e pubblico.

mi dirai che sono le solite oscillazioni "umorali" del mercato a notizie del genere, e quindi con vita e ripercussioni breve, ma l'effetto sulla quotazione questa notizia lo ha avuto.

Quello che mi chiedo, non si puó monitorare tramite un update del kernel chi prova a sfondare il suo settore di ram e bloccarlo?

A. Mo di firewall?

già si fà.
qui la questione è che i dati usati per le speculazioni di eventuali rami di calcolo non sono cancellati propiamente (messi tutti a zero o con bit casuali), ma che vengono lasciati tali e quali.
di solito verrebbero sovrascritti, ma con alcune tecniche puoi prendere possesso di quello spazio e quindi anche leggere senza che siano preventivamente cancellati, facendoti gli affari di un'altro processo di precedente esecuzione.

riuscire a tirare fuori qualcosa di sfruttabile diventa complicato, ma non impossibile.

soprattutto sui browser si puo' mettere in ascolto un programma che interviene in determinate azioni, riuscendo a carpire chiavi protette.

Non è esattamente cosi. Intel è coinvolta molto di più di AMD e ARM.
I dettagli dei due bug sono spiegati bene anche con video esempi qui https://spectreattack.com/. Meltdown che impatta sulle prestazioni (agisce tra sistema operativo e applicazioni) e Spectre che non impatta sulle prestazioni (agisce tra applicazioni). Al momento solo Intel è vulnerabile ad entrambi i bug e questa è la lista delle architetture di CPU coinvolte https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr mentre AMD https://www.amd.com/en/corporate/speculative-execution e ARM https://developer.arm.com/support/security-update sono vulnerabili solo a Spectre. In particolare, Intel è vulnerabile a tutte e tre le varianti, ARM solo a due mentre AMD solo a una. Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

Anche IBM Power 8 e 9:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
http://www-01.ibm.com/support/docview.wss?uid=swg22012320
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

Se c'è qualcuno che conosce bene la speculative execution allora potrebbe dirmi se isolando i processi all'interno della speculative execution, si può risolvere il problema.

In pratica non si esegue in anticipo una istruzione se questa appartiene a un altro processo ma la speculative execution si fa solo all'interno dello stesso processo.

Questo comporta un calo di efficienza parziale in quanto l'esecuzione anticipata delle istruzioni di livello kernel è bloccata all'interno dei processi normali ma in compenso i processi sono totalmente isolati.

già si fà.
qui la questione è che i dati usati per le speculazioni di eventuali rami di calcolo non sono cancellati propiamente (messi tutti a zero o con bit casuali), ma che vengono lasciati tali e quali.
di solito verrebbero sovrascritti, ma con alcune tecniche puoi prendere possesso di quello spazio e quindi anche leggere senza che siano preventivamente cancellati, facendoti gli affari di un'altro processo di precedente esecuzione.

riuscire a tirare fuori qualcosa di sfruttabile diventa complicato, ma non impossibile.

soprattutto sui browser si puo' mettere in ascolto un programma che interviene in determinate azioni, riuscendo a carpire chiavi protette.

Capito.

Ma peró si potrebbe dare ordine al programma che usa dati sensibili di cancellare la memoria usata? Immagino di no. Giusto?

io ho disattivato gli aggiornamenti. io cali di prestazioni per un bug assurdo e che nessuno sfrutterà e che se anche mi entrassero a vedere le password non trovano niente perchè la mia password è sempre la stessa non mi garba.

io ho disattivato gli aggiornamenti. io cali di prestazioni per un bug assurdo e che nessuno sfrutterà e che se anche mi entrassero a vedere le password non trovano niente perchè la mia password è sempre la stessa non mi garba.

in verità il problema non è carpire la password di accesso al sistema ma ben altro.

Cioè, non certo io che non ho neppure le competenze per partire ma chi ha realmente interesse a farlo (mosso dal solito motore, il denaro? :stordita: ), ti mette (potenzialmente) a pecorina la macchina tipo:
CPU occupata al 100% perchè viene usata per generare...denari? (vedi, quest'elemento ritorna)...

+ o - l'idea è questa (anche se l'esempio che ho portato è stupido)

Anche IBM Power 8 e 9:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
http://www-01.ibm.com/support/docview.wss?uid=swg22012320
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

Grazie per la segnalazione, non avevo considerato CPU per mainframe e quelle poco diffuse.

Il furbetto del quartierino.....Brian Krzanich amministratore delegato di Intel, avendo già capito che le azioni sarebbero andate giù..........ehhh sai com' è, gli seccava perdere soldi........poverino.....

E non si è dimesso ?

O non sapeva nulla di questa storia...........?

Che impieghi i soldi che ha preso dalla vendita, per risolvere il problema, invece!

Ma che poi, questi che hanno dato vita a Meltdown e Spectre, non hanno null' altro da fare nella vita...........

Un problema non da poco...........se penso a tutti i computer usati al mondo in ambito privato e pubblico, banche compre.................

Meltdown and Spectre

Bugs in modern computers leak passwords and sensitive data. (https://meltdownattack.com/)

Segnalo il primo POC:

http://cxsecurity.com/issue/WLB-2018010039

Spectre Information Disclosure Proof Of Concept

In particolare mi pare che acceda a un array tramite una misurazione di tempo (latenza):

time1 = __rdtscp(&junk); /* READ TIMER */
junk = *addr; /* MEMORY ACCESS TO TIME */
time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */

C'ho capito poco ma mi pare che misurando il tempo riesca ad accedere a un array

Qui spiegano un po' cosa c'entra il timing https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

Capendo l'enorme portata dei possibili problemi che questi bug potrebbero causare a milioni di PC in tutto il mondo, specialmente quelli equipaggiatti con hardware Intel vedo tantissima, troppa confusione sull'argomento e troppo allarmismo ingiustificato da chi dovrebbe dormire tranquillo e sereno.

Vedo troppi generalizzare il problema mentre è Intel a doverne pagare in maggioranza le conseguenze, visto che il bug affligge i suoi processori, in misura molto minore AMD e AMR.

Poi come al solito ci si fa prendere dal panico quando basta tenere sotto controllo il proprio dispositivo e non dare autorizzazioni e accessi random a tutto e a tutti.

Non è esattamente cosi. Intel è coinvolta molto di più di AMD e ARM.
I dettagli dei due bug sono spiegati bene anche con video esempi qui https://spectreattack.com/. Meltdown che impatta sulle prestazioni (agisce tra sistema operativo e applicazioni) e Spectre che non impatta sulle prestazioni (agisce tra applicazioni). Al momento solo Intel è vulnerabile ad entrambi i bug e questa è la lista delle architetture di CPU coinvolte https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr mentre AMD https://www.amd.com/en/corporate/speculative-execution e ARM https://developer.arm.com/support/security-update sono vulnerabili solo a Spectre. In particolare, Intel è vulnerabile a tutte e tre le varianti, ARM solo a due mentre AMD solo a una. Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

Interessante, grazie per le risorse e le fonti :) Comunque non griderei al complotto ma piuttosto mi chiederei dove è finita tutta la sicurezza di cui parlava Intel.

Il furbetto del quartierino.....Brian Krzanich amministratore delegato di Intel, avendo già capito che le azioni sarebbero andate giù..........ehhh sai com' è, gli seccava perdere soldi........poverino.....

E non si è dimesso ?

O non sapeva nulla di questa storia...........?

Che impieghi i soldi che ha preso dalla vendita, per risolvere il problema, invece!

Ma che poi, questi che hanno dato vita a Meltdown e Spectre, non hanno null' altro da fare nella vita...........

Un problema non da poco...........se penso a tutti i computer usati al mondo in ambito privato e pubblico, banche compre.................

Meltdown and Spectre

Bugs in modern computers leak passwords and sensitive data. (https://meltdownattack.com/)
Un po' difficile da credere, visto alcune compagnie AV che dovevano rilasciare conformità con l'update "fixa Meltdown" di Windows (previsto sulla carta per il 9 gennaio) avevano annunciato se fosse o meno compatibile (la famosa chiave di conformità nel registro) già durante lo scorso dicembre.

Esempio, questo (https://support.kaspersky.com/14042) è l'annuncio di compatibilità dei prodotti Kaspersky rilasciato il 29 dicembre, dove riporta cosa sarebbe stato compatibile (e cosa no) con l'update del 9 gennaio, con relative date. Quindi è abbastanza ingenuo pensare che Intel non sapesse di nulla, tanto meno il suo CEO ;)

...non dominabile evidentemente nemmeno da "team" di molte persone, progettisti, scienziati ecc. ecc. e non nel settore dei processori per calcolatori-computer di fatto delle enormi macchine a stati finiti.
Questo è un problema nel microcodice dei K8 e K10 AMD ad esempio...e chissà quanti altri ancora ne esistono latenti...
https://hackaday.com/2017/12/28/34c3-hacking-into-a-cpus-microcode/

Marco71.

Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?
Perché se implementi una cosa e funziona, e si tratta di roba che non cambia nel tempo (parliamo del meccanismo di funzionamento della memoria virtuale, che è codificato ormai da parecchi anni), allora non ci rimetti mano a meno che non trovi, per l'appunto, un errore.

Quindi niente complottismo: si tratta "semplicemente" di una cosa che è diffusa tanto quanto i calcoli elettronici. I famigerati "bug"...
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.
Che non risolvono assolutamente le problematiche di cui parla la notizia.

Non è che basta appiccicare la parola "open" su qualcosa per conferirgli un'aura di sicurezza...

Capendo l'enorme portata dei possibili problemi che questi bug potrebbero causare a milioni di PC in tutto il mondo, specialmente quelli equipaggiatti con hardware Intel vedo tantissima, troppa confusione sull'argomento e troppo allarmismo ingiustificato da chi dovrebbe dormire tranquillo e sereno.

Vedo troppi generalizzare il problema mentre è Intel a doverne pagare in maggioranza le conseguenze, visto che il bug affligge i suoi processori, in misura molto minore AMD e AMR.

Poi come al solito ci si fa prendere dal panico quando basta tenere sotto controllo il proprio dispositivo e non dare autorizzazioni e accessi random a tutto e a tutti.

Interessante, grazie per le risorse e le fonti :) Comunque non griderei al complotto ma piuttosto mi chiederei dove è finita tutta la sicurezza di cui parlava Intel.
E dov'è la sicurezza di AMD e ARM, visto che pure loro sono afflitte da vulnerabilità?

...assoluta per ciò che viene prodotto da menti umane limitate, incapaci di andare oltre progetti di una certa complessità in ogni settore dello scibile non esiste.
Le cpu con esecuzione fuori ordine sono un esempio...e non solo quelle progettate da Intel...tutte...
Se fosse vivo il buon Tomasulo darebbe calci nel lato b alle seguenti generazioni nuove generazioni di progettisti.

Marco71.

Non è esattamente cosi. Intel è coinvolta molto di più di AMD e ARM.
I dettagli dei due bug sono spiegati bene anche con video esempi qui https://spectreattack.com/. Meltdown che impatta sulle prestazioni (agisce tra sistema operativo e applicazioni) e Spectre che non impatta sulle prestazioni (agisce tra applicazioni). Al momento solo Intel è vulnerabile ad entrambi i bug e questa è la lista delle architetture di CPU coinvolte https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr mentre AMD https://www.amd.com/en/corporate/speculative-execution e ARM https://developer.arm.com/support/security-update sono vulnerabili solo a Spectre. In particolare, Intel è vulnerabile a tutte e tre le varianti, ARM solo a due mentre AMD solo a una.

Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?

Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.
Interessante, grazie per averlo postato :)

Ho evidenziato AMD perchè ho come processore AMD e la domanda, perchè è il centro di tutto.........questo scombussolamento mondiale..........

Io non ho nessun calo prestazione, il SO è veloce come prima, W10 Fall Creators Update 1709 build 16299.192 .

Che poi a parte il calo di prestazioni....il problema sono i famosi dati.......
Un po' difficile da credere, visto alcune compagnie AV che dovevano rilasciare conformità con l'update "fixa Meltdown" di Windows (previsto sulla carta per il 9 gennaio) avevano annunciato se fosse o meno compatibile (la famosa chiave di conformità nel registro) già durante lo scorso dicembre.

Esempio, questo (https://support.kaspersky.com/14042) è l'annuncio di compatibilità dei prodotti Kaspersky rilasciato il 29 dicembre, dove riporta cosa sarebbe stato compatibile (e cosa no) con l'update del 9 gennaio, con relative date. Quindi è abbastanza ingenuo pensare che Intel non sapesse di nulla, tanto meno il suo CEO ;)
Infatti la domanda è messa per dire, che sapeva tutto :)

...assoluta per ciò che viene prodotto da menti umane limitate, incapaci di andare oltre progetti di una certa complessità in ogni settore dello scibile non esiste.
Le cpu con esecuzione fuori ordine sono un esempio...e non solo quelle progettate da Intel...tutte...
*
Se fosse vivo il buon Tomasulo darebbe calci nel lato b alle seguenti generazioni nuove generazioni di progettisti.

Marco71.
Il problema, come avevo già evidenziato nell'altro thread, è che vogliamo CPU con prestazioni sempre migliori. E finisce che poi ne paghiamo le conseguenze.

Questi bug potrebbero segnare la fine dell'informatica :eek:
=> Tutti ad arare i campi di grano! :D

O la fortuna per l'informatico che magari riesce a risolverne qualcuna. :fagiano:

E dov'è la sicurezza di AMD e ARM, visto che pure loro sono afflitte da vulnerabilità?

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel, secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti, cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li. Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

Qui spiegano un po' cosa c'entra il timing https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

Sì, l'esempio è chiaro in tutte le sue parti. Però quello è l'esempio del Meltdown mentre il mio è del Spectre. Comunque se tu od altri avete capito Meltdown allora vi siete chiesti se forse per risolvere il problema quell'istruzione di accesso alla kernel memory dell'esempio:

w = kern_mem[address] # if we get here crash

dovesse essere eseguita in maniera *non* speculativa? Questo perché non appartiene al set di istruzioni permesse dalla modalità utente, quindi non doveva essere riempito il registro w_ e neppure x_ e neppure doveva esserci l'accesso alla memoria user_mem[x_].

Con questo vincolo il programma sarebbe diventato:

t = a+b
u = t+c
v = u+d
if v:
w = kern_mem[address] # if we get here crash
x = w&0x100
y = user_mem[x]

senza alcuna possibilità di out of order e di esecuzione speculativa e cioè non sarebbe stato eseguita la micidiale:

t, w_ = a+b, kern_mem[address]
u, x_ = t+c, w_&0x100
v, y_ = u+d, user_mem[x_]

if v:
# crash
w, x, y = w_, x_, y_ # we never get here

Concordi?

Questi bug potrebbero segnare la fine dell'informatica :eek:
=> Tutti ad arare i campi di grano! :D

Troppo ottimista: per arare i campi ci vuole troppa tecnologia! Io direi al massimo di zappare e vangare :D

Oggi email apocalittiche dalla divisione sistemi informatici :sofico:

EDIT: da noi è particolarmente problematico. Ci sono un sacco di sistemi vecchi che pilotano ancora Delle macchine. Per dire... Oggi lavoravo vicino a una Sparc Station coperta da una spanna di polvere con il compito di controllare qualche attuatore e a un terminale con winxp a controllare un amplificatore RF.
Il problema più grosso è se per questi vecchi s.o. verranno rilasciati o meno aggiornamenti con le patch.

XP, come sappiamo, non è più supportato da anni. Per Sparc non ho idea.
Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel,
Quindi hanno anche loro problemi di sicurezza. Mal comune, per l'appunto.
secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti,
Non conosco aziende che affermino che i loro prodotti non siano sicuri. Se conosci qualcuna, gradirei un link a una pagina o documento, giusto per prenderne visione.
cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li.
Lì dove? Non è chiaro cosa vorresti dire.
Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.
Senza alcuna prova (e almeno non emerso proprio nulla), questo è il classico complottismo spicciolo.

Ho già affermato che non ha alcun senso per un'azienda come Intel, che sforna 400 MILIONI (MI-LI-O-NI) l'anno, di tenersi nella pancia un problema di sicurezza di questa portata, senza porvi alcun rimedio, col rischio di potersi beccare denunce e class action.

Soltanto i complottisti, che non sono in grado di usare nemmeno un pallottoliere per fare dei conti della serva così banali, possono sostenere una tesi del genere.

Sì, l'esempio è chiaro in tutte le sue parti. Però quello è l'esempio del Meltdown mentre il mio è del Spectre. Comunque se tu od altri avete capito Meltdown allora vi siete chiesti se forse per risolvere il problema quell'istruzione di accesso alla kernel memory dell'esempio:

w = kern_mem[address] # if we get here crash

dovesse essere eseguita in maniera *non* speculativa? Questo perché non appartiene al set di istruzioni permesse dalla modalità utente, quindi non doveva essere riempito il registro w_ e neppure x_ e neppure doveva esserci l'accesso alla memoria user_mem[x_].

Con questo vincolo il programma sarebbe diventato:

t = a+b
u = t+c
v = u+d
if v:
w = kern_mem[address] # if we get here crash
x = w&0x100
y = user_mem[x]

senza alcuna possibilità di out of order e di esecuzione speculativa e cioè non sarebbe stato eseguita la micidiale:

t, w_ = a+b, kern_mem[address]
u, x_ = t+c, w_&0x100
v, y_ = u+d, user_mem[x_]

if v:
# crash
w, x, y = w_, x_, y_ # we never get here

Concordi?
Senza esecuzione OoO ovviamente il problema non si pone, perché l'eccezione verrebbe sollevata immediatamente.

Ma il problema è un altro: è l'accesso ai dati della cache caricati speculativamente. E' questo che dev'essere risolto.

Ovviamente separando completamente gli spazi d'indirizzamento di kernel e user land, si risolve il problema a monte. Ma con un costo prestazionale che al momento sembra abbastanza ridotto.

Senza esecuzione OoO ovviamente il problema non si pone, perché l'eccezione verrebbe sollevata immediatamente.

Ma il problema è un altro: è l'accesso ai dati della cache caricati speculativamente. E' questo che dev'essere risolto.

L'esempio linkato da SkyLinx è proprio relativo ai dati della cache elaborati speculativamente. Tali dati sono sia di tipo privilegiato che non. La mia idea è che se i dati sono di tipo non privilegiato allora possono essere elaborati speculativamente ma se sono dati privilegiati allora si blocca la speculatività.

E in effetti l'esempio linkato non avrebbe problemi se fosse seguita la pratica della mia idea.

Ovviamente separando completamente gli spazi d'indirizzamento di kernel e user land, si risolve il problema a monte. Ma con un costo prestazionale che al momento sembra abbastanza ridotto.

Immagino che in questo caso non venga eseguita l'istruzione speculativa:

t, w_ = a+b, kern_mem[address]

L'esempio linkato da SkyLinx è proprio relativo ai dati della cache elaborati speculativamente. Tali dati sono sia di tipo privilegiato che non.
Esattamente.
La mia idea è che se i dati sono di tipo non privilegiato allora possono essere elaborati speculativamente ma se sono dati privilegiati allora si blocca la speculatività.

E in effetti l'esempio linkato non avrebbe problemi se fosse seguita la pratica della mia idea.
In realtà si potrebbe fare altro. Il tuo sarebbe un caso particolare, mentre problematiche di questo tipo ce ne sono diverse, che non verrebbero risolte con la tua idea.

Serve una soluzione più generale al problema.
Immagino che in questo caso non venga eseguita l'istruzione speculativa:

t, w_ = a+b, kern_mem[address]
No, in questo caso, non essendo mappata alcuna memoria del kernel, è proprio impossibile accedervi. Dunque non esisterebbe nessuna kern_mem[address]: tutta la memoria che il processo vede è solo ed esclusivamente sua.

Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte.

Esattamente.

In realtà si potrebbe fare altro. Il tuo sarebbe un caso particolare, mentre problematiche di questo tipo ce ne sono diverse, che non verrebbero risolte con la tua idea.

Serve una soluzione più generale al problema.

No, in questo caso, non essendo mappata alcuna memoria del kernel, è proprio impossibile accedervi. Dunque non esisterebbe nessuna kern_mem[address]: tutta la memoria che il processo vede è solo ed esclusivamente sua.

Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte.

Mi piacerebbe un link di altri problemi che tu citi così da farmi una idea più chiara della complessità di Meltdown.

Ma quando dici "Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte" mi fa venire in mente che non è necessario separare i due spazi di memoria ma solo accedere alla memoria privilegiata senza i trucchi permessi dall'esecuzione speculativa.

L'articolo di HWUpgrade è impreciso.

L'esecuzione fuori ordine non centra proprio nulla (da sola almeno).

La causa del problema è la gestione della cache assieme all'esecuzione speculativa.

Vero che l'esecuzione speculativa è spesso presente solo in processori out of order, ma non sono la stessa cosa e ci posso essere anche processori out of order che non implementano l'esecuzione speculativa.

L'esecuzione speculativa non è niente di speciale e non è legata ai processi o al kernel, è semplicemente il non fermare / stallare la pipeline quando si incontra un salto (jump).
Ogni istruzione di salto genera una biforcazione del codice, se il salto avviene si deve proseguire dall'indirizzo indicato nel salto e se il salto non avviene si prosegue con l'istruzione successiva al salto.

Il problema è che se il salto avviene o non avviene lo si sa troppo tardi quindi il processore ha due scelte.
Fermarsi per sapere il risultato del salto e poi procedere, ma questo causa stalli della pipeline e perdita di prestazioni o proseguire scegliendo lui (predizione di salto in base a varie tecniche da quelle semplici tipo "salto sempre fatto se all'indietro e salto mai fatto se in avanti" a quelle più raffinate che richiedono storia dei salti passati e ...) una delle due strade e proseguire senza fermarsi.
Se la predizione di salto sarà stata azzeccata si avrà una prestazione massimale (come se il salto non fosse mai esistito) e se la predizione è sbagliata bisognerà annullare l'effetto delle istruzioni eseguite erroneamente come se queste non fossero mai state eseguite, con ovviamente perdita prestazionale.

L'esecuzione fuori ordine è invece la possibilità di eseguire istruzioni non nell'ordine del programma se tali istruzioni non hanno dipendenze tra di loro.
Es.
...
C=A*B
D=C+2
E=A+3
...
In un processore con esecuzione in ordine E sarebbe calcolato dopo (o al più in parallelo) che è stato calcolato D che a sua volta per forza deve aspettare che sia stato calcolato C, mentre in un processore con out of order, verrebbe iniziato il calcolo di C, D sarebbe messo in pausa causa dipendenze ma nel frattempo verrebbe calcolato E.
Di fatto il calcolo di E avverrebbe prima di D e quindi l'esecuzione è fuori ordine (solo l'esecuzione materiale è fuori ordine i risultati devono essere comunque sempre presentati in ordine per conservare la semantica del codice).
E questo non centra con l'esecuzione speculativa anche se di solito l'esecuzione speculativa è presente solo in processori che sono anche out of order.

PS
Anche sulle CPU senza speculazione hw ci sono delle tecniche per minimizzare il costo dei salti (es. i delay slot usati su Mips, l'uso di istruzioni condizionali per evitare l'uso di salti su Arm ed altre cpu)

Mi piacerebbe un link di altri problemi che tu citi così da farmi una idea più chiara della complessità di Meltdown.
Gli altri non riguardano Meltdown. Ma al momento preferisco non parlarne perché sto elaborando delle soluzioni a queste problematiche, e non so ancora cosa farci.
Ma quando dici "Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte" mi fa venire in mente che non è necessario separare i due spazi di memoria ma solo accedere alla memoria privilegiata senza i trucchi permessi dall'esecuzione speculativa.
Se vuoi continuare ad avere i due spazi di memoria condivisi ovviamente devi risolvere il problema dell'accesso ai dati "non tuoi" (del kernel, nello specifico) pur lavorando in maniera speculativa.

@Yrbaf: in questo caso si parla propriamente di esecuzione speculativa E out-of-order, perché non c'è alcun salto coinvolto, ma una violazione di privilegio che comporta il sollevamento di un'eccezione (che si potrebbe considerare un salto, in fin dei conti), che però ha dato ugualmente dato seguito al caricamento di dati del kernel in cache (da cui la "speculazione").

Ok se c'è speculazione c'è un cambio di PC quindi di fatto l'equivalente di un salto, poi che sia una istruzione di salto esplicita o una eccezione importa di meno.

Non ho letto gli articoli originali ma ancora non capisco cosa centri l'esecuzione out of order (che tra l'altro non vedo, ma magari vedrei se vedessi i testi originali).
Il colpevole pare solo l'esecuzione speculativa e la relativa gestione della cache che non fa un Undo completo (o non lo fa abbastanza velocemente dando tempo di leggerla) degli effetti delle istruzioni speculative.

Comunque in ogni caso anche se centrasse da sola non basterebbe, un processore out of order senza speculazione (e ci sono o c'erano) non dovrebbe soffrire del problema.
Come non soffrono i processori in order perché di solito sono tutti senza speculazione.

Sì, il paper originale (che trovi nel sito di Meltdown che è stato tirato sù appositamente) spiega molto meglio il tutto, mostrando anche le istruzioni eseguite dal processore, e perché funziona con l'esecuzione out-of-order.

Non ho letto gli articoli originali ma ancora non capisco cosa centri l'esecuzione out of order (che tra l'altro non vedo, ma magari vedrei se vedessi i testi originali).
Il colpevole pare solo l'esecuzione speculativa e la relativa gestione della cache che non fa un Undo completo (o non lo fa abbastanza velocemente dando tempo di leggerla) degli effetti delle istruzioni speculative.

Anch'io ho capito che se c'è una esecuzione speculativa allora le tracce vengono lasciate in un modo o nell'altro in quanto potrebbe essere che l'azione coinvolga la cache in certi casi oppure la memoria normale in altri per cui misurando le latenze si vengono a scoprire i dati della memoria privilegiata.

Ma cdimauro afferma che il vincolo (forse imposto dai produttori di processori che non hanno spazio di azione col microcodice) è quello di non toccare l'esecuzione speculativa sia per quanto riguarda l'out of order che i branch.

Si potrebbe programmare un browser che venga eseguito unicamente sulla GPU ? ( magari non le Intel :mbe: )
Così eliminiamo la gestione di dati sensibili da parte del processore centrale :D :mano: :winner: :cincin:

Per sicurezza vado a depositare il brevetto. Questa idea è da Nobel !!!

why? E' un problema generalizzato.

Non è uno ma più problemi (sostanzialmente 3), e solo Intel è coinvolta in tutti. La pezza SW più impattante prestazionalmente riguarda un problema solo di CPU Intel, ed altri rappezzamenti per gli altri problemi non risolvono completamente, ma AMD assicura che ne è coinvolta solo marginalmente.
https://pbs.twimg.com/media/DSrds-iXkAE1BWY.jpg

Ora che le cose si sanno, ti sembra così strano come reagiscono i mercati?

Tieni anche presente che se chi ha la gran parte del mercato è maggiormente coinvolta in fattori negativi, il deprezzamento anche di poco delle sue azioni ha come conseguenza un aumento ben più marcato di quelle della concorrenza meno coinvolta.
Su un mercato (x86/64) che in volumi vale 100 poniamo che Intel valga 80, Amd 10 ed Altri 10, se Intel perde il 10% passando a 72%, e questo viene rimpiazzato da AMD e Altri, ognuno dei due acquisirà 4 punti percentuali degli 8 persi da intel, passando da 10% a 14% con un incremento percentuale del 40%. In queste proporzioni è esattamente quanto sta succedendo (-5% per Intel, +20% per AMD e per Altri).

L'articolo di HWUpgrade è impreciso.

L'esecuzione fuori ordine non centra proprio nulla (da sola almeno).

La causa del problema è la gestione della cache assieme all'esecuzione speculativa.

Vero che l'esecuzione speculativa è spesso presente solo in processori out of order, ma non sono la stessa cosa e ci posso essere anche processori out of order che non implementano l'esecuzione speculativa.

L'esecuzione speculativa non è niente di speciale e non è legata ai processi o al kernel, è semplicemente il non fermare / stallare la pipeline quando si incontra un salto (jump).
Ogni istruzione di salto genera una biforcazione del codice, se il salto avviene si deve proseguire dall'indirizzo indicato nel salto e se il salto non avviene si prosegue con l'istruzione successiva al salto.

Il problema è che se il salto avviene o non avviene lo si sa troppo tardi quindi il processore ha due scelte.
Fermarsi per sapere il risultato del salto e poi procedere, ma questo causa stalli della pipeline e perdita di prestazioni o proseguire scegliendo lui (predizione di salto in base a varie tecniche da quelle semplici tipo "salto sempre fatto se all'indietro e salto mai fatto se in avanti" a quelle più raffinate che richiedono storia dei salti passati e ...) una delle due strade e proseguire senza fermarsi.
Se la predizione di salto sarà stata azzeccata si avrà una prestazione massimale (come se il salto non fosse mai esistito) e se la predizione è sbagliata bisognerà annullare l'effetto delle istruzioni eseguite erroneamente come se queste non fossero mai state eseguite, con ovviamente perdita prestazionale.

L'esecuzione fuori ordine è invece la possibilità di eseguire istruzioni non nell'ordine del programma se tali istruzioni non hanno dipendenze tra di loro.
Es.
...
C=A*B
D=C+2
E=A+3
...
In un processore con esecuzione in ordine E sarebbe calcolato dopo (o al più in parallelo) che è stato calcolato D che a sua volta per forza deve aspettare che sia stato calcolato C, mentre in un processore con out of order, verrebbe iniziato il calcolo di C, D sarebbe messo in pausa causa dipendenze ma nel frattempo verrebbe calcolato E.
Di fatto il calcolo di E avverrebbe prima di D e quindi l'esecuzione è fuori ordine (solo l'esecuzione materiale è fuori ordine i risultati devono essere comunque sempre presentati in ordine per conservare la semantica del codice).
E questo non centra con l'esecuzione speculativa anche se di solito l'esecuzione speculativa è presente solo in processori che sono anche out of order.

PS
Anche sulle CPU senza speculazione hw ci sono delle tecniche per minimizzare il costo dei salti (es. i delay slot usati su Mips, l'uso di istruzioni condizionali per evitare l'uso di salti su Arm ed altre cpu)

Grazie per la tua chiarissima esposizione: finalmente si capisce bene la problematica, anche se queste soluzioni di ottimizzazione lasciano molto perplesso chi non è addentrato (quasi come gli effetti relativistici spiegati alla massa).
Mi piacerebbe sapere dove documentarsi in rete su arcani di questo tipo.

Un estraneo ai fatti giudicherebbe secondo buon senso molto più oneroso scandire la logica di dipendenze nelle variabili del codice per applicare elaborazione "out of order" o addirittura ricorrere a statistiche predittive ed altre considerazioni probabilistiche per decidere se preeseguire magari inutilmente istruzioni successive ad un salto condizionato... piuttosto che lasciandare andare le cose avante belle semplici logiche e pulite nel sacrosanto rispetto del codice da eseguire.
Ma è poi così drammatico se lo stack di pipeline per qualche istante non lavora, piuttosto che lavorare magari inutilmente?

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel, secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti, cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li. Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

Quoto completamente.

Non si può difendere a prescindere una società che ha la faccia tosta di affermare che "non c'è un bug nei processori e tutto funziona come previsto"... peccato che quel che non funziona è quello che non hanno previsto (o hanno preferito non prevedere)!

why? E' un problema generalizzato.

proprio, guarda la tabella http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu
in pratica amd ha uno solo dei tre (spectra1, assenti spectra2 e meltdown) che mentre per intel affligge tutti i sistemi operativi e non esiste soluzione software per amd afflige solo linux (in alcuni casi) e ha soluzione software.

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel, secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti, cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li. Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu

http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu

Estrapolato dal tuo link:
"Nel mentre il comunicato di Intel (quello che cerca di far credere che tutti sono coinvolti un egual misura) ha avuto successo, in quanto ha fermato l'ascesa del titolo di AMD, che da un +10,5% è sceso ad un +7,5% finale, ed al contempo ha limitato la caduta del titolo Intel, passato da un -7% ad un -4,5%."

Ho sempre detto che AMD o altro concorrente potrebbe fare CPU migliori di Intel (e a questo punto direi che ci è realmente riuscita), ma per lo meno nell'immediato cambierebbe ben poco: lo strapotere ed il fattore condizionante del quasi monopolio Intel, a prescindere da come acquisito, non si riesce a scalfire solo con argomentazioni tecnologiche (e di convenienze di acquisto).

Non ho capito se spectre v2 affligge solo alcune CPU AMD

P.S. Ho visto soluzioni per praticamente tutti i sistemi (desktop, Android, iOS, ecc) ma non per le console. Qualcuno ha notizie a riguardo?

Anch'io ho capito che se c'è una esecuzione speculativa allora le tracce vengono lasciate in un modo o nell'altro in quanto potrebbe essere che l'azione coinvolga la cache in certi casi oppure la memoria normale in altri per cui misurando le latenze si vengono a scoprire i dati della memoria privilegiata.

Ma cdimauro afferma che il vincolo (forse imposto dai produttori di processori che non hanno spazio di azione col microcodice) è quello di non toccare l'esecuzione speculativa sia per quanto riguarda l'out of order che i branch.
No, non mi riferivo a quello. Il problema di Meltdown è strettamente legato a un bug relativo alla gestione della cache, che viene fuori grazie a precise sequenze di istruzioni che sfruttano l'attuale implementazione dell'architettura basata su esecuzione speculativa e out-of-order.

Il paper (che invito a leggere per chi fosse interessato) ne parla già dall'abstract.
Non è uno ma più problemi (sostanzialmente 3), e solo Intel è coinvolta in tutti. La pezza SW più impattante prestazionalmente riguarda un problema solo di CPU Intel,
Gli stessi ricercatori che hanno trovato la falla hanno precisato che l'impatto prestazionale è "negligible" (parole loro, ovviamente).

Notizia di ieri. Per chi s'informa, ovviamente.
Grazie per la tua chiarissima esposizione: finalmente si capisce bene la problematica, anche se queste soluzioni di ottimizzazione lasciano molto perplesso chi non è addentrato (quasi come gli effetti relativistici spiegati alla massa).
E' normale. Chi non è addentrato in certi argomenti può soltanto far viaggiare la fantasia e lasciarsi andare a battutine e attacchi privi di senso.
Mi piacerebbe sapere dove documentarsi in rete su arcani di questo tipo.
Su Appunti Digitali sono stati scritti diversi articoli da ingegneri che lavoravano per nVidia e AMD, e che sono abbastanza "potabili" per chi è a digiuno di micro/architetture.

Altrimenti ci sono svariati testi di Architetture degli Elaboratori, col Patterson fra i classici, che affrontano molto più estensivamente (nonché accademicamente) gli argomenti.

Infine, ci sono sempre i manuali per le ottimizzazioni che sono pubblicati da Intel e AMD che riportano numerose informazioni su loro specifiche microarchitetture.
Un estraneo ai fatti giudicherebbe secondo buon senso molto più oneroso scandire la logica di dipendenze nelle variabili del codice per applicare elaborazione "out of order" o addirittura ricorrere a statistiche predittive ed altre considerazioni probabilistiche per decidere se preeseguire magari inutilmente istruzioni successive ad un salto condizionato... piuttosto che lasciandare andare le cose avante belle semplici logiche e pulite nel sacrosanto rispetto del codice da eseguire.
Difatti è un'assunzione che può fare soltanto un estraneo ai fatti, per l'appunto, che non ha la minima idea di come funzionino i processori moderni e di quali tecniche vengano usate per migliorare le prestazioni rispetto alla primitiva esecuzione in stretto ordine e senza speculazioni.

Mentre esperti del settore ovviamente la pensano diversamente. Ecco cosa viene riportato già nel solo abstract del paper, ad appena la TERZA riga, che è stato pubblicato dai ricercatori di sicurezza che hanno individuato il famigerato Meltdown:

"Out-of-order execution is an indispensable performance feature and present in a wide range of modern processors."

Direi che sia piuttosto eloquente. Ovviamente per chi capisce E vuol capire.
Ma è poi così drammatico se lo stack di pipeline per qualche istante non lavora, piuttosto che lavorare magari inutilmente?
Cosa sarebbe questo "stack di pipeline"? E' un termine coniato da un "estraneo ai fatti"?

Se è così, vale il solito consiglio: è sempre meglio parlare soltanto di cose di cui si ha conoscenza. Quanto meno di base.
Quoto completamente.

Non si può difendere a prescindere una società che ha la faccia tosta di affermare che "non c'è un bug nei processori e tutto funziona come previsto"... peccato che quel che non funziona è quello che non hanno previsto (o hanno preferito non prevedere)!
Altre perle da "estraneo ai fatti"? O hai delle fonti per questo?

Già disponibile la patch di sicurezza per i telefoni Windows:
- W10M FCU build 15254.158
- W10M CU build 15063.850
- W10M AU build 14393.2007
Noi su Windows siamo già al sicuro, mentre i telefoni Android dovranno pregare i santi... :ciapet:
=> Lunga vita a W10M :yeah:

Già. Peccato che anche i Nokia-Microsoft che ho comprato a moglie e figlia avrebbero dovuto avere W10M, e invece sono rimasti alla 8.1. Dunque in balia di queste problematiche.

Dunque grazie, Microsoft, per aver messo sulla graticola i tuoi stessi clienti, trattandoli peggio di Google con Android.

P.S. E' bene ricordare che i processori usati sui dispositivi W10M, come pure Android, sono basati su ARM. Quindi "mal comune, mezzo gaudio": non è solo Intel che piange.

Con Interop Tools puoi aggiornare qualsiasi telefono a W10M. Il mio Lumia 630 in questo momento monta W10M FCU :)

Già. Peccato che anche i Nokia-Microsoft che ho comprato a moglie e figlia avrebbero dovuto avere W10M, e invece sono rimasti alla 8.1. Dunque in balia di queste problematiche.

Dunque grazie, Microsoft, per aver messo sulla graticola i tuoi stessi clienti, trattandoli peggio di Google con Android.

P.S. E' bene ricordare che i processori usati sui dispositivi W10M, come pure Android, sono basati su ARM. Quindi "mal comune, mezzo gaudio": non è solo Intel che piange.

Non mi permetto di dissentire perchè sei tu l'esperto, ma faccio un ragionamento logico.

Punto primo, avendo avuto anche io i Nokia-Microsoft da te menzionati, Lumia 920, 930 e non più supportati ne so qualcosa (si sapeva da tempo perchè hanno oltrepassato i 36 mesi di garantiti per il supporto di sicurezza) non credo abbia messo sulla graticola nessuno all'epoca, difficilmente oggi si può pensare di supportare terminali ormai scomparsi, se poi bontà sua Microsoft decidesse di fixare anche i terminali WP8.1 ormai fuori produzione da anni sarebbe pure bello, nel frattempo sto cercando di capire se Samsung fixerà anche il mio A5 2017, un telefono di un anno, fino ad oggi non so nulla.

Punto secondo, i processori ARM sono coinvolti in maniera molto marginale dalle falle in questione, un eventuale attacco risulta molto difficile da attuare e dubito che qualcuno compia lo sforzo necessario per bucare i terminali di tua Moglie o di tua figlia, a meno che non abbiano segreti industriali o lavorino per il governo.

Infine non so che terminali siano, ma dubito che sia stata una spesa elevata all'epoca vista la scarsa diffusione, penso che come tutti li hai presi a prezzi stracciati.

Poi si può discutere se 36 mesi sono pochi o molti, ma mi risulta che su terminali non più aggiornati rimasti a Windows 8.1 il supporto di sicurezza è proseguito ben oltre la scadenza, oltretutto installare windows 10 su uno Snapdragon S2 o S4 non credo si avrebbe avuto un terminale fluido come si era abituati, considerando che all'epoca oltre il processore non all'altezza persino la RAM era appena sufficiente, e non parlo dei 530 con 512 mb, anche se qualcuno è riuscito a ficcare W10 anche li..

Ma di cosa stiamo parlando? di una linea ormai morta e sepolta rimasta come reliquia? Il problema grave è qualche centianaia di milioni di terminali non più supportati in giro per il mondo, non qualche decina di rimasugli da museo che non se li caga nessuno, il problema sono i milioni di Computer, server e Workstation, in particolare e nella maggioranza con processori Intel, macchine che costano una cifra e che la soluzione sembra solo provvisoria.. quello è il problema..

Già disponibile la patch di sicurezza per i telefoni Windows:
- W10M FCU build 15254.158
- W10M CU build 15063.850
- W10M AU build 14393.2007
Noi su Windows siamo già al sicuro, mentre i telefoni Android dovranno pregare i santi... :ciapet:
=> Lunga vita a W10M :yeah:

Veramente Google ha una soluzione che non impatta le prestazioni della CPU, a differenza della soluzione Microsoft.
Per i Pixel è già stata fornita una patch.
Per gli android Stock (come lo Xiaomi Mi A1) arriverà a breve. In genere si patcha ogni primo giorno del mese.
Il problema sono tutti gli altri smartphone di marke con distro personalzizate di android. Forse la mancanza di patch spingerà gli utenti a distri libere ed alternative di android (ubuntu touch?!)

la mancanza di patch non avrà nessun effetto per la maggioranza degli user di smartphone, purtroppo...

è da tanto che lo scrivo ormai, ma la policy su android deve cambiare, non possono più lasciar fare gli oem come meglio credono. verrà utilizzato meno? pazienza

btw io in (semibramosa) attesa di patch per il bq acquaris che uso. e la bq è tra gli oem 'svegli'...

CUT

Qualcosa con Oreo almeno è cambiato, si chiama Project Treble, con quello dovrebbe essere più semplice aggiornare i terminali.

AMD ha optato per una soluzione un pelino drastica https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html

"This new firmware disables branch prediction on AMD family 17h processor"

Ma nel frattempo http://seclists.org/fulldisclosure/2018/Jan/12

Olè i mitici superchipponi tutta cripto che dovevano garantirci pane, lavoro e felicità. Ma levare quelle schifezze di ME e PSP no!?! Giusto per cominciare, neh!

proprio, guarda la tabella http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu
in pratica amd ha uno solo dei tre (spectra1, assenti spectra2 e meltdown) che mentre per intel affligge tutti i sistemi operativi e non esiste soluzione software per amd afflige solo linux (in alcuni casi) e ha soluzione software.
Interessante il link che hai postato .

Quindi chi usa un processore AMD in ambito Windows, non è coinvolto ?...........

comuque questa mattina si è aggiornato con la stessa patch anche WIN10 con CPU AMD (stesso antivirus dell'altro mio PC). Leggevo sulle news che hanno corretto un altro bug su AMD.

Su AMD l'auslogic benchmark dà risultati migliori.

Sul notebook con Intel:
-Intel extreme tuning vede una variazione dello 0.87% fra prima e dopo patch
-CPU-M indica una variazione del 1.6% nelle prestazioni della CPU
-intelburn test all'incirca uguale
-HWBot indica una perdita di 0.20%
-burnintest dellla passmark indica gli stessi risultati.
-il vecchio benchmark auslogic benchmark indica una variazione dell'8-10%. Questo test però non esegue cicli di calcoli, ma simula grafica 2D, uso CPU, uso HDD/SSD, ecc...

Interessante, grazie per le risorse e le fonti :) Comunque non griderei al complotto ma piuttosto mi chiederei dove è finita tutta la sicurezza di cui parlava Intel.
Complotto? Già dimenticato lo scandalo Prism nel NSA del 2013 (https://en.wikipedia.org/wiki/PRISM_(surveillance_program)) e lo scandalo Vault 7 del 2017 CIA (https://en.wikipedia.org/wiki/Vault_7)? Queste sono forme volute di controllo da parte degli USA verso gli altri stati dato che le CPU Intel sono prodotte in USA sotto il controllo del governo tramite NSA e CIA.
In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2) e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug.

...non dominabile evidentemente nemmeno da "team" di molte persone, progettisti, scienziati ecc. ecc. e non nel settore dei processori per calcolatori-computer di fatto delle enormi macchine a stati finiti.
Questo è un problema nel microcodice dei K8 e K10 AMD ad esempio...e chissà quanti altri ancora ne esistono latenti...

Marco71.
Certo, cambiando il microcodice di una CPU con uno buggato è normale avere la possibilità di mettere trojan. Il ME di Intel è un trojan di questo tipo.

E dov'è la sicurezza di AMD e ARM, visto che pure loro sono afflitte da vulnerabilità?
Leggi il mio primo messaggio. Solo Intel è vulnerabile al bug Meltdown. Riguardo al bug Spectre ARM è coinvolta pienamente mentre AMD solo parzialmente.
Leggi qui (http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu)

Perché se implementi una cosa e funziona, e si tratta di roba che non cambia nel tempo (parliamo del meccanismo di funzionamento della memoria virtuale, che è codificato ormai da parecchi anni), allora non ci rimetti mano a meno che non trovi, per l'appunto, un errore.

Quindi niente complottismo: si tratta "semplicemente" di una cosa che è diffusa tanto quanto i calcoli elettronici. I famigerati "bug"...

In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2) e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug. Non è complottismo, è la realtà dei fatti. Come negare PRISM, VAULT 7, ME e adesso questo? Solo una persona priva di ragionamento può ignorargli, senza offesa.


Che non risolvono assolutamente le problematiche di cui parla la notizia.

Non è che basta appiccicare la parola "open" su qualcosa per conferirgli un'aura di sicurezza...

Ne abbiamo parlato anche in altre sedi. Un software o hardware closed source non ti garantisce alcuna trasparenza e la storia recente parla chiaro. Le corrispondenti versioni open forniscono trasparenza e permettono di risolvere prima il problema.
Anche Snowden auspica l'adozione di hardware o software open source fonte (https://twitter.com/snowden/status/837367956229206016?lang=en) e lui conosce bene la situazione.

AMD ha optato per una soluzione un pelino drastica https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html

"This new firmware disables branch prediction on AMD family 17h processor"

Si per AMD il bug è solo su linux, al momento hanno optato per la soluzione più drastica, già modificata.


Ma nel frattempo http://seclists.org/fulldisclosure/2018/Jan/12

Olè i mitici superchipponi tutta cripto che dovevano garantirci pane, lavoro e felicità. Ma levare quelle schifezze di ME e PSP no!?! Giusto per cominciare, neh!

Mi quoto (https://www.hwupgrade.it/forum/showpost.php?p=45283218&postcount=13):
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

No, non mi riferivo a quello. Il problema di Meltdown è strettamente legato a un bug relativo alla gestione della cache, che viene fuori grazie a precise sequenze di istruzioni che sfruttano l'attuale implementazione dell'architettura basata su esecuzione speculativa e out-of-order.

Il paper (che invito a leggere per chi fosse interessato) ne parla già dall'abstract.



Io per Meltdown ho capito solo questo esempio che si trova in fondo alla pagina dopo molte spiegazioni preliminari:

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

mettono insieme il branch prediction con la speculative execution in un bel esempio molto facile da comprendere. Invece il paper che mi hai suggerito di leggere è troppo complicato e non ci sono esempi nel testo che mi permettono di seguire i lunghi discorsi che loro fanno nel paper. Troppo complicato per me questo metodi di apprendimento e comprensione. È come comprendere un teorema senza formule ma con una descrizione a parole come facevano gli antichi: troppo complicato.

Edit: aggiungo che nell'esempio la cache è sfruttato per individuare il dato presente nella memoria privilegiata (kernel memory).In pratica la cache è la cartina di tornasole per distinguere tra un bit a 0 e un bit a 1 di un certo indirizzo nella memoria privilegiata, la distinzione è fatta con i tempi di latenza tra il dato in cache o in RAM.

Ma su Windows XP la falla verrà corretta anche se il supporto è terminato?

Ma su Windows XP la falla verrà corretta anche se il supporto è terminato?

(a regola) no.

Ma anche fosse SI, XP (per quanto ancora sia dura da accettare per qualcuno) è esposto ad infiniti modi per scalarne privilegi rispetto ai suoi successori.

Accettatelo perchè è cosi' per cui non occorre scomodare neppure Spectre :eek: ecc


Cioè, si parla ancora di un defunto?

(a regola) no.

Ma anche fosse SI, XP (per quanto ancora sia dura da accettare per qualcuno) è esposto ad infiniti modi per scalarne privilegi rispetto ai suoi successori.

Accettatelo perchè è cosi' per cui non occorre scomodare neppure Spectre :eek: ecc


Cioè, si parla ancora di un defunto?

mi spiego meglio:
XP su un Ryzen/Intel 8°gen + flash BIOS etc? (su quelli prima invece mi viene direttamente da ridere)

Piuttosto una martellata sui °° perchè (forse) sarò anche coperto contro Spectre e C. ma sono talmente tanti altri i pericoli REALI in cui posso imbattermi per cui è sprecato anche solo perdere tempo a parlarne.

(a regola) no.

Ma anche fosse SI, XP (per quanto ancora sia dura da accettare per qualcuno) è esposto ad infiniti modi per scalarne privilegi rispetto ai suoi successori.

Accettatelo perchè è cosi' per cui non occorre scomodare neppure Spectre :eek: ecc


Cioè, si parla ancora di un defunto?

Speriamo che MS fa un'eccezione anche se XP è fuori supporto :) perchè mi sembra una falla abbastanza grave :(

qual'è il senso di sprecare risorse (denaro, sudore,..) su una cosa che E' GIA' A PECORINA a prescindere da questo rischio?

Cioè, se io avessi XP (indipendentemente dalla piattaforma hardware), mi preoccuperei di altro...e questo non lo volete (/potete?) accettare.

XP → CESTINO

Per carità, è stato bello...ma allora viviamo di ricordi e non parliamone più

Ma su Windows XP la falla verrà corretta anche se il supporto è terminato?

Per fare un paragone appropriato è come chiedere a Fiat di aggiornare il carburatore della Topolino..
17 anni in informatica corrispondono a 50 annni nelle auto..

Possibile, ma non è garantito :D

ma xp lo lasciate morire in pace? :D

è da tanto che lo scrivo ormai, ma la policy su android deve cambiare, non possono più lasciar fare gli oem come meglio credono. verrà utilizzato meno? pazienza



dubito google dica "pazienza" se si usa di meno :D

è da tanto che lo scrivo ormai, ma la policy su android deve cambiare, non possono più lasciar fare gli oem come meglio credono. verrà utilizzato meno? pazienza


Project Treble, lanciato con Android Oreo serve proprio a questo. Gli OEM non avranno più scuse. E se continuano....beh, sarà ora che i consumatori traggano le dovute conclusioni e agiscano di conseguenza.

dubito google dica "pazienza" se si usa di meno :D

Project Treble, lanciato con Android Oreo serve proprio a questo. Gli OEM non avranno più scuse. E se continuano....beh, sarà ora che i consumatori traggano le dovute conclusioni e agiscano di conseguenza.

temo non sia abbastanza, e prima o poi 'pazienza' dovrà dirlo secondo me, con aggiornamenti obbligatori e imposti, e se non accetti usi altro os

si, lo so...

temo non sia abbastanza, e prima o poi 'pazienza' dovrà dirlo secondo me, con aggiornamenti obbligatori e imposti, e se non accetti usi altro os

si, lo so...

Bella questione. Non so se Google abbia o meno il potere per fare una cosa del genere. Da un lato esistono alternative ad Android, dall'altro queste alternative hanno una frazione delle app di Android.

Se da un lato gli OEM non possono migrare all'istante, dall'altro potrebbero in 4-5 anni farla pagare a Google. Chiaramente non è detto che dall'altra parte troverebbero il bengodi. Un'ipotetica Microsoft o Canonical non gradirebbero trovarsi con terminali su cui girano i loro OS che non vengono aggiornati mai.

Credo che a questo giro gli OEM dovranno correggere il tiro o cominceranno a volare sberle. Considerando pure ormai il tema sicurezza è diventato di dominio pubblico, la pressione da parte degli utenti dovrebbero aumentare nel prossimo futuro.

Penso che quanto successo con Meltdown e Spectre abbia lasciato poca gente che ancora dorme tra due guanciali.

doppio

Credo che a questo giro gli OEM dovranno correggere il tiro o cominceranno a volare sberle. Considerando pure ormai il tema sicurezza è diventato di dominio pubblico, la pressione da parte degli utenti dovrebbero aumentare nel prossimo futuro.

su questo non sono così ottimista, ma vedremo
per il resto la ricetta non ce l'ho ci mancherebbe, ma questa situazione del tutto particolare, potrebbe essere la prova che così com'è ora non va bene. se poi chi dovrebbe farlo trarrà le conclusioni, in un mondo dove contano solo i bilanci a tre mesi, mah...
anche perchè alla fine una possibile conseguenza di questo 'richiamo sulla sicurezza agli utenti' potrebbe essere una corsa al cambio terminale, e non sarebbe irreale ipotizzare che ci contino pure gli oem...

maaaaa dopo la patch perchè se lancio la conversione di un video da 4 Gb della telecamera il processore va al 46% di 2.93GHz invece che al 100%?
:mbe:

la questione di android è sempre la solita alla fine... è vero che treble toglie la scusa dei driver ma dubito che per i terminali di fascia basa cambierà molto...
alla fine ci guadagno abbastanza poco vendendo quelli anche con supporto quasi nullo...

Grazie per la tua chiarissima esposizione: finalmente si capisce bene la problematica, anche se queste soluzioni di ottimizzazione lasciano molto perplesso chi non è addentrato (quasi come gli effetti relativistici spiegati alla massa).
Mi piacerebbe sapere dove documentarsi in rete su arcani di questo tipo.

Oltre a quanto già consigliato puoi consultare le dispense in Italiano del corso di Architetture II dell'Università di Torino.

Cerca Gunetti (che è un docente) + architettureII e troverai la pagina del sito con i pdf delle Slide che spiegano parecchia roba (in modo abbastanza comprensibile ma ovviamente un minimo di basi le richiedono) e con i rimandi a testi (almeno 3) da consultare per approfondimenti.

Ah non centrano nulla con questo bug, sono solo corsi su RISC, ILP (statica e dinamica), Branch Prediction Speculativa e non, MultiIssue, Cache, Architetture dei processori moderni con vari casi concreti esaminati, ...ecc


Un estraneo ai fatti giudicherebbe secondo buon senso molto più oneroso scandire la logica di dipendenze nelle variabili del codice per applicare elaborazione "out of order" o addirittura ricorrere a statistiche predittive ed altre considerazioni probabilistiche per decidere se preeseguire magari inutilmente istruzioni successive ad un salto condizionato... piuttosto che lasciandare andare le cose avante belle semplici logiche e pulite nel sacrosanto rispetto del codice da eseguire.
Ma è poi così drammatico se lo stack di pipeline per qualche istante non lavora, piuttosto che lavorare magari inutilmente?
L'elaborazione out of order è sicuramente più onerosa ed infatti richiedendo anche più energia di solito i processori più parsimoniosi (vedi Atom, almeno quelli vecchi, ma anche molti Arm) sono InOrder.
Però i più veloci sono invece OoO.

Non è lavoro inutile perché tu fai del lavoro nella speranza che sia produttivo.
Le istruzioni speculative è vero che se il salto (o cambio di Program Counter) è predetto in modo errato sono lavoro inutile che potrebbe generare pure ulteriore lavoro per l'operazione di undo.
Ma è anche vero che tu speri di azzeccare spesso/con elevata incidenza (sempre è statisticamente impossibile) la predizione e quindi quando questo avviene ti sei solo portato avanti a fare lavoro che tanto dovevi comunque fare.

Ovvio che se i meccanismi di predizione sono poco efficienti allora alla fine vai più piano che senza questi sofismi.
E' lo stesso con la cache.
Un sistema dotato di cache ha tempi di accesso alla ram più lenti di un sistema senza cache (perché devi attraversare tutti i livelli di cache).
Però poi tu conti sul fatto che per pochi cache miss totale (con hit in ram) avrai molti cache hit conseguenti.
Certo che se fai solo cache miss allora un sistema senza cache andrebbe più veloce di te.

ma le vecchie cpu tipo Marvell Armada , kirkwood armv7 sono affette anche loro?

Con Interop Tools puoi aggiornare qualsiasi telefono a W10M. Il mio Lumia 630 in questo momento monta W10M FCU :)
E' lo stesso telefono delle donne di casa. Come va? Hai avuto cali prestazionali?
Non mi permetto di dissentire perchè sei tu l'esperto, ma faccio un ragionamento logico.
Tranquillo: è un forum di discussione, dove chiunque può dire la sua. Qui non stiamo parlando di questione tecniche, peraltro. ;)
Punto primo, avendo avuto anche io i Nokia-Microsoft da te menzionati, Lumia 920, 930 e non più supportati ne so qualcosa (si sapeva da tempo perchè hanno oltrepassato i 36 mesi di garantiti per il supporto di sicurezza) non credo abbia messo sulla graticola nessuno all'epoca, difficilmente oggi si può pensare di supportare terminali ormai scomparsi, se poi bontà sua Microsoft decidesse di fixare anche i terminali WP8.1 ormai fuori produzione da anni sarebbe pure bello, nel frattempo sto cercando di capire se Samsung fixerà anche il mio A5 2017, un telefono di un anno, fino ad oggi non so nulla.

Punto secondo, i processori ARM sono coinvolti in maniera molto marginale dalle falle in questione, un eventuale attacco risulta molto difficile da attuare e dubito che qualcuno compia lo sforzo necessario per bucare i terminali di tua Moglie o di tua figlia, a meno che non abbiano segreti industriali o lavorino per il governo.

Infine non so che terminali siano, ma dubito che sia stata una spesa elevata all'epoca vista la scarsa diffusione, penso che come tutti li hai presi a prezzi stracciati.

Poi si può discutere se 36 mesi sono pochi o molti, ma mi risulta che su terminali non più aggiornati rimasti a Windows 8.1 il supporto di sicurezza è proseguito ben oltre la scadenza, oltretutto installare windows 10 su uno Snapdragon S2 o S4 non credo si avrebbe avuto un terminale fluido come si era abituati, considerando che all'epoca oltre il processore non all'altezza persino la RAM era appena sufficiente, e non parlo dei 530 con 512 mb, anche se qualcuno è riuscito a ficcare W10 anche li..

Ma di cosa stiamo parlando? di una linea ormai morta e sepolta rimasta come reliquia? Il problema grave è qualche centianaia di milioni di terminali non più supportati in giro per il mondo, non qualche decina di rimasugli da museo che non se li caga nessuno, il problema sono i milioni di Computer, server e Workstation, in particolare e nella maggioranza con processori Intel, macchine che costano una cifra e che la soluzione sembra solo provvisoria.. quello è il problema..
Non è questo il punto. Il punto è che Microsoft aveva annunciato l'aggiornamento a W10M di tutti i dispositivi WP8, e non l'ha fatto. Non c'entrano niente i 36 mesi di supporto: avrebbe dovuto mantenere la parola data.

A saperlo prima NON avrei comprato quei telefoni.

Inoltre aveva già lasciato a piedi me, che sono stato un pioniere, prendendo uno dei primi WP7, che ha aggiornato soltanto fino alla 7.8 e lasciandomi quindi a piedi.

Per cui la terza possibilità non gliela concedo più: Microsoft ha finito con me per quanto riguarda gli smartphone. A meno che non riuscirà ad avere quote di mercato comparabili agli altri player E un parco app dello stesso livello.

/OT.

AMD ha optato per una soluzione un pelino drastica https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html

"This new firmware disables branch prediction on AMD family 17h processor"
Decisamente drastica. Comporterà un notevole calo delle prestazioni. Ci sono benchmark pre-post patch?
Ma nel frattempo http://seclists.org/fulldisclosure/2018/Jan/12
Interessante.
Olè i mitici superchipponi tutta cripto che dovevano garantirci pane, lavoro e felicità. Ma levare quelle schifezze di ME e PSP no!?! Giusto per cominciare, neh!
Questo, lo dovresti sapere, è un non-sequitur: sono due cose logicamente diverse che non c'entrano niente l'una con l'altra.

Complotto? Già dimenticato lo scandalo Prism nel NSA del 2013 (https://en.wikipedia.org/wiki/PRISM_(surveillance_program)) e lo scandalo Vault 7 del 2017 CIA (https://en.wikipedia.org/wiki/Vault_7)? Queste sono forme volute di controllo da parte degli USA verso gli altri stati dato che le CPU Intel sono prodotte in USA sotto il controllo del governo tramite NSA e CIA.
Sì, già dimenticato. Passiamo avanti, visto che è il solo spauracchio complottista che viene tirato fuori regolarmente ogni volta che si parla di problemi di sicurezza.
In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2) e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug.
Il link l'hai letto? Mi pare di no. Non è che puoi postare cose a caso quando il thread parla di SPECIFICHE vulnerabilità, e ricamarci sopra il classico fantascenario complottista.

Potresti cortesemente DIMOSTRARE come da quel link si arrivi alla fantasticheria che ti sei sparato più sotto?
Certo, cambiando il microcodice di una CPU con uno buggato è normale avere la possibilità di mettere trojan. Il ME di Intel è un trojan di questo tipo.
Il microcodice delle CPU e l'IME sono due cose COMPLETAMENTE DIVERSE.

Così, tanto per continuare sulla scia di cose messe assieme a caso, solo perché si parla di sicurezza.
Leggi il mio primo messaggio. Solo Intel è vulnerabile al bug Meltdown. Riguardo al bug Spectre ARM è coinvolta pienamente mentre AMD solo parzialmente.
Leggi qui (http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu)
Ho già letto tutto. E t'è sfuggito anche un link che riporta una graziosa tabella con diversi processori ARM che sono affetti ANCHE da Meltdown.
In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2) e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug. Non è complottismo, è la realtà dei fatti. Come negare PRISM, VAULT 7, ME e adesso questo? Solo una persona priva di ragionamento può ignorargli, senza offesa.
Vedi sopra: questo è puro complottismo basato su un link sparato ad muzzum solo perché si parla di sicurezza.

DIMOSTRA come da quel link si arrivi allo scenario allucinante che ti sei inventato di sana pianta.

D'altra parte ti ricordo che l'onere della prova è tuo, visto che è la TUA tesi.
Ne abbiamo parlato anche in altre sedi. Un software o hardware closed source non ti garantisce alcuna trasparenza e la storia recente parla chiaro. Le corrispondenti versioni open forniscono trasparenza e permettono di risolvere prima il problema.
Sì, ne abbiamo già parlato, e ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché.

Dimostrazione che né tu né altri avete minimamente scalfito, a parte cercare di aggirarla con giochetti di parole, perché dovreste riscrivere la matematica per piegarla alle vostre fantasie.
Anche Snowden auspica l'adozione di hardware o software open source fonte (https://twitter.com/snowden/status/837367956229206016?lang=en) e lui conosce bene la situazione.
Puoi anche chiedere a lui che smonti il mio teorema, allora: tanto è del campo e gli sarà facile, no?

In mancanza mi attengo a ciò che ho dimostrato.
Mi quoto (https://www.hwupgrade.it/forum/showpost.php?p=45283218&postcount=13):
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.
Mi quoto:

"ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché."

Io per Meltdown ho capito solo questo esempio che si trova in fondo alla pagina dopo molte spiegazioni preliminari:

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

mettono insieme il branch prediction con la speculative execution in un bel esempio molto facile da comprendere.
Al momento non ho tempo di leggere anche quel link, perché sono esausto.

A naso direi che la branch prediction venga utilizzata soltanto nei casi di Spectre.

In Meltdown ti serve l'esecuzione speculativa + l'out-of-order. Non si affida affatto alla branch prediction.
Invece il paper che mi hai suggerito di leggere è troppo complicato e non ci sono esempi nel testo che mi permettono di seguire i lunghi discorsi che loro fanno nel paper. Troppo complicato per me questo metodi di apprendimento e comprensione. È come comprendere un teorema senza formule ma con una descrizione a parole come facevano gli antichi: troppo complicato.
Posso confermarti che è un paper abbastanza complesso da digerire per chi non è ferrato con gli argomenti.

Lascia perdere: c'è da mettersi le mani nei capelli (per chi li ha :asd:) per capire la genialata che si trova dietro a Meltdown. Tanto di cappello, veramente, a chi l'ha scoperto.
Edit: aggiungo che nell'esempio la cache è sfruttato per individuare il dato presente nella memoria privilegiata (kernel memory).In pratica la cache è la cartina di tornasole per distinguere tra un bit a 0 e un bit a 1 di un certo indirizzo nella memoria privilegiata, la distinzione è fatta con i tempi di latenza tra il dato in cache o in RAM.
In estrema sintesi, sì, ma manca un pezzo dello scenario (il ruolo che ha il probe array) che è molto interessante ed è la chiave per capire come funziona l'attacco.

Posso confermare, peraltro, che le mie idee sono applicabili ai casi descritti nel paper Meltdown.

Però un amico mi ha inviato un link a un tweet in cui uno studente è riuscito a sniffare la memoria del kernel senza gli espedienti del paper. Per cui in questo caso le mie contromisure non dovrebbero funzionare; ma mancano di PoC di questo tizio, non posso confermare al momento.

ma le vecchie cpu tipo Marvell Armada , kirkwood armv7 sono affette anche loro?

Il kirkwood se non ricordo male è ARMv5 e quindi in order e senza speculazione.
Ergo non soffre del problema.

Nella famiglia Armada però ci sono un sacco di processori di cui alcuni Out of Order (es. quelli basati su Cortex A9, A15, A57) e quindi alcuni modelli potrebbero essere affetti.

PS
Mi pare di aver visto che Cortex A8 sia nella lista degli affetti dai problemi, anche se A8 è un processore InOrder.
Mentre non sono affetti (tutti InOrder) A5, A7, A35, A53, A55

L'elaborazione out of order è sicuramente più onerosa ed infatti richiedendo anche più energia di solito i processori più parsimoniosi (vedi Atom, almeno quelli vecchi, ma anche molti Arm) sono InOrder.
Però i più veloci sono invece OoO.

Non è lavoro inutile perché tu fai del lavoro nella speranza che sia produttivo.
Le istruzioni speculative è vero che se il salto (o cambio di Program Counter) è predetto in modo errato sono lavoro inutile che potrebbe generare pure ulteriore lavoro per l'operazione di undo.
Ma è anche vero che tu speri di azzeccare spesso/con elevata incidenza (sempre è statisticamente impossibile) la predizione e quindi quando questo avviene ti sei solo portato avanti a fare lavoro che tanto dovevi comunque fare.

Ovvio che se i meccanismi di predizione sono poco efficienti allora alla fine vai più piano che senza questi sofismi.
E' lo stesso con la cache.
Un sistema dotato di cache ha tempi di accesso alla ram più lenti di un sistema senza cache (perché devi attraversare tutti i livelli di cache).
Però poi tu conti sul fatto che per pochi cache miss totale (con hit in ram) avrai molti cache hit conseguenti.
Certo che se fai solo cache miss allora un sistema senza cache andrebbe più veloce di te.
*

C'è sempre un trade-off. In questo caso il fatto che Meltdown sia presente a partire dal PentiumPro, che è la prima CPU out-of-order di Intel (il precedente Pentium era in-order), dovrebbe far capire che non è stato un atto voluto, ma un errore di distrazione dei progettisti che non hanno tenuto conto di scenari complicati come quelli che sono descritti nel paper Meltdown, per quanto riguarda esclusivamente la sicurezza (visto che i processori operano correttamente con tutti i calcoli che gli vengono dati in pasti).

La macchinosità di Meltdown dovrebbe essere garanzia, per chi ha avuto modo di sbatterci le corna e studiarsela, che non stiamo parlando cose banalotte, come il dottore che dimentica la pinza nella pancia del paziente, ma di questioni estremamente complicate che possono sfuggire a quelli che, in ultima analisi, sono pur sempre degli esseri umani e... sbagliano.

Poi, vabbé, sappiamo che i forum sono pieni di geni delle microarchitetture (non sto riferendo a te, sia chiaro. ;)) che si sentono in diritto di pontificare pur non avendo la minima idea di quello che dicono... :rolleyes:
ma le vecchie cpu tipo Marvell Armada , kirkwood armv7 sono affette anche loro?
C'era una tabella, ma non trovo più il link.

Comunque se sono processori out-of-order, è possibile che siano affetti.

Al momento non ho tempo di leggere anche quel link, perché sono esausto.

A naso direi che la branch prediction venga utilizzata soltanto nei casi di Spectre.

In Meltdown ti serve l'esecuzione speculativa + l'out-of-order. Non si affida affatto alla branch prediction.



Mi sa che ho fatto confusione. C'è un if, un branch, nell'algoritmo ma non viene sfruttata la predizione. In effetti viene sfruttata l'esecuzione speculativa e l'out of order.

Sì, già dimenticato. Passiamo avanti, visto che è il solo spauracchio complottista che viene tirato fuori regolarmente ogni volta che si parla di problemi di sicurezza.

Mi fa ridere quando le persone pur di nascondere la realtà utilizzano la parola complottista.
Mi dispiace aver toccato la tua ex Intel, i dati e i fatto parlano chiaro fonte (http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu). Poi puoi continuare a dire ciò che vuoi. L'importante è credere alle favole.


Il link l'hai letto? Mi pare di no. Non è che puoi postare cose a caso quando il thread parla di SPECIFICHE vulnerabilità, e ricamarci sopra il classico fantascenario complottista.

Potresti cortesemente DIMOSTRARE come da quel link si arrivi alla fantasticheria che ti sei sparato più sotto?


Certo, Intel ha cambiato la gestione della memoria MMU:

Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).

Non sono parole mie, ma dello sviluppatore di openSSL che ne capisce molto più di chiunque in questo forum senza offesa fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2).


Il microcodice delle CPU e l'IME sono due cose COMPLETAMENTE DIVERSE.
Così, tanto per continuare sulla scia di cose messe assieme a caso, solo perché si parla di sicurezza.


Certo che sono cose diverse, il risultato ottenuto è lo stesso un trojan nella CPU.


Ho già letto tutto. E t'è sfuggito anche un link che riporta una graziosa tabella con diversi processori ARM che sono affetti ANCHE da Meltdown.


Si e no. Solo alcune architetture ARM e i problemi sono risolvibili senza cambiare CPU diversamente da Intel. Anche tu non hai letto con dettaglio fonte (http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu).


Vedi sopra: questo è puro complottismo basato su un link sparato ad muzzum solo perché si parla di sicurezza.

DIMOSTRA come da quel link si arrivi allo scenario allucinante che ti sei inventato di sana pianta.

D'altra parte ti ricordo che l'onere della prova è tuo, visto che è la TUA tesi.

Cosa devo dimostrare? Il programmatore di openSSL dice chiaramente di non comprare le CPU Intel architettura core 2 perché sono buggate dal punto di vista della sicurezza fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2). Dato che adesso è emerso un problema riconducibile al cambio di gestione della memoria avvenuto a suo tempo...basta fare uno più uno. Non ho dimostrazioni matematiche ne della validità ne della falsificazione della mia tesi.


Sì, ne abbiamo già parlato, e ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché.

Dimostrazione che né tu né altri avete minimamente scalfito, a parte cercare di aggirarla con giochetti di parole, perché dovreste riscrivere la matematica per piegarla alle vostre fantasie.

Ma quale dimostrazione? Non c'è nessuna dimostrazione in nessun senso ne che il codice open sia più sicuro ne il contrario. Io vedo solo incapacità di analizzare fatti.


Puoi anche chiedere a lui che smonti il mio teorema, allora: tanto è del campo e gli sarà facile, no?

In mancanza mi attengo a ciò che ho dimostrato.

Lui ha fatto la storia ed è grazie a persone come lui che l'umanità non ha ancora perso la dignità. La libertà di parola e di espressione sono i valore più grandi. Visto che fai tanto l'altezzoso provare a contattarlo su twitter e sentiamo se ti risponde.


Mi quoto:

"ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché."

Bravissimo.

Interessante questo commento che ho trovato in giro


Non si tratta di un bug software ma di un bug hardware per cui è necessario modificare come funziona il kernel Linux cosa che se fatta in fretta può provocare immensi danni a tutto Internet.

https://assets.vg247.it/current/2018/01/pasted-image-0-600x283.png

Questa l'immagine dell'uso della CPU del server EPIC:

https://www.vg247.it/2018/01/06/epic-mostra-limpatto-della-patch-spectre-meltdown-di-intel-sui-server-di-gioco-di-fortnite/

in cui si vede che dal momento della Patch per Intel del bug Meltdown i server hanno fatto un +30% di CPU utilization.

Interessante questo commento che ho trovato in giro

A me l'articolo sembra il solito banale complottismo da 4 soldi.. non ha veramente senso.

Senza voler difendere Google (che mi sta sulle scatole veramente) mi domando come si fa a paragonare un difetto o bug trovato in qualche prodotto Microsoft a questa roba qui che è la falla più grossa che si sia mai vista e che affligge tutti i processori, tutti, da 10 anni a questa parte.

Logico che Google non ha diffuso i dati mesi fa: e meno male che hanno avuto l'accortezza di non farlo. Ma ti rendi conto il casino che poteva succedere e i danni che si potevano arrecare senza che nessuna contromisura fosse pronta prima della resa pubblica della cosa ?

Boh, qua sempre più gli interessi personali e il fanatismo prevalgono veramente sul buon senso e la ragionevolezza.

Oltre a quanto già consigliato puoi consultare le dispense in Italiano del corso di Architetture II dell'Università di Torino.

Cerca Gunetti (che è un docente) + architettureII e troverai la pagina del sito con i pdf delle Slide che spiegano parecchia roba (in modo abbastanza comprensibile ma ovviamente un minimo di basi le richiedono) e con i rimandi a testi (almeno 3) da consultare per approfondimenti.

Ah non centrano nulla con questo bug, sono solo corsi su RISC, ILP (statica e dinamica), Branch Prediction Speculativa e non, MultiIssue, Cache, Architetture dei processori moderni con vari casi concreti esaminati, ...ecc


L'elaborazione out of order è sicuramente più onerosa ed infatti richiedendo anche più energia di solito i processori più parsimoniosi (vedi Atom, almeno quelli vecchi, ma anche molti Arm) sono InOrder.
Però i più veloci sono invece OoO.

Non è lavoro inutile perché tu fai del lavoro nella speranza che sia produttivo.
Le istruzioni speculative è vero che se il salto (o cambio di Program Counter) è predetto in modo errato sono lavoro inutile che potrebbe generare pure ulteriore lavoro per l'operazione di undo.
Ma è anche vero che tu speri di azzeccare spesso/con elevata incidenza (sempre è statisticamente impossibile) la predizione e quindi quando questo avviene ti sei solo portato avanti a fare lavoro che tanto dovevi comunque fare.

Ovvio che se i meccanismi di predizione sono poco efficienti allora alla fine vai più piano che senza questi sofismi.
E' lo stesso con la cache.
Un sistema dotato di cache ha tempi di accesso alla ram più lenti di un sistema senza cache (perché devi attraversare tutti i livelli di cache).
Però poi tu conti sul fatto che per pochi cache miss totale (con hit in ram) avrai molti cache hit conseguenti.
Certo che se fai solo cache miss allora un sistema senza cache andrebbe più veloce di te.

Ancora una volta ti ringrazio per la tua disponibilità e la chiarezza delle tue risposte, oltre che per le referenze informative che mi fornisci. Molti su questo forum dovrebbero prendere esempio da te.

I miei dubbi da "profano" erano appunto sul grado di probabilità di azzeccarla, necessariamente abbastanza elevato da compensare statisticamente le perdite dovute a tali processi.
Ma ripensandoci, anche se da un punto di vista puramente teorico non vedo algoritmi applicabili alla bisogna, da un punto di vista pratico ovvero di apprendimento di precedenti comportamenti la cosa ha il suo senso: se nella maggioranza più o meno elevata dei casi precedenti un ramo di codice si è comportato in un modo A anziche B andando a buon fine, posso assumere che anche in futuro posso puntare sulla predominanza di comportamenti A anzichè B per raggiungere lo scopo (in fin dei conti siamo in un'era di invadenza della famigerata A.I.).
PS: A ripensarci ulteriormente tutto il giro del fumo, cioè Branch (Speculative) Prediction, OutOFOrder Execution ... ed addirittura quello che chiamerei Parallele SubTasking, potrebbero essere molto facilitati se non proprio risolti da un'attenta programmazione (e non da un tanto al kilo come spesso avviene); il programmatore in fase di codifica sa assai spesso che probabilità ha un salto condizionato di essere eseguito, e basta che ponga la condizioe di salto relativa all'evento meno probabile (tipicamente, salto per condizione di errore, che si spera avvenga raramente); inoltre dovrebbe avere a disposizione un linguaggio che gli permetta di evidenziare le istruzioni ovvero le sequenze di esse parallelizzabili, attribuendo ciè un tag di (pari) priorità a ciascun ramo dove voglia sforzarsi di fare questa distinzione, cosa molto più facile per lui in sede di stesura codice che per la macchina che deve esaminare ciecamente tutte le dipendenze delle variabili. Ovviamente le cpu dovrebbero comportarsi in conseguenza di questi assunti.
Se poi nella babilonia dei linguaggi attuali si sono fatti i salti mortali per evitare l'uso dell'odiato GOTO, ovvero si è perso il controllo della traduzione dello stesso in codice oggetto, non so che farci, io per scrivere software di base ho quasi sempre lavorato in Assembler Main Frames

Ancora una volta ti ringrazio per la tua disponibilità e la chiarezza delle tue risposte, oltre che per le referenze informative che mi fornisci. Molti su questo forum dovrebbero prendere esempio da te.

I miei dubbi da "profano" erano appunto sul grado di probabilità di azzeccarla, necessariamente abbastanza elevato da compensare statisticamente le perdite dovute a tali precessi.
Ma ripensandoci, anche se da un punto di vista puramente teorico non vedo algoritmi applicabili alla bisogna, da un punto di vista pratico ovvero di apprendimento di precedenti comportamenti la cosa ha il suo senso: se nella maggioranza più o meno elevata dei casi precedenti un ramo di codice si è comportato in un modo A anziche B andando a buon fine, posso assumere che anche in futuro posso puntare sulla predominanza di comportamenti A anzichè B per raggiungere lo scopo (in fin dei conti siamo in un'era di invadenza della famigerata A.I.).

Io non so come facciano ma immagino che i cicli for e i while li becchino tutti e infatti tali cicli sono dei branch condizionati che saltano sempre ad eccezione di una volta quando il ciclare finisce. Cicli che ciclano una sola volta sono rari.

Il metodo più semplice è la predizione statica.
Ad esempio la tecnica elementare del "salto indietro sempre fatto" garantisce di azzeccarre tutti i cicli di un loop tranne quello di uscita e quindi un basso tasso di errore (su loop con molti cicli).

Ovviamente una tecnica che va bene in certi casi può non andare bene o essere pure pessima in altri.
E quindi si rendono necessarie tecniche più complesse (che diventano predizione dinamica quando tengono conto della storia passata dei salti cambiando nel tempo la predizione) se si vuole coprire con buona % di successo le varie casistiche.

Nelle slide citate trovate vari esempi o citazioni (branch prediction buffer a 1 bit ed a 2 bit, predittori correlati, schema a torneo), poi nelle cpu attuali di oggi si usano cose ancora molto più complesse.
Alcune probabilmente pure coperte da segreto industriale.

Per fare un paragone appropriato è come chiedere a Fiat di aggiornare il carburatore della Topolino..
17 anni in informatica corrispondono a 50 annni nelle auto..

Possibile, ma non è garantito :D

Come gravità si tratterebbe non di aggiornare un carburatore ma di sostituire un condotto pompa benzina non più adatto ai carburanti attuali, difettoso già da progetto, che ora rischia di riversare benzina sulla testata (calda) del motore.

Se ci fossero ancora decine di milioni di Topolino in circolazione, non so la FiCA, ma un'azienda seria lo farebbe.

A me l'articolo sembra il solito banale complottismo da 4 soldi.. non ha veramente senso.

Senza voler difendere Google (che mi sta sulle scatole veramente) mi domando come si fa a paragonare un difetto o bug trovato in qualche prodotto Microsoft a questa roba qui che è la falla più grossa che si sia mai vista e che affligge tutti i processori, tutti, da 10 anni a questa parte.

Logico che Google non ha diffuso i dati mesi fa: e meno male che hanno avuto l'accortezza di non farlo. Ma ti rendi conto il casino che poteva succedere e i danni che si potevano arrecare senza che nessuna contromisura fosse pronta prima della resa pubblica della cosa ?

Boh, qua sempre più gli interessi personali e il fanatismo prevalgono veramente sul buon senso e la ragionevolezza.

Affligge tutti i processori, tutti? E magari tutti in egual misura? Vero?

Comoda e molto onesta la nota divulgata da Intel, che tenta di equiparare in un'unico calderone chi ha le rogne chi ne è praticamente esente!

Affligge tutti i processori, tutti? E magari tutti in egual misura? Vero?

Comoda e molto onesta la nota divulgata da Intel, che tenta di equiparare in un'unico calderone chi ha le rogne chi ne è praticamente esente!


Ho detto questo ?

Ma l'hai letto quel che ho scritto e che cosa diceva il pezzo di articolo postato da Emiliano ? perché sembra di no.

Ho detto questo ?

Ma l'hai letto quel che ho scritto e che cosa diceva il pezzo di articolo postato da Emiliano ? perché sembra di no.

Troppo tardi per cercare quello cui ti riferisci, ho solo letto di sfuggita la tua frase e ho inteso che quel tutti ma proprio tutti fosse una difesa smaccata di Intel colta in fallo.
E' vero, ti riferivi a Google, mi pare; se ti ho frainteso perdonami, buona notte.

Troppo tardi per cercare quello cui ti riferisci, ho solo letto di sfuggita la tua frase e ho inteso che quel tutti ma proprio tutti fosse una difesa smaccata di Intel colta in fallo.
E' vero, ti riferivi a Google, mi pare; se ti ho frainteso perdonami, buona notte.

Sì, mi riferivo a Google.. infatti.

Tranquillo, capita di fraintendere... l'importante è chiarirsi!

Non sono parole mie, ma dello sviluppatore di openSSL che ne capisce molto più di chiunque in questo forum senza offesa fonte.


...forse, forse. D'altronde conosci l'interno Universo degli "utenti" di questo forum e puoi avere un giudizio così aprioristico.

Marco71.

https://assets.vg247.it/current/2018/01/pasted-image-0-600x283.png

Questa l'immagine dell'uso della CPU del server EPIC:

https://www.vg247.it/2018/01/06/epic-mostra-limpatto-della-patch-spectre-meltdown-di-intel-sui-server-di-gioco-di-fortnite/

in cui si vede che dal momento della Patch per Intel del bug Meltdown i server hanno fatto un +30% di CPU utilization.
Quindi fammi capire, c'era un virus NSA che rubava risorse al server sfruttando il bug ? :oink:

Ho un dubbio sulle percentuali.
Non sarà che prima tot utenti impegnavano la CPU al 25% ed ora invece deve lavorare al 60% per lo stesso numero di utenti, perchè ha ridotto la sua capacità di calcolo? quindi ha avuto una perdita di capacità della metà, passando dal 25% al 60%?

questa casistica è imparagonabile con qualunque altra di 'normale amminstrazione'...

Tutti i processori x86 degli ultimi 20 anni - dopo il primo Pentium e a esclusione degli Itanium e degli Atom pre-2003)
Cosa s'intende per "Atom pre-2003" ? Secondo Wikipedia i processori Intel Atom (https://it.wikipedia.org/wiki/Intel_Atom) sono comparsi sul mercato il 2 aprile 2008.

Quindi fammi capire, c'era un virus NSA che rubava risorse al server sfruttando il bug ? :oink:

Ho un dubbio sulle percentuali.
Non sarà che prima tot utenti impegnavano la CPU al 25% ed ora invece deve lavorare al 60% per lo stesso numero di utenti, perchè ha ridotto la sua capacità di calcolo? quindi ha avuto una perdita di capacità della metà, passando dal 25% al 60%?

io l'ho intesa così!

@nx-99
Sicuramente si tratta di una svista, intende gli atom precedenti fino alla serie 2xxx, che erano processori in order e quindi presumibilmente non soggetti al problema.

Quindi fammi capire, ...
Direi che la questione è molto più semplice: a causa della patch (per meltdown, quella che provoca dei cali prestazionali), i processori dei server lavorano di più (oltre il doppio in questo caso) per ottenere gli stessi risultati di prima.
Evidentemente questo è uno dei casi peggiori, dove la patch incide in modo molto pesante sulle prestazioni dei processori.

Come gravità si tratterebbe non di aggiornare un carburatore ma di sostituire un condotto pompa benzina non più adatto ai carburanti attuali, difettoso già da progetto, che ora rischia di riversare benzina sulla testata (calda) del motore.

Se ci fossero ancora decine di milioni di Topolino in circolazione, non so la FiCA, ma un'azienda seria lo farebbe.
non so onestamente se l'esempio che avete portato sia il più calzante però, per proseguirlo (si parla infatti di XP!), ricorda anche che "questa azienda seria di cui parli" è come se in precedenza avesse detto chiaramente che quel tipo di vettura non è più idonea a circolare (o, meglio, circolare circola però, essendo aumentato il traffico e l'attraversamento pedonale, questa continua a frenare in 100 mt mentre LE ALTRE -a parità di velocità- in 10).

Si sono ridotte le distanze tra le auto (ce ne sono di più in giro, aumentano i pedoni,...) insomma:
per la collettività è uguale o, se circoli, rappresenti un pericolo?

Quindi se si esegue il tool rilasciato da intel ed è tutto a posto si può stare abbastanza tranquilli? perché con la versione del tool nell'articolo di novembre dove gli ivybridge non erano coinvolti, la versione gui del tool mi dava tutto ok, mentre quella da console mi diceva: il sistema potrebbe essere vulnerabile. Ho scaricato l'ultima versione oggi ed eseguito il test (gui e console) e mi dice che il sistema non è vulnerabile, ma il comunicato di intel ha esteso rispetto a novembre, le generazione di processori intel core coinvolti: non ci sto capendo niente:mc: Io ho un Intel core i5 3470.

Ahia che dolor segnorita...

Userbenchmark pre e post patch. Il pre patch l'avevo fatto a settembre 2017.
http://i65.tinypic.com/15yer82.jpg

CPU passa da 61.9 a 52.6% del frattile

Passmark 9, fatto sempre a settembre pre patch
segna un passaggio da 6925.8 a 6830.5 e variazioni su diskmark e grafica dovute forse a nuovi driver.
Il test della CPU però è basato solo su calcoli con numeri primi, floating point, ecc...

questa casistica è imparagonabile con qualunque altra di 'normale amminstrazione'...

Dipende se per normale amministrazione consideri anche l'uso in ufficio di hypervisors per le VM.
Devo ancora vedere cosa succede a livello di Vmware, MS Hyper-V, Citrix XenServer.... da lato host ed all'interno delle VM :O

Quindi se si esegue il tool rilasciato da intel ed è tutto a posto si può stare abbastanza tranquilli? perché con la versione del tool nell'articolo di novembre dove gli ivybridge non erano coinvolti, la versione gui del tool mi dava tutto ok, mentre quella da console mi diceva: il sistema potrebbe essere vulnerabile. Ho scaricato l'ultima versione oggi ed eseguito il test (gui e console) e mi dice che il sistema non è vulnerabile, ma il comunicato di intel ha esteso rispetto a novembre, le generazione di processori intel core coinvolti: non ci sto capendo niente:mc: Io ho un Intel core i5 3470.

Il bug di novembre non centra nulla con Spectre e Meltdown

Dipende se per normale amministrazione consideri anche l'uso in ufficio di hypervisors per le VM.
Devo ancora vedere cosa succede a livello di Vmware, MS Hyper-V, Citrix XenServer.... da lato host ed all'interno delle VM :O

intendevo a livello di gravità del bug scoperto, che non si può paragonare al 'normale tran-tran' come i bug che regolarmente saltano fuori per ad esempio gli os

Va beh, la morale di tutto questo è che tra qualche mese inizieranno a circolare le nuove super CPU "Meltdown & Spectre free", i nuovi cellulari con processori aggiornati ecc... per la gioia dei produttori. Se il mercato stagna lo si fa ripartire... lo so, i tanti duri e puri si rifiuteranno di cedere al malcelato ricatto e lotteranno per i loro diritti... ma la maggior parte, la stragrande maggior parte, si accoderà. Questo è il danno maggiore che il singolo home user rischia.

Lista schede asus che riceveranno l'update il 9 10 gennaio
https://www.asus.com/News/V5urzYAT6myCC1o2

Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)?

Da quanto tempo picchi tua moglie?

Come è possibile che Intel non se ne sia accorta in 20 anni?

Nello stesso modo in cui nessun altro se n'è accorto in 20 anni?

Solo una persona priva di ragionamento può ignorargli, senza offesa.

Sempre senza offesa, ma una frase che esprime giudizi sul ragionamento altrui che contiene un errore da 3a elementare - che per di più che è proprio legato al ragionamento - non fa molto per metterti nella posizione di fare queste affermazioni.

Al di là di tutto, il succo del tuo "ragionamento" è:
- Si sapeva dell'esistenza di alcuni bug (che siano gli stessi di queste falle non l'hai dimostrato)
- Alcuni bug non sono stati corretti
-> Quindi sono stati messi apposta e/o sono stati sfruttati malevolmente.

Il che dal punto di vista logico è un argomento ovviamente fallace, ovvero privo proprio del ragionamento di cui parli sopra.

Cosa s'intende per "Atom pre-2003" ? Secondo Wikipedia i processori Intel Atom (https://it.wikipedia.org/wiki/Intel_Atom) sono comparsi sul mercato il 2 aprile 2008.

Significa che gli è scappato un 1 ed intendeva pre 2013 (mi pare che sia il 2012 in realtà l'anno dell'arrivo degli Atom con Out Of Order)

Il bug di novembre non centra nulla con Spectre e Meltdown
io mi riferivo a questo articolo (https://www.hwupgrade.it/articoli/cpu/5052/falle-di-sicurezza-nelle-cpu-intel-core-xeon-atom-e-celeron-milioni-di-pc-il-tool-di-verifica_index.html), quindi sono due cose slegate fra loro? ...andiamo bene.

io mi riferivo a questo articolo (https://www.hwupgrade.it/articoli/cpu/5052/falle-di-sicurezza-nelle-cpu-intel-core-xeon-atom-e-celeron-milioni-di-pc-il-tool-di-verifica_index.html), quindi sono due cose slegate fra loro? ...andiamo bene.

si sono bug distinti

io mi riferivo a questo articolo (https://www.hwupgrade.it/articoli/cpu/5052/falle-di-sicurezza-nelle-cpu-intel-core-xeon-atom-e-celeron-milioni-di-pc-il-tool-di-verifica_index.html), quindi sono due cose slegate fra loro? ...andiamo bene.

Si.
Sono due cose slegate

Vecchio bug è questo

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

Il nuovo

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

Nello stesso modo in cui nessun altro se n'è accorto in 20 anni?


Come gia postato Theo de Raadt ( openbsd) 10 anni evidenziava numerosi bugs nel core 2, prevedendo disastri a venire. Piu bravo a leggere nella "sfera di cristallo" fu, 2 anni piu tardi , Kris Kaspersky "CPU cache side-channel attacks" https://zadereyko.info/downloads/library/D2T1_Kris_Kaspersky_Remote_Code_Execution_Through_Intel_CPU_Bugs.pdf
Poi è chiaro senza macchina del tempo prevedere specificatamente Meltdown e Spectre è piuttosto difficile, diciamo però che i presupposti c'erano e gli "allarmi" lanciati, colpevolmente chi di dovere ha evidentemente minimizzato la cosa, forse per superficialità, forse per una questione di costi.

Mi sa che ho fatto confusione. C'è un if, un branch, nell'algoritmo ma non viene sfruttata la predizione. In effetti viene sfruttata l'esecuzione speculativa e l'out of order.
Sì, infatti. L'if (istruzione jz) è stato inserito soltanto per controllare il caso particolare del byte zero.

Sì, infatti. L'if (istruzione jz) è stato inserito soltanto per controllare il caso particolare del byte zero.

Esatto c'è un jump se un flag è zero, di solito collegato al valore di un registro, penso sia questa l'istruzione assembly jz che non conosco.

Mi fa piacere che tu abbia letto il link con l'esempio almeno non sono il solo a discutere su qualche cosa che gli autori dicono esemplificativo del bug Meltdown, anche se in realtà la situazione reale è molto più complessa (io so solo che in più ci sono gli indirizzi virtuali e che nella cache ci sono le pagine di memoria privilegiata e quelle utente in modo mischiato, penso ci sia un flag per distinguerle).

Mi fa ridere quando le persone pur di nascondere la realtà utilizzano la parola complottista.
Mi dispiace aver toccato la tua ex Intel, i dati e i fatto parlano chiaro fonte (http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu). Poi puoi continuare a dire ciò che vuoi. L'importante è credere alle favole.
Al solito metti link a caso quando si parlava d'altro. Nulla di non già visto da te. Passiamo avanti.
Certo, Intel ha cambiato la gestione della memoria MMU:

Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).

Non sono parole mie, ma dello sviluppatore di openSSL che ne capisce molto più di chiunque in questo forum senza offesa fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2).
E con questo abbiamo capito che di come funzioni Meltdown tu non hai capito un'acca, visto che NON è un problema di MMU, ma di esecuzione speculativa + OoO. E sì che, peraltro, era stata già discussa in diversi commenti, ma che evidentemente o non hai letto o non hai capito (propendo più per la seconda, ovviamente).

Ciò precisato, quoto Marco71:
...forse, forse. D'altronde conosci l'interno Universo degli "utenti" di questo forum e puoi avere un giudizio così aprioristico.
Se tu, Erotavlas, sei una nullità, visto che non solo non hai competenze in materia ma difetti anche di logica (come ti è stato fatto notare anche da altri), non vuol dire che altri utenti qui siano nella tua stessa situazione.

Tu non sai cosa fanno e quali capacità abbiano, per cui astieniti dal fare paragoni che lasciano il tempo che trovano, tirati fuori esclusivamente per sviare la discussione, visto che non sei in grado di sostenerla in nessun altro modo.

Infine, se pensi che Intel abbia cambiato qualcosa appositamente per favorire bug del genere, beh, l'onere della prova è tutto tuo: DIMOSTRALO portando FATTI, e non vuote chiacchiere.
Certo che sono cose diverse, il risultato ottenuto è lo stesso un trojan nella CPU.
Stai ancora cercando malamente di rigirare la frittata. Hai accomunato due cose che non c'entrano nulla, e adesso gli metti il cappellino del trojan per tirartene fuori.

Ritenta con qualcun altro, non con me che so tenere le fila di una discussione e so esattamente cosa avevi detto prima.
Si e no. Solo alcune architetture ARM e i problemi sono risolvibili senza cambiare CPU diversamente da Intel. Anche tu non hai letto con dettaglio fonte (http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu).
Ancora lo stesso link di prima, riciclato per l'occasione. Ma forse non ti è chiaro (e non sarebbe l'unica cosa) che i workaround esistenti consentono anche ai processori Intel di continuare a essere utilizzati senza cambiarli.
Cosa devo dimostrare? Il programmatore di openSSL dice chiaramente di non comprare le CPU Intel architettura core 2 perché sono buggate dal punto di vista della sicurezza fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2). Dato che adesso è emerso un problema riconducibile al cambio di gestione della memoria avvenuto a suo tempo...basta fare uno più uno. Non ho dimostrazioni matematiche ne della validità ne della falsificazione della mia tesi.
La falsificazione della tua tesi è banale, perché al solito hai preso un link a caso senza nemmeno verificare se fosse applicabile ai casi oggetto della discussione. Come già detto, NON è un problema di MMU. Che poi tu non lo capisca e continui a sostenere il contrario, non mi meraviglia di certo.

Nel famoso dibattito fra Berlusconi e Prodi, quest'ultimo fece una battuta sul primo, asserendo che fosse come un ubriaco che barcollando cercava di aggrapparsi a qualche lampione per rimanere in piedi.

Sostanzialmente è quello che fai tu, che t'infili in una discussione solo perché parla di sicurezza (tema a te molto caro) e, non capendo una benemerita mazza della specifica problematica, comincia a google a destra e a manca cercando malamente pezze d'appoggio a sostegno delle tesi fanta-complottistiche che spiattelli sistematicamente.
Ma quale dimostrazione? Non c'è nessuna dimostrazione in nessun senso ne che il codice open sia più sicuro ne il contrario. Io vedo solo incapacità di analizzare fatti.
Stai cercando ancora di aggrapparti a qualche lampione, tentando invano di cambiare la discussione.

No, una dimostrazione c'è, te l'ho fornita tempo fa, e confuta la tua "tesi" che continui ancora a propinare.

Eccola: l'essere "open" NON è condizione necessaria affinché un sistema possa essere "sicuro".
Lui ha fatto la storia ed è grazie a persone come lui che l'umanità non ha ancora perso la dignità. La libertà di parola e di espressione sono i valore più grandi.
Questa è un'altra fallacia logica a cui t'aggrappi spesso: il ricorso all'autorità.

Vedi, il fatto che Snowden sia un personaggio di una certa caratura NON vuol dire che tu lo possa tirare in ballo a ogni dove per portare acqua al tuo mulino.

Il tuo mulino lo devi, invece, dotare di un robusto sistema di approvvigionamento idrico. Ossia di FATTI a sostegno delle tue tesi.
Visto che fai tanto l'altezzoso provare a contattarlo su twitter e sentiamo se ti risponde.
Altra fallacia logica. Ma sappiamo che in questo "campo" sei molto abile.

Ancora una volta no: NON sono io che devo dimostrare alcunché né andare a tirare la giacchetta a qualcuno.

Io la mia parte l'ho fatta e ho tirato fuori una dimostrazione che confuta la balla (vedi sopra) che proferisci da tempo immemore. Tanto basta.

Se non ti piace, beh, non posso farci niente. Non sono certo io che devo a elemosinare aiuto perché non ti soddisfa il fatto che qualcuno ti abbia contraddetto.

Se affermi che i sistemi debbano essere open per questioni di sicurezza, l'onere della prova rimane a TUO carico, e NON mio, che peraltro ho già dimostrato che non è così.

Poi per me puoi anche mettere assieme Snowden, de Raadt, Kaspersky, e qualunque altro illustre esperto di sicurezza: la mia dimostrazione rimarrà comunque in piedi.

Né tu né nessun altro esperto vi potete arrogare il diritto di piegare la matematica a vostro piacimento.
Bravissimo.
Grazie.

Cdmauro, ti prego, risparmiaci.

Ancora una volta ti ringrazio per la tua disponibilità e la chiarezza delle tue risposte, oltre che per le referenze informative che mi fornisci. Molti su questo forum dovrebbero prendere esempio da te.

I miei dubbi da "profano" erano appunto sul grado di probabilità di azzeccarla, necessariamente abbastanza elevato da compensare statisticamente le perdite dovute a tali processi.
I "profani" dovrebbero stare buoni e tranquilli, documentarsi, comprendere la problematica, e POI, se avessero qualcosa da dire, esprimere il proprio pensiero.

Quello che fai tu è, invece, prendere l'n-esima occasione per piantare qualche pugnalata alla tua odiata Intel, anche se non hai capito proprio nulla dell'argomento della discussione.

POI vieni messo con le spalle al muro e sputtanato pubblicamente per le frottole che hai raccontato, e quindi vieni a fare la parte della vittima "parlando a suocera affinché nuora intenda".

Questi giochetti retorici da due soldi puoi farli con chi non ti conosce: non con me che so benissimo cosa ti frulli per la testa, e so leggere anche fra le righe di ciò che scrivi.

La prossima volta, caro "profano", appendi la tastiera al muro finché non avrai competenze adeguate per affrontare un argomento, e i coltelli tienteli ben chiusi nel cassetto.
Ma ripensandoci, anche se da un punto di vista puramente teorico non vedo algoritmi applicabili alla bisogna, da un punto di vista pratico ovvero di apprendimento di precedenti comportamenti la cosa ha il suo senso: se nella maggioranza più o meno elevata dei casi precedenti un ramo di codice si è comportato in un modo A anziche B andando a buon fine, posso assumere che anche in futuro posso puntare sulla predominanza di comportamenti A anzichè B per raggiungere lo scopo (in fin dei conti siamo in un'era di invadenza della famigerata A.I.).
Ma va: chi l'avrebbe mai detto! Siamo alla fiera delle banalità (per chi mastica qualcosa di microarchitetture, ovviamente).

Comunque no: non serve tirare in ballo l'IA, visto che non è il caso. E' sufficiente un "normale", ben rodato, concetto di predizione.
PS: A ripensarci ulteriormente tutto il giro del fumo,
Non mi pare che sia fumo buono, a giudicare da quel che leggo.
cioè Branch (Speculative) Prediction, OutOFOrder Execution ... ed addirittura quello che chiamerei Parallele SubTasking,
E adesso arriviamo pure a coniare dei nuovi termini.

Quanto c'è da imparare ancora nella vita...
potrebbero essere molto facilitati se non proprio risolti da un'attenta programmazione
Ed ecco che parte un'altra coltellata: chi l'avrebbe mai detto.

Ma soprattutto è chiaro che ci troviamo di fronte al genio delle microarchitetture. Uno che, se messo nel banco di prova, "ovviamente" tirerebbe fuori processori senza il minimo bug.

Intel, AMD (sì, perché c'è pure lei che commette errori: lo so che è difficile da accettare, ma è la realtà), ARM, ecc., potrebbero smettere di pubblicare errata dei loro processori, se a svilupparli ci fosse il qui presente rockroll.
(e non da un tanto al kilo come spesso avviene);
Che detto da uno che non ha capito una mazza di cosa sia e come funzioni la programmazione a oggetti, demonizzandola solo per questo motivo, direi che è tutto dire.
il programmatore in fase di codifica sa assai spesso che probabilità ha un salto condizionato di essere eseguito, e basta che ponga la condizioe di salto relativa all'evento meno probabile (tipicamente, salto per condizione di errore, che si spera avvenga raramente);
E qui diamo anche un colpo di spugna a tutti gli strumenti di profiling esistenti: il programmatore sa cosa succede, e quindi sono inutili. Pensa lui a risolvere tutto, a monte.

Ovviamente prendiamo rockroll per programmare qualunque cosa: Egli "sa". Tutto.
inoltre dovrebbe avere a disposizione un linguaggio che gli permetta di evidenziare le istruzioni ovvero le sequenze di esse parallelizzabili, attribuendo ciè un tag di (pari) priorità a ciascun ramo dove voglia sforzarsi di fare questa distinzione,
Cosa intendi per "parallelizzabili" in questo contesto? E di quali distinzione parli? Non è molto chiaro.

A primo acchito ciò che propini sembrerebbe qualcosa di simile ai VLIW e ai loro bundle, dove le istruzioni in esse contenute sono tutte "parallelizzabili".

Ma il paradigma VLIW ha fallito poiché non general-purpose, ed è rimasto confinato a specifici contesti in cui ha senso.

Itanium di Intel è un esempio di processore VLIW che ha fallito nel portare questo paradigma nella computazione di massa.
cosa molto più facile per lui in sede di stesura codice che per la macchina che deve esaminare ciecamente tutte le dipendenze delle variabili.
Il linguaggio di cui parli esiste già: si chiama assembly. E alcune architetture, come x86, hanno appositi prefissi di "branch hinting" per segnalare che quell'istruzione di salto condizionato è "strongly taken" o "strongly not-taken".

Ovviamente non consiglio né auguro a nessuno di lavorare in assembly.

Nemmeno io, che l'ho usato parecchio in passato, ho mai usato questi prefissi di branch hinting, perché sono una complicazione e non ne vale la pena (vedi qui sotto).
Ovviamente le cpu dovrebbero comportarsi in conseguenza di questi assunti.
Ma anche no: un branch predictor fa di gran lunga un lavoro migliore di questi meccanismi statici di predizione dei salti.

Quindi lasciamo al processore la libertà di ignorare questi hint, e fare di testa sua, che molto probabilmente "c'azzecca" meglio.
Se poi nella babilonia dei linguaggi attuali si sono fatti i salti mortali per evitare l'uso dell'odiato GOTO, ovvero si è perso il controllo della traduzione dello stesso in codice oggetto, non so che farci, io per scrivere software di base ho quasi sempre lavorato in Assembler Main Frames
Il controllo non si è affatto perso. I goto (jump) sono sempre lì, e sono abbastanza distinguibili analizzando il codice di alto livello scritto.

Ovviamente in assembly sono esplicitati. Ma, come dicevo, non consiglio a nessuno di programmare in assembly: troppo oneroso per ottenere dei risultati, ed enormi limitazioni di portabilità. Fatta eccezione per particolari casi che sono stati ben ponderati (anche con l'aiuto di tool di profiling), l'assembly è meglio lasciarlo perdere.

EDIT.
Affligge tutti i processori, tutti? E magari tutti in egual misura? Vero?

Comoda e molto onesta la nota divulgata da Intel, che tenta di equiparare in un'unico calderone chi ha le rogne chi ne è praticamente esente!
Ho detto questo ?

Ma l'hai letto quel che ho scritto e che cosa diceva il pezzo di articolo postato da Emiliano ? perché sembra di no.
Troppo tardi per cercare quello cui ti riferisci, ho solo letto di sfuggita la tua frase e ho inteso che quel tutti ma proprio tutti fosse una difesa smaccata di Intel colta in fallo.
E' vero, ti riferivi a Google, mi pare; se ti ho frainteso perdonami, buona notte.
Non è che hai frainteso: è che tu, per natura, devi attaccare Intel, per cui quando hai letto quella frase sei partito in quarta per crocifiggerla.

Ahia che dolor segnorita...

Userbenchmark pre e post patch. Il pre patch l'avevo fatto a settembre 2017.
http://i65.tinypic.com/15yer82.jpg

CPU passa da 61.9 a 52.6% del frattile

Passmark 9, fatto sempre a settembre pre patch
segna un passaggio da 6925.8 a 6830.5 e variazioni su diskmark e grafica dovute forse a nuovi driver.
Il test della CPU però è basato solo su calcoli con numeri primi, floating point, ecc...
Lascia perdere i test sintetici. Controlla le applicazioni reali, quelle che usi tutti i giorni.
Cdmauro, ti prego, risparmiaci.
Esiste l'ignore list: usa(te)la.

Come gia postato Theo de Raadt ( openbsd) 10 anni evidenziava numerosi bugs nel core 2, prevedendo disastri a venire. Piu bravo a leggere nella "sfera di cristallo" fu, 2 anni piu tardi , Kris Kaspersky "CPU cache side-channel attacks" https://zadereyko.info/downloads/library/D2T1_Kris_Kaspersky_Remote_Code_Execution_Through_Intel_CPU_Bugs.pdf
Poi è chiaro senza macchina del tempo prevedere specificatamente Meltdown e Spectre è piuttosto difficile, diciamo però che i presupposti c'erano e gli "allarmi" lanciati, colpevolmente chi di dovere ha evidentemente minimizzato la cosa, forse per superficialità, forse per una questione di costi.
Sia de Raadt sia Kaspersky parlano di cose ben diverse. Il nodo centrale delle loro tesi è che la presenza di bug/errata siano sfruttabili per scopi malevoli, ma Meltdown e Spectre fanno parte dei cosiddetti attacchi "side-channel" che da qualche anno a questa parte hanno introdotto tipologie completamente diverse di vulnerabilità.

Qui non siamo in presenza di bug veri e propri, sfruttabili per certi fini. No, i processori funzionano correttamente e fanno il loro lavoro. Tant'è che, nel caso di Meltdown (che è quello che ho studiato a fondo), l'istruzione che tenta di accedere alla memoria del kernel viene, giustamente, "bacchettata" (solleva un'eccezione). E quelle successive, che hanno fatto uso del valore letto, vengono correttamente "eliminate" (rollback). Tutto, insomma, funziona esattamente come da specifiche.

Il problema è un altro, di tutt'altra natura. E' che nonostante l'esecuzione sia stata "da manuale", la micro-architettura è rimasta "perturbata": si porta dietro qualche "segno" di ciò che è successo, celato al suo interno.

L'ISA, insomma, è a posto (assolutamente nulla fa riflettere ciò che era avvenuto dietro le quinte: né i registri della CPU sono stati alterati in alcun modo, né ci sono tracce in memoria). Ma la microarchitettura no: quella non è a posto, perché consente di scoprire qualcosa di ciò che è avvenuto, e questo qualcosa è, purtroppo, pericoloso.

Difatti nei titoli delle notizie si afferma che sia possibile leggere la memoria del kernel. Non è così: il tentativo è, infatti, fallito! Come ci si aspetterebbe, documentazione tecnica del funzionamento dell'ISA alla mano.

Ma per una via traversa (e molto cervellotica) è, però, possibile ugualmente ricostruire il contenuto di quella cella di memoria (lo evidenzio). Ai fini pratici la differenza è sottile, praticamente impercepibile, ma, invece, è profonda.

E' un po' come i tentativi dei fisici di voler ottenere informazioni sulla materia oscura per via indiretta, visto che normalmente è impossibile da "osservare", volendo fare un paragone completamente diverso.

Sia de Raadt sia Kaspersky parlano di cose ben diverse. Il nodo centrale delle loro tesi è che la presenza di bug/errata siano sfruttabili per scopi malevoli, ma Meltdown e Spectre fanno parte dei cosiddetti attacchi "side-channel" che da qualche anno a questa parte hanno introdotto tipologie completamente diverse di vulnerabilità.

Qui non siamo in presenza di bug veri e propri, sfruttabili per certi fini. No, i processori funzionano correttamente e fanno il loro lavoro. Tant'è che, nel caso di Meltdown (che è quello che ho studiato a fondo), l'istruzione che tenta di accedere alla memoria del kernel viene, giustamente, "bacchettata" (solleva un'eccezione). E quelle successive, che hanno fatto uso del valore letto, vengono correttamente "eliminate" (rollback). Tutto, insomma, funziona esattamente come da specifiche.

Il problema è un altro, di tutt'altra natura. E' che nonostante l'esecuzione sia stata "da manuale", la micro-architettura è rimasta "perturbata": si porta dietro qualche "segno" di ciò che è successo, celato al suo interno.

L'ISA, insomma, è a posto (assolutamente nulla fa riflettere ciò che era avvenuto dietro le quinte: né i registri della CPU sono stati alterati in alcun modo, né ci sono tracce in memoria). Ma la microarchitettura no: quella non è a posto, perché consente di scoprire qualcosa di ciò che è avvenuto, e questo qualcosa è, purtroppo, pericoloso.

Difatti nei titoli delle notizie si afferma che sia possibile leggere la memoria del kernel. Non è così: il tentativo è, infatti, fallito! Come ci si aspetterebbe, documentazione tecnica del funzionamento dell'ISA alla mano.

Ma per una via traversa (e molto cervellotica) è, però, possibile ugualmente ricostruire il contenuto di quella cella di memoria (lo evidenzio). Ai fini pratici la differenza è sottile, praticamente impercepibile, ma, invece, è profonda.

E' un po' come i tentativi dei fisici di voler ottenere informazioni sulla materia oscura per via indiretta, visto che normalmente è impossibile da "osservare", volendo fare un paragone completamente diverso.

Ti ringrazio per la spiegazione. Una curiosità, in questi giorni mi chiedevo se gli errata nei microprocessori ( Intel,AMD,Arm, poco importa) vengono fixati nel momento in cui qualcuno li rileva oppure il progetto rimane inalterato,la produzione continua e si cerca di porvi rimedio lato os o bios

Esatto c'è un jump se un flag è zero, di solito collegato al valore di un registro, penso sia questa l'istruzione assembly jz che non conosco.
Sì, è proprio quella.
Mi fa piacere che tu abbia letto il link con l'esempio
Un amico mi ha recuperato anche il PoC di Meltdown che fa uso delle TSX di Intel, per cui ho avuto modo di analizzare meglio il codice reale dell'exploit e approfondirne meglio il funzionamento.

Senza TSX è più complicato, ma comunque il concetto generale è esattamente lo stesso (anche se le macchine senza TSX sono ovviamente le più diffuse).
almeno non sono il solo a discutere su qualche cosa che gli autori dicono esemplificativo del bug Meltdown, anche se in realtà la situazione reale è molto più complessa (io so solo che in più ci sono gli indirizzi virtuali e che nella cache ci sono le pagine di memoria privilegiata e quelle utente in modo mischiato, penso ci sia un flag per distinguerle).
La situazione, infatti, è più complessa. E lo si capisce anche analizzando il PoC di cui parlavo prima.

Infatti Meltdown non è basato sugli indirizzi virtuali (se non per il fatto che dentro c'è mappata la memoria del kernel), e sembrerà assurdo ma nella cache non c'è mappata alcuna memoria del kernel che possa, quindi, essere letta. Non c'è niente di tutto questo.

Meltdown utilizza un geniale effetto collaterale delle specifiche micro-architetture, e... usa la cache di dati dell'utente (quindi non del kernel!) per i suoi scopi.

E' cervellotico. Geniale. Andrebbe studiato a fondo e meditato, perché ti apre letteralmente la mente su un mondo completamente nuovo, tutto da scoprire.

Chi è convinto che si tratti del solito bug sfruttabile, non ha la minima idea del concetto che c'è dietro.

E' per questo che invito chiunque a leggere il paper. Pesantissimo, da sbattere la testa sui muri, nulla da dire su questo, ma dopo uno si porta a casa un bagaglio culturale particolarmente arricchito.

Ti ringrazio per la spiegazione. Una curiosità, in questi giorni mi chiedevo se gli errata nei microprocessori ( Intel,AMD,Arm, poco importa) vengono fixati nel momento in cui qualcuno li rileva oppure il progetto rimane inalterato,la produzione continua e si cerca di porvi rimedio lato os o bios
Come affermato anche da de Raadt e Kaspersky, alcuni vengono corretti, e altri no purtroppo. Per alcuni non è possibile nemmeno un fix lato o.s. e/o BIOS (se un'istruzione può causare un hangout, ad esempio, l'unica è... non eseguirla. Ma non puoi farlo: se è lì, è perché è usata).

Ma c'è da dire che soltanto alcuni possono essere usati per fini malevoli, e ovviamente di questi mi aspetto la correzione. Di quelli che possono causare blocchi o malfunzionamenti in determinate (generalmente rare) condizioni, credo che possiamo metterci l'anima in pace se non verranno mai corretti.

Comunque la soluzione non è certo quella proposta da de Raadt. I processori moderni, di tutti i produttori, sono ormai macchine molto complicate, e saranno sempre pieni di bug. La soluzione non è, ovviamente, non comprarli, perché non ha senso.

Non ci resta che convivere con questi bug. Come conviviamo coi bug dei software, che sono diventati altrettanto complessi.

Signori miei, rispolveratela http://thumbs2.imagebam.com/39/e5/e5/f8e39b710951173.jpg (http://www.imagebam.com/image/f8e39b710951173) :ciapet:

Consiglio anch'io di leggere i paper dei due "bug". Io sto leggendo quello relativo a Meltdown e, boh... Veramente una cosa geniale, che, semplicemente, sfrutta un comportamento naturale e corretto della micro-architettura per tirar fuori informazioni altrimenti inaccessibili.

Come già ha detto cdimauro, non è nemmeno un bug, in realtà.

me lo riposti che me lo sono perso? Grazie Cesare.
Eccolo: https://meltdownattack.com/meltdown.pdf

Di nulla. :)

Lista schede asus che riceveranno l'update il 9 10 gennaio
https://www.asus.com/News/V5urzYAT6myCC1o2

Si sa se anche schede piu' vecchie lo riceveranno? Fino alla sesta generazione e' scandaloso. Dovrebbero patcharele tutte per un problema del genere.

Si sa se anche schede piu' vecchie lo riceveranno? Fino alla sesta generazione e' scandaloso. Dovrebbero patcharele tutte per un problema del genere.

non è un problema, dai un'occhiata a partire da qui:

https://www.hwupgrade.it/forum/showthread.php?p=45287669#post45287669

Il furbetto del quartierino.....Brian Krzanich amministratore delegato di Intel, avendo già capito che le azioni sarebbero andate giù..........ehhh sai com' è, gli seccava perdere soldi........poverino.....

E non si è dimesso ?

O non sapeva nulla di questa storia...........?

Che impieghi i soldi che ha preso dalla vendita, per risolvere il problema, invece!

Ma che poi, questi che hanno dato vita a Meltdown e Spectre, non hanno null' altro da fare nella vita...........

Un problema non da poco...........se penso a tutti i computer usati al mondo in ambito privato e pubblico, banche compre.................

Meltdown and Spectre

Bugs in modern computers leak passwords and sensitive data. (https://meltdownattack.com/)


Furbo o no con quello che ha fatto SE dovesse venir fuori che sapeva prima di vendere in America ti schiaffano dentro e buttano le chiavi, con conseguente sputtanamento della casa che rappresenta senza pensare che le conseguenze in borsa sarebbero catastrofiche.

Cmq ancora non si capisce bene di quanto sia il calo prestazionale ma da quello che leggo varia a seconda di cio' che si fa con il PC. Il fatto comunque da condannare e' che per 10 anni, come qualcuno ha scritto in precedenza, ci hanno lasciato con il buco :ciapet: aperto. :D :D

Anche NVIDIA è pronta a rilasciare una patch di sicurezza con i suoi driver: :eek:
http://nvidia.custhelp.com/app/answers/detail/a_id/4611

Anche NVIDIA è pronta a rilasciare una patch di sicurezza con i suoi driver: :eek:
http://nvidia.custhelp.com/app/answers/detail/a_id/4611

Pure NVidia........ AZZ quindi quale palcoscenico ci troviamo davati ?

No perche' mi chiedo CPU-DISCO-GPU ridimensionate con prestazioni, probabilmente, che potrebbero incidere sull'uso del PC in ambito professionale e videoludico.

Pensando al mondo QUADRO e mettendo che fosse vero un -21% per il rendering foto, meno prestazioni disco SSD, meno prestazioni Nvidia Quadro (ancora da misurare se mai ci fossero dei cali), qui si rischia che un PC che hai comprato l'anno scorso e' gia' dimezzato della sua potenza, per non parlare del mondo gaming se mai le prestazioni delle verdi fossero castrate. :mbe: :mbe:

Si.
Sono due cose slegate

Vecchio bug è questo

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr

Il nuovo

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

Ok ho riletto con attenzione i due articoli, quali soluzioni ci sono? ho provveduto a fare l'aggiornamento al SO e ad aggiornare il browser, per la mia mobo Asrock z77 pro4-m, non ci sono aggiornamenti bios (e non credo ci saranno). Si fa riferimento nel primo caso a Intel® ME, mentre per spectre e meltdown qui si parlava di aggiornare i microcode, che non so cosa siano. Sarebbe utile un breve decalogo delle cose da fare per chi non ha particolari conoscenze come me in ambito informatico. Grazie comunque.

Pure NVidia........ AZZ quindi quale palcoscenico ci troviamo davati ?

No perche' mi chiedo CPU-DISCO-GPU ridimensionate con prestazioni, probabilmente, che potrebbero incidere sull'uso del PC in ambito professionale e videoludico.

Pensando al mondo QUADRO e mettendo che fosse vero un -21% per il rendering foto, meno prestazioni disco SSD, meno prestazioni Nvidia Quadro (ancora da misurare se mai ci fossero dei cali), qui si rischia che un PC che hai comprato l'anno scorso e' gia' dimezzato della sua potenza, per non parlare del mondo gaming se mai le prestazioni delle verdi fossero castrate. :mbe: :mbe:

la maggioranza delle correzioni dovranno arrivare nei singoli software, che dovranno essere ricompilati per tenere in conto la possibilità di attacco tramite Spectre
si parlava di un 30% massimo(che non è affatto poco) dipendente dall'applicazione utilizzata, ma spero che si riferisca complessivamente all'intero sistema.

"In August 2017, Russian company Positive Technologies (Dmitry Sklyarov) published a method to disable the ME via an undocumented built-in mode. As Intel has confirmed[45] the ME contains a switch to enable government authorities such as the NSA to make the ME go into High-Assurance Platform (HAP) mode after boot. This mode disables all of ME's functions. It is authorized for use by government authorities only and is supposed to be available only in machines produced for them. Yet it turned out that most machines sold on the retail market can be tricked into activating the switch.[46][47]. Manipulation of the HAP bit was quickly incorporated into the me_cleaner project[48]." (https://en.wikipedia.org/wiki/Intel_Management_Engine#Security_vulnerabilities)

si parlava di un 30% massimo(che non è affatto poco) dipendente dall'applicazione utilizzata, ma spero che si riferisca complessivamente all'intero sistema.

Si, ma si parlava di questa percentuale riferita alla CPU/SSD/MEMORIA non penso ci si riferisse anche al mondo GPU ecco perche' sono perplesso. :mbe:
No perche' se anche questo mondo venisse coinvolto sarebbero caxxi amari un po' per tutti.

http://www.bitsandchips.it/cache/550x576-equal_images_2018_01_04_mdintelbug.jpg

Segnalo questa tabella proveniente dal sito:

http://www.bitsandchips.it/9-hardware/9365-intel-risponde-ufficialmente-sul-bug-che-affligge-le-proprie-cpu

in cui si riassume la situazione allo stato attuale. Ovviamente le varianti dei due attacchi non è detto siano limitate a quelle fin'ora trovate.

Ecco i NUOVI driver NVIDIA 390.65 che adottano misure di protezione contro le recenti falle di sicurezza scoperte:
http://www.nvidia.it/Download/index.aspx?lang=it
Fiondatevi a scaricarli! :ops:

Ecco i NUOVI driver NVIDIA 390.65 che adottano misure di protezione contro le recenti falle di sicurezza scoperte:
http://www.nvidia.it/Download/index.aspx?lang=it
Fiondatevi a scaricarli! :ops:

Sarebbe bello se qualcuno potesse fare dei test prime e dopo e vedere cosa realmente accade.

Si, ma si parlava di questa percentuale riferita alla CPU/SSD/MEMORIA non penso ci si riferisse anche al mondo GPU ecco perche' sono perplesso. :mbe:
No perche' se anche questo mondo venisse coinvolto sarebbero caxxi amari un po' per tutti.

No, le correzioni devono essere fatte a molti programmi e molti livelli, soprattutto pe il bug spectre ma la diminuzione di efficienza riguarda solo ed esclusivamente gli Intel e solo per il bug Meltdown e, all'atto pratico, solo per i server, quindi riguarda solo un consistente rallentamento di Internet. Lato pc casalingo o professionale il baco Meltdown non da quasi nessun problema ai pc Intel.

CUT

Sembra ci sia un certo impatto sia su alcuni giochi che su ssd.
Vedi qui:
https://www.youtube.com/watch?v=JbhKUjPRk5Q
Sarebbe utile avere un test sia PRE su sistema Intel+nVidia e un test POST con patch windows+bios+driver nvidia a questo punto, visto che anche le VGA nvidia sono coinvolte.

Sembra ci sia un certo impatto sia su alcuni giochi che su ssd.
Vedi qui:
https://www.youtube.com/watch?v=JbhKUjPRk5Q
Sarebbe utile avere un test sia PRE su sistema Intel+nVidia e un test POST con patch windows+bios+driver nvidia a questo punto, visto che anche le VGA nvidia sono coinvolte.

A parte i test sintetici e a parte un uso quasi esclusivo dell'SSD con un certo tipo di accesso (Alcuni hanno fatto un test dove accedevano casualmente all'SSD con dati da 1 byte) il risultato secondo molti test con programmi reali e molti videogiochi testati è quasi nullo.

Un test che simulava programmi reali aveva rilevato un calo delle performance del processore patchato del 4% e non ho visto di peggio.

il risultato secondo molti test con programmi reali e molti videogiochi testati è quasi nullo.

Molti di quei test iniziali erano fatti su Linux con OpenGL.. Ho visto dei test più recenti su Windows DirectX in cui la differenza nei frame minimi di alcuni giochi è di più del 50% in meno rispetto a prima dell'applicazione della patch.

Tipo da 80 a 39 fps o da 70 a 30... (non son numeri a caso: son numeri che ho letto in quei test).

Altro che calo trascurabile e marginale

Molti di quei test iniziali erano fatti su Linux con OpenGL.. Ho visto dei test più recenti su Windows DirectX in cui la differenza nei frame minimi di alcuni giochi è di più del 50% in meno rispetto a prima dell'applicazione della patch.

Tipo da 80 a 39 fps o da 70 a 30... (non son numeri a caso: son numeri che ho letto in quei test).

Altro che calo trascurabile e marginale

Allora non so, mi riprometto di seguire comunque i risultati di test reali.

[...]

Tipo da 80 a 39 fps o da 70 a 30... (non son numeri a caso: son numeri che ho letto in quei test).

Altro che calo trascurabile e marginale
Della serie: una volta gestito l'impatto legale (class action), tecnico e di immagine, finirà come al solito a produrre un altro boom di aggiornamenti hardware specie se finalmente arrivanno sui titoli dei giornali non solo gli impatti sulle prestazioni ma anche gli exploit reali di tali bugs per frodi e danni alle aziende. E così dopo i ramsonware ci pensa Intel & C a fabbricare una nuova ondata di aggiornamenti visto anche possibile non supporto di tutta la parte di architettura x86.
Quello che ancora non capisco è come sia possibile la noncuranza in quel senso, vista l'esistenza di XP (*) Embedded / POSReady ad uso banche & C :confused:
Significa anche eliminare segmenti come le varie Enterprise x86 di tutta la gamma Windows.
Sarà una buona scusa per anticipare la dismissione XP (*), 7, 8 .. e 10 X86 consolidando x64?

Secondo le dichiarazioni di Intel, non si tratta di difetto di progettazione, ma è così che le CPU dovevano funzionare. :eek:
In pratica sono state scardinate tutte le fondamenta dell'informatica dei calcolatori! :eekk:

Quindi, negli Intel se non ho capito male, il Pentium G3258 o comunque la famiglia G non ne è affetta?

Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
Intel® Atom™ Processor C Series
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor x3 Series
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series
Intel® Celeron® Processor N Series
Intel® Pentium® Processor J Series
Intel® Pentium® Processor N Series

Alla fine della fiera mi sembra che è un problema difficile da risolvere, non basta la solita patch del S.O, del browser o del bios pure i driver della scheda grafica, qui bisogna agire a livello strutturale sui processori per togliere il problema alla radice.

A questo punto mi sorge spontanea una domanda:
Da quanto tempo si sapeva di queste falle? perchè non si è cominciato a lavorare a livello hardware per rilasciare nuovi step di processori corretti?

I dubbi cominciano ad essere molti, i sospetti pure...

In pratica non si salva nessuna CPU Intel fra quelle in uso corrente

Della serie: una volta gestito l'impatto legale (class action), tecnico e di immagine, finirà come al solito a produrre un altro boom di aggiornamenti hardware specie se finalmente arrivanno sui titoli dei giornali non solo gli impatti sulle prestazioni ma anche gli exploit reali di tali bugs per frodi e danni alle aziende.
Gli aggiornamenti hardware ci sono da sempre: non è a causa di problematiche (non bug, in questo caso) come questi che ne arriveranno di nuovi.
E così dopo i ramsonware ci pensa Intel & C a fabbricare una nuova ondata di aggiornamenti visto anche possibile non supporto di tutta la parte di architettura x86.
Non mi è chiaro cosa vorresti intendere con la parte che ho sottolineato: potresti spiegarti meglio, cortesemente?
Quello che ancora non capisco è come sia possibile la noncuranza in quel senso, vista l'esistenza di XP (*) Embedded / POSReady ad uso banche & C :confused:
Significa anche eliminare segmenti come le varie Enterprise x86 di tutta la gamma Windows.
Sarà una buona scusa per anticipare la dismissione XP (*), 7, 8 .. e 10 X86 consolidando x64?
I prodotti che hai citato in genere non sono connessi a internet e/o non consentono di scaricare ed eseguire codice malevolo da remoto. Dunque non dovrebbero essere interessati.

In questi casi potrebbe anche girarci Windows 3.0: tanto la macchina non viene toccata.

Alla fine della fiera mi sembra che è un problema difficile da risolvere, non basta la solita patch del S.O, del browser o del bios pure i driver della scheda grafica, qui bisogna agire a livello strutturale sui processori per togliere il problema alla radice.

A questo punto mi sorge spontanea una domanda:
Da quanto tempo si sapeva di queste falle?
Le due vulnerabilità sono state pubblicate a giugno (Spectre) e luglio (Meltdown) dello scorso anno, se non ricordo male.
perchè non si è cominciato a lavorare a livello hardware per rilasciare nuovi step di processori corretti?
Probabilmente hanno iniziato a fare le verifiche del caso, per vedere se effettivamente queste vulnerabilità fossero dei rischi concreti.
I dubbi cominciano ad essere molti, i sospetti pure...
Di/su cosa?

Molti di quei test iniziali erano fatti su Linux con OpenGL.. Ho visto dei test più recenti su Windows DirectX in cui la differenza nei frame minimi di alcuni giochi è di più del 50% in meno rispetto a prima dell'applicazione della patch.

Tipo da 80 a 39 fps o da 70 a 30... (non son numeri a caso: son numeri che ho letto in quei test).

Altro che calo trascurabile e marginale

Mi piacerebbe sapere se INTEL e NVIDIA hanno per anni saputo e taciuto, ma chiaramente farei prima a chiede e ad avere una risposta sull'esistenza degli alieni. :stordita:

No perche' ora sembra che tutti stiano cadendo dal cielo ma per anni hanno cavalcato il "bug" barando sulle prestazioni dei propri prodotti a discapito di altri che magari si comportavano "alla dritta". :mbe:

Per quanto uno voglia poi cercare di minimizzare l'accaduto, leggo dei post che sinceramente mi lasciano perplesso, ma da utente finale sinceramente mi romperebbe le scatole sapere ora che l'HW acquistato a caro prezzo in realta' non valeva poi i soldi spesi.

Non mi è chiaro cosa vorresti intendere con la parte che ho sottolineato: potresti spiegarti meglio, cortesemente?
Molto probabilmente intende che, al momento, sebbene patchate, le versioni x86 di Windows (7 / 8.1 / 10) non danno alcuna protezione da Meltdown, solo in ambito x64 il Kernel VA Shadowing è supportato e attivo (parlando di CPU Intel, dato che per AMD non è necessario). Quindi chi sta utilizzando Win 7 / 8.1 / 10 in versione 32 bit, che abbia aggiornato o meno il sistema operativo non cambia nulla, se ha una CPU Intel è ancora vulnerabile a Meltdown.

No perche' ora sembra che tutti stiano cadendo dal cielo ma per anni hanno cavalcato il "bug" barando sulle prestazioni dei propri prodotti a discapito di altri che magari si comportavano "alla dritta". :mbe:

Per quanto uno voglia poi cercare di minimizzare l'accaduto, leggo dei post che sinceramente mi lasciano perplesso, ma da utente finale sinceramente mi romperebbe le scatole sapere ora che l'HW acquistato a caro prezzo in realta' non valeva poi i soldi spesi.

Mi spiace e senza offesa ma da quello che scrivi si capisce che non hai la minima idea di quello che sia successo: nessuno ha barato, e l'HW che hai comprato vale esattamente quanto l'hai pagato.

Mi spiace e senza offesa ma da quello che scrivi si capisce che non hai la minima idea di quello che sia successo: nessuno ha barato, e l'HW che hai comprato vale esattamente quanto l'hai pagato.

No no l'idea ce l'ho di quello che e' successo non ti preoccupare, ma pensi realmente che nessuno si sia accorto della falla per 10 anni ? Pensi realmente che nessuno abbia sfruttato la "falla" a proprio piacimento ?

Inoltre visto che i dati sono altalenanti, se ho un datacenter con 50 o + macchine virtualizzate se dovessi accorgermi che dopo gli aggiornamenti ho dei rallentamenti, ho esattamente quello che ho comprato 4 anni fa o meno ?
Penso proprio di NO.

Quello che ho sempre scritto nei vari post e' che il problema per l'Home PC puo' essere anche trascurabile, anche se ho letto di test con i nuovi driver NVIDA con FPS paurosamente crollati (da verificare sia ben chiaro), ma se l'impatto per le macchine virtualizzate fosse consistente sarebbero cavoli amari.

non si può escludere niente (per definizione), tuttavia anche dare per scontato...

Molto probabilmente intende che, al momento, sebbene patchate, le versioni x86 di Windows (7 / 8.1 / 10) non danno alcuna protezione da Meltdown, solo in ambito x64 il Kernel VA Shadowing è supportato e attivo (parlando di CPU Intel, dato che per AMD non è necessario). Quindi chi sta utilizzando Win 7 / 8.1 / 10 in versione 32 bit, che abbia aggiornato o meno il sistema operativo non cambia nulla, se ha una CPU Intel è ancora vulnerabile a Meltdown.

Corretto e sotto aggiungo...


Non mi è chiaro cosa vorresti intendere con la parte che ho sottolineato: potresti spiegarti meglio, cortesemente?

I prodotti che hai citato in genere non sono connessi a internet e/o non consentono di scaricare ed eseguire codice malevolo da remoto. Dunque non dovrebbero essere interessati.
.
Se la logica fosse quella del dispositivo non collegato e dunque sicuro allora nemmeno il supporto ransomware sarebbe stato necessario... eppure M$ ha deciso diversamente in quel contesto, intervendo anche con quelle versioni POS Ready ed Embedded, cosa che non ha fatto finora e non spiego il perchè.

La frase sottolineata, ammetto scritta in modo maldestro, voleva intendere il fatto che l'architettura x86 sembra essere la più trascurata in questo frangente di emergenza visto che un patch applicato può lasciar intendere la protezione specie in ambiente retail e dunque Win7 x86, Win 8/8.1 x86 e Win 10x, cosa che invece poi non avviene, stando appunto alle note di quei security bulletin (immagino che un IT admin invece si legga quella note con la sua Windows 10 LTSB x86 in azienda...).
In questo senso il duo Wintel potrebbe avere l'occasione per spingere ancor più verso un'unica architettura x64, o se non altro con questo comportamento omissivo indicare che la x86 è superata ed... abbandonata a se stessa.
Quindi forza e coraggio! Investite per forza in ambiente x64...altra ondata di acquisti.

segnalo (visto di volata) i test pre/post di phoronix usando clear linux e varie cpu
mi pare il più impattato sia apache

Microsoft ha comunicato che queste patch di sicurezza hanno un impatto negativo sulle prestazioni soprattutto sulle vecchie versioni di Windows, come Windows 7 :ciapet: e Windows 8, perchè su questi vecchi OS si verifica un maggior numero di transizioni fra lo spazio utente e kernel a causa del fatto che la gestione del rendering dei caratteri è implementata tutta a livello kernel. In Windows 10 invece è stata spostata in user space.
"Older versions of Windows have a larger performance impact because Windows 7 and Windows 8 have more user-kernel transitions because of legacy design decisions, such as all font rendering taking place in the kernel."
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems
=> Ecco un'altra ragione per passare a Windows 10 :D

Quindi hanno anche loro problemi di sicurezza. Mal comune, per l'appunto.

Mai detto il contrario ;) In misura diversa ma tutti ne sono affetti.

Non conosco aziende che affermino che i loro prodotti non siano sicuri. Se conosci qualcuna, gradirei un link a una pagina o documento, giusto per prenderne visione.

C'è chi lo afferma, c'è chi come Intel lo evidenzia ogni 5 secondi.

Lì dove? Non è chiaro cosa vorresti dire.

Nelle CPU Intel.

Senza alcuna prova (e almeno non emerso proprio nulla), questo è il classico complottismo spicciolo.

Ho già affermato che non ha alcun senso per un'azienda come Intel, che sforna 400 MILIONI (MI-LI-O-NI) l'anno, di tenersi nella pancia un problema di sicurezza di questa portata, senza porvi alcun rimedio, col rischio di potersi beccare denunce e class action.

Soltanto i complottisti, che non sono in grado di usare nemmeno un pallottoliere per fare dei conti della serva così banali, possono sostenere una tesi del genere.

Infatti ho usato il condizionale ;) Non ha senso però qualcosa è successo e penso che le denunce e class action arriveranno un pò per tutti, anche se nelle clausole di questa roba non era specificato niente ;)

Molto probabilmente intende che, al momento, sebbene patchate, le versioni x86 di Windows (7 / 8.1 / 10) non danno alcuna protezione da Meltdown, solo in ambito x64 il Kernel VA Shadowing è supportato e attivo (parlando di CPU Intel, dato che per AMD non è necessario). Quindi chi sta utilizzando Win 7 / 8.1 / 10 in versione 32 bit, che abbia aggiornato o meno il sistema operativo non cambia nulla, se ha una CPU Intel è ancora vulnerabile a Meltdown.
OK, adesso è chiaro e concordo.
Corretto e sotto aggiungo...

Se la logica fosse quella del dispositivo non collegato e dunque sicuro allora nemmeno il supporto ransomware sarebbe stato necessario... eppure M$ ha deciso diversamente in quel contesto, intervendo anche con quelle versioni POS Ready ed Embedded, cosa che non ha fatto finora e non spiego il perchè.
Nemmeno io, perché quei kiosk sono, di fatti, isolati. L'ISDN (perché mi pare che usino ancora questa) la usano solo per eseguire le transazioni.
La frase sottolineata, ammetto scritta in modo maldestro, voleva intendere il fatto che l'architettura x86 sembra essere la più trascurata in questo frangente di emergenza visto che un patch applicato può lasciar intendere la protezione specie in ambiente retail e dunque Win7 x86, Win 8/8.1 x86 e Win 10x, cosa che invece poi non avviene, stando appunto alle note di quei security bulletin (immagino che un IT admin invece si legga quella note con la sua Windows 10 LTSB x86 in azienda...).
In questo senso il duo Wintel potrebbe avere l'occasione per spingere ancor più verso un'unica architettura x64, o se non altro con questo comportamento omissivo indicare che la x86 è superata ed... abbandonata a se stessa.
Quindi forza e coraggio! Investite per forza in ambiente x64...altra ondata di acquisti.
Come detto sopra a ulukaii, concordo. E' una scelta incomprensibile, visto che la suddivisione/isolamento degli spazi d'indirizzamento dovrebbe essere fattibile anche coi s.o. a 32 bit (x86).

Non mi spiego perché abbandonare questi sistemi. A meno che non abbiano voluto dirottare tutte le risorse per fixare prima le versioni a 64 bit, eseguire il rollout, e seguirne eventuali problematiche. Questo perché le versioni a 64 bit sono le più diffuse e importanti (specialmente a livello server, dove non dovrebbero esistere più da anni versioni a 32 bit).

Come detto sopra a ulukaii, concordo. E' una scelta incomprensibile, visto che la suddivisione/isolamento degli spazi d'indirizzamento dovrebbe essere fattibile anche coi s.o. a 32 bit (x86).

Non mi spiego perché abbandonare questi sistemi. A meno che non abbiano voluto dirottare tutte le risorse per fixare prima le versioni a 64 bit, eseguire il rollout, e seguirne eventuali problematiche. Questo perché le versioni a 64 bit sono le più diffuse e importanti (specialmente a livello server, dove non dovrebbero esistere più da anni versioni a 32 bit).
Concordo è la mai stessa conclusione.

No no l'idea ce l'ho di quello che e' successo non ti preoccupare, ma pensi realmente che nessuno si sia accorto della falla per 10 anni ? Pensi realmente che nessuno abbia sfruttato la "falla" a proprio piacimento ?
Quando pensi di passare dal complottismo da due soldi a studiarti i paper e i fondamenti delle microarchitetture, così da darti da solo le (giuste, finalmente) risposte?
Inoltre visto che i dati sono altalenanti, se ho un datacenter con 50 o + macchine virtualizzate se dovessi accorgermi che dopo gli aggiornamenti ho dei rallentamenti, ho esattamente quello che ho comprato 4 anni fa o meno ?
Penso proprio di NO.
Considerato che la sfera di cristallo non ce l'ha nessuno (avvisami in caso contrario) e che le problematiche di sistemi complessi sono sostanzialmente inevitabili, sì: quello che hai comprato prima hai anche ora. Anche a fronte di questi problemi.
Quello che ho sempre scritto nei vari post e' che il problema per l'Home PC puo' essere anche trascurabile, anche se ho letto di test con i nuovi driver NVIDA con FPS paurosamente crollati (da verificare sia ben chiaro), ma se l'impatto per le macchine virtualizzate fosse consistente sarebbero cavoli amari.
Come hanno già ripetuto diversi esperti, INCLUSI i ricercatori che hanno trovato le falle, normalmente le perdite non sono consistenti, e nel caso in cui l siano dipendono dal CARICO DI LAVORO (specifico).
segnalo (visto di volata) i test pre/post di phoronix usando clear linux e varie cpu
mi pare il più impattato sia apache
E Redis, mi pare.
Mai detto il contrario ;) In misura diversa ma tutti ne sono affetti.
Beh, mi pare ovvio: Intel è la micro/architettura più diffusa in assoluto in ambito desktop e server.
C'è chi lo afferma, c'è chi come Intel lo evidenzia ogni 5 secondi.
Quindi lo affermano tutti. Grazie per avermelo confermato.
Nelle CPU Intel.
Non hai capito. DOVE sarebbero mancati i controlli?
Infatti ho usato il condizionale ;) Non ha senso però qualcosa è successo e penso che le denunce e class action arriveranno un pò per tutti, anche se nelle clausole di questa roba non era specificato niente ;)
Non ha senso quello che avevi detto (ma non soltanto tu). Poi che siano arrivate le class action nessuno lo nega, ma è tutto da vedere se tutte le loro istanze verranno accolte.

No no l'idea ce l'ho di quello che e' successo non ti preoccupare, ma pensi realmente che nessuno si sia accorto della falla per 10 anni ?

Quindi secondo te i ricercatori che hanno trovato questo problema - insieme magari a molta altra gente che ne era a conoscenza - erano lì ad aspettare che qualcuno desse loro il via, magari da una decina d'anni?

Pensi realmente che nessuno abbia sfruttato la "falla" a proprio piacimento ?

Ribadisco che si capisce che non hai idea di quello di cui stai parlando perché stai facendo tutto facile, e ti sembra facile perché parli col senno di poi. Il fatto che questo problema sia stato trovato dopo tutti questi anni dovrebbe farti capire quanto sia difficile trovare problemi del genere. La probabilità che qualcuno l'abbia sfruttato è pressoché nulla, perché un bug del genere non si trova ogni giorno: la scoperta di questi bug dice infatti molto più sulla sagacia dei ricercatori che sulla [mancanza di ] competenza di chi ha progettato il processore.


Inoltre visto che i dati sono altalenanti, se ho un datacenter con 50 o + macchine virtualizzate se dovessi accorgermi che dopo gli aggiornamenti ho dei rallentamenti, ho esattamente quello che ho comprato 4 anni fa o meno ?
Penso proprio di NO.

Certo che hai quello che hai comprato, ovvero un processore che è stato progettato in un certo modo; progettazione che da una parte permette quelle prestazioni (e mille altre cose) e dall'altra include - come tutti i processori - enne bug, e di cui nessuno ti potrà mai garantire che sia totalmente esente. Se pensi che esista sulla terra un processore o un software senza bug - eccetto "Hello World", e alcune volte anche su quello è meglio dubitare - sei un povero illuso.

La differenza è che prima nessuno sapeva dell'esistenza di questo bug, non che il processore non ce l'avesse. I processori sono esattamente quelli di prima, con le stesse identiche prestazioni, che guarda caso sono proprio frutto di espedienti come quelli sfruttati dall'attacco. È ovvio che il bug è insito nella progettazione, ma dall'altro lato è altrettanto ovvio che il bug di per sé non è deleterio (= non diminuisce le prestazioni), altrimenti non avresti potuto usufruire di quelle prestazioni fino ad oggi. Per questo non ha senso dire che non hai la stessa cosa che hai comprato 4 anni fa; e allo stesso modo non ha senso trattare un processore come se fosse software o un hardware qualsiasi che sia facile da aggiornare attraverso firmware: ormai quel bug fa parte dell'architettura e non si può far altro che considerarlo una sua debolezza.

Ora che il problema è stato scoperto puoi scegliere se proteggerti e di conseguenza subire un potenziale calo di prestazioni, esattamente così come, ad esempio, puoi decidere di proteggerti dai virus sul tuo PC con un antivirus, e subire di conseguenza un calo di prestazioni; oppure puoi evitare le patch e rischiare: diventa - purtroppo, chiaramente - un normale trade-off.

[..] A meno che non abbiano voluto dirottare tutte le risorse per fixare prima le versioni a 64 bit, eseguire il rollout, e seguirne eventuali problematiche. Questo perché le versioni a 64 bit sono le più diffuse e importanti (specialmente a livello server, dove non dovrebbero esistere più da anni versioni a 32 bit).

Oppure: proviamo a non fixarle; vediamo le proteste a livello mondiale e visto che dovremo poi produrre nuove CPU le facciamo solo con il supporto x64 e questo sia a livello hardware che di OS. Wintel contenta perchè risparmia risorse; magari avvocati dicono che si può fare con un costo accettabile e tutti gli altri ad aggiornare.

Mah, ho letto tanti complottismi su questa roba ma mi paiono tutti campati per aria.

MS ci campa con la retrocompatibilità, sono sicuro che entro un mese uscirà anche la patch per i 32 bit, anche se in effetti è strano che non abbiano patchato tutto assieme.

E' semplicemente una cosa gestita male, neanche io ci vedo particolari complotti contro sistemi x86.

Dotevevano gestire meglio il rilascio dei KB, dato che è ridicolo (e fuorviante) lasciare che i bugfix elencati nei KB fossero comuni a entrambe le versioni (x86/x64), invece che rilasciare KB a parte per gli x86 che indicassero appunto la sola presenza dei fix sicurezza non legati a meltdown/spectre del rollup mensile. Abbastanza parac#l0 infilarci solo una nota generale della FAQ, peraltro aggiornata più chiaramente su questo punto solo nei giorni successivi, quando altrove già se ne parlava (non ovunque, visto che ci sono portali "tecnologici" che ancora sembrano non saperne nulla).

Insomma, una confusione inutile che poteva essere gestita in modo migliore dando maggior chiarezza.

Per me serve per spingere le vendite dei nuovi pc. La gente si accontentava dei vecchi, ora che gli viene detto che sicuramente hanno problemi...

microcode intel per cpu anche di una decina d'anni: https://downloadcenter.intel.com/dow...?product=52214
al momento per linux.

spero di non aver capito male il tutto.

Per me serve per spingere le vendite dei nuovi pc. La gente si accontentava dei vecchi, ora che gli viene detto che sicuramente hanno problemi...
gombloddo

Per me serve per spingere le vendite dei nuovi pc. La gente si accontentava dei vecchi, ora che gli viene detto che sicuramente hanno problemi...
Come se quelli nuovi non ne avessero.

Si segnalano gravi problemi su Linux Ubuntu 16.04 dopo aver applicato le relative patch di sicurezza che correggono questa falla, la macchina non parte più: :ciapet:
https://ubuntuforums.org/showthread.php?t=2382157
(https://ubuntuforums.org/showthread.php?t=2382157)

Dove sono i benchmark prestazionali sulle CPU Ryzen con la patch applicata ?
Possibile nessun sito si degni di farli ?

Ma la patch/fix della cpu proprio, di intel, non c'è? E' Windows che la incorpora nei suoi aggioranamenti?

DOPPIO

Oppure: proviamo a non fixarle; vediamo le proteste a livello mondiale e visto che dovremo poi produrre nuove CPU le facciamo solo con il supporto x64 e questo sia a livello hardware che di OS. Wintel contenta perchè risparmia risorse; magari avvocati dicono che si può fare con un costo accettabile e tutti gli altri ad aggiornare.
Troppo complottismo. Le risorse delle multinazionali NON sono illimitate, e quindi mi pare ovvio che le abbiano indirizzato verso le soluzioni a 64 bit, che ormai da anni sono le più diffuse.

Una patch del genere la si può applicare anche con le versioni a 32 bit dei s.o., per cui penso ci sia solo da aspettare.

Poi che il futuro sia solo 64 bit mi pare ovvio, e la stessa Microsoft qualche mese fa ha annunciato che ci saranno solo quelle.
E' semplicemente una cosa gestita male, neanche io ci vedo particolari complotti contro sistemi x86.

Dotevevano gestire meglio il rilascio dei KB, dato che è ridicolo (e fuorviante) lasciare che i bugfix elencati nei KB fossero comuni a entrambe le versioni (x86/x64), invece che rilasciare KB a parte per gli x86 che indicassero appunto la sola presenza dei fix sicurezza non legati a meltdown/spectre del rollup mensile. Abbastanza parac#l0 infilarci solo una nota generale della FAQ, peraltro aggiornata più chiaramente su questo punto solo nei giorni successivi, quando altrove già se ne parlava (non ovunque, visto che ci sono portali "tecnologici" che ancora sembrano non saperne nulla).

Insomma, una confusione inutile che poteva essere gestita in modo migliore dando maggior chiarezza.
*

Ma la patch/fix della cpu proprio, di intel, non c'è? E' Windows che la incorpora nei suoi aggioranamenti?

:read: :help:

Ma la patch/fix della cpu proprio, di intel, non c'è? E' Windows che la incorpora nei suoi aggioranamenti?

:read: :help:
Per Meltdown la patch è lato OS per Win 7/8.1/10 (ma solo per x64 perché le versioni x86 non sono ancora state patchate).

Per le due varianti Spectre occorrono mitigazioni lato applicazioni (esempio browser e client vari) e aggiornamenti al microcode della CPU e solo in "pochi" lo riceveranno. Questi ultimi sono effettuati lato update del bios/uefi e possono essere fatti (alternativamente) lato OS con dei tools (qui (https://www.hwupgrade.it/forum/showpost.php?p=45287830&postcount=26804) ho indicato a grandi linee come avviene il tutto).

Intel si limita al momento a distribuire i microcode agli oem/produttori e questi distribuiscono i bios/uefi update a seconda di come hanno deciso di operare, esempio come ho indicato qui (https://www.hwupgrade.it/forum/showpost.php?p=45295258&postcount=26921) Asus aggiornerà solo 6,7,8 generazione, il resto ciccia. Anche i microcode stessi distribuiti da Intel non coprono tutte le CPU interessate, ma praticamente da Haswell in poi (con alcune eccezioni).

Quindi non passa tutto da update di Windows, ma occorre OS + microcode + applicazioni, i più fortunati riceveranno tutti e 3, i meno fortunati solo gli update delle applicazioni (esempio i già patchati Edge, Firefox, Chrome). In condizioni medie, diciamo OS + microcode via VMware (sempre che esista un microcode fixa-falla) + applicazioni.

Per Meltdown la patch è lato OS per Win 7/8.1/10 (ma solo per x64 perché le versioni x86 non sono ancora state patchate).

Per le due varianti Spectre occorrono mitigazioni lato applicazioni (esempio browser e client vari) e aggiornamenti al microcode della CPU e solo in "pochi" lo riceveranno. Questi ultimi sono effettuati lato update del bios/uefi e possono essere fatti (alternativamente) lato OS con dei tools (qui (https://www.hwupgrade.it/forum/showpost.php?p=45287830&postcount=26804) ho indicato a grandi linee come avviene il tutto).

Intel si limita al momento a distribuire i microcode agli oem/produttori e questi distribuiscono i bios/uefi update a seconda di come hanno deciso di operare, esempio come ho indicato qui (https://www.hwupgrade.it/forum/showpost.php?p=45295258&postcount=26921) Asus aggiornerà solo 6,7,8 generazione, il resto ciccia. Anche i microcode stessi distribuiti da Intel non coprono tutte le CPU interessate, ma praticamente da Haswell in poi (con alcune eccezioni).

Quindi non passa tutto da update di Windows, ma occorre OS + microcode + applicazioni, i più fortunati riceveranno tutti e 3, i meno fortunati solo gli update delle applicazioni (esempio i già patchati Edge, Firefox, Chrome). In condizioni medie, diciamo OS + microcode via VMware (sempre che esista un microcode fixa-falla) + applicazioni.

i microcode sono usciti 3 giorni fa

https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873

Per queste cpu

-- Updates upon 20171117 release --
IVT C0 (06-3e-04:ed) 428->42a
SKL-U/Y D0 (06-4e-03:c0) ba->c2
BDW-U/Y E/F (06-3d-04:c0) 25->28
HSW-ULT Cx/Dx (06-45-01:72) 20->21
Crystalwell Cx (06-46-01:32) 17->18
BDW-H E/G (06-47-01:22) 17->1b
HSX-EX E0 (06-3f-04:80) 0f->10
SKL-H/S R0 (06-5e-03:36) ba->c2
HSW Cx/Dx (06-3c-03:32) 22->23
HSX C0 (06-3f-02:6f) 3a->3b
BDX-DE V0/V1 (06-56-02:10) 0f->14
BDX-DE V2 (06-56-03:10) 700000d->7000011
KBL-U/Y H0 (06-8e-09:c0) 62->80
KBL Y0 / CFL D0 (06-8e-0a:c0) 70->80
KBL-H/S B0 (06-9e-09:2a) 5e->80
CFL U0 (06-9e-0a:22) 70->80
CFL B0 (06-9e-0b:02) 72->80
SKX H0 (06-55-04:b7) 2000035->200003c
GLK B0 (06-7a-01:01) 1e->22

un punto non del tutto indifferente (diciamo lato immagine, per non stare a fare il pelo) è se, come già discusso, releaseranno i microcode fixati per _tutte_ le cpu affette, e non solo quelle fino a 5 anni. imho il concetto di obsolescenza (non programmata, intendo effettiva) in questo caso peculiare si applica meno e appunto è una questione per lo più di immagine

releaseranno i microcode CUT

(scusa se mi permetto)
Dire "rilasceranno" faceva schifo?
Ste parole non si possono leggere.
:muro:

(scusa se mi permetto)
Dire "rilasceranno" faceva schifo?
Ste parole non si possono leggere.
:muro:

pazienza

i microcode sono usciti 3 giorni fa

https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873

Per queste cpu
Appunto, lo so, gli ho linkati anche in altri thread, la questione è sempre la medesima, come ho già detto in vari post.

1) i microcode fixati riguardano solo quelle CPU, per le altre del pack è riproposto l'ultimo microcode già disponibile (in genere datato 2013-2015 a seconda dell'età della CPU) e non è espressamente indicato che ulteriori ne verranno aggiunti (si spera)
2) c'è sempre da tenere a mente che aggiornare "in proprio" può portare a possibili problemi collaterali (BSoD, freeze, etc.)
3) nel caso di microcode applicato dall'OS (il metodo all'avvio di VMware) come ammesso dagli stessi autori, la patch al microcode potrebbe non essere caricata così in anticipo da essere sufficiente o utile:
Q: In the context of Meltdown/Spectre, it appears that running this driver does not update the microcode early enough for the OS to recognise the "Hardware Support for Branch Target Injection mitigation" as per Microsoft's article

A: Yes, I think that's right. Some folks inside VMware have tried to use this Fling recently for the same reason, and they also didn't see Windows recognizing the hardware support. It's not surprising -- presumably the Windows kernel is not expecting a driver to load microcode and thus probably detects and caches the presence or absence of CPUID features, etc., prior to driver loading.
Quindi si ritorna al mio commento all'origine.

Windows Server ha avuto l'ultima versione a 32bit con Windows Server 2008, abbandonata poi con Windows Server 2008 R2. Insommma sono tanti anni che non si installano più versioni a 32bit per obbligo e personalmente già le mie installazioni di Windows Server 2003, a suo tempo, erano tutte a 64bit. A meno di strani software legacy è davvero raro vedere una macchina 32bit in ambito server, e da un sacco di tempo.
Ecco, appunto.

L'unico problema è con roba tipo i Compute Stick con 2GB di memoria, che hanno Windows x86, e quindi sono affetti dai bug.

Negli altri casi, che dovrebbero essere la stragrande maggioranza, gli utenti desktop dovrebbero usare versioni a 64 bit dei loro s.o..

No non solo i compute stick anche molti tablet (o convertibili) Atom low cost degli ultimi 2 anni che montano windows 8.1 e/o Windows 10 usano SOLO la versione a 32bit.

Anzi il fw EUFI presente impedisce le installazioni a 64 bit di Windows (non ci riesci a fare partire l'installazione) anche se il processore supporta i 64b.
Riesci ad usare a 64b solo Linux ma non Windows.

Ma infatti avevo scritto "roba tipo". ;)

Beh non mi pare che i compute stick siano tipo i tablet :D o mini notebook per l'ottica dell'utente medio.
O almeno è abbastanza facile non comprendere in pieno cosa si copre.

Forse era meglio dire prodotti con cpu Intel anche recenti (meno di 2 o 3 anni) ma con meno di 4GB di ram installata non espandibile e che quindi escono (per motivi di efficienza, probabilmente più per risparmio spazio disco eMMC) con versioni a 32b dell'OS (nonostante cpu a 64b) e sui quali in alcuni casi ti hanno pure messo un lock per impedirti di installare tu versioni a 64b

Chiedo a cdimauro che ne sa molto, non poteva intel rilasciare l'aggiornamento del microcode come ha fatto per ill bug dell' IME precedente ?

Ad esempio la mia vecchia scheda H87 non ha necessitato l'aggiornamento de bios ed il microcode si è aggiornato.

Mantre questa volta sembra sia necessario un aggiornamento bios che forse non vedrò mai.

io cmq nel mio piccolo ho deciso che se verrà mantenuta la 'regola 5 anni' per la sistemazione dei microcode intel, bollerò (sempre nel mio piccolo) come malgestita la questione, anche e soprattutto a livello di immagine. non si può considerare alla stregua dei 'soliti' aggiornamenti (al netto di altre questioni, pur non esattamente marginali, ma a me interessa poter risolvere, punto)

tra l'altro usando un os che sarebbe anche 'agile' dato che gestisce la cosa a livello di bootloader, rosico anche alquanto a non poter tappare la cpu che sto usando. in prospettiva, d'accordo, ma pur tuttavia...

uff, ci sono 4 thread che parlano degli stessi argomenti (scrivo qua ma vale per gli altri tre)

Per Meltdown la patch è lato OS per Win 7/8.1/10 (ma solo per x64 perché le versioni x86 non sono ancora state patchate).

Per le due varianti Spectre occorrono mitigazioni lato applicazioni (esempio browser e client vari) e aggiornamenti al microcode della CPU e solo in "pochi" lo riceveranno. Questi ultimi sono effettuati lato update del bios/uefi e possono essere fatti (alternativamente) lato OS con dei tools (qui (https://www.hwupgrade.it/forum/showpost.php?p=45287830&postcount=26804) ho indicato a grandi linee come avviene il tutto).

Intel si limita al momento a distribuire i microcode agli oem/produttori e questi distribuiscono i bios/uefi update a seconda di come hanno deciso di operare, esempio come ho indicato qui (https://www.hwupgrade.it/forum/showpost.php?p=45295258&postcount=26921) Asus aggiornerà solo 6,7,8 generazione, il resto ciccia. Anche i microcode stessi distribuiti da Intel non coprono tutte le CPU interessate, ma praticamente da Haswell in poi (con alcune eccezioni).

Quindi non passa tutto da update di Windows, ma occorre OS + microcode + applicazioni, i più fortunati riceveranno tutti e 3, i meno fortunati solo gli update delle applicazioni (esempio i già patchati Edge, Firefox, Chrome). In condizioni medie, diciamo OS + microcode via VMware (sempre che esista un microcode fixa-falla) + applicazioni.
Grazie per risposta super esaustiva!

Sbaglio o per esempio asus, che ha rilasciato da pochissimi giorni vari nuovi bios, non ha incluso queste cose sistemate?

(scusa se mi permetto)
Dire "rilasceranno" faceva schifo?
Ste parole non si possono leggere.
:muro:

Mi è venuta una stretta alla pancia leggendolo. :stordita:

Grazie per risposta super esaustiva!

Sbaglio o per esempio asus, che ha rilasciato da pochissimi giorni vari nuovi bios, non ha incluso queste cose sistemate?
Beh, molti produttori stanno rilasciato bios aggiornati in questi giorni, ma per essere sicuro che riguardi Spectre, devi controllare che il changelog riporti "microcode update" o qualcosa di simile.

pazienza

Vorrai dire patiencia.

Beh, molti produttori stanno rilasciato bios aggiornati in questi giorni, ma per essere sicuro che riguardi Spectre, devi controllare che il changelog riporti "microcode update" o qualcosa di simile.
ah si... c'è scritto "Update CPU MicroCode" ... :D
Grazie mille ancora

io cmq nel mio piccolo ho deciso che se verrà mantenuta la 'regola 5 anni' per la sistemazione dei microcode intel, bollerò (sempre nel mio piccolo) come malgestita la questione, anche e soprattutto a livello di immagine. non si può considerare alla stregua dei 'soliti' aggiornamenti (al netto di altre questioni, pur non esattamente marginali, ma a me interessa poter risolvere, punto)

tra l'altro usando un os che sarebbe anche 'agile' dato che gestisce la cosa a livello di bootloader, rosico anche alquanto a non poter tappare la cpu che sto usando. in prospettiva, d'accordo, ma pur tuttavia...

uff, ci sono 4 thread che parlano degli stessi argomenti (scrivo qua ma vale per gli altri tre)
Da consumatore non posso che darti ragione...
Beh non mi pare che i compute stick siano tipo i tablet :D o mini notebook per l'ottica dell'utente medio.
O almeno è abbastanza facile non comprendere in pieno cosa si copre.

Forse era meglio dire prodotti con cpu Intel anche recenti (meno di 2 o 3 anni) ma con meno di 4GB di ram installata non espandibile e che quindi escono (per motivi di efficienza, probabilmente più per risparmio spazio disco eMMC) con versioni a 32b dell'OS (nonostante cpu a 64b) e sui quali in alcuni casi ti hanno pure messo un lock per impedirti di installare tu versioni a 64b
Beh, ma dopo l'avevo scritto: "con 2GB di memoria, che hanno Windows x86" :stordita:
Chiedo a cdimauro che ne sa molto, non poteva intel rilasciare l'aggiornamento del microcode come ha fatto per ill bug dell' IME precedente ?

Ad esempio la mia vecchia scheda H87 non ha necessitato l'aggiornamento de bios ed il microcode si è aggiornato.

Mantre questa volta sembra sia necessario un aggiornamento bios che forse non vedrò mai.
Il microcodice può essere aggiornato indipendentemente dal fatto che il produttore rilasci o meno un BIOS che lo integri.

Idem per il firmware del'IME.

Da quanto tempo picchi tua moglie?


Quanta intelligenza?! Da quanto tempo non accendi il cervello?!


Nello stesso modo in cui nessun altro se n'è accorto in 20 anni?

Infatti, intel lo sapeva almeno dal 2007 fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2). Il problema della speculative execution è legato a un bug della MMU fonte1 (https://blog.trendmicro.com/trendlabs-security-intelligence/speculation-risky-understanding-meltdown-spectre/), fonte2 (https://blog.trendmicro.com/trendlabs-security-intelligence/speculation-risky-understanding-meltdown-spectre/).

fonte3 (https://linuxaria.com/article/spectre-and-meltdown-explained)
At this point, you already know enough to understand Meltdown. This vulnerability is basically a bug in MMU logic, and is caused by skipping address checks during the speculative execution (rumors are, there’s the source code comment saying this was done “not to break optimizations”)

fonte4 (https://www.personal-view.com/talks/discussion/18660/meltdown-cpu-bug-for-dummies)
Processor have MMU, Memory Management Unit. It is responsible to check memory space for specific process. For example, prevent it to read/write outside his designated space.
Issue is that during speculative execution of code CPU can ignore MMU for a while, and despite it properly stops, results of the execution can be obtained indirectly by attacker.
All Intel CPUs after Pentium Pro era are affected. Why AMD is not affected? Speculative execution unit works differently and ask MMU sooner, hence stops. Why Intel made this? Because current approach makes CPUs faster and cooler.


Sempre senza offesa, ma una frase che esprime giudizi sul ragionamento altrui che contiene un errore da 3a elementare - che per di più che è proprio legato al ragionamento - non fa molto per metterti nella posizione di fare queste affermazioni.

Grazie per la correzione dell'errore. Ho sbagliato a non rileggere con sufficiente attenzione. Penso fosse chiaro cosa volessi scrivere.


Al di là di tutto, il succo del tuo "ragionamento" è:
- Si sapeva dell'esistenza di alcuni bug (che siano gli stessi di queste falle non l'hai dimostrato)
- Alcuni bug non sono stati corretti
-> Quindi sono stati messi apposta e/o sono stati sfruttati malevolmente.

Il che dal punto di vista logico è un argomento ovviamente fallace, ovvero privo proprio del ragionamento di cui parli sopra.

No, non ho dimostrato niente, ma nemmeno voi avete dimostrato il contrario.
Ti riporto la situazione ovvero i fatti.
Ci sono due bug Meltdown e Spectre dovuti alla speculative execution e a un bug della MMU.
Nel 2008 uno sviluppatore di openSSH dice di non comprare le CPU core 2 intel a causa di mega bug/falle alla MMU.
Affermo quanto detto in precedenza:

In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug. Non è complottismo, è la realtà dei fatti. Come negare PRISM, VAULT 7, ME e adesso questo? Solo una persona priva di ragionamento può ignorargli, senza offesa.

Infatti, intel lo sapeva almeno dal 2007 fonte (https://marc.info/?l=openbsd-misc&m=118296441702631&w=2).
Falso, e continui a riportare come un pappagallo lo stesso identico link che NON parla assolutamente dello stesso problema.

A questo punto è chiaro che non sai né come funzionino Meltdown e Spectre né hai la minima idea di cosa parli il link che hai riportato.
Il problema della speculative execution è legato a un bug della MMU fonte1 (https://blog.trendmicro.com/trendlabs-security-intelligence/speculation-risky-understanding-meltdown-spectre/), fonte2 (https://blog.trendmicro.com/trendlabs-security-intelligence/speculation-risky-understanding-meltdown-spectre/).
fonte1 e fonte2 sono esattamente lo stesso link.

Comunque, no: non è un problema di MMU.
fonte3 (https://linuxaria.com/article/spectre-and-meltdown-explained)
At this point, you already know enough to understand Meltdown. This vulnerability is basically a bug in MMU logic, and is caused by skipping address checks during the speculative execution (rumors are, there’s the source code comment saying this was done “not to break optimizations”)
Non è un bug, come già ampiamente discusso.

Inoltre riporti solite speculazioni ("rumor"), ma assolutamente nessuna prova a supporto.
fonte4 (https://www.personal-view.com/talks/discussion/18660/meltdown-cpu-bug-for-dummies)
Processor have MMU, Memory Management Unit. It is responsible to check memory space for specific process. For example, prevent it to read/write outside his designated space.
Issue is that during speculative execution of code CPU can ignore MMU for a while, and despite it properly stops, results of the execution can be obtained indirectly by attacker.
All Intel CPUs after Pentium Pro era are affected. Why AMD is not affected? Speculative execution unit works differently and ask MMU sooner, hence stops. Why Intel made this? Because current approach makes CPUs faster and cooler.
L'ultima frase è pura speculazione non suffragata da alcun fondamento.
No, non ho dimostrato niente, ma nemmeno voi avete dimostrato il contrario.
L'onere della prova è di chi afferma una tesi.

Gli altri si limitano ad aspettare la dimostrazione della tesi. Non devono, quindi, dimostrare alcuna negazione della tesi.
Ti riporto la situazione ovvero i fatti.
Ci sono due bug Meltdown e Spectre dovuti alla speculative execution e a un bug della MMU.
Non sono bug, come ampiamente discusso.

Adesso prendi il manuale dell'architettura x86/x64 dal sito di Intel o AMD (tanto è indifferente: le specifiche dell'ISA sono sempre le stesse), e facci vedere dov'è che starebbe il bug.

Ribadisco: l'onere della prova è TUO, perché TUA è la tesi che propagandi. :read:
Nel 2008 uno sviluppatore di openSSH dice di non comprare le CPU core 2 intel a causa di mega bug/falle alla MMU.
Che non hanno NULLA a che vedere con le due vulnerabilità che sono state trovate adesso.

La tua è la classica fallacia logica del Pendio scivoloso (https://www.linux.it/~della/fallacies/pendio-scivoloso.html).
Affermo quanto detto in precedenza:

In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug. Non è complottismo, è la realtà dei fatti. Come negare PRISM, VAULT 7, ME e adesso questo? Solo una persona priva di ragionamento può ignorargli, senza offesa.
E' puro complottismo perché non c'è nessun legame fra le due, e comunque le premesse sono false, come già detto (i bug del 2007 sono tutt'altra cosa).

Non è che se torni dopo un po' di tempo a spiattellare le tue solite bufale complottiste, queste diventino automaticamente a forza di ripeterle.

In ogni caso le tue balle le devi dimostrare: l'onere della prova è tutto TUO.

Ed è esilarante che proprio tu accusi gli altri di essere "privi di ragionamento", quando hai dimostrato enorme mancanza di logica...

Quanta intelligenza?! Da quanto tempo non accendi il cervello?!

Hm, stai ripetendo lo stesso errore logico che hai commesso nell'altro messaggio per farmi capire che l'hai capito, oppure perché non l'hai capito per niente?
Difficile dirlo: se fosse la prima ipotesi, non sarebbe un modo particolarmente furbo per farmelo capire, e se fosse la seconda, sarebbe ironico che tu mi rispondessi in questo modo, perché non solo si tratterebbe del solito attacco personale con insultino annesso che purtroppo non si schioda dal livello delle elementari, ma anche perché se avessi acceso il cervello*, avresti potuto pensarci un po' su prima di rispondere, e avresti capito quello che volevo farti capire.

(*) Visto? So farlo anch'io: non è particolarmente difficile, né dimostra particolare intelligenza.

Infatti, intel lo sapeva almeno dal 2007[...]

Non sto a ripetere quello che ti è stato detto e ridetto, aggiungo solo questo: ammettiamo pure che Intel lo sapesse e che le fonti che hai citato si riferiscano a quel problema. Se lo sapeva Intel, lo sapevano anche i ricercatori, e a questo punto ti rigiro la tua stessa domanda: com'è possibile che pur conoscendo questo problema da 10 anni, i ricercatori ci abbiano messo tutto questo tempo per pubblicare un exploit?


No, non ho dimostrato niente, ma nemmeno voi avete dimostrato il contrario.

Altro errore di logica, che qui sul forum si commette molto frequentemente. Ti invito a leggere questa (https://www.hwupgrade.it/forum/showpost.php?p=45299148&postcount=74) risposta che ho dato ad un altro utente poco tempo fa.

Affermo quanto detto in precedenza:
[...]Come negare PRISM, VAULT 7, ME e adesso questo? Solo una persona priva di ragionamento può ignorargli, senza offesa.

... e fai il copia&incolla dello stesso errore. Fantastico.

Hm, stai ripetendo lo stesso errore logico che hai commesso nell'altro messaggio per farmi capire che l'hai capito, oppure perché non l'hai capito per niente?
Difficile dirlo: se fosse la prima ipotesi, non sarebbe un modo particolarmente furbo per farmelo capire, e se fosse la seconda, sarebbe ironico che tu mi rispondessi in questo modo, perché non solo si tratterebbe del solito attacco personale con insultino annesso che purtroppo non si schioda dal livello delle elementari, ma anche perché se avessi acceso il cervello*, avresti potuto pensarci un po' su prima di rispondere, e avresti capito quello che volevo farti capire.

(*) Visto? So farlo anch'io: non è particolarmente difficile, né dimostra particolare intelligenza.

Le mie affermazioni non vogliono dimostrare la superiorità o inferiorità di nessuno. Il mio obiettivo era di evidenziare il fatto che la maggioranza delle persone non guarda mai il rovescio della medaglia, ma si ferma all'apparenza. (Detto in modo meno delicato, non accende il cervello).


Non sto a ripetere quello che ti è stato detto e ridetto, aggiungo solo questo: ammettiamo pure che Intel lo sapesse e che le fonti che hai citato si riferiscano a quel problema. Se lo sapeva Intel, lo sapevano anche i ricercatori, e a questo punto ti rigiro la tua stessa domanda: com'è possibile che pur conoscendo questo problema da 10 anni, i ricercatori ci abbiano messo tutto questo tempo per pubblicare un exploit?

E' la stessa domanda che mi sto facendo, l'unica risposta valida è che sia collegato alla sorveglianza di massa avviata nel 2007 e sfociata con Prism e Vault 7.
Vedi sotto.


Altro errore di logica, che qui sul forum si commette molto frequentemente. Ti invito a leggere questa (https://www.hwupgrade.it/forum/showpost.php?p=45299148&postcount=74) risposta che ho dato ad un altro utente poco tempo fa.

Grazie per la lettura, non stiamo parlando di un teorema matematico. Stiamo parlando di evidenza, non di dimostrazione. Al massimo potremmo parlare di un capo accusatorio in un processo penale.
La mia affermazione riporta sembra quindi è condizionale. Se avessi le prove per dimostrarlo in tribunale, non starei qui a perdere tempo in questo forum, ma andrei in altre sedi.
I fatti storici fanno pensare a quanto ho affermato purtroppo soprattutto dopo gli scandali Prism e Vault 7.
Considerando anche solo il primo sappiamo che vari attori del settore informatico (google, microsoft, yahoo, apple, etc.) erano a conoscenza del tutto molto prima della sua pubblicazione nel 2013.
Di conseguenza non mi meraviglierei se tra qualche anno venisse fuori la realtà dei fatti (la mia tesi) ovvero che i bug erano noti e voluti.


... e fai il copia&incolla dello stesso errore. Fantastico.
Certo, altrimenti non sarebbe stata una citazione. Se avessi voluto correggere avrei potuto farlo. Non eri tu l'esperto di logica?!

Al solito metti link a caso quando si parlava d'altro. Nulla di non già visto da te. Passiamo avanti.

Non sono link messi a caso, ma sei libero di pensare come vuoi.


E con questo abbiamo capito che di come funzioni Meltdown tu non hai capito un'acca, visto che NON è un problema di MMU, ma di esecuzione speculativa + OoO. E sì che, peraltro, era stata già discussa in diversi commenti, ma che evidentemente o non hai letto o non hai capito (propendo più per la seconda, ovviamente).


Falso, e continui a riportare come un pappagallo lo stesso identico link che NON parla assolutamente dello stesso problema.

A questo punto è chiaro che non sai né come funzionino Meltdown e Spectre né hai la minima idea di cosa parli il link che hai riportato.

fonte1 e fonte2 sono esattamente lo stesso link.

Comunque, no: non è un problema di MMU.

Non è un bug, come già ampiamente discusso.

Inoltre riporti solite speculazioni ("rumor"), ma assolutamente nessuna prova a supporto.

L'ultima frase è pura speculazione non suffragata da alcun fondamento.


A questo punto ci sono due possibilità: tutte le fonti da me riportate sono errate e gli autori dovrebbero cambiare mestiere oppure fossi in te mi farei qualche domanda su quanto hai capito tu...
Altre persone affermano cose diverse dalle tue e credo molto di più alla loro spiegazione che alle tue parole.


Ciò precisato, quoto Marco71:

Se tu, Erotavlas, sei una nullità, visto che non solo non hai competenze in materia ma difetti anche di logica (come ti è stato fatto notare anche da altri), non vuol dire che altri utenti qui siano nella tua stessa situazione.

Tu non sai cosa fanno e quali capacità abbiano, per cui astieniti dal fare paragoni che lasciano il tempo che trovano, tirati fuori esclusivamente per sviare la discussione, visto che non sei in grado di sostenerla in nessun altro modo.

Non pensavo che questo forum fosse frequentato da persone in grado di programmare openSSH e altro. Se mi sono sbagliato, non ho problemi ad ammetterlo. Mancano le prove a questo punto. Visto che ti piacciono le dimostrazioni :)


Infine, se pensi che Intel abbia cambiato qualcosa appositamente per favorire bug del genere, beh, l'onere della prova è tutto tuo: DIMOSTRALO portando FATTI, e non vuote chiacchiere.

I fatti fanno pensare a questo. Lo dice lo sviluppatore openSSH che nell'architettura intel core 2 ci sono dei bug nel MMU. Nel mio messaggio precedente ho scritto [B]sembra[\B] link (https://www.hwupgrade.it/forum/showpost.php?p=45284363&postcount=68). Basterebbe leggerlo.
Le altri fonti affermano che l'esecuzione speculativa insieme al fatto che la MMU consenta l'esecuzione senza controllare gli indirizzi, siano responsabili dei due bug Meltdown e Spectre.


Stai ancora cercando malamente di rigirare la frittata. Hai accomunato due cose che non c'entrano nulla, e adesso gli metti il cappellino del trojan per tirartene fuori.

Ritenta con qualcun altro, non con me che so tenere le fila di una discussione e so esattamente cosa avevi detto prima.

No, forse non ho specificato bene. Intendevo dire che il cambiamento del microcodice di una CPU può portare ad avere un trojan in modo simile al trojan intel ME.


Ancora lo stesso link di prima, riciclato per l'occasione. Ma forse non ti è chiaro (e non sarebbe l'unica cosa) che i workaround esistenti consentono anche ai processori Intel di continuare a essere utilizzati senza cambiarli.

Si a scapito delle prestazioni che in ambito server con I/O e chiamate al kernel frequenti si riducono anche al 30%. Io vorrei il 30% del costo indietro se avessi una CPU xeon. Intel sta cercando di mascherare questo aspetto con soluzioni alquanto ridicole fonte (https://www.tomshw.it/intel-contro-spectre-meltdown-linus-torvalds-all-attacco-90984).


La falsificazione della tua tesi è banale, perché al solito hai preso un link a caso senza nemmeno verificare se fosse applicabile ai casi oggetto della discussione. Come già detto, NON è un problema di MMU. Che poi tu non lo capisca e continui a sostenere il contrario, non mi meraviglia di certo.

Nel famoso dibattito fra Berlusconi e Prodi, quest'ultimo fece una battuta sul primo, asserendo che fosse come un ubriaco che barcollando cercava di aggrapparsi a qualche lampione per rimanere in piedi.

Sostanzialmente è quello che fai tu, che t'infili in una discussione solo perché parla di sicurezza (tema a te molto caro) e, non capendo una benemerita mazza della specifica problematica, comincia a google a destra e a manca cercando malamente pezze d'appoggio a sostegno delle tesi fanta-complottistiche che spiattelli sistematicamente.

Da quanto mi risulta dalle varie fonti che ti ho riportato sopra il problema della speculative execution è legato a un problema/bug della MMU che consente l'esecuzione senza controllare gli indirizzi.
Sono tutti incompetenti oppure hai sbagliato tu?


Questa è un'altra fallacia logica a cui t'aggrappi spesso: il ricorso all'autorità.

Vedi, il fatto che Snowden sia un personaggio di una certa caratura NON vuol dire che tu lo possa tirare in ballo a ogni dove per portare acqua al tuo mulino.

Il tuo mulino lo devi, invece, dotare di un robusto sistema di approvvigionamento idrico. Ossia di FATTI a sostegno delle tue tesi.

No, ma è stato Snowden a suggerire di utilizzare solo software open source proprio perché solo per questa tipologia è possibile verificare la presenza di bug di sicurezza voluti o non voluti. Lo stessa cosa per quanto riguarda hardware open quando Snowden via twitter ha chiesto ad AMD di aprire i sorgenti del firmware di Ryzen. Fatti (Prism, Vault7).
Lo riporto perché è l'esatto mio pensiero e ritengo che Snowden abbia molte più competenze della maggior parte delle persone in questo forum soprattutto rispetto a te, senza offesa.
Forse non ti piace che io citi persone più capaci di te che tu chiami autorità perché tu ti credi un'autorità. Forse sto cominciando a capire.


Non sono bug, come ampiamente discusso.

Adesso prendi il manuale dell'architettura x86/x64 dal sito di Intel o AMD (tanto è indifferente: le specifiche dell'ISA sono sempre le stesse), e facci vedere dov'è che starebbe il bug.


Quindi Meltdown e Spectre non sono bug?! Sono vulnerabilità ovvero un sottoinsieme dei bug. E' inutile parlare con te, se neghi pure questo.


Nel 2008 uno sviluppatore di openSSH dice di non comprare le CPU core 2 intel a causa di mega bug/falle alla MMU.
La tua è la classica fallacia logica del Pendio scivoloso (https://www.linux.it/~della/fallacies/pendio-scivoloso.html).

I link che ti ho riportato in precedenza che hai commentato dicono questo. Sono tutti sbagliati?


Non è che se torni dopo un po' di tempo a spiattellare le tue solite bufale complottiste, queste diventino automaticamente a forza di ripeterle.

In ogni caso le tue balle le devi dimostrare: l'onere della prova è tutto TUO.

Ed è esilarante che proprio tu accusi gli altri di essere "privi di ragionamento", quando hai dimostrato enorme mancanza di logica...

Sono passate tre settimane. La discussione è scaduta? I forum seri chiudono automaticamente le discussioni dopo 6 mesi di inattività. Non ho avuto modo di approfondire prima di oggi. Le mie affermazione sono supportate da fatti, quando sono idee personali ho sempre usato il condizionale. Vedi tu...


Altra fallacia logica. Ma sappiamo che in questo "campo" sei molto abile.

Ancora una volta no: NON sono io che devo dimostrare alcunché né andare a tirare la giacchetta a qualcuno.

Io la mia parte l'ho fatta e ho tirato fuori una dimostrazione che confuta la balla (vedi sopra) che proferisci da tempo immemore. Tanto basta.

Se non ti piace, beh, non posso farci niente. Non sono certo io che devo a elemosinare aiuto perché non ti soddisfa il fatto che qualcuno ti abbia contraddetto.

Se affermi che i sistemi debbano essere open per questioni di sicurezza, l'onere della prova rimane a TUO carico, e NON mio, che peraltro ho già dimostrato che non è così.

Poi per me puoi anche mettere assieme Snowden, de Raadt, Kaspersky, e qualunque altro illustre esperto di sicurezza: la mia dimostrazione rimarrà comunque in piedi.

Né tu né nessun altro esperto vi potete arrogare il diritto di piegare la matematica a vostro piacimento.

Stai cercando ancora di aggrapparti a qualche lampione, tentando invano di cambiare la discussione.

No, una dimostrazione c'è, te l'ho fornita tempo fa, e confuta la tua "tesi" che continui ancora a propinare.

Eccola: l'essere "open" NON è condizione necessaria affinché un sistema possa essere "sicuro".


Non ho detto una balla, ma la realtà dei fatti supporta questa tesi. Te lo spiego nuovamente. Un software per essere sicuro deve poter essere esaminato da esperti di sicurezza e in generale dal maggior numero possibile di persone competenti. A questo punto ci sono due possibilità. Se il codice è chiuso occorre che il proprietario del codice lo faccia esaminare a una o più società/persone terze esperte di sicurezza dato che non vuole pubblicarlo. Se il codice è aperto questo può essere esaminato dalle stesse società/persone terze esperte di sicurezza oltre che da altre N persone o società con le competenze necessarie.
Non esiste una dimostrazione matematica che dato un qualunque software aperto possa affermare se esso sia o meno sicuro. Esistono delle prove formali per alcuni tipi di software usati in settori critici (un esempio L4 microkernel).
Tuttavia l'evidenza pratica e dei fatti storici (Prism, Vault7, etc.) mostra che una condizione necessaria è che il software sia aperto. Se il software è chiuso ed è sospettato che ci siano backdoor o altro, come è possibile fidarsi anche se è stato revisionato da N società/persone esperti di sicurezza? Occorre fidarsi del proprietario del software oltre che delle N società/persone le quali sono in conflitto di interessi essendo pagate da esso.
Inoltre, se prendi un qualunque libro sulla sicurezza o più semplicemente wikipedia fonte (https://en.wikipedia.org/wiki/Open-source_software_security), la pratica della sicurezza attraverso l'oscuramento del funzionamento è fortemente sconsigliata security through obscurity.
Per concludere non si può affermare che qualunqe software o hardware aperto siano più sicuro dei rispettivi chiusi, tuttavia l'evidenza dei fatti storici, supportata dagli esperti di sicurezza più competenti al mondo, afferma che per avere trasparenza e sicurezza è necessario poter esaminare il sorgente.

E' la stessa domanda che mi sto facendo, l'unica risposta valida è che sia collegato alla sorveglianza di massa avviata nel 2007 e sfociata con Prism e Vault 7.


Be', l'altra ipotesi, che fra l'altro è il tipico "Rasoio di Occam", è che non ci fosse sotto niente.


Grazie per la lettura, non stiamo parlando di un teorema matematico. Stiamo parlando di evidenza, non di dimostrazione. Al massimo potremmo parlare di un capo accusatorio in un processo penale.

Ammesso e non concesso (la logica informale riguarda il discorso, non la matematica), si tratta - trasposta - della stessa cosa, ovvero il motivo per cui si presume l'innocenza e non la colpevolezza.


[...]
I fatti storici fanno pensare a quanto ho affermato purtroppo soprattutto dopo gli scandali Prism e Vault 7.
Considerando anche solo il primo sappiamo che vari attori del settore informatico (google, microsoft, yahoo, apple, etc.) erano a conoscenza del tutto molto prima della sua pubblicazione nel 2013.
Di conseguenza non mi meraviglierei se tra qualche anno venisse fuori la realtà dei fatti (la mia tesi) ovvero che i bug erano noti e voluti.

La differenza fondamentale è che qui sono coinvolti anche i ricercatori, e tenerli a bada per 10 anni è un compito ben arduo e uno sforzo colossale, non solo perché devi avere qualche modo per identificare repentinamente chi scopre la vulnerabilità, ma perché devi anche riuscire a convincerli (ovvero corromperli, oppure - ta da da - "sbarazzartene" :asd:) tutti - dal primo all'ultimo - a rinunciare a renderla nota al pubblico.


Certo, altrimenti non sarebbe stata una citazione. Se avessi voluto correggere avrei potuto farlo. Non eri tu l'esperto di logica?!

Quando si trascrive una citazione riportando volutamente un errore lo si identifica con "(sic) (https://it.wikipedia.org/wiki/Sic)", per cui no, se l'avevi capito non era "logico" che la riportassi così com'era senza correggere l'errore né evidenziarlo. Comunque questo non ha niente a che fare con la logica di cui si parlava sopra.

Le mie affermazioni non vogliono dimostrare la superiorità o inferiorità di nessuno. Il mio obiettivo era di evidenziare il fatto che la maggioranza delle persone non guarda mai il rovescio della medaglia, ma si ferma all'apparenza. (Detto in modo meno delicato, non accende il cervello).
In pratica stai descrivendo te stesso, visto che non ti prendi la briga di analizzare come si deve le vulnerabilità oggetto di questo thread per capire come funzionano, e quindi prendere atto che i link che avevi postato c'entrano come la pepata di cozze sulla cassata siciliana.
E' la stessa domanda che mi sto facendo, l'unica risposta valida è che sia collegato alla sorveglianza di massa avviata nel 2007 e sfociata con Prism e Vault 7.
Vedi sotto.
Per essere precisi, l'unica TUA risposta valida è quella del tipico complottista.
Grazie per la lettura, non stiamo parlando di un teorema matematico. Stiamo parlando di evidenza, non di dimostrazione. Al massimo potremmo parlare di un capo accusatorio in un processo penale.
La mia affermazione riporta sembra quindi è condizionale. Se avessi le prove per dimostrarlo in tribunale, non starei qui a perdere tempo in questo forum, ma andrei in altre sedi.
I fatti storici fanno pensare a quanto ho affermato purtroppo soprattutto dopo gli scandali Prism e Vault 7.
Ennesima fallacia logica: lo spaventapasseri (https://www.linux.it/~della/fallacies/spaventapasseri.html).

I due fatti NON sono collegati. A meno che, ovviamente, non lo DIMOSTRI. :read:
Considerando anche solo il primo sappiamo che vari attori del settore informatico (google, microsoft, yahoo, apple, etc.) erano a conoscenza del tutto molto prima della sua pubblicazione nel 2013.
E anche questo è del tutto falso, ma tant'è: lo ripeti in continuazione nella vana speranza che possa diventare vero, come tuo solito.
Di conseguenza non mi meraviglierei se tra qualche anno venisse fuori la realtà dei fatti (la mia tesi) ovvero che i bug erano noti e voluti.
E qui le "conclusioni" di stampo tipicamente travagliesco: ossia senza fondamenta. Basta mettere assieme alcuni fatti che sono soltanto legati a qualche argomento (la sicurezza nello specifico), per arrivare a postulare fantasie.

Sherlock Holmes ti fa un baffo.
Non sono link messi a caso, ma sei libero di pensare come vuoi.
I link sono i TUOI, come pure è TUA la balla spaziale che propini. Per cui sì: sono liberissimo di pensare quello che ho già scritto, a meno che non ti degno di DIMOSTRARE la correlazione fra le vulnerabilità in questione e i bug presenti negli errata pubblicati da Intel 11 anni fa.

L'onere della prova è e rimane tuo. Come logica, scienza, e giurisprudenza comandano. :read:
A questo punto ci sono due possibilità: tutte le fonti da me riportate sono errate e gli autori dovrebbero cambiare mestiere oppure fossi in te mi farei qualche domanda su quanto hai capito tu...
Altre persone affermano cose diverse dalle tue e credo molto di più alla loro spiegazione che alle tue parole.
E chi se ne frega. Io i paper me li sono letti (Meltdown nello specifico, me lo smazzato parola per parola. Si Spectre ho letto la sintesi degli autori dei paper). Dunque SO come funzionano. E so che gli errata di 10 anni non c'entrano assolutamente nulla.

Ma siccome il genio incompreso delle micro/architetture sei tu, che hai affermato quella TUA tesi, a me tocca semplicemente aspettare di vedere in che modo dagli errata di cui sopra si arriva all'implementazione delle due vulnerabilità.

Io son qui che aspetto, ma non farmi invecchiare come tuo solito, eh!
Non pensavo che questo forum fosse frequentato da persone in grado di programmare openSSH e altro. Se mi sono sbagliato, non ho problemi ad ammetterlo. Mancano le prove a questo punto. Visto che ti piacciono le dimostrazioni :)
Ancora la fallacia logica del Ricorso all'autorità (https://www.linux.it/~della/fallacies/ricorso-all-autorita.html). E sì che te l'avevo già passato il link, ma come tuo solito o non leggi o non capisci. D'altra parte hai ampiamente dimostrato che tu e la logica siete diametralmente opposti.

No, io non devo dimostrare proprio niente. Chi qui spara sentenze ad muzzum non capendo una benemerita mazza né delle falle di sicurezza in questione né dell'architettura dei processori, sei proprio tu, con le tesi che hai presentato andando a raccogliere il giro per il web.

Roba che rimarrà spazzatura finché non DIMOSTRERAI (visto che è TUO l'onere) la loro correlazione.
I fatti fanno pensare a questo. Lo dice lo sviluppatore openSSH che nell'architettura intel core 2 ci sono dei bug nel MMU. Nel mio messaggio precedente ho scritto [B]sembra[\B] link (https://www.hwupgrade.it/forum/showpost.php?p=45284363&postcount=68). Basterebbe leggerlo.
Già fatto, ed è una cosa che, invece, è chiaro che tu NON abbia fatto, visto che continui a sparare colossali balle in merito.

Il fatto che quel link parli di possibilità vulnerabilità dovute agli ERRATA di Intel (che è materiale PUBBLICO; ma su questo ne parlo dopo) NON implica, logica alla mano (non la tua, ovviamente, che di logica hai dimostrato di essere completamente a digiuno), che ciò sia a fondamento delle vulnerabilità in discussione.

Non è che ci voglia molto a capirlo, eh! Solo un minimo di logica elementare, banale.
Le altri fonti affermano che l'esecuzione speculativa insieme al fatto che la MMU consenta l'esecuzione senza controllare gli indirizzi, siano responsabili dei due bug Meltdown e Spectre.
Non so cos'abbia capito tu o questi soggetti, visto che l'MMU il suo lavoro lo fa. Infatti gli indirizzi vengono, eccome, controllati, ed è il motivo per cui viene generata l'eccezione BEN DESCRITTA NEL PAPER DI MELTDOWN.

Il problema è che tu, non avendo letto il paper, non hai la minima idea di come funzioni la vulnerabilità, e quindi continui a sparare colossali sciocchezze.

Te lo ripeto: l'MMU funziona perfettamente. COME DA SPECIFICHE. Infatti:

BLOCCA L'ESECUZIONE DELL'ISTRUZIONE CHE TENTA DI ACCEDERE ALLA MEMORIA DEL KERNEL


Vediamo se così evidenziato lo capisci, finalmente.

Ma ripeto: è tutto scritto nel paper. BASTEREBBE LEGGERLO, invece di andare a perdere tempo a zonzo, a caccia di improbabili link a supporto delle fantasie che ti sei costruito.
No, forse non ho specificato bene. Intendevo dire che il cambiamento del microcodice di una CPU può portare ad avere un trojan in modo simile al trojan intel ME.
Siamo nell'ambito delle mere ipotesi, quindi sì: è possibile. Il che NON implica che succeda. Sempre logica alla mano. :read:
Si a scapito delle prestazioni che in ambito server con I/O e chiamate al kernel frequenti si riducono anche al 30%. Io vorrei il 30% del costo indietro se avessi una CPU xeon.
Il 30% s'è raggiunto per lo più in benchmark sintetici. A seconda del carico di lavoro, la perdita di prestazione è variabile, arrivando (paradossalmente) persino a miglioramenti prestazionali in alcuni casi.

In ogni caso il processore funziona correttamente. Come da specifiche. Dunque Intel non ti deve restituire nulla (posto che quantificare il danno sarebbe cosa tutt'altro che semplice, data l'enorme variabilità, per l'appunto).
Intel sta cercando di mascherare questo aspetto con soluzioni alquanto ridicole fonte (https://www.tomshw.it/intel-contro-spectre-meltdown-linus-torvalds-all-attacco-90984).
Ho già letto, e faresti bene a leggere la mail dello sviluppatore che gli ha risposto (mi pare che l'abbia postata pabloski nel thread della notizia, qui su hwupgrade) che spiega perché Torvalds si sbaglia, visto che la patch serve per Skylake (che si comporta in maniera diversa rispetto ai predecessori).

Al solito, e come dovrebbe essere ma sfortunatamente non è visto che la gente si ferma ai titoli e alla superficialità di cui parlavi prima, bisognerebbe leggere e approfondire le questioni, prima di lanciarsi in facili giudizi.
Da quanto mi risulta dalle varie fonti che ti ho riportato sopra il problema della speculative execution è legato a un problema/bug della MMU che consente l'esecuzione senza controllare gli indirizzi.
Sono tutti incompetenti oppure hai sbagliato tu?
Se lo dicono tutti (ma questo lo stai sostenendo TU, e quindi mi permetto di nutrire dubbi), allora sì: sono tutti una massa di incompetenti.

Come ho scritto sopra, l'MMU funziona correttamente, e non ha nessun bug. Fonte: il paper di Meltdown. Quando te lo leggerai, SEMPRE CHE TU RIESCA A CAPIRLO (ovviamente), lo appurerai anche tu. Ma siccome so che preferisci perdere tempo a leggere balle spaziali anziché documentarti su come funziona la vulnerabilità, è chiaro che non lo farai.

Ma son problemi tuoi: sei e rimani un ignorante sull'argomento.
No, ma è stato Snowden a suggerire di utilizzare solo software open source proprio perché solo per questa tipologia è possibile verificare la presenza di bug di sicurezza voluti o non voluti. Lo stessa cosa per quanto riguarda hardware open quando Snowden via twitter ha chiesto ad AMD di aprire i sorgenti del firmware di Ryzen. Fatti (Prism, Vault7).
Lo riporto perché è l'esatto mio pensiero e ritengo che Snowden abbia molte più competenze della maggior parte delle persone in questo forum soprattutto rispetto a te, senza offesa.
Forse non ti piace che io citi persone più capaci di te che tu chiami autorità perché tu ti credi un'autorità. Forse sto cominciando a capire.
Ripeto: a te la logica fa un baffo, visto che continui a cadere nella fallacia logica del ricorso all'autorità (vedi sopra).

Il fatto che Snowden possa fare delle affermazioni (ma questo lo dici tu), non vuol dire proprio nulla. E il fatto che tu la pensi allo stesso modo, idem.

Ciò conta sono i FATTI. E i fatti mi cosano (cit.).
Quindi Meltdown e Spectre non sono bug?! Sono vulnerabilità ovvero un sottoinsieme dei bug. E' inutile parlare con te, se neghi pure questo.
Non sono bug, infatti. I processori, come già detto, funzionano perfettamente come da specifiche.

Se affermi che sono bug, allora non ti sarà difficile prendere il manuale di Intel o AMD e farmi vedere esattamente dov'è che le specifiche non sarebbero state rispettate.

Come ho già detto sopra, l'MMU funziona PERFETTAMENTE. Paper di Meltdown alla mano. :read:
I link che ti ho riportato in precedenza che hai commentato dicono questo. Sono tutti sbagliati?
Sì. Leggi il paper di Meltdown e fatti finalmente una cultura.
Sono passate tre settimane. La discussione è scaduta? I forum seri chiudono automaticamente le discussioni dopo 6 mesi di inattività.
Adesso snoccioli pure la definizione di forum "serio". No comment...
Non ho avuto modo di approfondire prima di oggi. Le mie affermazione sono supportate da fatti, quando sono idee personali ho sempre usato il condizionale. Vedi tu...
Tu non hai riportato nessun fatto finora. Solo colossali sciocchezze che cozzano violentemente contro il paper di Meltdown.

Quando DIMOSTRERAI le tue tesi ne riparleremo. Ma dubito che tu possa smontare il paper di cui sopra. In ogni caso son qui che aspetto, eh!
Non ho detto una balla, ma la realtà dei fatti supporta questa tesi. Te lo spiego nuovamente. Un software per essere sicuro deve poter essere esaminato da esperti di sicurezza e in generale dal maggior numero possibile di persone competenti.
Questa è una TUA assunzione arbitraria. Non è una definizione oggettiva e incontrovertibile, che peraltro ti avevo già chiesto e continui a non fornire.
A questo punto ci sono due possibilità. Se il codice è chiuso occorre che il proprietario del codice lo faccia esaminare a una o più società/persone terze esperte di sicurezza dato che non vuole pubblicarlo. Se il codice è aperto questo può essere esaminato dalle stesse società/persone terze esperte di sicurezza oltre che da altre N persone o società con le competenze necessarie.
Non esiste una dimostrazione matematica che dato un qualunque software aperto possa affermare se esso sia o meno sicuro.
Applica il Rasoio di Occam che ha citato giulop, perché l'affermazione vale per QUALUNQUE software, e non solo per quello open.

Ti ho già passato il link del problema dell'arresto, ma è chiaro che non hai letto nemmeno questo. Come al solito...
Esistono delle prove formali per alcuni tipi di software usati in settori critici (un esempio L4 microkernel).
Sì, ci sono. E costano una quantità abnorme di tempo per poter arrivare alla dimostrazione della correttezza formale.

Ecco perché lo si può fare soltanto con software semplici.
Tuttavia l'evidenza pratica e dei fatti storici (Prism, Vault7, etc.) mostra che una condizione necessaria è che il software sia aperto.
Questa è una TUA assunzione, soggettiva, e ampiamente opinabile.
Se il software è chiuso ed è sospettato che ci siano backdoor o altro, come è possibile fidarsi anche se è stato revisionato da N società/persone esperti di sicurezza? Occorre fidarsi del proprietario del software oltre che delle N società/persone le quali sono in conflitto di interessi essendo pagate da esso.
Il che NON implica che il software non sia "sicuro". Sempre logica alla mano.
Inoltre, se prendi un qualunque libro sulla sicurezza o più semplicemente wikipedia fonte (https://en.wikipedia.org/wiki/Open-source_software_security), la pratica della sicurezza attraverso l'oscuramento del funzionamento è fortemente sconsigliata security through obscurity.
Wikipedia non fa testo, e quello rimane, per l'appunto, un consiglio.

Un altro consiglio te lo do io: pubblica lo schema d'allarme di casa tua, della tua macchina, ecc. Così ci facciamo quattro risate dopo che si saranno portati via tutto grazie alla maggior sicurezza dell'essere open. :asd:
Per concludere non si può affermare che qualunqe software o hardware aperto siano più sicuro dei rispettivi chiusi,
Questo te l'ho DIMOSTRATO FORMALMENTE io. :read:
tuttavia l'evidenza dei fatti storici, supportata dagli esperti di sicurezza più competenti al mondo, afferma che per avere trasparenza e sicurezza è necessario poter esaminare il sorgente.
Affermazione arbitraria, soggettiva, e ampiamente opinabile, come già detto.

Adesso, e per tornare in tema, o dimostri che dagli errata pubblicati da Intel si arriva a Spectre e Meltdown, o le tue affermazioni sono le sparate tipiche di non capisce una mazza degli argomenti in questione, e pretende di pontificare prendendo link a caso sul web.

E per essere chiari: il tuo complottismo spicciolo cozza violentemente contro la tua stessa tesi. Infatti se fosse vero che le due vulnerabilità fossero state note fin dal 2007, ossia per quella mail di Teo*OpenBSD, allora vorrebbe dire che Intel non avrebbe nascosto proprio un bel niente. Visto che, esattamente al contrario, aveva pubblicato già all'epoca i bug negli errata di cui parla Teo. Ossia Intel aveva già reso pubblico il tutto.

Con buona pace dei complottisti che non hanno niente di meglio da fare nella vita.

P.S. Non ho tempo per rileggere e correggere eventuali errori. Tanto quel che conta è la sostanza, e quella c'è tutta. :read:

Se hai le patch, niente, a parte eventuali perdite prestazioni che variano a seconda del tipo di applicazioni che fai girare.

Senza patch puoi vivere lo stesso senza alcuna perdita prestazionale, ma con particolari accorgimenti (se hai un s.o. a 64 bit).

Ammiro la voglia che avete di scrivere papiri e papiri e papiri.
Risposte e contro risposte divise frase per frase.
Ovviamente cosi facendo si perde il senso di qualsiasi cosa.
Alla fine all'utente normale cosa succede con questi bug?

Devi ammettere però che cdimauro non evita le risposte, sempre risposto a tutto senza sviarsela anche con me :) E fa bene, sono arrivati pure i complottisti, qualcuno li deve pur contrastare! :asd:

Alla fine nulla se si sanno dove mettere le mani, i problemi arrivano quando ci sono gli utonti che non sanno usare un PC, come appunto successe per il Ransomware. ;)

Ammiro la voglia che avete di scrivere papiri e papiri e papiri.
Risposte e contro risposte divise frase per frase.
Ovviamente cosi facendo si perde il senso di qualsiasi cosa.

Se le leggi e poni attenzione no, il senso non lo si perde per questo motivo; lo si perde solo se quel che si dice non ha senso.

Immagino che il problema sia dovuto alla lunghezza e alla complessità degli argomenti trattati. D'altra parte non stiamo parlando di cose banali, e se l'argomento interessa un (bel, in questo caso) po' di impegno è richiesto.

Lato mio non posso farci nulla: quel che scrivo è già abbastanza divulgativo, e se il mio interlocutore scrive un papiro perché ama esercitare i polpastrelli (anziché studiare seriamente l'argomento), è ovvio che la risposta sarà anch'essa di una certa lunghezza. Ma non per questo posso tirarmi indietro e lasciar passare tutte le colossali sciocchezze che sono state scritte, e che purtroppo alimentano le solite leggende metropolitane.

Altrimenti si salta il messaggio, e amen: nessuno è obbligato a leggere roba indigesta.

@MaxFabio93: :flower: D'altra parte vale sempre quanto scritto da Umberto Eco: ormai internet ha sdoganato schiere di tuttologi che, del tutto privi di competenze, pretendono di parlare di qualunque cosa.

AMD è vulnerabile a Spectre solo su Linux o anche su Windows ?

AMD è vulnerabile a Spectre solo su Linux o anche su Windows ?
Perdonami ma... dopo tutto quello che è stato scritto poni ancora questa domanda?
Ti ho anche fornito un link al comunicato ufficiale di AMD che mi pare sia abbastanza chiaro a proposito.

Perdonami ma... dopo tutto quello che è stato scritto poni ancora questa domanda?
Ti ho anche fornito un link al comunicato ufficiale di AMD che mi pare sia abbastanza chiaro a proposito.
Non ho visto alcun link tuo.
Ne ho postati io ma in nessuno diceva che su Windows la vulnerabilità non esisteva

Non ho visto alcun link tuo.
Ne ho postati io ma in nessuno diceva che su Windows la vulnerabilità non esisteva

ho seguito l'intera vicenda e tutti gli n-mila post: con un po' di umiltà ammetti che ci fai :Prrr: