Io non capisco di cosa ci si stupisca. Questo tipo di problemi è chiaro che salti fuori nel momento in cui fornisci una CPU che abbia stato nascosto CPU-wide che impatta sulle prestazioni (pipeline, cache, branch predictor, execution unit shareate tra core diversi) e metodi precisi per misurare le prestazioni. Il peccato originale sta lì, tutto il resto sono mitigazioni che cercano di mettere un tappo a una nave che è comunque by design piena di buchi.
Vuoi una CPU senza questi problemi? Comprati una MCU pensata per hard-realtime, in cui tutto è perfettamente deterministico e non c'è praticamente stato nascosto, ma poi non lamentarti che va tutto 20 volte più lento. Per quanto riguarda i miei casi d'uso, preferisco il tradeoff corrente - CPU con un sacco di birra ma che intrinsecamente hanno problemi di questo tipo.
L'altra cosa che mi dà sui nervi è che sembra che questi problemi siano disastrosi e bisogna metterci una patch al più presto ovunque; in realtà di questa roba frega molto poco al consumer medio; nel momento in cui il browser (che è dove davvero gira codice untrusted di ogni genere) è più o meno al sicuro (e per quello almeno per ora sembra bastare una buona dose di jitter aggiunto all'orologio), su tutto il resto più o meno chissene frega. Alla fine su una macchina consumer gira codice sostanzialmente tutto di un utente, e la divisione tra codice kernel e codice user è utile sostanzialmente come difesa rispetto a bug (non vuoi che un'applicazione bacata qualunque ti tiri giù il sistema), non tanto per protezione di chissà che di valore. Non fatemi pagare il 30% di performance per syscall di "scassare apposta lo stato del branch predictor e smappare completamente le pagine kernel" per problemi che non mi riguardano.
Per quanto riguarda VPS e in generale servizi cloud, "sucks to be you". Aggiustare una cosa del genere a basso livello e senza impattare le performance la vedo difficile, le cose ovvie che mi vengono in mente "ad alto livello" sono:
- "rompere" il TSC per tutti gli host, rendendo molto più complicato fare misure di timing precise, critiche per questo tipo di exploit;
- evitare in blocco di far condividere un core a processi/VM che non stanno nello stesso "security context"; se sullo stesso core hyperthreaded gira codice che sta già di suo nella stessa "gabbia" non c'è rischio di sicurezza;
- spostare in blocco la parte di crittografia in "scatole sicure" (siano essi set di istruzioni dedicati non-leaking dal punto di vista delle performance come AES-NI, o coprocessori dedicati, o core dedicati solo a quello su cui gira solo codice fidato), e sperare che nessuno si metta a mirare ad estrarre dati dal tuo codice specifico.
Rispondi quotando