falla processori intel

[Sentenza]

La verità starà senz'altro nel mezzo.

Avevo letto rapidamente una nota riservata ieri sera, dove si ipotizzava un aumento sensibile dei context switch.

E i context switch.... saprai benissimo quanto pesano e che frequenza tendono ad avere specialmente su macchine high end

Non mi sono informato bene della cosa perché come al solito i giornalisti non sanno spiegare gli argomenti tecnico-scientifici (e anche perché in vacanza non ho molta voglia di interessarmi dell'argomento). In base a quello che ha detto Dirty Harry (che è lo stesso tipo di problema che ho supposto pure io), i context switch non dovrebbero entrare in gioco se si riesce a controllare la validità dell'indirizzo nello strato intermedio fra la chiamata a livello utente e la INT 80 (la funzione di wrapper che in Linux è offerta dalle glibc), in quanto se l'indirizzo riguarda la memoria riservata al kernel si evita proprio di chiamare il syscall handler. Però, ripeto, è probabile che mi sbagli sia perché il problema non è stato descritto completamente sia perché non ho dimestichezza con problematiche di livello kernel.

[i-alca]

Dici che mettere un controllo sull'indirizzo di memoria nelle funzioni che wrappano gli interrupt software provocherebbe un rallentamento eccessivo?

Premesso che non ho avuto tempo di seguire con attenzione il problema, ma dipende sempre dal software che stai mandando in esecuzione..... in generale si, che provoca un rallentamento, anche perché dovresti impedire a chiamate da software funzionante in user space di eseguire codice in kernel space..... il sistema più brutale sarebbe quello di trappare un interrupt, eseguire un context switch all'inizio della routine ed uno alla fine.... in processori specializzati potrebbe significare almeno un page fault, se non due....
dovrei ragionarci.... non ho tutti gli elementi ora..... tu hai degli elementi più specifici ?

[Sentenza]

Premesso che non ho avuto tempo di seguire con attenzione il problema, ma dipende sempre dal software che stai mandando in esecuzione..... in generale si, che provoca un rallentamento, anche perché dovresti impedire a chiamate da software funzionante in user space di eseguire codice in kernel space..... il sistema più brutale sarebbe quello di trappare un interrupt, eseguire un context switch all'inizio della routine ed uno alla fine.... in processori specializzati potrebbe significare almeno un page fault, se non due....
dovrei ragionarci.... non ho tutti gli elementi ora..... tu hai degli elementi più specifici ?

Il page fault è scatenato dallo MMU quando la pagina cercata è in swap e non in RAM, non è questo il problema. Da quanto ho capito (ripeto, non mi sono informato bene) la questione è che in seguito a page fault il kernel non scateni l'eccezione di segmentation fault ma permette di accedere alla pagina, questo perché per la CPU sotto esame quell'indirizzo di memoria è lecito. A parere mio il problema è che il processore permetta di scrivere in una porzione di RAM dedicata al kernel che dovrebbe essere di sola lettura; se così non fosse non avrei capito il problema, perché se la porzione di RAM in questione fosse anche di scrittura non vedo come il processore possa sapere se l'istruzione sia di livello kernel o utente. Quindi, sempre se ho intuito il problema, secondo me bisogna controllare l'indirizzo prima di arrivare alla chiamata di sistema, altrimenti diventa un'istruzione di basso livello come un'altra, non vedo come la CPU possa discriminare quale componente software ne abbia ordinato l'esecuzione. Per questo dicevo che si potrebbe mettere un controllo al wrapper del syscall handler: così facendo però il controllo verrebbe effettuato a ogni chiamata di sistema, rallentando la CPU. Dato però che si parla di un rallentamento anche del 30% ho dei dubbi che il problema sia questo, perché mi sembra difficile (eufemismo) che un controllo su un indirizzo possa pregiudicare la velocità di quest'ordine di grandezza.

[i-alca]

Non guardarlo dal punto di vista SW del SO, ma dal punto di vista HW. Io intendevo l'aumento del numero di cicli macchina relativo all'impatto del CPMD(*) su un processore moderno.


(*) Cache-related Preemption and Migration Delay

[Sentenza]

Non guardarlo dal punto di vista SW del SO, ma dal punto di vista HW. Io intendevo l'aumento del numero di cicli macchina relativo all'impatto del CPMD(*) su un processore moderno.


(*) Cache-related Preemption and Migration Delay

Non ho capito.

[i-alca]

Sintetizzando e semplificando, uno dei punti più vulnerabili è la data cache di tipo L1 o L2, dove non esiste differenza tra dati in kernel space e user space. Se è necessario creare una separazione tra le due modalità di esecuzione, il sistema più sicuro è creare un meccanismo di cache miss, che impedisca di avere contemporaneamente in data cache dati appartenenti allo user space ed al kernel space quando la program cache esegue istruzioni in user space. Questo porta ad un rallentamento, tanto maggiore quanto maggiore è la quantità di dati da sostituire in data cache, parzialmente compensata da una frequenza più elevata del processore.
Non ho idea se qualche virus o trojan recente sia riuscito a sfruttare questa criticità, ma da quello che ho letto, pur con la riservatezza che aleggia intorno al problema, sembra che la parte interessata sia proprio relativa al meccanismo di funzionamento delle cpu-cache.

[L'anticristo]

Così ad occhio direi che un incremento sensibile di cache miss possa avere un impatto molto modesto su dispositivi low end, mentre per applicazioni CPU & memory intensive potrebbe costituire un problema

[Sentenza]

Sintetizzando e semplificando, uno dei punti più vulnerabili è la data cache di tipo L1 o L2, dove non esiste differenza tra dati in kernel space e user space. Se è necessario creare una separazione tra le due modalità di esecuzione, il sistema più sicuro è creare un meccanismo di cache miss, che impedisca di avere contemporaneamente in data cache dati appartenenti allo user space ed al kernel space quando la program cache esegue istruzioni in user space. Questo porta ad un rallentamento, tanto maggiore quanto maggiore è la quantità di dati da sostituire in data cache, parzialmente compensata da una frequenza più elevata del processore.
Non ho idea se qualche virus o trojan recente sia riuscito a sfruttare questa criticità, ma da quello che ho letto, pur con la riservatezza che aleggia intorno al problema, sembra che la parte interessata sia proprio relativa al meccanismo di funzionamento delle cpu-cache.

Ah ok, allora il problema è un altro rispetto a quello che avevo pensato. Avevo pensato che la CPU scrivesse in un segmento di sola lettura, ma comunque in seguito a una chiamata di sistema, un'istruzione a livello kernel ma con un indirizzo passatogli da spazio utente.

[i-alca]

Così ad occhio direi che un incremento sensibile di cache miss possa avere un impatto molto modesto su dispositivi low end, mentre per applicazioni CPU & memory intensive potrebbe costituire un problema

Dipende dalle applicazioni.... utilizzando solamente programmi da ufficio il problema dovrebbe essere decisamente minore....
Dovranno essere ripensati anche i compilatori....

[22gradi]

Che storia assurda ma ancora di più è vedere il CEO che vende di corsa le propruie azioni priam che perdano valore.... forse le ha vendute per aiutare finanziariamente i prossimi lavoratori qualora dovessero essere licenziati per scarso lavoro?