SGAxe e CrossTalk, due nuovi attacchi alle CPU Intel: correttivi in arrivo

[CrapaDiLegno]

Chi afferma che le vulnerabilità ci sono perché implementare le varie strategie di sicurezza avrebbe reso le CPU meno veloci dimostra che non capisce nulla della materia.
Infatti i Phenom erano così veloci perché avevano il baco nella TBL. La patch SW li ha resi delle lumache inusabili in campo professionale ma Il phenom II che aveva le patch alla TBL in HW non era né più complesso né più lento (anzi) del Phenom prima versione.

Intervenire via HW ad un problema che si conosce non comporta nessun rallentamento o è minimo. Al max il vero problema è qualche transistor in più.
Gli interventi posticci fatti tramite SW che può gestire l'HW ad un livello diverso sono ovviamente più impattanti. E non si può comparare la perdita di prestazioni per una patch SW che può solo disabilitare questo o quella funzionalità HW, come magari dover fare flush di cache a manetta con quanto è possibile fare direttamente sul blocco HW in causa.

Faccio un esempio sciocco ma che forse rende l'idea.
Avete progettato una bellissima porta a ventola, tipo quelle dei saloon western. L'avete messa sull'entrata della cucina di un grande ristorante dove entrano ed escono i camerieri più volte al minuto. Quindi certamente è più veloce di una porta classica con la maniglia.
La porta quindi funziona perfettamente e fa il suo lavoro in maniera super efficiente.
Ad un certo punto si scopre che la porta blindata del ristorante ha una falla e si può aprire facilmente permettendo a chiunque di entrare e di gironzolare per tutti i locali. Ovviamente quelli che non hanno la serratura.
La vostra cucina è "difesa" dalla porta a ventola che non ha maniglia o serratura.
Ora trovate un modo di difendere la cucina da intrusi con qualche escamotage che non modifichi la porta stessa.
Ovviamente il metodo deve permettere la mattina dopo ai camerieri di continuare a lavorare. Vediamo chi trova la soluzione meno impattante.
Quando credete di avere trovato la soluzione ottimale, pensate ora di poter modificare la porta a ventola (ovvero di poter mettere mano all'HW) e trovate la miglior soluzione in questo caso.

Ora ditemi come e quanto le modifiche alla porta rallentano i camerieri rispetto alla versione originale.

[calabar]

@CrapaDiLegno
Nell'esempio del del Phenom confondi bug con vulnerabilità, sono due cose concettualmente differenti.

Qui non si tratta di risolvere un problema o sistemarlo con qualche transistor, ma di sottovalutare una possibile minaccia alla sicurezza.
Ovviamente in Intel possono dire "eh ma sfruttarlo è una cosa astrusa, e chi ci pensava?" ma alcuni già parecchio tempo fa avevano sollevato il problema. Pare proprio che in Intel abbiano deciso di proseguire su quella strada pensando che la minaccia fosse trascurabile, del resto avevano in mano una soluzione efficace e trovare alternative non sempre è banale. Poi però la cosa è esplosa loro sotto la sedia.

In quest'ottica il tuo esempio della porta a ventola suonerebbe in questo modo: decido di utilizzare una porta di quel tipo perchè così i miei camerieri passeranno più velocemente dalla cucina alla sala sottovalutando la questione sicurezza. Quando mi rendo conto che invece c'è un problema di sicurezza, se voglio risolverlo, devo tornare alla porta a maniglia oppure concepire qualcosa di completamente nuovo (che come dicevo, non è banale).
Certo, posso fare una doppia porta (la seconda chiusa solo di notte) o adottare qualunque altra soluzione adeguata, ma questa è una tematica che riguarda i ristoranti e non i processori.

[\_Davide_/]

Originariamente inviato da calabar

Non ha molto senso.
Quando sono saltate fuori le prime vulnerabilità di questo tipo si è subito visto come l'architettura AMD fosse molto più resiliente, anche laddove era affetta le possibilità di sfruttamento erano comunque remote.

Non è questo il punto: essendo i processori AMD molto meno diffusi (quasi inesistenti in ambito server) nessuno si mette a cercare vulnerabilità su di essi. Magari ci sono, magari sono enormi, ma finchè qualcuno non le dimostra è difficile saperlo.

Tieni conto che vedo server praticamente tutti i giorni, e nell'ultimo anno ho visto due soli HPE DL585 su piattaforma AMD.

[CrapaDiLegno]

Nell'esempio del del Phenom confondi bug con vulnerabilità, sono due cose concettualmente differenti.

Non c'è differenza tra le due cose. Sono 2 malfunzionamenti che hanno cause ed effetti simili.
L'uso della TBL è un sistema per aumentare la velocità del processore (e non di poco). Equivale a quello che si sostiene abbia fatto Intel per accelerare il codice.
Nel caso del baco dell TBL si è dovuto intervenire con una patch SW, che è lo stesso che si è dovuto fare con le mitigazioni per le vulnerabilità.
La causa è la stessa perché derivano in entrambi i casi da problemi HW.

Quando conosci il problema, nel mio caso derivato dal malfunzionamento di un altro dispositivo a cui non avevi pensato, puoi implementare tutte le soluzioni HW che vuoi.
Ma se non puoi metterci mano la cosa non è così agevole. Montare una seconda porta come lo fai? Aggiungi un pezzo di muro resistente a sufficienza che sta davanti alla porta a ventola? E' comunque un intervento HW.
Se posso modificare la porta, indovina cosa faccio? Ci metto una serratura che blocca le ante insieme. un'ora di lavoro, 30 euro di bella serratura resistente e ho risolto il problema.
Altrimenti mi devo inventare robe astruse per tenere chiusa quella porta e nessuno sarà in realtà efficace quanto la soluzione HW.

Per quanto riguarda "lo sapevano" "non lo sapevano" mi sembra la solita cosa che si dice quando scappano i buoi. Lo sapevano così tanto tante persone che i bachi di questo tipo hanno colpito anche altre architetture anche più moderne.
E loro? Tutti incapaci?
Qui si fa i fighi perché Zen in qualche modo è immune ad alcune vulnerabilità (mica tutte), ma il problema è ben più serio e pesante e credere che sia un problema solo di Intel che lo ha fatto "apposta" perché con le patch non poteva raggiungere quelle performance è roba da asilo Mariuccia.

Quando si progettano le cose lo si fa SEMPRE come compromesso di diverse cose. Puoi stare sicuro che la prossima architettura che sarà pensata per risolvere queste vulnerabilità (che sono poi bachi perché permettono di fare cose non previste) saranno colpite da altre vulnerabilità che si faranno sempre in modo più complesso e in verità alla fine anche poco utilizzabile.

Ogni anno la tecnologia aumenta e permette di fare cose che prima non si potevano fare. Hanno bucato protocolli di crittografia, resi algoritmi crittografici inutili anche solo per la pura potenza di calcolo raggiunta (eh, ma non potevano pensarci prima? Sì, così l'encryption durava 3 settimane invece che 1 minuto, compromessi, sempre compromessi). Hanno bucato persino la PS3 che era "inespugnabile" con tecniche che ovviamente non avevano pensato.

A casa tua hai un sistema di allarme? Lo hai messo che controlla ogni centimetro cubo dello spazio interno o hai fatto dei compromessi per cui magari controlli solo le porte? E se ti scavano un buco sotto casa ed entrano?
E se ti sollevano la casa e te la portano via?
E se se ne sbattono dell'allarme e della porta blindata ed entrano con un carro armato? E se domani trovano il modo di passare attraverso i muri? Hai pensato a tutti i modi per cui possono entrare e hai preso le dovute precauzioni?
Pensato che potrebbero darti fuoco alla casa per entrare?

Nessuno che capisce qualcosa di sicurezza può pensare di essere immune a tutto. Né a quello che già si conosce, né ovviamente e a maggior ragione a quello che sarà.
Fai un calcolo rischio/probabilità/danno/opportunità. E costi.

[calabar]

Originariamente inviato da CrapaDiLegno;

Non c'è differenza tra le due cose.

C'è una grande differenza.
Un processore affetto da bug non si comporta per come è stato progettato, ma non è necessariamente vulnerabile ad attacchi.
Un processore soggetto a vulnerabilità funziona esattamente come progettato ma carenze nel progetto lo rendono vulnerabile ad attacchi.

Dopo la tua premessa non ti offenderai se non leggo tutto il resto.

Originariamente inviato da _Davide_/;

Non è questo il punto: essendo i processori AMD molto meno diffusi (quasi inesistenti in ambito server) nessuno si mette a cercare vulnerabilità su di essi. Magari ci sono, magari sono enormi, ma finchè qualcuno non le dimostra è difficile saperlo.

In questo caso la diffusione, come spiegavo, non conta.
Non stiamo parlando di un processore che a causa delle sue vulnerabilità ha subito attacchi, e quindi i malintenzionati si sono concentrati sulla piattaforma più diffusa. Ad oggi non esistano attacchi documentati, non mi pare per lo meno, ma potrei essermi perso qualcosa.
Stiamo invece parlando di vulnerabilità scoperte dai ricercatori di sicurezza per le quali sono stati analizzati processori di ogni tipo, da quelli per PC a quelli per smartphone, e per tutti ne è stata valutata la vulnerabilità.
Questo lavoro di ricerca ha dimostrato che i processori AMD oggi sono meno vulnerabili di quelli Intel a questo genere di vulnerabilità e il fatto che continuino a spuntare nuove vulnerabilità sui processori Intel lo conferma.
Ricordo poi che Intel avrebbe tutto l'interesse a promuovere studi che dimostrino la vulnerabilità dei processori AMD e il fatto che sia saltato fuori poco e niente direi che possiamo considerarla un'altra conferma.

Poi oh, ragazzi, capita. Non è una lotta tra sostenitori di Intel e di AMD, sono microarchitetture differenti e capita che una sia più soggetta dell'altra ad un tipo di vulnerabilità. Stavolta è andata peggio ad Intel.

[cdimauro]

Originariamente inviato da andbad

Ok, quindi abbiamo trovato il colpevole di tutti questi bug.

LOL

Come dicevo nei messaggi precedenti, non dubito che Intel ci stia lavorando da tempo, dubito che sia in grado di restare al passo con la sua stessa tecnologia. Ipotizzavo dunque che forse è necessario una riprogettazione IN TOTO di tutta la logica che sta dietro alla CPU, con un orientamento non più prestazionale ma di sicurezza.

Non credo. Come già detto, tutti i processori sono (ancora) affetti da vulnerabilità di sicurezza di tipo side-channel. Se fosse soltanto Intel lo potrei capire, ma qui si tratta di una problematica generale, che è legata all'esecuzione speculativa.

Ciò che devono fare i produttori è chiudere le attuali falle, e fare ipotesi se alcune parti della micro-architettura possano essere sfruttate da eventuali futuri falle applicando quindi dei fix. Ma si tratta in ogni caso di un'attività creativa: non puoi sapere a priori cosa s'inventeranno i cacciatori di falle di sicurezza.

Se vuoi essere sicuro (per quel che si sa finora, per lo meno) di non avere di queste problematiche dovresti rinunciare all'esecuzione out-of-order, e tornare a quella in-order. Che significa avere un enorme impatto prestazionale. Cosa che nessun produttore né tanto meno cliente vorrà mai (siamo troppo ben abituati a prestazioni da capogiro).

Probabilmente c'entrano le percentuali di mercato. Dal 2018 è quasi un bollettino di guerra (e sento solo di Intel).

Esattamente. E' la micro-architettura più diffusa in ambito consumer e server, per cui è ovvio che i ricercatori si concentrino su quella.

Un po' come Windows per i s.o., insomma.

A memoria i bug prima di Spectre/Meltdown erano rari e riguardavano errori nei calcoli (peraltro non proprio comunissimi).

Sì, esattamente.

Ora si parla di intercettare dati relativi alla sicurezza, mi pare ben più grave.

By(t)e

Si tratta di intercettare dati normalmente non accessibili, per la precisione, ma non lo definire affatto più grave.

Più grave per me rimane un bug che causi corruzione dei dati (magari in maniera subdola / non facilmente prevedibile) rispetto a una falla che sia molto difficilmente sfruttabile.

Originariamente inviato da calabar

Non ha molto senso.
Quando sono saltate fuori le prime vulnerabilità di questo tipo si è subito visto come l'architettura AMD fosse molto più resiliente, anche laddove era affetta le possibilità di sfruttamento erano comunque remote.

E' soltanto una coincidenza. Produttori di altri processori come IBM e ARM sono stati affetti sostanzialmente da tutte le stesse vulnerabilità di Intel, pur avendo architetture e micro-architetture molto diverse, e non credo che si siano messi d'accordo...

Intel avrebbe avuto solo vantaggi a mostrare come anche i processori AMD mostrando che non era stata lei a trascurare la sicurezza ma che si trattava di problemi generalizzati poco prevedibili, ma non è mai saltato fuori nulla (oddio... quasi! Qualcuno ricorda questo articolo e la campagna FUD di cui parla? Qualcuno ci ha provato almeno ).
Pensare che sia un caso mi pare azzardato, il motivo più plausibile rimane la maggiore robustezza dell'architettura AMD nei confronti di attacchi di questo tipo.

Rimane una coincidenza.

D'altra parte se ci fosse stato dolo nella realizzazione di processori in cui appositamente si fosse sacrificata la sicurezza per le prestazioni, intanto sarebbero tutti colpevoli e poi la cosa sarebbe venuta fuori da parecchio tempo.

Questo non è proprio vero.
Quando sono saltate fuori le vulnerabilità sono apparse anche testimonianze di esperti del settore che avevano individuato potenziali rischi di questo tipo molti anni prima (se non sbaglio se ne parlava almeno dal 2008), quindi il problema era noto, ma è stato trascurato fino a quando non è esploso.

No, ricordi male.

Molto probabilmente ti riferisci ad attacchi side-channel riguardo alla crittografia, ossia la possibilità di riuscire a risalire alla chiave di decodifica sfruttando alcune caratteristiche micro-architetturali, come ad esempio il diverso numero di cicli di clock richiesti per processare certi dati.
Giusto per fare un esempio pratico, se per eseguire delle divisioni di interi viene richiesto un numero diverso di cicli di clock a seconda del numero di bit che siano 1 nel divisore, allora facendo un certo numero di prove è possibile risalire alla chiave di codifica con cui sono stati criptati i dati.
Oggi un attacco del genere non dovrebbe essere più possibile, perché vengono utilizzate delle istruzioni che accelerano in hardware certe operazioni utilizzate per gli algoritmi di criptazione più diffusi, e che richiedono lo stesso numero di cicli di clock per essere eseguite.

Invece gli attacchi di tipo side-channel di cui stiamo parlando risalgono a circa due anni, e gli stessi esperti di sicurezza hanno dichiarato che si sia trattato di un approccio geniale, ma visto né ipotizzato prima.

Puoi controllare le fonti per entrambe le cose nel thread "bug di sicurezza dei processori Intel" (se non ricordo male il nome. Comunque di recente è stato scritto qualche commento).

Originariamente inviato da calabar

C'è una grande differenza.
Un processore affetto da bug non si comporta per come è stato progettato, ma non è necessariamente vulnerabile ad attacchi.
Un processore soggetto a vulnerabilità funziona esattamente come progettato ma carenze nel progetto lo rendono vulnerabile ad attacchi.

Dopo la tua premessa non ti offenderai se non leggo tutto il resto.

Una doverosa precisazione: non c'è nessuna carenza del progetto, per quanto detto prima.

In questo caso la diffusione, come spiegavo, non conta.
Non stiamo parlando di un processore che a causa delle sue vulnerabilità ha subito attacchi, e quindi i malintenzionati si sono concentrati sulla piattaforma più diffusa. Ad oggi non esistano attacchi documentati, non mi pare per lo meno, ma potrei essermi perso qualcosa.
Stiamo invece parlando di vulnerabilità scoperte dai ricercatori di sicurezza per le quali sono stati analizzati processori di ogni tipo, da quelli per PC a quelli per smartphone, e per tutti ne è stata valutata la vulnerabilità.

Invece è una questione di diffusione. Perché quando leggi che i ricercatori hanno trovato una falla sui processori Intel, e che non siano sicuri o non abbiano controllato se sia applicabile a quelli di AMD, è evidente che la discriminante sia la diffusione dei processori per quanto riguarda questo tipi di studi.

Anche qui, nel thread ci cui sopra puoi trovare fonti in merito.

Questo lavoro di ricerca ha dimostrato che i processori AMD oggi sono meno vulnerabili di quelli Intel a questo genere di vulnerabilità e il fatto che continuino a spuntare nuove vulnerabilità sui processori Intel lo conferma.

Finora l'unica cosa certa è che i processori Intel siano fra i più soggetti, anche per il fatto che sono i più studiati.

Ricordo poi che Intel avrebbe tutto l'interesse a promuovere studi che dimostrino la vulnerabilità dei processori AMD e il fatto che sia saltato fuori poco e niente direi che possiamo considerarla un'altra conferma.

Ma assolutamente no. L'unico interesse di Intel è di analizzare eventuali falle sulle sue micro-architetture. Intel non ha risorse illimitate e non può sprecarle per analizzare le micro-architetture dei concorrenti quando è e dev'essere impegnata nel risolvere i suoi problemi.

Poi oh, ragazzi, capita. Non è una lotta tra sostenitori di Intel e di AMD, sono microarchitetture differenti e capita che una sia più soggetta dell'altra ad un tipo di vulnerabilità. Stavolta è andata peggio ad Intel.

Questo è certamente condivisibile.

[\_Davide_/]

Originariamente inviato da calabar

In questo caso la diffusione, come spiegavo, non conta.
Non stiamo parlando di un processore che a causa delle sue vulnerabilità ha subito attacchi, e quindi i malintenzionati si sono concentrati sulla piattaforma più diffusa. Ad oggi non esistano attacchi documentati, non mi pare per lo meno, ma potrei essermi perso qualcosa.
Stiamo invece parlando di vulnerabilità scoperte dai ricercatori di sicurezza per le quali sono stati analizzati processori di ogni tipo, da quelli per PC a quelli per smartphone, e per tutti ne è stata valutata la vulnerabilità.
Questo lavoro di ricerca ha dimostrato che i processori AMD oggi sono meno vulnerabili di quelli Intel a questo genere di vulnerabilità e il fatto che continuino a spuntare nuove vulnerabilità sui processori Intel lo conferma.
Ricordo poi che Intel avrebbe tutto l'interesse a promuovere studi che dimostrino la vulnerabilità dei processori AMD e il fatto che sia saltato fuori poco e niente direi che possiamo considerarla un'altra conferma.

Poi oh, ragazzi, capita. Non è una lotta tra sostenitori di Intel e di AMD, sono microarchitetture differenti e capita che una sia più soggetta dell'altra ad un tipo di vulnerabilità. Stavolta è andata peggio ad Intel.

Concordo, ma non nel segmento server dove, in pratica, Intel ha il monopolio sui server standard e non ha alcun interesse nel doversi difendere in quanto non vi sono alternative valide

[calabar]

@\_Davide_/
In realtà il segmento server è proprio quello in cui Spectre, Meltdown e affini ha causato più danni, il crollo prestazionale dovuto alle mitigazioni è stato molto pesante.
È vero che Intel detiene la maggior parte delle quote di mercato, ma AMD sta guadagnando terreno e sempre più partner propongono soluzioni server con motore AMD (sono apparsi anche annunci a riguardo di recente su questo sito).
In definitiva la minor vulnerabilità delle soluzioni AMD può essere un buon grimaldello per migliorare la penetrazione di questo mercato ed Intel non può che avere ogni interesse a spuntare quest'arma, soprattutto in un settore così importante.

Originariamente inviato da cdimauro;

E' soltanto una coincidenza.

Una coincidenza per modo di dire. Non è una cosa casuale, semplicemente in Intel hanno lavorato peggio.

Originariamente inviato da cdimauro;

No, ricordi male

Sono abbastanza sicuro invece di ricordare bene, avevo letto a riguardo articoli e fonti. Ora però è passato tropo tempo e ci metterei troppo a ripescarli.
Per chiarirci, mi riferisco a ricercatori di sicurezza che come novelle cassandre dicevano che l'approccio adottato da Intel poteva esporre i processori ad attacchi di questo tipo. Due anni fa il concept di questi attacchi è stato concretizzato e il problema è diventato concreto, ma l'idea alla loro base era stata prevista molto prima.

Originariamente inviato da cdimauro;

Invece è una questione di diffusione. Perché quando leggi che i ricercatori hanno trovato una falla sui processori Intel, e che non siano sicuri o non abbiano controllato se sia applicabile a quelli di AMD, è evidente che la discriminante sia la diffusione dei processori per quanto riguarda questo tipi di studi.

Credo che nessuno di noi abbia dati su quali processori siano più studiati, ma possiamo essere certi di non avere un "movente", ossia una vera motivazione per cui i processori Intel dovrebbero esserlo, chi fa ricerca non ha interesse a preferire gli Intel agli altri perchè più diffusi, e infatti diverse vulnerabilità non trovate su processori AMD sono invece state provate per esempio su processori mobile.
Se ricordi bene, già dai primi articoli i ricercatori dicevano di non essere ancora riusciti a realizzare dei proof-of-concept su processori AMD, non di non averci provato.

Originariamente inviato da cdimauro;

Una doverosa precisazione: non c'è nessuna carenza del progetto, per quanto detto prima.

Le carenze ci sono, proprio per i motivi esposti prima.
Carenza non significa che non funzioni come previsto, solo che non sono stati sufficientemente attenti agli aspetti legati alla sicurezza (intenzionalmente o meno è un discorso a parte, anche se si potrebbe dire che a pensar male...) tanto che il progetto è risultato più vulnerabile.

Originariamente inviato da cdimauro;

Ma assolutamente no.

Eccerto... e viviamo nel mondo delle fate!

[\_Davide_/]

Originariamente inviato da calabar

@\_Davide_/
In realtà il segmento server è proprio quello in cui Spectre, Meltdown e affini ha causato più danni, il crollo prestazionale dovuto alle mitigazioni è stato molto pesante.
È vero che Intel detiene la maggior parte delle quote di mercato, ma AMD sta guadagnando terreno e sempre più partner propongono soluzioni server con motore AMD (sono apparsi anche annunci a riguardo di recente su questo sito).
In definitiva la minor vulnerabilità delle soluzioni AMD può essere un buon grimaldello per migliorare la penetrazione di questo mercato ed Intel non può che avere ogni interesse a spuntare quest'arma, soprattutto in un settore così importante.

Le soluzioni con CPU AMD ci sono sempre state e sono ben presenti da almeno 5 anni, ma dove le hai viste in uso?
Intel ha troppo mercato, chi sceglie AMD è una nicchia molto piccola. Ho sentito solo di qualcuno (nemmeno visto personalmente) che a causa dei problemi derivanti dalle patch per spectre e meltdown è passato ad AMD (nonostante proposte vantaggiosissime su intel)

[CrapaDiLegno]

Originariamente inviato da calabar

C'è una grande differenza.
Un processore affetto da bug non si comporta per come è stato progettato, ma non è necessariamente vulnerabile ad attacchi.
Un processore soggetto a vulnerabilità funziona esattamente come progettato ma carenze nel progetto lo rendono vulnerabile ad attacchi.

Dopo la tua premessa non ti offenderai se non leggo tutto il resto.

Se vuoi fare lo spocchioso fai pure, ma se non sai descrivere cosa è un bug e ne prendi una concezione tutta tua allora sì, parla da solo di roba che non capisci.

Per inciso un baco è un comportamento che non è stato pensato al momento del design e porta a comportamenti diversi dal previsto.
Un baco può essere qualsiasi cosa e causato da molte cose.
Un baco è non fare le divisioni in maniera corretta.
Un baco è sbagliare a fare accesso alla TBL.
Un baco è permettere l'accesso alla cache quando non è previsto che si possa fare.

Quali siano gli effetti di questi bachi è differente da dire che una vulnerabilità non è un baco perciò il resto del discorso che non capisci non è valido.
Non fare i calcoli correttamente è un problema funzionale in genere, ma può essere anche un problema di sicurezza: alcuni algoritmi possono essere resi fragili visto che la generazione dei numeri casuali può usare quel tipo di calcoli.
Sbagliare a fare accesso alla TBL non è un problema di sicurezza se i dati non vengono condivisi con i processi utente sbagliati, ma può esserlo se lo fanno.
Permettere l'accesso ai dati della cache che non competono ad un processo è un baco. Che diventa di sicurezza perché espone i dati di altri a chi non dovrebbe vederli. Anche se tutto apparentemente continua a funzionare per te utente inconsapevole e ignorante del fatto che il design prevede che questo tipo di cose non debbano accadere. Per cui è un funzionamento fuori specifica. Per cui è un baco.

Come vedi un baco è un baco. Sono le sue conseguenze ad essere differenti.

Se non comprendi questo e vai di filosofia personale non considerando che non è solo Intel ad avere questi problemi ma tutte le architetture, la tua amata AMD compresa, allora sì, continua a parlare del nulla che non ho interesse a spiegarti come stanno le cose visto che non hai la capacità di comprenderle e vuoi solo sottolineare quando è brutta Intel rispetto alla tua bella AMD (che di patch correttive ne ha create e distribuite comunque).

[rockroll]

Originariamente inviato da CrapaDiLegno

Se vuoi fare lo spocchioso fai pure, ma se non sai descrivere cosa è un bug e ne prendi una concezione tutta tua allora sì, parla da solo di roba che non capisci.

Per inciso un baco è un comportamento che non è stato pensato al momento del design e porta a comportamenti diversi dal previsto.
Un baco può essere qualsiasi cosa e causato da molte cose.
Un baco è non fare le divisioni in maniera corretta.
Un baco è sbagliare a fare accesso alla TBL.
Un baco è permettere l'accesso alla cache quando non è previsto che si possa fare.

Quali siano gli effetti di questi bachi è differente da dire che una vulnerabilità non è un baco perciò il resto del discorso che non capisci non è valido.
Non fare i calcoli correttamente è un problema funzionale in genere, ma può essere anche un problema di sicurezza: alcuni algoritmi possono essere resi fragili visto che la generazione dei numeri casuali può usare quel tipo di calcoli.
Sbagliare a fare accesso alla TBL non è un problema di sicurezza se i dati non vengono condivisi con i processi utente sbagliati, ma può esserlo se lo fanno.
Permettere l'accesso ai dati della cache che non competono ad un processo è un baco. Che diventa di sicurezza perché espone i dati di altri a chi non dovrebbe vederli. Anche se tutto apparentemente continua a funzionare per te utente inconsapevole e ignorante del fatto che il design prevede che questo tipo di cose non debbano accadere. Per cui è un funzionamento fuori specifica. Per cui è un baco.

Come vedi un baco è un baco. Sono le sue conseguenze ad essere differenti.

Se non comprendi questo e vai di filosofia personale non considerando che non è solo Intel ad avere questi problemi ma tutte le architetture, la tua amata AMD compresa, allora sì, continua a parlare del nulla che non ho interesse a spiegarti come stanno le cose visto che non hai la capacità di comprenderle e vuoi solo sottolineare quando è brutta Intel rispetto alla tua bella AMD (che di patch correttive ne ha create e distribuite comunque).

Permettimi di dire che quel che ha affermato Calabar è assolutamente condivisibile e non offende nessun interlocutore, mentre tu ti sei offeso malgrado la premessa ed hai attaccato il tuo interlocutore sul piano personale, sviando il discorso sulla terminologia del baco e filosofegginado sulla eventualità, per te quasi certezza, che problemi di vulnerabilità derivano dal cosidetto baco anzichè da più o meno consapevolmente bacati compromessi progettuali in HW.

E se non me lo permetti pazienza...

[cdimauro]

Originariamente inviato da calabar

@\_Davide_/
In realtà il segmento server è proprio quello in cui Spectre, Meltdown e affini ha causato più danni, il crollo prestazionale dovuto alle mitigazioni è stato molto pesante.
È vero che Intel detiene la maggior parte delle quote di mercato, ma AMD sta guadagnando terreno e sempre più partner propongono soluzioni server con motore AMD (sono apparsi anche annunci a riguardo di recente su questo sito).

Riparliamone quando ci saranno dati concreti sulle quote di mercato in ambito server.

In definitiva la minor vulnerabilità delle soluzioni AMD può essere un buon grimaldello per migliorare la penetrazione di questo mercato ed Intel non può che avere ogni interesse a spuntare quest'arma, soprattutto in un settore così importante.

E' anche per questo che ha messo in piedi un tuo esclusivamente dedicato alla ricerca di vulnerabilità nelle sue micro-architetture. D'altra parte il segmento data center è da anni il gioiello aziendale che garantisce guadagni molto elevati.

Una coincidenza per modo di dire. Non è una cosa casuale, semplicemente in Intel hanno lavorato peggio.

Peggio rispetto a cosa? Perché c'è un prima e un dopo Meltdown/Spectre.
Prima si lavorava senza questa consapevolezza, e l'unico metro di giudizio erano le prestazioni.
Dopo è arrivata la doccia fredda e con ciò la necessità di capire quali problemi potrebbero sorgere con le proprie micro-architetture.

D'altra parte che sia stata una coincidenza e quindi cosa casuale, lo avevi affermato proprio tu alla fine del precedente commento:

"sono microarchitetture differenti e capita che una sia più soggetta dell'altra ad un tipo di vulnerabilità"

"capita" -> è soggetto al caso.

http://www.treccani.it/vocabolario/capitare

"ar capo, metter capo, quindi giungere, arrivare, ma di solito per caso o incidentalmente
[...]
Di cose, venire per caso
[...]
avere o no fortuna in una scelta
[...]
Accadere, succedere d’improvviso
[...]
di cose che sopraggiungono quando uno meno se l’aspetta"

Quindi mettiti d'accordo con te stesso: o è frutto del caso o non lo è. Nella seconda delle ipotesi sei liberissimo di dimostrarlo, ovviamente, perché l'onere della tesi è a tuo carico.

Sono abbastanza sicuro invece di ricordare bene, avevo letto a riguardo articoli e fonti. Ora però è passato tropo tempo e ci metterei troppo a ripescarli.
Per chiarirci, mi riferisco a ricercatori di sicurezza che come novelle cassandre dicevano che l'approccio adottato da Intel poteva esporre i processori ad attacchi di questo tipo. Due anni fa il concept di questi attacchi è stato concretizzato e il problema è diventato concreto, ma l'idea alla loro base era stata prevista molto prima.

Io ricordo molto bene invece, e ribadisco: ti riferisci agli attacchi side-channel relativi alla crittografia (che l'utente maxsin72 aveva portato nel thread che avevo menzionato, pensando di aver trovato dei vecchi attacchi side-channel simili a Meltdown e Spectre).
Inoltre ricordo benissimo le dichiarazioni degli esperti di sicurezza in merito, che hanno affermato di essere davanti ad attacchi completamente nuovi.

In quel thread troverai link per entrambe le cose, e potrai verificarlo tu stesso.

In alternativa e se pensi ancora che si tratti di articoli/notizie diversi, sarei interessato a leggerli, perché si tratterebbe di una novità che mi piacerebbe analizzare e studiare.

Credo che nessuno di noi abbia dati su quali processori siano più studiati, ma possiamo essere certi di non avere un "movente", ossia una vera motivazione per cui i processori Intel dovrebbero esserlo, chi fa ricerca non ha interesse a preferire gli Intel agli altri perchè più diffusi, e infatti diverse vulnerabilità non trovate su processori AMD sono invece state provate per esempio su processori mobile.
Se ricordi bene, già dai primi articoli i ricercatori dicevano di non essere ancora riusciti a realizzare dei proof-of-concept su processori AMD, non di non averci provato.

Questo riguarda Meltdown e alcune varianti di Spectre.

Ma da allora sono uscite fuori diverse vulnerabilità, e per alcune i ricercatori hanno affermato di non avere ancora (all'epoca della pubblicazione della notizia) verificato se fossero applicabili anche ad AMD.

Questo implica ovviamente che il loro focus è stato rivolto esclusivamente a Intel, che è il maggior fornitore di processori x86/x64. Dunque sì: la diffusione è una discriminante.

Le carenze ci sono, proprio per i motivi esposti prima.
Carenza non significa che non funzioni come previsto, solo che non sono stati sufficientemente attenti agli aspetti legati alla sicurezza (intenzionalmente o meno è un discorso a parte, anche se si potrebbe dire che a pensar male...) tanto che il progetto è risultato più vulnerabile.

E ancora una volta no: carenza vuol dire che manchi qualcosa.
PRIMA di Meltdown/Spectre non c'era nulla che potesse avvalorare questa tesi. I progetti NON erano quindi carenti di alcunché.
DOPO ovviamente si è posta la questione, ma anche qui continuare a parlare di carenza lascia il tempo che trova, visto che non puoi riprogettare da capo le tue micro-architetture senza investirci parecchio tempo/risorse, e peraltro niente ti potrà mai garantire che non salteranno fuori delle nuove vulnerabilità anche con le future micro-architetture.

Se parli di carenze devi dimostrare che il progetto sia stato appositamente realizzato senza qualcosa che abbia di conseguenza minato la sua sicurezza.

Se vuoi continuare a sostenere questa tesi... accomodati pure, e porta le prove di ciò che affermi. Sono sicuro che non soltanto i progettisti di micro-architetture, ma anche i ricercatori di sicurezza di tutto il mondo non vedrebbero l'ora di leggere la tua dimostrazione.

Eccerto... e viviamo nel mondo delle fate!

In effetti bisogna proprio vivere nel mondo delle fiabe per sostenere di poter andare a caccia di vulnerabilità nelle micro-architetture della concorrenza, di cui si conoscono soltanto i diagrammi di massima e il manuale delle ottimizzazioni, quando già si fa faticare a trovarle nelle proprie micro-architetture di cui si ha totale conoscenza incluso il codice RTL della loro implementazione.

Ma anche qui: se hai prove a sostegno delle tue fantasie, non hai che da presentarle...

Originariamente inviato da rockroll

problemi di vulnerabilità derivano dal cosidetto baco anzichè da più o meno consapevolmente bacati compromessi progettuali in HW.

E se non me lo permetti pazienza...

Più che altro mancano le dimostrazioni di queste tue sparate. Ma sappiamo bene che ciò deriva esclusivamente dal tuo odio verso Intel e il tuo amore per AMD.

Altrimenti ti saresti accorto che anche AMD soffre di problemi di vulnerabilità (non c'è nessun processore che attualmente sia totalmente esente da tutte quelle finora scoperte), e dunque applicando il tuo concetto potremmo affermare che ciò derivi da "più o meno consapevolmente bacati compromessi progettuali in HW".

[386DX40]

In un mondo parallelo, con i processi produttivi che ci sono oggigiorno tornerei a processori single core, architetture in-order e magari chiederei ai produttori di o.s. e software di iniziare a rivedere/ripensare la filosofia di fondo delle loro architetture software appunto perche' se magari diversi o.s. oggigiorno necessitano di giga di ram, accelerazioni hardware dipendenti da drivers, framework intermedi anche solo per la gui o software di centinaia di mega di file solo di installazione per leggere un pdf quando lo si leggeva vent'anni fa con un decimo delle risorse e con lo "stesso" risultato (almeno parlo per l'utente "medio" e utilizzo home tralasciando ambiti server/cloud o specifici tipo workstation grafiche/sviluppo o quel che sia che conosco meno) non e' che forse ma forse uno dei problemi sia li invece di continuare a compensare strati e strati e strati di dipendenze, frameworks, software concatenati tra loro per fare anche le cose piu' basilari? Un bios per una scheda madre moderna quanto pesa 8 megabytes? Seriamente?
Dubito che il problema sia l'hardware che forse ha dovuto trovare ogni modo anche con relativi lati negativi di compensare la suddetta pesantezza assurda di ogni cosa; se dovessimo fare un parallelo tra la "potenza" delle architetture moderne su sistemi operativi e software di vent'anni fa avremmo un decimo dell'uso delle risorse, un decimo del consumo di watt, etc, etc.. e alla fine l'uso che se ne fa e' lo stesso o forse e' cambiato il motivo per cui la tecnologia consumer esiste, forse non piu' prodotti a scatola chiusa ma servizi.

[\_Davide_/]

Originariamente inviato da cdimauro

Riparliamone quando ci saranno dati concreti sulle quote di mercato in ambito server.

Ci lavoro tutti i giorni ed accedo alla maggiorparte dei DC del nord Italia, oltre all'incontrare molte persone diverse: la mia idea è ben chiara

[cdimauro]

Originariamente inviato da 386DX40

In un mondo parallelo, con i processi produttivi che ci sono oggigiorno tornerei a processori single core, architetture in-order

Non sono i processori multicore il problema (che sono la via più semplice per migliorare le prestazioni, anche se purtroppo non applicabili a qualunque tipo di codice; tutt'altro), ma la condivisione delle risorse del core che esegue processi e/o thread diversi lasciando delle "tracce".
I problemi più grossi possono avvenire con tecnologie come l'SMT, dove tale condivisione avviene allo stesso tempo (più processi/thread eseguiti nello stesso momento condividendo le stesse risorse del core).
Onde evitare problemi, quindi, si dovrebbe paradossalmente tornare a un'elaborazione batch (mono processo e strettamente sequenziale: quasi come il DOS, ma ancora peggio. Perché il DOS consentiva parzialmente l'esecuzione di più processi allo stesso modo: chi conosce "l'indos flag", che è stato sfruttato dai famigerati TSR, sa di cosa parlo... e che si tratta di roba da archeologia informatica ), ma si capisce che non si può certo tornare a questi livelli.

L'esecuzione out-of-order è la causa principale dei problemi di cui stiamo parlando negli ultimi due anni, ma tornare a quella in-order non è conveniente a causa del drammatico crollo delle prestazioni che non piacerebbe principalmente ai fruitori dei processori (ossia noi: gli utenti).

e magari chiederei ai produttori di o.s. e software di iniziare a rivedere/ripensare la filosofia di fondo delle loro architetture software appunto perche' se magari diversi o.s. oggigiorno necessitano di giga di ram, accelerazioni hardware dipendenti da drivers, framework intermedi anche solo per la gui o software di centinaia di mega di file solo di installazione per leggere un pdf quando lo si leggeva vent'anni fa con un decimo delle risorse e con lo "stesso" risultato (almeno parlo per l'utente "medio" e utilizzo home tralasciando ambiti server/cloud o specifici tipo workstation grafiche/sviluppo o quel che sia che conosco meno) non e' che forse ma forse uno dei problemi sia li invece di continuare a compensare strati e strati e strati di dipendenze, frameworks, software concatenati tra loro per fare anche le cose piu' basilari? Un bios per una scheda madre moderna quanto pesa 8 megabytes? Seriamente?
Dubito che il problema sia l'hardware che forse ha dovuto trovare ogni modo anche con relativi lati negativi di compensare la suddetta pesantezza assurda di ogni cosa; se dovessimo fare un parallelo tra la "potenza" delle architetture moderne su sistemi operativi e software di vent'anni fa avremmo un decimo dell'uso delle risorse, un decimo del consumo di watt, etc, etc.. e alla fine l'uso che se ne fa e' lo stesso o forse e' cambiato il motivo per cui la tecnologia consumer esiste, forse non piu' prodotti a scatola chiusa ma servizi.

Il problema è la produttività: per realizzare software di una certa complessità si cerca di ridurre i tempi di sviluppo sfruttando framework et similia di più alto livello. Con la conseguente maggior richiesta di prestazioni e/o memoria.

Tornare indietro dopo aver assaggiato le comodità del software moderno non è certo possibile. Almeno per il momento.

In futuro, con la morte della legge di Moore, anche elettronica e informatica dovranno ridimensionarsi, perché prestazioni e storage sbatteranno contro i sopraggiunti limiti. La ricerca di nuovi materiali (alternativi al silicio) si rivelerà soltanto come uno spostamento in avanti dei limiti fisici della materia, che verranno comunque raggiunti.

Soltanto allora si ricomincerà a spendere più tempo con le ottimizzazioni, riscoprendo anche l'uso del linguaggio assembly (ovviamente non per tutto), e magari arriveranno nuove architetture che consentiranno di ottenere prestazioni in single-core/thread migliori (grazie all'elaborazione di più "lavoro utile" per ciclo di clock).

Ma ci vorranno ancora un bel po' di anni.

Originariamente inviato da \_Davide_/

Ci lavoro tutti i giorni ed accedo alla maggiorparte dei DC del nord Italia, oltre all'incontrare molte persone diverse: la mia idea è ben chiara

Anche la mia, lavorando in una multinazionale che adopera parecchi server.

[\_Davide_/]

Originariamente inviato da cdimauro

Anche la mia, lavorando in una multinazionale che adopera parecchi server.

Voi ne avete su base AMD?

In ogni caso valutare una singola azienda non è indicativo della situazione, almeno, nazionale.

[386DX40]

Originariamente inviato da cdimauro

Non sono i processori multicore il problema (che sono la via più semplice per migliorare le prestazioni, anche se purtroppo non applicabili a qualunque tipo di codice; tutt'altro), ma la condivisione delle risorse del core che esegue processi e/o thread diversi lasciando delle "tracce".
I problemi più grossi possono avvenire con tecnologie come l'SMT, dove tale condivisione avviene allo stesso tempo (più processi/thread eseguiti nello stesso momento condividendo le stesse risorse del core).
Onde evitare problemi, quindi, si dovrebbe paradossalmente tornare a un'elaborazione batch (mono processo e strettamente sequenziale: quasi come il DOS, ma ancora peggio. Perché il DOS consentiva parzialmente l'esecuzione di più processi allo stesso modo: chi conosce "l'indos flag", che è stato sfruttato dai famigerati TSR, sa di cosa parlo... e che si tratta di roba da archeologia informatica ), ma si capisce che non si può certo tornare a questi livelli.

L'esecuzione out-of-order è la causa principale dei problemi di cui stiamo parlando negli ultimi due anni, ma tornare a quella in-order non è conveniente a causa del drammatico crollo delle prestazioni che non piacerebbe principalmente ai fruitori dei processori (ossia noi: gli utenti).

Il problema è la produttività: per realizzare software di una certa complessità si cerca di ridurre i tempi di sviluppo sfruttando framework et similia di più alto livello. Con la conseguente maggior richiesta di prestazioni e/o memoria.

Tornare indietro dopo aver assaggiato le comodità del software moderno non è certo possibile. Almeno per il momento.

In futuro, con la morte della legge di Moore, anche elettronica e informatica dovranno ridimensionarsi, perché prestazioni e storage sbatteranno contro i sopraggiunti limiti. La ricerca di nuovi materiali (alternativi al silicio) si rivelerà soltanto come uno spostamento in avanti dei limiti fisici della materia, che verranno comunque raggiunti.

Soltanto allora si ricomincerà a spendere più tempo con le ottimizzazioni, riscoprendo anche l'uso del linguaggio assembly (ovviamente non per tutto), e magari arriveranno nuove architetture che consentiranno di ottenere prestazioni in single-core/thread migliori (grazie all'elaborazione di più "lavoro utile" per ciclo di clock).

Ma ci vorranno ancora un bel po' di anni.

Anche la mia, lavorando in una multinazionale che adopera parecchi server.

Vero. Ma a volte ripartire dalle basi il prima possibile diventa necessario e questo continuo spostare avanti adagiandosi sulla comodita' appunto di framework, linguaggi high level, risorse presumibilmente infinite che poi all'atto pratico risultano finite eccome non potendo anche loro fare miracoli mostra da anni i suoi limiti. Non ho macchine moderne ma a leggere di quanta ram viene usata oggigiorno diventa incompresibile. Da un lato credo ci sia anche un problema lato utenza che non nota questo continuo appesantire perche' si e' velocizzato l'hw e cosi' via..
Se in pochi anni si passava da un 386 a un Pentium e da uno slot ISA ad uno PCI (passando per il VLB ovvio) allora era come aver cambiato pianeta in termini di percezione diretta di quella potenza proprio perche' non solo tutto il mondo hw e sw era in fermento e l'evoluzione esponenziale ma soprattutto il sofware rimaneva estremamente low level. A volte si scusa molto con il discorso della "risoluzione" delle interfacce come se il problema fosse solo la GUI, che magari in parte lo e' ma non certo per la risoluzione in se. Una intefaccia come quella di W95 in 4K probabilmente chiederebbe un "millesimo" delle risorse di una moderna e l'area di lavoro sarebbe la stessa. Tutta questa rincorsa allo "user friendly", agli effetti grafici iperfluidi e per finire molti processi dipendenti e orientati al web, al cloud, ai software come servizio prima che prodotto, ove quello offline valutabile per quel che e' senza risorse esterne allo stesso sembra non esistere quasi piu'. Vale per tutto anche distribuzioni su linux tralvolta molto pesanti mentre altre almeno si salvano per essenzialita' del pacchetto base con interfacce leggere a cui poi eventualmente aggiungere altro sw.

[cdimauro]

Originariamente inviato da \_Davide_/

Voi ne avete su base AMD?

Non mi occupo di server, ma finora non ne ho mai visto. Ho visto pure prototipi basati su Xeon Phi, ma finora mai visto nulla a marchio AMD.

In ogni caso valutare una singola azienda non è indicativo della situazione, almeno, nazionale.

Certamente, ma considerate anche le quote di mercato in ambito server che vengono snocciolate di tanto in tanto, mi pare che la situazione sia pressapoco quella di cui abbiamo parlato.

E non parliamo poi dei NUC di Intel: di quelli se ne ordinano a valanga rispetto ai server, perché sono davvero molto comodi in diversi ambiti, incluso per tirar sù server "non mission critical" spendendo molto poco.

Originariamente inviato da 386DX40

Vero. Ma a volte ripartire dalle basi il prima possibile diventa necessario e questo continuo spostare avanti adagiandosi sulla comodita' appunto di framework, linguaggi high level, risorse presumibilmente infinite che poi all'atto pratico risultano finite eccome non potendo anche loro fare miracoli mostra da anni i suoi limiti. Non ho macchine moderne ma a leggere di quanta ram viene usata oggigiorno diventa incompresibile. Da un lato credo ci sia anche un problema lato utenza che non nota questo continuo appesantire perche' si e' velocizzato l'hw e cosi' via..

Ma infatti è proprio questo il nocciolo della questione: l'hardware è progredito tantissimo grazie alla legge di Moore, per cui il software ne ha approfittato per offrire agli utenti prodotti sempre più comodi e funzionali. Ma approfittarne ha significato alzare di conseguenza il consumo di risorse. Solo che tutto ciò è stato, per l'appunto, "coperto" dall'avanzamento tecnologico.

Su questo non ci vedo nulla di male: è stata e continua a essere (ancora per un po') una situazione win-win.

Se in pochi anni si passava da un 386 a un Pentium e da uno slot ISA ad uno PCI (passando per il VLB ovvio) allora era come aver cambiato pianeta in termini di percezione diretta di quella potenza proprio perche' non solo tutto il mondo hw e sw era in fermento e l'evoluzione esponenziale ma soprattutto il sofware rimaneva estremamente low level. A volte si scusa molto con il discorso della "risoluzione" delle interfacce come se il problema fosse solo la GUI, che magari in parte lo e' ma non certo per la risoluzione in se.

La risoluzione è quello che generalmente incide di più: più è elevata, più pixel ci sono da processare, e quindi servono più memoria / banda di memoria / più potenza di calcolo.
Idem se ne aumenti la "profondità" (numero di bit per il colore) o il frame rate: le richieste di risorse aumentano di conseguenza.

Quindi, come vedi, le richieste sono come minimo proporzionali (senza nemmeno toccare gli effetti speciali), e sono anche quelle che incidono di più.

Una intefaccia come quella di W95 in 4K probabilmente chiederebbe un "millesimo" delle risorse di una moderna e l'area di lavoro sarebbe la stessa. Tutta questa rincorsa allo "user friendly", agli effetti grafici iperfluidi

Ti capisco, ma quegli effetti ci sono perché abbiamo "semplicemente" imparato a sfruttare gli avanzamenti delle schede grafiche / GPU che ci sono stati per i giochi.

Se hai una GPU che ti consente di elaborare effetti, perché sfruttarla soltanto per i giochi? Visto che è lì, a girarsi i pollici, la si sfrutta eventualmente anche per la GUI.

Non è che le GPU siano state dotate di hardware dedicato esclusivamente per la GUI.
Questo succedeva agli inizi, perché iniziavano a diffondersi le GUI nei computer, e quindi ci si poneva il problema di aiutare la CPU anche per compiti molto semplici, come spostare una finestra. E quindi sono sputati coprocessori dedicati, come Blitter (Amiga rulez! ), per sgravare la CPU da questi compiti semplici ma molto ripetitivi nonché voraci di risorse.
Quindi parliamo in ogni caso di ottimizzazione, ed è stata una cosa "buona e giusta".

e per finire molti processi dipendenti e orientati al web, al cloud, ai software come servizio prima che prodotto, ove quello offline valutabile per quel che e' senza risorse esterne allo stesso sembra non esistere quasi piu'.

Questa è una possibilità in più, però, e per giunta serve anche a dare una mano, scaricando tante volte l'onere delle computazione su server dedicati, alleggerendo i client.

E' una sorta di ritorno ai mainframe coi clienti "stupidi" (usati soltanto per l'I/O), che dal punto di vista dell'ottimizzazione nonché uso delle risorse dovrebbe essere apprezzabile.

Vale per tutto anche distribuzioni su linux tralvolta molto pesanti mentre altre almeno si salvano per essenzialita' del pacchetto base con interfacce leggere a cui poi eventualmente aggiungere altro sw.

Linux ha ben altri problemi: una mostruosa frammentazione.
Da utente non mi posso mettere a cercare la distro "giusta" fra tutte quelle esistenti: è un'enorme perdita di tempo.
E da programmatore non ne parliamo, con tutti i toolkit/framework/librerie/IDE/editor.

Su Linux c'è un'immane spreco di risorse che va dai programmatori che sviluppano tutta quella roba agli utenti che devono averci a che fare.

Io sono un amante del tutto pronto con pochi click. Ho già perso una montagna di tempo in gioventù a smanettare, ma adesso sono un utente che non vuole perdere tempo a sistemare la macchina, ma vuole essere immediatamente produttivo e focalizzato esclusivamente sulla risoluzione dei MIEI problemi.

[\_Davide_/]

Originariamente inviato da cdimauro

Non mi occupo di server, ma finora non ne ho mai visto. Ho visto pure prototipi basati su Xeon Phi, ma finora mai visto nulla a marchio AMD.

Esistere esistono: ad esempio tutte le serie HPE con il 5 finale sono su base AMD (es. DL385, DL585 &co). Quello che intendevo dire è che in giro non se ne trova praticamente nessuno.

Originariamente inviato da cdimauro

E non parliamo poi dei NUC di Intel: di quelli se ne ordinano a valanga rispetto ai server, perché sono davvero molto comodi in diversi ambiti, incluso per tirar sù server "non mission critical" spendendo molto poco.

Su questi non ho mai messo mano nè ci lavoro abitualmente. Non so nemmeno se esista una alternativa commercializzata su AMD

[cdimauro]

Originariamente inviato da \_Davide_/

Esistere esistono: ad esempio tutte le serie HPE con il 5 finale sono su base AMD (es. DL385, DL585 &co). Quello che intendevo dire è che in giro non se ne trova praticamente nessuno.

Sì, esatto, volevo dire quello: mai visti nella mia azienda.

Su questi non ho mai messo mano nè ci lavoro abitualmente. Non so nemmeno se esista una alternativa commercializzata su AMD

Non ce ne sono.