Un bug hardware affligge la memoria virtuale delle CPU Intel

[Frix00]

Originariamente inviato da maxsin72

Viene da chiedersi perchè un singolo sviluppatore esterno a microsoft stia facendo quello che avrebbe dovuto già fare microsoft stessa

come in tutte le cose, chi fa da se'...

[aqua84]

ne hanno trovate altre...
https://arstechnica.com/gadgets/2018...ution-attacks/

[xxxyyy]

Originariamente inviato da Frix00

come in tutte le cose, chi fa da se'...

Non proprio tutte...

Non toccarti il BIOS, che si diventa

Io aspetto e spero.

[Saturn]

Il tool in pratica rende avviabile una chiavetta usb che poi dovrà essere impostata come primo disco di avvio, ed è compatibile sia con uefi che con il bios classico. Si caricherà il grub e poi il sistema partità normalmente. L'ho testata con un i7-980 ed ora la cpu risulta disporre degli ultimi microcode. I test spectre e meltdown (ho provato solo il tool InSpectre che verifica entrambi) vengono superati anche se, come ovvio, viene segnalata la potenziale perdita di performances. Per ora non ho riscontrato problemi, neanche nelle macchine virtualizzate in questo sistema. Al massimo basta rimuovere la chiavetta e tornare a fare il boot normalmente...ringrazio ancora Varg87 per la segnalazione!

[Varg87]

Questo sarebbe un buon metodo per non perdere prestazioni sempre e comunque.
Avvio il PC per giocare o per effettuare operazioni non rischiose? Inserisco la chiavetta.
Avvio il PC per homebanking o operazioni piú delicate? La tolgo.

[s-y]

Originariamente inviato da Varg87

Questo sarebbe un buon metodo per non perdere prestazioni sempre e comunque.
Avvio il PC per giocare o per effettuare operazioni non rischiose? Inserisco la chiavetta.
Avvio il PC per homebanking o operazioni piú delicate? La tolgo.

dovrebbe essere il contrario, se la chiavetta 'chiude'

[Varg87]

Sí, avevo qualche birra in corpo.

[s-y]

hehe, no doubt
fatto quella nota perchè tutto sommato 'sto thread è un pò una 'quick reference' ormai e poteva creare confusione in qualcuno (non certo pari a quella che si ottiene sbevazzando, e da veneto lo so bene )

[Saturn]

Originariamente inviato da Varg87

Sí, avevo qualche birra in corpo.

[maxsin72]

Ulteriori test di Phoronix con le ultime patch per spectre dai quali intel esce con le ossa rotte con riduzioni di prestazioni anche del 50% mentre per AMD le perdite di performance sono minime:





link https://www.phoronix.com/scan.php?pa...nux-420-bisect

E qui ulteriori approfondimenti https://www.phoronix.com/scan.php?pa...20-stibp&num=1

[s-y]

dipende dalla patch per le vulnerabilità degli smt (ht), non ricordo se disabilita del tutto o meno però
ci sono anche in corso discussioni su come implementarla, se attiva di default o no
certo che se l'impatto è questo e non mitigabile, ci sarà effettivamente da decidere il come

[maxsin72]

Originariamente inviato da s-y

dipende dalla patch per le vulnerabilità degli smt (ht), non ricordo se disabilita del tutto o meno però
ci sono anche in corso discussioni su come implementarla, se attiva di default o no
certo che se l'impatto è questo e non mitigabile, ci sarà effettivamente da decidere il come

Non mi è parso di trovare riferimenti ad smt disabilitato nei link che ho postato.

L'autore dei test spiega questo: Going into this testing my thinking was perhaps an Intel P-State CPU frequency scaling driver regression as something that has caused some performance regressions in the past or perhaps a scheduler change. There's also been a lot of Linux 4.20 changes in general that some unintentional regression must have slipped in there somewhere primarily hurting the Intel Linux performance... As a reminder, Linux 4.20 is the biggest kernel release of the year in terms of lines of code changed with more than 354 thousand lines of new code added at the end of October when this merge window opened.

As outlined in the Linux 4.20 feature overview, there are a lot of exciting changes with this kernel. But why is it slower? More work on f&#!*#(# Spectre!

Hoping it was just a simple performance regression in Linux 4.20 that could be quickly resolved, that was not the finding when bisecting these performance shortcomings... An intentional kernel change for better mitigating against Spectre is the latest reason why the Intel Linux performance is much slower. That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.

In pratica il principale indiziato sarebbe una mitigazione ovvero STIBP support for cross-hyperthread Spectre Variant Two mitigation che però non disabilità ne HT ne SMT ed evidentemente impatta in modo diverso su intel rispetto ad AMD https://www.phoronix.com/scan.php?pa...X-HT-STIBP-420

Comunque future ottimizzazioni potrebbero, se nel frattempo non salteranno fuori nuovi problemi, migliorare la situazione.

[tallines]

Originariamente inviato da maxsin72

Ulteriori test di Phoronix con le ultime patch per spectre dai quali intel esce con le ossa rotte con riduzioni di prestazioni anche del 50% mentre per AMD le perdite di performance sono minime:

Ottima notizia, avendo Amd come processore

[s-y]

Originariamente inviato da maxsin72

Comunque future ottimizzazioni potrebbero, se nel frattempo non salteranno fuori nuovi problemi, migliorare la situazione.

nel frattempo hanno deciso di 'sospendere' la patch stibp in questione (ad ora solo per le release stable) causa troppo impatto sulle prestazioni, mentre continueranno a lavorarci in parallelo

le prime release che inizieranno ad avere il codice 'ripulito' saranno rispettivamente la 4.19.4 e la 4.14.83

ricordo che per chi ha intel non smt (ht) il rallentamento di cui sopra non dovrebbe sussistere

[El Alquimista]

Originariamente inviato da s-y

ricordo che per chi ha intel non smt (ht) il rallentamento di cui sopra non dovrebbe sussistere

io l'HT l'ho disabilitato
non so se aiuta

[maxsin72]

Originariamente inviato da s-y

nel frattempo hanno deciso di 'sospendere' la patch stibp in questione (ad ora solo per le release stable) causa troppo impatto sulle prestazioni, mentre continueranno a lavorarci in parallelo

le prime release che inizieranno ad avere il codice 'ripulito' saranno rispettivamente la 4.19.4 e la 4.14.83

ricordo che per chi ha intel non smt (ht) il rallentamento di cui sopra non dovrebbe sussistere

Meno male, evidentemente si sono accorti che era da ottimizzare meglio.

[cdimauro]

Direi: è stato un tonfo notevole...

[s-y]

sempre riguardo alla patch stibp per linux di cui sopra
intanto le stable 'ripulite' sono state rilasciate circa una settimana fa, mentre sulla rc della 4.20 è in testing un approccio più selettivo sui processi dove applicare la costosa mitigazione, invece che 'a tappeto' come nella prima (e come si sa, troppo precipitosa) istanza, e pare che i bench 'generalisti' confermino un miglioramento

ps: io nel frattempo colto la palla che era da un pò che rimbalzava e migrato su amd. non ne sentivo estremo bisogno prestazionalmente (i5-2400) ma cmq erano 6 anni abbondanti che si faceva 24/7 o quasi...

[cdimauro]

Ottimo, e com'era prevedibile (hanno avuto troppo fretta).

Avresti per caso qualche link a test, cortesemente?

[s-y]

Originariamente inviato da cdimauro

Avresti per caso qualche link a test, cortesemente?

per ora no, almeno io, ho riferito quanto scritto al riguardo dal solito phoronix, che a breve cmq pubblicherà