Linus Torvalds interviene su STIBP e l’impatto delle performance nel kernel. Senza Flame.

Questo è stato l’anno dei bug nelle CPU, specialmente nelle x86. Ne abbiamo visto varianti su varianti, tanto che anche noi, talvolta, ne abbiamo perso qualcuno.

Ultima in ordine di tempo è stata L1TF, per cui abbiamo dato notizia delle prime patch. Le patch definitive sono attese nella versione del kernel 4.20, attualmente ancora in fase di sviluppo, insieme alle patch per STIBP, ennesima variante degli attacchi per ottenere informazioni da processi eseguiti in parallelo sulla stessa CPU.

Tutto bene? Mica tanto!

Dai primi test (eseguiti anche dagli amici di Phoronix) l’impatto sulle performance è veramente alto, per tanti tipi di applicazioni. Tanto alto da aver attirato l’attenzione di Linus: in un messaggio nella mailing list intitolato ‘STIBP by default.. Revert?’ (STIBP di dfefault… marcia indietro?) si lamenta dell’attivazione coatta della patch per tutti, quando i vantaggi sulla sicurezza sono in confronto solo marginali. Lo riportiamo integralmente:

This was marked for stable, and honestly, nowhere in the discussion did I see any mention of just *how* bad the performance impact of this was.

When performance goes down by 50% on some loads, people need to start asking themselves whether it was worth it. It’s apparently better to just disable SMT entirely, which is what security-conscious people do anyway.

So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?

I think we should use the same logic as for L1TF: we default to something that doesn’t kill performance. Warn once about it, and let the crazy people say “I’d rather take a 50% performance hit than worry about a theoretical issue”.

Linus

Questa patch è stata segnata come stabile, e onestamente, da nessuna parte nella discussione ho visto alcuna menzione *di quanto* fosse pesante l’impatto sulle performance.

Quando le performance sono inferiori del 50% per alcuni tipi di carico, la gente comincia a chiedersi se ne valga la pena. Ed apparentemente è meglio disabilitare solo l’SMT [l’Hyper-Threading di Intel, N.d.T.] interamente, cosa che la gente consapevole nella sicurezza fa comunque.

Quindi perché rendere quel rallentamento dato da STIBP di default quando chi se ne cura *davvero* [della sicurezza] già disattiva l’SMT?

Penso dovremmo usare la stessa logica usata per L1TF: scegliamo di default qualcosa che non uccida le performance. Avvisare per questo, e lasciare che le persone pazze dicano “preferisco avere una penalità del 50% nelle performance che preoccuparmi per un problema teorico”.

Linus

Notate nulla? Chi segue le uscite di Linus saprà che mancano tante cose: parolacce, epiteti alle persone, attacchi violenti all’intelligenza degli sviluppatori coinvolti. Insomma, tutto quel folklore che lo caratterizzava. E per il quale aveva deciso da solo di allontanarsi dallo sviluppo – e dalle mailing list -, proprio per migliorare il suo modo di porsi con gli altri. Perfino nelle altre risposte, e con chi difendeva l’attivazione di default, le parole rimangono di questo tono.

Che la cura abbia funzionato?

Leggi il contenuto originale su Mia mamma usa Linux!