Link alla notizia: https://www.hwupgrade.it/news/cpu/linus-torvalds-parla-di-intel-e-meltdown-e-volano-gli-stracci_73397.html

Linus Torvalds, lo sviluppatore finlandese naturalizzato statunitense che creò il kernel Linux, ha una forte opinione riguardo quanto avvenuto in casa Intel con Meltdown. Tra le espressioni colorite il concetto è chiaro

Click sul link per visualizzare la notizia.

A quando i benchmark con e senza patch?

Tranquillo che ne usciranno a fiumi.

nun vorrei dì ma phoronix è da giorni che ne sta facendo di bench...

Chi ha acquistato dei sistemi con CPU Intel, pagandoli un tanto a CPU e facendo affidamento alle prestazioni pre-bug, avrà diritto ad un rimborso? Ad esempio, se io ho acquistato un sistema da 1 PFlop - e quindi con n CPU Intel - e dopo l'applicazione della patch le n CPU mi danno diciamo un 10% di velocità in meno, chi mi rimborsa quel 10%?

Qui un video con un po di test:
https://www.youtube.com/watch?time_continue=341&v=_qZksorJAuY

per fortuna almeno nei kernel di linux, si può già escludere dal esecuzione la patch di meltdown e tutto lascia intendere che sarà così anche per spectre..

visto che intel non mi (ci) risarcirà mai per questa ennesima sparata di silicone a random (qualcuno ricorda le altre? bene!), non intendo pagare per la seconda volta una cpu, acquistandone un altra solo perché la prima è furbescamente "obsoleta" a suo modo;

se poi ci saranno risvolti legali, guerre termonucleari, bitcoin a valore zero perché non era protetta l'esecuzione del codice nelle mie stazioni meltdownate o spectrate, che sia intel a spiegare il perché all'umanità atterrita, coi suoi soldi :banned:

A quando i benchmark con e senza patch?

Su Hackaday un utente nei commenti ha messo un semplice sorgente C++ da dove si vede che certi accessi al kernel hanno triplicato il tempo di esecuzione.

Il commento sta qui
https://hackaday.com/2018/01/09/getting-a-handle-on-meltdown-update-impact-stay-tuned-for-spectre/#comment-4296159
il codice è qui
https://pastebin.com/5qacGA17

Chi ha acquistato dei sistemi con CPU Intel, pagandoli un tanto a CPU e facendo affidamento alle prestazioni pre-bug, avrà diritto ad un rimborso? Ad esempio, se io ho acquistato un sistema da 1 PFlop - e quindi con n CPU Intel - e dopo l'applicazione della patch le n CPU mi danno diciamo un 10% di velocità in meno, chi mi rimborsa quel 10%?

se hai un super computer da 1PFlops sicuro non ci gira sopra software tipo un browser ed una java machines, quindi il problema non ti compete.

niente.. anche intel ha fallito.. ormai dobbiamo sperare sullo sviluppo open anche nell'hardware.. :rolleyes:

Vai Linus, spacca tutto...
A Nvidia li ha fatti neri, a quelli di openSuse ancora gli fischiano le orecchie, a Intel gli sparerebbe...

Il Vittorio Sgarbi Finnico

Capre, Capre, Capre... :asd:

Vai Linus, spacca tutto...
A Nvidia li ha fatti neri, a quelli di openSuse ancora gli fischiano le orecchie, a Intel gli sparerebbe...

Il Vittorio Sgarbi Finnico

Capre, Capre, Capre... :asd:

Solo che il nostrano Sgarbi è al 90% cazzaro.
Linus ha ragione da vendere, la patch proposta in upstream per Linux da Intel consisteva in una riga in cui tutte le CPU erano considerate "insicure", con il risultato di attivare la patch per Meltdown nel kernel per tutte (*tutte*) le cpu. Ridicolo è dire poco, irresponsabile non rende l'idea.

Solo che il nostrano Sgarbi è al 90% cazzaro.
Linus ha ragione da vendere, la patch proposta in upstream per Linux da Intel consisteva in una riga in cui tutte le CPU erano considerate "insicure", con il risultato di attivare la patch per Meltdown nel kernel per tutte (*tutte*) le cpu. Ridicolo è dire poco, irresponsabile non rende l'idea.

In effetti era procedura saggia se le patch si potevano evitare per quelle CPU prive di vulnerabilità per Meltdown e la variante di Spectre non coinvolta.
Voler tirare in ballo tutti sembra la famosa massima, tutti hanno problemi quindi nessun problema, cosa che potrebbe andare bene per mitigare la perdita di immagine, cosa diversa per chi su quelle patch ci deve lavorare...

Concordo con le critiche di Linus.
D'altra parte tutto questo andazzo fa parte della "logica" del sistema.
Cioè di quella della ricerca esasperata delle prestazioni a scapito della solidità e della stabilità, da troppi anelata e attesa, compresi moltissimi di noi utenti, troppi dei quali vivono di novità da bruciare subito in campo Hardware e Software.
Così i produttori, in una corsa forsennata fra loro e per accontentare esigenze dell'utenza, la quale è composta anche da istituzioni, istituti di ricerca e universitari, militari e aziende, si danno da fare per sfornare le loro "meraviglie del creato".
Insomma, stiamo tutti rincorrendo i soliti "pifferai" magici che ci fanno l'occhiolino.
Ricordo la sfrenata pubblicità sulle riviste "d'epoca" di informatica del finire del 1980, quando si reclamizzavano con enfasi assurda macchine con "48 k" di Ram per svolgere i lavori dell'ufficio, con i primi computer di size "midi", figliastri dei mainframe e precursori ideali dei personal computer.
Tutta roba nostalgica finita nella spazzatura.
Ma almeno allora le CPU non avevano circuiti interni di controllo di vario livello con i ben noti MiniX e con le delizie attuali, tutta roba che per me è spazzatura.
Evidentemente non si vogliono fabbricare processori che fanno il loro lavoro onestamente, ma si cerca il pelino per dimostrare quanto valgono le lauree in ingegneria dei progettisti e fabbricanti di chip.
Una inutile narcisistica esibizione di "virtuosismo" a chi più ne ha, più ne metta.

Che poi in questo marasma qualcuno magari come NSA abbia potuto o possa inzuppare il "biscottino", a qualcuno non piace proprio come idea, e la nega, chiedendo "dimostrazioni" di fatti che stanno sotto gli occhi di tutti.
Forse per difendere a oltranza una cieca fede in qualcosa che oggi è diventata una "religione", ovvero una struttura di anelata perfezione assoluta che ci avvicina tutti agli dei, che ci fa sentire un "dio" con le dita appoggiate su una tastiera e con lo sguardo perduto nello splendore di un display luminescente.

Ma almeno 'ste CPU, le sappiamo fare in modo che nessuno ci possa ficcare dentro un codice malevolo?
Ovvero, perché una CPU deve avere perfino un "firmware" o altra robaccia del genere, da contagiare o inoculare con qualche riga di codice?

Ma allora dov'è 'sta "sicurezza" tanto bramata, come l'acqua nel deserto al viaggiatore disperso da un mese?

E che dire poi dei sistemi operativi, che in tutto ciò si affannano a dare una mano alla cara "amica" Intel, con 'ste famose "patch", che a casa mia 60 anni fa si chiamavano "le pezze al culo"?
Ma davvero vogliamo credere che non esista affatto un qualcuno "cui prodest", cioè al quale tutto questo non porti vantaggi nascosti?

Su Hackaday un utente nei commenti ha messo un semplice sorgente C++ da dove si vede che certi accessi al kernel hanno triplicato il tempo di esecuzione.

Il commento sta qui
https://hackaday.com/2018/01/09/getting-a-handle-on-meltdown-update-impact-stay-tuned-for-spectre/#comment-4296159
il codice è qui
https://pastebin.com/5qacGA17
Sono test sintetici (addirittura usando /dev/null per ridurre ai minimi termini l'impatto della syscall), e quindi che lasciano il tempo che trovano. Nel mondo reale l'impatto non sarà mai e poi mai così elevato.

Intanto:
Si segnalano gravi problemi su Linux Ubuntu 16.04 dopo aver applicato le relative patch di sicurezza che correggono questa falla, la macchina non parte più: :ciapet:
https://ubuntuforums.org/showthread.php?t=2382157
(https://ubuntuforums.org/showthread.php?t=2382157)
Linus dovrebbe evitare di parlare a sproposito, quando il suo s.o. ha una lunghissima lista di bug, e alcuni che vegetano pure da anni. Lui stesso s'è lamentato di quanto complesso e difficilmente gestibile sia diventato.

Per non parlare poi del fallimento di Transmeta, dove lavorava in precedenza quando realizzavano processori per competere con Intel e AMD. Forse avrebbe dovuto imparare qualcosa di come si realizzano processori, specialmente di una certa complessità.

La coerenza non sa dove stia di casa...

Concordo con le critiche di Linus.
D'altra parte tutto questo andazzo fa parte della "logica" del sistema.
Cioè di quella della ricerca esasperata delle prestazioni a scapito della solidità e della stabilità, da troppi anelata e attesa, compresi moltissimi di noi utenti, troppi dei quali vivono di novità da bruciare subito in campo Hardware e Software.
Così i produttori, in una corsa forsennata fra loro e per accontentare esigenze dell'utenza, la quale è composta anche da istituzioni, istituti di ricerca e universitari, militari e aziende, si danno da fare per sfornare le loro "meraviglie del creato".
Insomma, stiamo tutti rincorrendo i soliti "pifferai" magici che ci fanno l'occhiolino.
Ricordo la sfrenata pubblicità sulle riviste "d'epoca" di informatica del finire del 1980, quando si reclamizzavano con enfasi assurda macchine con "48 k" di Ram per svolgere i lavori dell'ufficio, con i primi computer di size "midi", figliastri dei mainframe e precursori ideali dei personal computer.
Tutta roba nostalgica finita nella spazzatura.
Ma almeno allora le CPU non avevano circuiti interni di controllo di vario livello con i ben noti MiniX e con le delizie attuali, tutta roba che per me è spazzatura.
Evidentemente non si vogliono fabbricare processori che fanno il loro lavoro onestamente, ma si cerca il pelino per dimostrare quanto valgono le lauree in ingegneria dei progettisti e fabbricanti di chip.
Una inutile narcisistica esibizione di "virtuosismo" a chi più ne ha, più ne metta.

Che poi in questo marasma qualcuno magari come NSA abbia potuto o possa inzuppare il "biscottino", a qualcuno non piace proprio come idea, e la nega, chiedendo "dimostrazioni" di fatti che stanno sotto gli occhi di tutti.
Forse per difendere a oltranza una cieca fede in qualcosa che oggi è diventata una "religione", ovvero una struttura di anelata perfezione assoluta che ci avvicina tutti agli dei, che ci fa sentire un "dio" con le dita appoggiate su una tastiera e con lo sguardo perduto nello splendore di un display luminescente.

Ma almeno 'ste CPU, le sappiamo fare in modo che nessuno ci possa ficcare dentro un codice malevolo?
Ovvero, perché una CPU deve avere perfino un "firmware" o altra robaccia del genere, da contagiare o inoculare con qualche riga di codice?

Ma allora dov'è 'sta "sicurezza" tanto bramata, come l'acqua nel deserto al viaggiatore disperso da un mese?

E che dire poi dei sistemi operativi, che in tutto ciò si affannano a dare una mano alla cara "amica" Intel, con 'ste famose "patch", che a casa mia 60 anni fa si chiamavano "le pezze al culo"?
Ma davvero vogliamo credere che non esista affatto un qualcuno "cui prodest", cioè al quale tutto questo non porti vantaggi nascosti?
Ma quanto complottismo e modestia.

Realizzatelo voi un processore moderno a elevate prestazioni. E mi raccomando: SENZA bug.

Quant'è facile aprire la bocca e parlare...

Ma almeno 'ste CPU, le sappiamo fare in modo che nessuno ci possa ficcare dentro un codice malevolo?

Domanda senza senso e che dimostra la tua ignoranza nel settore.
Nessuna CPU e' priva di bug, tanto per cominciare.

Per quanto concerne Meltdown, nessuno ficca codice malevolo. Anzi, proprio la presenza di codice che tenta di accedere ad un indirizzo di memoria riservato e' cio' che fa generare un'eccezione alla CPU, la quale fa quello che dovrebbe fare.

Ovvero, perché una CPU deve avere perfino un "firmware" o altra robaccia del genere, da contagiare o inoculare con qualche riga di codice?

Una CPU moderna ha qualche funzionalita' in piu' rispetto ad una del 1980, direi...

Ma allora dov'è 'sta "sicurezza" tanto bramata, come l'acqua nel deserto al viaggiatore disperso da un mese?

L'utente brama le prestazioni, e lo si nota ogni volta in cui viene presentata una nuova CPU, con tutti pronti a scagliarsi per un misero +5%. Per raggiungere tali prestazioni, dato che non si puo' certo stravolgere l'ISA, si cercano dei workaround. Che, ovviamente, potrebbero introdurre delle falle, anche se nel caso specifico e' davvero un estremo.

E che dire poi dei sistemi operativi, che in tutto ciò si affannano a dare una mano alla cara "amica" Intel, con 'ste famose "patch", che a casa mia 60 anni fa si chiamavano "le pezze al culo"?
Ma davvero vogliamo credere che non esista affatto un qualcuno "cui prodest", cioè al quale tutto questo non porti vantaggi nascosti?

Non sono "pezze al culo", sono, appunto, patch. Ossia, PER ME, il motivo principale per cui esistono gli aggiornamenti. E gli sviluppatori di sistemi operativi sono ben felici gli strumenti messi a disposizione dall'hardware, workaround compresi.

Per il resto, Torvalds parla giusto per elevarsi a mente superiore, come se il "suo" kernel fosse esente da bug e fosse un gioiellino di ingegneria del software. Proprio lo stesso Torvalds di Transmeta, tra l'altro.

Ma quanto complottismo e modestia.

Realizzatelo voi un processore moderno a elevate prestazioni. E mi raccomando: SENZA bug.

Quant'è facile aprire la bocca e parlare...


Capisco che in questi giorni è difficile, l'azienda che da il pane va difesa strenuamente e oltre ogni ragionevole logica.
Dici "progettatela voi senza bug".
Lo farei ma non è il mio campo, però voglio farti un esempio più attinente a quello che capisco.
Se l'ingegnere strutturista che ha progettato casa tua ti dice che la struttura è solidissima ma ci sono dei punti particolari sui pilastri che se colpiti con un martello fanno collassare l'intero edificio, cmq no problem, da un appartamento da 10000€/mq vuoi la perfezione assoluta?
E poi quel difettuccio non lo conosce nessuno, quei piccoli bugs sono potenzialmente letali ma sono bug fisiologici di una struttura complessa da 100-150 piani, chi andrà mai a dare una martellata su un muro nel corso della vita di un edificio?
Cosa gli rispondiamo?
A me risponderebbero che sono un incapace incompetente e che sono stato pagato per fare quello che ho fatto male, mica probono e sarebbe stato meglio rivolgersi ad un altro ingegnere, i difettucci sulla sicurezza non sono neanche lontanamente ammessi, figuriamoci giustificarli a spada tratta
A te cosa rispondiamo?
Che in amd sanno evidentemente lavorare meglio e che i dipendenti intel vengono pagati per fare il loro lavoro col cu...ore e senza responsabilità tanto i clienti sono solo polli da spennare?
"Eh ma ci sono miliardi di transistor"
"Eh ma non me li regali mica i processori, anzi"
Ovviamente avrai già una risposta che spiegone tuttone, ma prima di premere invio ripensa all'ingegnere che lascia bug strutturali a casa tua e se gli lasceresti mezzo centesimo e dormiresti tranquillo

Capisco che in questi giorni è difficile, l'azienda che da il pane va difesa strenuamente e oltre ogni ragionevole logica.
Dici "progettatela voi senza bug".
Lo farei ma non è il mio campo, però voglio farti un esempio più attinente a quello che capisco.
Se l'ingegnere strutturista che ha progettato casa tua ti dice che la struttura è solidissima ma ci sono dei punti particolari sui pilastri che se colpiti con un martello fanno collassare l'intero edificio, cmq no problem, da un appartamento da 10000€/mq vuoi la perfezione assoluta?
E poi quel difettuccio non lo conosce nessuno, quei piccoli bugs sono potenzialmente letali ma sono bug fisiologici di una struttura complessa da 100-150 piani, chi andrà mai a dare una martellata su un muro nel corso della vita di un edificio?
Cosa gli rispondiamo?
A me risponderebbero che sono un incapace incompetente e che sono stato pagato per fare quello che ho fatto male, mica probono e sarebbe stato meglio rivolgersi ad un altro ingegnere, i difettucci sulla sicurezza non sono neanche lontanamente ammessi, figuriamoci giustificarli a spada tratta
A te cosa rispondiamo?
Che in amd sanno evidentemente lavorare meglio e che i dipendenti intel vengono pagati per fare il loro lavoro col cu...ore e senza responsabilità tanto i clienti sono solo polli da spennare?
"Eh ma ci sono miliardi di transistor"
"Eh ma non me li regali mica i processori, anzi"
Ovviamente avrai già una risposta che spiegone tuttone, ma prima di premere invio ripensa all'ingegnere che lascia bug strutturali a casa tua e se gli lasceresti mezzo centesimo e dormiresti tranquillo
Guarda che lui non lavora piu' per Intel.

Per tutto il resto, no, non la progetteresti senza bug, cosi' come non esiste alcun software senza bug, che ti piaccia o no. Pure le CPU AMD ne hanno, quindi di che parliamo?

Tra l'altro, in questo caso (e parlo di Meltdown), non e' nemmeno veramente un bug, ad essere sinceri.

Cioe', la CPU fa quello che dicono le specifiche dell'ISA. E' a livello di micro-architettura che si utilizza un comportamento "fisiologico" per estrapolare informazioni. Ovviamente la causa e' un workaround di Intel.

Guarda che lui non lavora piu' per Intel.

Per tutto il resto, no, non la progetteresti senza bug, cosi' come non esiste alcun software senza bug, che ti piaccia o no. Pure le CPU AMD ne hanno, quindi di che parliamo?

Tra l'altro, in questo caso (e parlo di Meltdown), non e' nemmeno veramente un bug, ad essere sinceri.

Cioe', la CPU fa quello che dicono le specifiche dell'ISA. E' a livello di micro-architettura che si utilizza un comportamento "fisiologico" per estrapolare informazioni. Ovviamente la causa e' un workaround di Intel.

Impossibile da progettare senza bug?
Perché troppo complessi?
Allora quando si viene sgamati si ammettono la colpa e le responsabilità, si dichiara che si sta lavorando e lo si fa.
Difesa ad oltranza e benaltrismo sono il modo per apparire anche più colpevoli.
Ovviamente anche il danno causato va rifondato, fa parte delle responsabilità, incassare profumatamente prevede possibilità esborsi in danni altrettanto profumati, il contratto sarebbe vincolante per entrambe le parti, mica solo per chi vende.
A prescindere dal fatto che si giustifica da 20 anni la presenza, di bugs sw e hw.
E se invece di cercare sempre le patch qualcuno fosse pagato per non inserirli nemmeno?
Se non si è capaci McDonald's assume sempre cassieri

Impossibile da progettare senza bug?
Perché troppo complessi?
Allora quando si viene sgamati si ammettono la colpa e le responsabilità, si dichiara che si sta lavorando e lo si fa.
Difesa ad oltranza e benaltrismo sono il modo per apparire anche più colpevoli.
Ovviamente anche il danno causato va rifondato, fa parte delle responsabilità, incassare profumatamente prevede possibilità esborsi in danni altrettanto profumati, il contratto sarebbe vincolante per entrambe le parti, mica solo per chi vende.
A prescindere dal fatto che si giustifica da 20 anni la presenza, di bugs sw e hw.
E se invece di cercare sempre le patch qualcuno fosse pagato per non inserirli nemmeno?
Se non si è capaci McDonald's assume sempre cassieri

Non e' questione di capacita', ma ovviamente non hai idea di cosa parli.
Un software complesso ha sempre dei bug, che ti piaccia o no (e non piace a nessuno, in primis a chi sviluppa). Lo stesso vale per un componente hardware come una CPU, per cui e' praticamente impossibile effettuare dei test approfonditi che considerino TUTTE le possibilita'.

Ma tu stai dicendo che TUTTI gli sviluppatori e progettisti di componenti elettronici sono incompetenti, giusto?

Che Intel peggio e più meschinamente di così non se la potesse gestire sono d'accordo: la conferenza stampa di qualche giorno fa è stata qualcosa di indecoroso e indegno, col tentativo di dar a credere che tutti i processori di tutte le aziende (di cui han pure fatto subdolamente i nomi) siano affetti in egual misura da questi problemi.

Han lavorato bene solo al contenimento dei loro danni, diciamo, a esser garbati.

Sul resto.. bug o errori in fase di progettazione di cose così complesse come le moderne CPU non sono del tutto evitabili a priori.. c'è poco da farci.

Tra l'altro meltdown è più l'exploit di alcune soluzioni adottate dalle CPU Intel a livello di ottimizzazione interna che un bug vero e proprio.

Certo, come se la son giocata poi in Intel .. non fa molto a loro onore.

Ma parla proprio lui ?

MS ha risolto con la patch apposita, Apple agirà anch'essa di conseguenza, non capisco questo accanimento esagerato, è così per tutti, non solo per Linux.
O magari su Linux gli impatti sono maggiori ?

Inoltre è l'OS che in maniera più consistente dovrebbe adattarsi all'hardware rispetto alla situazione opposta.
Quindi non capisco per cosa si lamenta, la vulnerabilità va presa come una caratteristica delle cpu Intel e come tale deve essere adattato.

Perché se le cose stanno così, magari dovremmo cominciare a guardare più verso ARM64Con le performance che si ritrovano ... mi domando se questo individuo abbia un idea di quanto contino le performance in certi ambiti.

Inoltre cosa vorrebbe dire che guardano verso ARM ? Hanno potere politico su quali cpu far adottare dai produttori di PC e Servers ? Gli OS si devono adattare alle piattaforme in giro.

Non e' questione di capacita', ma ovviamente non hai idea di cosa parli.
Un software complesso ha sempre dei bug, che ti piaccia o no (e non piace a nessuno, in primis a chi sviluppa). Lo stesso vale per un componente hardware come una CPU, per cui e' praticamente impossibile effettuare dei test approfonditi che considerino TUTTE le possibilita'.

Ma tu stai dicendo che TUTTI gli sviluppatori e progettisti di componenti elettronici sono incompetenti, giusto?

Invece no, non hai capito il senso.
Sono d'accordo con la tesi di Intel, la CPU lavora come deve e il problema risiede proprio in questo, che sia stato su commissiine o per un semplice rapporto prestazioni/sicurezza maggiore, come ogni progetto è figlio di compromessi.

Con questa scoperta si è capito che in Intel privilegiano le prestazioni alla sicurezza al contrario degli annunci sempre fatti, se per questa loro scelta io ci perdo x% che ho pagato, loro ci devono perdere la stessa percentuale minimo, ma io aggiungerei il bonus dell'intenzionalitá, se da questo hanno tratto vantaggio sui concorrenti (se vai più forte vendi di più) ed io ho comprato la tua macchina proprio per le prestazioni abbinate alla sicurezza.
Il sunto è che a prescindere da x, y e z motivi, in Intel hanno "sbagliato" il rapporto prestazioni/sicurezza, forse andava bene per il 95 quando internet era quasi una leggenda metropolitana, nel 2017 le esigenze dicono che la loro responsabilità è totale, non esiste giustificazione che tenga al fatto che per colpa loro io ci perda soldi, non c'era alternativa, ma nel caso ci fosse stata avrei potuto comprare hw da loro e ora "guadagnerei di più", ma l'alternativa non c'era anche perché tu dicevi andare di più con la stessa sicurezza.
Dato che nel corso degli anni hanno avuto più occasioni per porre rimedio a questo livello di sicurezza inferiore (come ha fatto la concorrenza) di cui erano consci per mantenere il vantaggio prestazionale, è da andare a lavorare al McDonald's sostenere che non ci sia responsabilità e intenzionalità.

ma possibile che ogni volta si finisca in una sterile discussione sulla supremazia di qualche OS ?

Le falle Melt. e Sp. in questi giorni diventano addirittura feature, loghi da esibire sulla confezione.. mi ricorda la magia delle antenne degli iphone e degli schermi crepati/gialli.. magic features anche quelle, da prendere con filosofia chi può, chi no con religiosa colpa.

a onor del vero su windows la patch meltdown è stata applicata senza alcun criterio a tutte le macchine (causando problemi), e la stessa cosa volevano fare con il merge nel main quelli di intel.. se parliamo di potenza operativa impattata, scappa da ridere a confrontare quanti server basati su kernel linux ci siano al mondo a confronto con i rispettivi microsoft.
Torvalds fa bene ad alzare dita, e fare polemica, sopratutto se cercano di "manomettere" il kernel per coprire in fretta e furia una mancanza nella loro progettazione hw..

Adesso non resta che sedersi, e godere di tutti gli articoli trionfanti sulla patch che addirittura migliora (!!!) le prestazioni :D :D .. perché si sa che se a una macchina togli il turbo e sgonfi un poco le ruote, questa andrà più veloce :doh:

a onor del vero su windows la patch meltdown è stata applicata senza alcun criterio a tutte le macchine (causando problemi), e la stessa cosa volevano fare con il merge nel main quelli di intel.. se parliamo di potenza operativa impattata, scappa da ridere a confrontare quanti server basati su kernel linux ci siano al mondo a confronto con i rispettivi microsoft.
Torvalds fa bene ad alzare dita, e fare polemica, sopratutto se cercano di "manomettere" il kernel per coprire in fretta e furia una mancanza nella loro progettazione hw..
La patch su Windows è stata installata ma non applicata su tutte le CPU, a quanto mi è stato detto.
Lato Linux, mi domando se è Intel che realizza le proprie CPU per gli OS Linux o è il contrario ?

Mi domando anche se queste patch siano più penalizzanti per Linux rispetto a Windows o meno, e ancora non trovo risposta.

Invece no, non hai capito il senso.
Sono d'accordo con la tesi di Intel, la CPU lavora come deve e il problema risiede proprio in questo, che sia stato su commissiine o per un semplice rapporto prestazioni/sicurezza maggiore, come ogni progetto è figlio di compromessi.

Con questa scoperta si è capito che in Intel privilegiano le prestazioni alla sicurezza al contrario degli annunci sempre fatti, se per questa loro scelta io ci perdo x% che ho pagato, loro ci devono perdere la stessa percentuale minimo, ma io aggiungerei il bonus dell'intenzionalitá, se da questo hanno tratto vantaggio sui concorrenti (se vai più forte vendi di più) ed io ho comprato la tua macchina proprio per le prestazioni abbinate alla sicurezza.
Il sunto è che a prescindere da x, y e z motivi, in Intel hanno "sbagliato" il rapporto prestazioni/sicurezza, forse andava bene per il 95 quando internet era quasi una leggenda metropolitana, nel 2017 le esigenze dicono che la loro responsabilità è totale, non esiste giustificazione che tenga al fatto che per colpa loro io ci perda soldi, non c'era alternativa, ma nel caso ci fosse stata avrei potuto comprare hw da loro e ora "guadagnerei di più", ma l'alternativa non c'era anche perché tu dicevi andare di più con la stessa sicurezza.
Dato che nel corso degli anni hanno avuto più occasioni per porre rimedio a questo livello di sicurezza inferiore (come ha fatto la concorrenza) di cui erano consci per mantenere il vantaggio prestazionale, è da andare a lavorare al McDonald's sostenere che non ci sia responsabilità e intenzionalità.

Ma sono proprio gli utenti a prediligere le prestazioni (entro certi limiti, ovviamente).
L'esistenza stessa dell'esecuzione Out of Order e' dovuta alla ricerca delle prestazioni, ed e' proprio il meccanismo che e' stato sfruttato per Meltdown.

Sul fatto che Intel stia forse minimizzando troppo sono d'accordo, e sicuramente devono stare attenti a come gestiscono questa cosa.

Ma per il resto, anche l'intenzionalita' e' difficile da dimostrare proprio leggendo il paper di Meltdown: sono riusciti a sfruttare variazioni micro-architetturali per bypassare i sistemi di sicurezza della CPU la quale, ripeto, quando vede che l'istruzione MOV tenta di accedere ad un indirizzo vietato genera un'eccezione e blocca tutto. Io penso che sia sinceramente difficile anche solo immaginare l'esistenza di una falla del genere.

Tornando IT, Torvalds puo' permettersi tutte 'ste sparate proprio perche' il "suo" kernel viene scritto per buona parte dagli incompetenti.

ma possibile che ogni volta si finisca in una sterile discussione sulla supremazia di qualche OS ?

Le falle Melt. e Sp. in questi giorni diventano addirittura feature, loghi da esibire sulla confezione.. mi ricorda la magia delle antenne degli iphone e degli schermi crepati/gialli.. magic features anche quelle, da prendere con filosofia chi può, chi no con religiosa colpa.

a onor del vero su windows la patch meltdown è stata applicata senza alcun criterio a tutte le macchine (causando problemi), e la stessa cosa volevano fare con il merge nel main quelli di intel.. se parliamo di potenza operativa impattata, scappa da ridere a confrontare quanti server basati su kernel linux ci siano al mondo a confronto con i rispettivi microsoft.
Torvalds fa bene ad alzare dita, e fare polemica, sopratutto se cercano di "manomettere" il kernel per coprire in fretta e furia una mancanza nella loro progettazione hw..

Adesso non resta che sedersi, e godere di tutti gli articoli trionfanti sulla patch che addirittura migliora (!!!) le prestazioni :D :D .. perché si sa che se a una macchina togli il turbo e sgonfi un poco le ruote, questa andrà più veloce :doh:

Meltdown e' una falla, ovviamente, ma non e' un bug in senso stretto in quanto la CPU si comporta esattamente secondo le specifiche x86. Infatti non permette l'accesso a indirizzi di memoria riservati senza i giusti privilegi.

Meltdown e' una falla, ovviamente, ma non e' un bug in senso stretto in quanto la CPU si comporta esattamente secondo le specifiche x86. Infatti non permette l'accesso a indirizzi di memoria riservati senza i giusti privilegi.

questo è chiaro, un po' come scoprire oggi che aver dato l'automobile a tutti nel tempo, porti adesso al inquinamento da traffico su gomma e a migliaia di morti per incidenti stradali in più..

ripeto, il rant di Linus, è per come intel ha gestito (e sta gestendo) la patch agli OS.. a lui non proponi codice sciatto (e colpevole) da infilare notte tempore nel main, non senza che ti becchi una scudisciata in pubblico o un dito medio davanti alla stampa

Ma sono proprio gli utenti a prediligere le prestazioni (entro certi limiti, ovviamente).
L'esistenza stessa dell'esecuzione Out of Order e' dovuta alla ricerca delle prestazioni, ed e' proprio il meccanismo che e' stato sfruttato per Meltdown.

Sul fatto che Intel stia forse minimizzando troppo sono d'accordo, e sicuramente devono stare attenti a come gestiscono questa cosa.

Ma per il resto, anche l'intenzionalita' e' difficile da dimostrare proprio leggendo il paper di Meltdown: sono riusciti a sfruttare variazioni micro-architetturali per bypassare i sistemi di sicurezza della CPU la quale, ripeto, quando vede che l'istruzione MOV tenta di accedere ad un indirizzo vietato genera un'eccezione e blocca tutto. Io penso che sia sinceramente difficile anche solo immaginare l'esistenza di una falla del genere.

Tornando IT, Torvalds puo' permettersi tutte 'ste sparate proprio perche' il "suo" kernel viene scritto per buona parte dagli incompetenti.

L'intenzionalitá e dimostrata dal fatto che sapevano che la loro soluzione seppur più veloce ha sicurezza inferiore e se ne sono sbattuti, hanno preferito mantenere la soluzione più veloce.
Cosa che non ha fatto la concorrenza e su cui si sono avvantaggiato anche grazie alla soluzione meno sicura.
Come giustamente dicono, loro non potevano sapere che qualcuno prima o poi potesse immaginare un uso di questa falla tanto incredibile quanto fantasioso, la CPU lavora comunque secondo specifiche quindi non è un bug.
Devo dirti che livello di retorica ha una frase del genere?
Dovrei interpellare Junior di Dragonball Z per rendere l'idea :D

questo è chiaro, un po' come scoprire oggi che aver dato l'automobile a tutti nel tempo, porti adesso al inquinamento da traffico su gomma e a migliaia di morti per incidenti stradali in più..

ripeto, il rant di Linus, è per come intel ha gestito (e sta gestendo) la patch agli OS.. a lui non proponi codice sciatto (e colpevole) da infilare notte tempore nel main, non senza che ti becchi una scudisciata in pubblico o un dito medio davanti alla stampa
Il dito media davanti alla stampa e la sfuriata non se le può permettere LUI. Visto che le distro Linux occupano una percentuale ridicola e in più l'unica cosa che dovrebbe fare è supportare al meglio i prodotti in giro. Se quasi tutti i sistemi sono Intel dovrebbe tacere.

Da quando qualcuno ha da ridire sul fatto che un produttore si autopenalizzi ?
Se intel ti dà un codice sciatto da infilare, tu in funzione del supporto lo infili come fanno tutti e basta.

Se l'utente finale non sarà soddisfatto si ripercuoterà su Intel, quindi lui cosa centra ?

L'intenzionalitá e dimostrata dal fatto che sapevano che la loro soluzione seppur più veloce ha sicurezza inferiore e se ne sono sbattuti, hanno preferito mantenere la soluzione più veloce.
Cosa che non ha fatto la concorrenza e su cui si sono avvantaggiato anche grazie alla soluzione meno sicura.
Come giustamente dicono, loro non potevano sapere che qualcuno prima o poi potesse immaginare un uso di questa falla tanto incredibile quanto fantasioso, la CPU lavora comunque secondo specifiche quindi non è un bug.
Devo dirti che livello di retorica ha una frase del genere?
Dovrei interpellare Junior di Dragonball Z per rendere l'idea :DCi mancherebbe altro, è la stessa cosa che fan tutti, la performance prima di ogni cosa. La CPU può essere sicura quanto vuoi ma se la performance latita non interessa a quasi nessuno, anzi se esistessero CPU poco sicure ma con netti vantaggi prestazionali molti quì le preferirebbero anche accettando i termini di un contratto che non garantisce nulla.

Più o meno sicura non esiste, se ci han messo 10 anni a scovarla magari così prevedibile non era.

hai idea di quanti dispositivi facciano uso del kernel linux? mi sa di no...
dai server ai cellulari ad una miriade di altri oggettini...
Sui cellulari Android c'è Intel dietro ?
Lato server quanti a livello di % usano Linux e Intel ?

solita solfa...

Impossibile da progettare senza bug?
Perché troppo complessi?
Allora quando si viene sgamati si ammettono la colpa e le responsabilità, si dichiara che si sta lavorando e lo si fa.
Difesa ad oltranza e benaltrismo sono il modo per apparire anche più colpevoli.
Ovviamente anche il danno causato va rifondato, fa parte delle responsabilità, incassare profumatamente prevede possibilità esborsi in danni altrettanto profumati, il contratto sarebbe vincolante per entrambe le parti, mica solo per chi vende.
A prescindere dal fatto che si giustifica da 20 anni la presenza, di bugs sw e hw.
E se invece di cercare sempre le patch qualcuno fosse pagato per non inserirli nemmeno?
Se non si è capaci McDonald's assume sempre cassieri

nel mondo dell'informatica non esistono SW/HW privi di bugs. I bugs ci sono sempre, ed è per questo che si rilasciano fix con aggiornamenti vari e continui. Quelli che fanno notizia sono in primis i bugs che causano problemi ad un numero significativo di utenti, e poi quelli che non ne causano ma potrebbero causarli se sfruttati in qualche modo per aggirare la sicurezza.

la maggior parte dei bugs presenti non vengono mai scoperti e/o corretti, perchè se causano qualche problema lo fanno in una percentuale irrisioria di utenti e sistemi. Ci sono miliardi di variabili in gioco e non è possibile fare un software o un hardware privo al 100% di bugs.
E' per questo che nei sistemi più sensibili, come sugli aerei ad esempio, ci sono computers e sistemi ridondanti che si controllano a vicenda.

nessun produttore di HW/SW ha mai dichiarato di essere esente da bugs, e mai lo farà, se credevi il contrario e sei convinto di poterlo fare tu (così come si progetta un condominio :doh: ) allora fallo, se ci riuscirai diventerai l'unico produttore di SW/HW al mondo super miliardario.

Il dito media davanti alla stampa e la sfuriata non se le può permettere LUI. Visto che le distro Linux occupano una percentuale ridicola e in più l'unica cosa che dovrebbe fare è supportare al meglio i prodotti in giro. Se quasi tutti i sistemi sono Intel dovrebbe tacere.

Da quando qualcuno ha da ridire sul fatto che un produttore si autopenalizzi ?
Se intel ti dà un codice sciatto da infilare, tu lo infili come fanno tutti e basta.

Se l'utente finale non sarà soddisfatto non darà mica la colpa a Linux, quindi lui cosa centra ?

A parte le convinzioni personali, stai usando un forum che gira su kernel linux, come già avviene su 50% della rete mondiale..
Da quel che scrivi mi rendo conto che non ti è chiaro cosa sia l'albero principale del kernel, e ti invito a darci un occhio.
Il "tu lo infili e basta" non succede nemmeno nel segretissimo processo di sviluppo del kernel MS :D

A parte le convinzioni personali, stai usando un forum che gira su kernel linux, come già avviene su 50% della rete mondiale..
Da quel che scrivi mi rendo conto che non ti è chiaro cosa sia l'albero principale del kernel, e ti invito a darci un occhio.
Il "tu lo infili e basta" non succede nemmeno nel segretissimo processo di sviluppo del kernel MS :D
Succede ovunque invece, perchè è Linux che supporta i prodotti Intel e non viceversa.
Il dito lo alzi se Intel ti imponesse di inserire un codice penalizzante solo sul tuo sistema, sfortunatamente però in questo caso la situazione è così per tutti, quindi gli OS Linux based non han perso competitività nei confronti dei competitors.

Succede ovunque invece, perchè è Linux che supporta i prodotti Intel e non viceversa.
Il dito lo alzi se Intel ti imponesse di inserire un codice penalizzante solo sul tuo sistema, sfortunatamente però in questo caso la situazione è così per tutti, quindi gli OS Linux based non han perso competitività nei confronti dei competitors.

E il fatto che stia scrivendo su un server Linux in che modo dovrebbe interessarmi ?

è un opinione che linux supporti intel
Intel vuole vedere i suoi prodotti x86 ben piazzati negli ambiti a maggior guadagno, quelli server.. se domani si ritira dalla collaborazione con linux, amd si mangia tutta la fetta di mercato e poi i computer fanno quella cosa dei licenziamenti automatici :D

il dito lo alza quando il codice proposto è inadeguato, scarso, poco efficiente, di parte o addirittura inesistente.. già successo ai tempi del passaggio uefi, nessuno infiltra codice a caso per i suoi scopi, e non lo fa sopratutto se è migliorabile

è un opinione che linux supporti intel
Intel vuole vedere i suoi prodotti x86 ben piazzati negli ambiti a maggior guadagno, quelli server.. se domani si ritira dalla collaborazione con linux, amd si mangia tutta la fetta di mercato e poi i computer fanno quella cosa dei licenziamenti automatici :D

il dito lo alza quando il codice proposto è inadeguato, scarso, poco efficiente, di parte o addirittura inesistente.. già successo ai tempi del passaggio uefi, nessuno infiltra codice a caso per i suoi scopi, e non lo fa sopratutto se è migliorabile
Intel con quel codice ha penalizzato se stessa, non Linux.
Il consumatore si rivale su Intel, non ha quindi conseguenze su Linux.

Ma quale fetta ? Intel vanta i prodotti migliori e la performance / watt vince su quasi tutto lato server negli ambiti in cui sono usate questo tipo di CPU, supponendo che dalla prossima generazione Intel avrà chiuso questa vulnerabilità, non esiste proprio che AMD si mangi quella fetta.

Collaborazione di Linux ? In cosa consisterebbe ?
Se consiste che Intel collabora con Linux affinchè il supporto al nuovo prodotto sia ottimale, cosa cambierebbe ?

Intel con quel codice ha penalizzato se stessa, non Linux.
Il consumatore si rivale su Intel, non ha quindi conseguenze su Linux.

Ma quale fetta ? Intel vanta i prodotti migliori e la performance / watt vince su quasi tutto lato server negli ambiti in cui sono usate questo tipo di CPU, supponendo che dalla prossima generazione Intel avrà chiuso questa vulnerabilità, non esiste proprio che AMD si mangi quella fetta.

Collaborazione di Linux ? In cosa consisterebbe ?
Se consiste che Intel collabora con Linux affinchè il supporto al nuovo prodotto sia ottimale, cosa cambierebbe ?

rileggi

...con l'analisi fatta dal Dr. Di Mauro...
Linus dovrebbe evitare di parlare a sproposito, quando il suo s.o. ha una lunghissima lista di bug, e alcuni che vegetano pure da anni. Lui stesso s'è lamentato di quanto complesso e difficilmente gestibile sia diventato.

Per non parlare poi del fallimento di Transmeta, dove lavorava in precedenza quando realizzavano processori per competere con Intel e AMD. Forse avrebbe dovuto imparare qualcosa di come si realizzano processori, specialmente di una certa complessità.

La coerenza non sa dove stia di casa... .
Torvalds non si ricorda (?) dei grossissimi problemi di quando ancora studente (è un mio coetaneo e lo seguivo già all'epoca dal centro di calcolo di ingegneria a Pisa) stava muovendo i primissi passi studiando l'architettura 80386 e la sua "modalità protetta"...
Torvalds dovrebbe sapere (?) che è impossibile per l'umana mente progettare sistemi complessi privi da subito di errori, deviazioni dalle specifiche nominali...o forse non lo sa per avere più una mente da informatico puro che crede troppo spesso di poter porre rimedio a tutto modificando "qualche linea di codice" che non quella da fisico oppure ingegnere che si "sporca le mani" con i limiti reali e fisici ?

Impossibile da progettare senza bug?
Perché troppo complessi?
Esattamente è così...oltre una certa complessità (misurabile secondo il numero di transistor integrati, secondo il numero di unità e sottounità integrate ecc.) non pensare nemmeno di ottenere una cpu ovvero una enorme macchina a stati finiti priva di errata...nemmeno AMD ne ha mai prodotte esenti da ciò...nemmeno ARM...e neppure le defunte implementazioni microarchitetturali MIPS, SPARC ecc. ecc.

Marco71.

Capisco che in questi giorni è difficile, l'azienda che da il pane va difesa strenuamente e oltre ogni ragionevole logica.
Dici "progettatela voi senza bug".
Lo farei ma non è il mio campo, però voglio farti un esempio più attinente a quello che capisco.

...dimmi, come intenderesti procede nel caso...se fosse il tuo settore.
Forse in termini di complessità è più "complesso" progettare una enorme macchina a stati finiti che non potrà (finché il santo Graal del mondo quantico almeno non sarà fruibile e pubblicamente da tutti oltre che avere esso stesso una certa "pontenza" computazionale dimostrata) ma essere formalmente provata in modo esaustivo ovvero una cpu "moderna" che non un ponte od una casa.

Marco71.

...Ma tu stai dicendo che TUTTI gli sviluppatori e progettisti di componenti elettronici sono incompetenti, giusto? ...
...sì lo afferma tra le righe in modo più o meno celato.
Rivendicando la presunta superiorità di certa parte dell'ingegneria di produrre sistemi fisici completi "progettati a regola d'arte" senza errori di progetto ovvero devianze dalle specifiche nominali iniziali.

Marco71.

...che le doglianze provengano e vengano così energicamente esternate essendo al corrente benissimo del fatto che nonostante la "miriade" di programmatori, sviluppatori ecc. sotto il Suo coordinamento nemmeno oggi nel 2018 si sia riusciti nell'intento di progettare nemmeno il solo nucleo di sistema operativo "perfetto" in modo "autentico".

Marco71.

...mi sono sbagliato...Torvalds è coevo...ma è del 1969.

Marco1971.

Vai Linus, spacca tutto...
A Nvidia li ha fatti neri, a quelli di openSuse ancora gli fischiano le orecchie, a Intel gli sparerebbe...

Il Vittorio Sgarbi Finnico

Capre, Capre, Capre... :asd:

:D

Sono test sintetici (addirittura usando /dev/null per ridurre ai minimi termini l'impatto della syscall), e quindi che lasciano il tempo che trovano. Nel mondo reale l'impatto non sarà mai e poi mai così elevato.

Intanto:

Linus dovrebbe evitare di parlare a sproposito, quando il suo s.o. ha una lunghissima lista di bug, e alcuni che vegetano pure da anni. Lui stesso s'è lamentato di quanto complesso e difficilmente gestibile sia diventato.

Per non parlare poi del fallimento di Transmeta, dove lavorava in precedenza quando realizzavano processori per competere con Intel e AMD. Forse avrebbe dovuto imparare qualcosa di come si realizzano processori, specialmente di una certa complessità.

La coerenza non sa dove stia di casa...

concordo sul discorso "dove sta andando linux",...
non piace piu tanto neanche a me.. tra systemd e glitch grafici un po' troppo frequenti... mi sa che migro il pc domestico a FreeBSD 11 :read:

Domanda senza senso e che dimostra la tua ignoranza nel settore.
Nessuna CPU e' priva di bug, tanto per cominciare.

Per quanto concerne Meltdown, nessuno ficca codice malevolo. Anzi, proprio la presenza di codice che tenta di accedere ad un indirizzo di memoria riservato e' cio' che fa generare un'eccezione alla CPU, la quale fa quello che dovrebbe fare.

Una CPU moderna ha qualche funzionalita' in piu' rispetto ad una del 1980, direi...

L'utente brama le prestazioni, e lo si nota ogni volta in cui viene presentata una nuova CPU, con tutti pronti a scagliarsi per un misero +5%. Per raggiungere tali prestazioni, dato che non si puo' certo stravolgere l'ISA, si cercano dei workaround. Che, ovviamente, potrebbero introdurre delle falle, anche se nel caso specifico e' davvero un estremo.


Non sono "pezze al culo", sono, appunto, patch. Ossia, PER ME, il motivo principale per cui esistono gli aggiornamenti. E gli sviluppatori di sistemi operativi sono ben felici gli strumenti messi a disposizione dall'hardware, workaround compresi.

Per il resto, Torvalds parla giusto per elevarsi a mente superiore, come se il "suo" kernel fosse esente da bug e fosse un gioiellino di ingegneria del software. Proprio lo stesso Torvalds di Transmeta, tra l'altro.
concordo :O

Capisco che in questi giorni è difficile, l'azienda che da il pane va difesa strenuamente e oltre ogni ragionevole logica.
Premesso che, come ti hanno già detto, non lavoro più alla Intel da più di un anno, se proprio vogliamo parlare di logica, la tua si configura come la classica fallacia logica dell'Attacco Ad Hominem (https://www.linux.it/~della/fallacies/ad-hominem.html).

Ma tranquillo: è roba piuttosto comunque nell'era dei tuttologi internettiani.

D'altra parte la logica mica la vendono al mercato...
Dici "progettatela voi senza bug".
Lo farei ma non è il mio campo,
Su questo non c'erano proprio dubbi.

Sempre nell'era internettiana non è affatto difficile trovare i famigerati tuttologici di cui sopra, che hanno letto da qualche parte che il pane si fa col grano, e con questo vorrebbero insegnare il mestiere al panettiere...
però voglio farti un esempio più attinente a quello che capisco.
Se l'ingegnere strutturista che ha progettato casa tua ti dice che la struttura è solidissima ma ci sono dei punti particolari sui pilastri che se colpiti con un martello fanno collassare l'intero edificio, cmq no problem, da un appartamento da 10000€/mq vuoi la perfezione assoluta?
E poi quel difettuccio non lo conosce nessuno, quei piccoli bugs sono potenzialmente letali ma sono bug fisiologici di una struttura complessa da 100-150 piani, chi andrà mai a dare una martellata su un muro nel corso della vita di un edificio?
Cosa gli rispondiamo?
A me risponderebbero che sono un incapace incompetente e che sono stato pagato per fare quello che ho fatto male, mica probono e sarebbe stato meglio rivolgersi ad un altro ingegnere, i difettucci sulla sicurezza non sono neanche lontanamente ammessi, figuriamoci giustificarli a spada tratta
E' un esempio che non calza assolutamente, e questo proprio perché non sei del mestiere.

Tutto ciò che attiene alla computazione trova le fondamenta nella famigerata Teoria della Computabilità. Fra i vari teoremi che (per chi non è passato troppo velocemente dalla zappa alla tastiera, ovviamente) sono ben noti nonché studiati) c'è il famigerato problema dell'arresto (https://it.wikipedia.org/wiki/Problema_della_terminazione), le cui implicazioni sono pratiche sono, purtroppo, quelle che sono state già descritte da altri (GTKM e l'ing. Marco71).

Ora, a meno che tu non abbia deciso di rivoluzione la matematica (perché l'informatica ne è una branca) E avendo tu stesso affermato di non essere del mestiere, dovresti evitare di immischiarti in questioni che non ti sono e non ti possono essere affini, e lasciare dunque a chi, invece, lo è, del mestiere, di spiegare come funziona il mondo della computazione (hardware e software).

Ma se, invece, pretendi di continuare a discettare, allora vuol dire che ci troviamo di fronte alla prossima Medaglia Fields (https://it.wikipedia.org/wiki/Medaglia_Fields) (se il nickname risultasse veritiero), e quindi ti chiederei la cortesia di fornire una tua DIMOSTRAZIONE che sia possibile costruire processori (o scrivere software, che soffre delle stesse, identiche, problematiche riguardo alla computabilità) che il problema dell'arresto non sia vero, e dunque che sì: è possibile stabilire se un algoritmo abbia o meno bug ("si arresti o meno", nel contesto del teorema).
A te cosa rispondiamo?
Che in amd sanno evidentemente lavorare meglio e che i dipendenti intel vengono pagati per fare il loro lavoro col cu...ore
Quindi AMD produce processori senza bug? Spectre l'hai sentito nominare? E il famigerato bug del segmentation fault?

Ma, soprattutto, la domanda nasce spontanea a questo punto: hai mai aperto un errata di AMD?
e senza responsabilità
Ah, ma questo è vero: alla Intel i dipendenti fanno quello che vogliono. "Si sa". Nessuno ha responsabilità...
tanto i clienti sono solo polli da spennare?
Anche questo è senz'altro vero. E' ben noto che AMD, invece, è una ONLUS.
"Eh ma ci sono miliardi di transistor"
Già. Ineluttabile verità.
"Eh ma non me li regali mica i processori, anzi"
?
Ovviamente avrai già una risposta che spiegone tuttone,
Più che altro ho già fornito ampiamente spiegazioni perché certe cose DEVO saperle, visto che a differenza di te non ho passato il tempo a costruire la torre di Hanoi coi sassolini, ma ho dovuto studiare e portarmi a casa la laurea e l'esperienza in questo campo.

Comunque anche altri, anch'essi in condizioni simili alla mia, ti hanno già risposto. Poi che tu NON voglia capire, o perché ti mancano le basi, o perché sei entrato in modalità orecchie tappate, è anch'esso evidente.
ma prima di premere invio ripensa all'ingegnere che lascia bug strutturali a casa tua e se gli lasceresti mezzo centesimo e dormiresti tranquillo
Non ho bisogno di pensare a quell'ingegnere perché, come già detto, il tuo esempio non c'entra proprio niente ed è del tutto inapplicabile alla computazione.

Ma ribadisco: sei ancora in tempo per la prossima Medaglia Fields.

Nel frattempo preparo il tappeto rosso da metterti davanti al genio che distruggerà le basi della computazione...

......
...sì lo afferma tra le righe in modo più o meno celato.
Rivendicando la presunta superiorità di certa parte dell'ingegneria di produrre sistemi fisici completi "progettati a regola d'arte" senza errori di progetto ovvero devianze dalle specifiche nominali iniziali.

Marco71.

Chiaro, con gli estratti e senza manco leggere tutto può sembrare che sia così.
Ma rileggi bene e rileggi tutto.
Il problema è nell'interpretazione della situazione.
Questo non è un bug, ma una falla lasciata lì per trarre vantaggio.
Bug=errore, qui è una scelta progettuale.
Ma forse un non ingegnere non riesce a cogliere la sottile differenza tra le due cose.
La superiorità di una categoria rispetto all'altra forse la suppone chi vuole sentirsi inferiore, il discorso è totalmente diverso.
Ma voi siete gli esperti, io do un parere da chi i processori li compra e pretende che il prodotto sia buono quanto i soldi che vengono dati in cambio, chi sarò mai... ;)

.

Non ho bisogno di pensare a quell'ingegnere perché, come già detto, il tuo esempio non c'entra proprio niente ed è del tutto inapplicabile alla computazione.

.

Anche per te la differenza tra un limite minimo di sicurezza determinato a monte e un errore "casuale" è la stessa cosa?
Hai ragione, l'esempio dell'ingegnere è inadatto, dovrei passare a Mario che ha x mele e Filippo che ha y pere.
L'intenzionalitá è stata ammessa quando hanno detto che la CPU non ha bug perché lavora secondo le specifiche.
Sono le specifiche che sono state poste più in basso.
Ma vanno più forti della concorrenza
Ma chi non progetta CPU muto deve stare, deve solo sganciare all'occorrenza ;)
Editato: purtroppo avendo solo cpu Intel non posso lamentarmi con AMD dei suoi bug, ma quando ryzen che ho preso a mio padre all'ultima tornata avrà problemi lo farò.
Io tifo per il rapporto prezzo/prestazioni del mio portafoglio non per la squadra del cuore.
Difendere a spada tratta anche se non ti pagano più è anche più grave.

Chiaro, con gli estratti e senza manco leggere tutto può sembrare che sia così.
Ma rileggi bene e rileggi tutto.
Il problema è nell'interpretazione della situazione.
Questo non è un bug, ma una falla lasciata lì per trarre vantaggio.
Bug=errore, qui è una scelta progettuale.
Ma forse un non ingegnere non riesce a cogliere la sottile differenza tra le due cose.
La superiorità di una categoria rispetto all'altra forse la suppone chi vuole sentirsi inferiore, il discorso è totalmente diverso.
Ma voi siete gli esperti, io do un parere da chi i processori li compra e pretende che il prodotto sia buono quanto i soldi che vengono dati in cambio, chi sarò mai... ;)
guarda non e' proprio possibile scrivere sw o progettare complesse reti logiche (che stanno a capo delle mobo e dei proci) in cui non sia possibile forzare dei bug...
si possono mitigare (come infatti fanno i registri tipo EAP), ma se un buffer va in overflow, la parte restante che non e' stata processata dallo heap incriminato va ad infilarsi nell'IP (registro dedito all'esecuzione del codice asm), colla conseguenza che quel codice verra' eseguito...

questo bug (chiamiamolo cosi ma in realta' non lo e') non lo puoi sconfiggere...
ecco perche', come da esempio, non e' proprio possibile produrre una cpu esente da bug... a meno che non mitighi (EAP).. ma se mitighi introduci nuovi bugs... magari meno gravi, ma sembre bugs trattasi :read:

...sono laureato in ingegneria elettronica e "bazzico" materia di microprocessori dal 1978 quando avevo 7 anni...

Marco71.

...questo Questo non è un bug, ma una falla lasciata lì per trarre vantaggio..

Marco71.

...questo .

Marco71.

Un certo meltdown che approfitta di una SCELTA progettuale più prestazionale implementata da intel e che non impatta sulla scelta meno prestazionale implementata da AMD non è sufficiente?
Cercate in tutti i modi di travisare le mie parole per farmi ammettere che do degli incompetenti agli ingegneri Intel, ma in realtà siete voi a farlo dicendo che non è una cosa "voluta".
Continuo a confermare che gli ingegneri Intel hanno fatto perfettamente il loro lavoro, ma avevano obiettivi diversi da quelli che credete voi.
Ripeto, considerare una scelta progettuale che prevede un determinato rapporto prestazione/sicurezza come un errore "casuale" (o forse si dovrebbe definire errore statistico , non so) è fare retorica e far passare gli ingegneri per incapaci

Impossibile da progettare senza bug?
Perché troppo complessi?
Sì.
Allora quando si viene sgamati si ammettono la colpa e le responsabilità, si dichiara che si sta lavorando e lo si fa.
E perché dovrebbero farlo? La CPU, come peraltro TU STESSO hai ammesso dopo, lavorano secondo le specifiche.
Difesa ad oltranza e benaltrismo sono il modo per apparire anche più colpevoli.
T'assicuro che è molto peggio l'ignoranza generalizzata di cui è unta e bisunta l'era internettiana dei tuttologi che pontificano a destra e a manca senza avere la minima idea di quello che dicono.
Ovviamente anche il danno causato va rifondato, fa parte delle responsabilità, incassare profumatamente prevede possibilità esborsi in danni altrettanto profumati, il contratto sarebbe vincolante per entrambe le parti, mica solo per chi vende.
Dimmi un po', il contratto cosa direbbe?
A prescindere dal fatto che si giustifica da 20 anni la presenza, di bugs sw e hw.
Mi pare ovvio. Per chi è del settore, ovviamente. Gli altri continuano a costruire torri di Hanoi coi sassolini.
E se invece di cercare sempre le patch qualcuno fosse pagato per non inserirli nemmeno?
Ed ecco l'altro male che abbonda e ammorba l'era internettiana: il complottismo.

Non ti fai mancare nulla, eh!
Se non si è capaci McDonald's assume sempre cassieri
Meglio starne alla larga: con questa mentalità potresti far danni anche lì.
Invece no, non hai capito il senso.
Sono d'accordo con la tesi di Intel, la CPU lavora come deve e il problema risiede proprio in questo, che sia stato su commissiine
Prove che sia andata così ne hai?

Ah, già, scusami: nell'era internettiana le prove non servono: i sospetti e la fantasia galoppante sono più che sufficienti per inchiodare chiunque.
o per un semplice rapporto prestazioni/sicurezza maggiore, come ogni progetto è figlio di compromessi.
In tal caso dovrebbero essere i ricercatori di sicurezza a dover andare a lavorare da McDonald's, visto in più di 10 (DIECI) anni non si sono accorti dei problemi.

E bada bene che parlo al PLURALE, visto che le vulnerabilità sono diverse, e affliggono anche gli altri produttori di CPU. Ma ovviamente a te questo non interessa: l'UNICA che dev'essere messa in croce è Intel.
Con questa scoperta si è capito che in Intel privilegiano le prestazioni alla sicurezza al contrario degli annunci sempre fatti, se per questa loro scelta io ci perdo x% che ho pagato, loro ci devono perdere la stessa percentuale minimo, ma io aggiungerei il bonus dell'intenzionalitá, se da questo hanno tratto vantaggio sui concorrenti (se vai più forte vendi di più) ed io ho comprato la tua macchina proprio per le prestazioni abbinate alla sicurezza.
Il sunto è che a prescindere da x, y e z motivi, in Intel hanno "sbagliato" il rapporto prestazioni/sicurezza, forse andava bene per il 95 quando internet era quasi una leggenda metropolitana, nel 2017 le esigenze dicono che la loro responsabilità è totale, non esiste giustificazione che tenga al fatto che per colpa loro io ci perda soldi, non c'era alternativa, ma nel caso ci fosse stata avrei potuto comprare hw da loro e ora "guadagnerei di più", ma l'alternativa non c'era anche perché tu dicevi andare di più con la stessa sicurezza.
Dato che nel corso degli anni hanno avuto più occasioni per porre rimedio a questo livello di sicurezza inferiore (come ha fatto la concorrenza) di cui erano consci per mantenere il vantaggio prestazionale, è da andare a lavorare al McDonald's sostenere che non ci sia responsabilità e intenzionalità.
Questo nemmeno lo commento, perché è un puro concentrato di ignoranza e complottismo da due soldi, di cui purtroppo è ammorbata l'era internettiana.

Ed è inutile chiedere prove per le ragioni che ho esposto.
L'intenzionalitá e dimostrata dal fatto che sapevano che la loro soluzione seppur più veloce ha sicurezza inferiore e se ne sono sbattuti, hanno preferito mantenere la soluzione più veloce.
Lo sapevano loro, oppure lo sa solo un Juanito.82 qualunque e qualunquista internettiano?
Cosa che non ha fatto la concorrenza e su cui si sono avvantaggiato anche grazie alla soluzione meno sicura.
Come giustamente dicono, loro non potevano sapere che qualcuno prima o poi potesse immaginare un uso di questa falla tanto incredibile quanto fantasioso, la CPU lavora comunque secondo specifiche quindi non è un bug.
Devo dirti che livello di retorica ha una frase del genere?
Dovrei interpellare Junior di Dragonball Z per rendere l'idea :D
Sarebbe sufficiente interpellare chi ti ha dato quella roba scarsa.

Chiaro, con gli estratti e senza manco leggere tutto può sembrare che sia così.
Ma rileggi bene e rileggi tutto.
Il problema è nell'interpretazione della situazione.
Questo non è un bug, ma una falla lasciata lì per trarre vantaggio.
Dimostralo, come ti è stato già chiesto. Altrimenti sei un bugiardo e un pubblico mentitore.
Bug=errore, qui è una scelta progettuale.
Ma forse un non ingegnere non riesce a cogliere la sottile differenza tra le due cose.
Non serve un ingegnere, ma le PROVE che dimostrino che sia una scelta progettuale.

Finora a parte una colossale valanga di stupidaggini, non hai portato assolutamente nulla di concreto: soltanto il frutto della tua immaginazione.
La superiorità di una categoria rispetto all'altra forse la suppone chi vuole sentirsi inferiore, il discorso è totalmente diverso.
Ma voi siete gli esperti, io do un parere da chi i processori li compra e pretende che il prodotto sia buono quanto i soldi che vengono dati in cambio, chi sarò mai... ;)
Ma guarda che si vede proprio che sei limitato al solo acquisto dei processori: su questo penso che qui nessuno ha dubbi.
Anche per te la differenza tra un limite minimo di sicurezza determinato a monte e un errore "casuale" è la stessa cosa?
Hai ragione, l'esempio dell'ingegnere è inadatto, dovrei passare a Mario che ha x mele e Filippo che ha y pere.
Allora, visto che la metti in questi termini tirando in ballo a sproposito titoli di ingegneri et similia, passiamo alla dimostrazione di quanta ignoranza stai vomitando.

Hai parlato di "limite minimo di sicurezza". Bene, DEFINISCI FORMALMENTE (quindi IN MANIERA OGGETTIVA / INCONTROVERTIBILE):
- cosa s'intende per "sicurezza" (e quindi per sistema "sicuro");
- una metrica che consenta di misurare il livello di "sicurezza" di un sistema;
- quali limiti sono raggiungibili da tale metrica, e dunque quale dovrebbe essere questo "minimo".

Questo così, tanto per cominciare: è l'antipasto.

Se riesci a sopravvivere a questo (cosa di cui dubito fortemente, perché altrimenti ci sarebbe la rivoluzione di cui parlavo negli altri commenti, visto che tutte le problematiche di questo tipo si riconducono allo stesso problema di cui ho portato le fonti prima), poi dovresti anche dirci:
- chi l'avrebbe determinato;
- cosa intendi per "a monte".
L'intenzionalitá è stata ammessa quando hanno detto che la CPU non ha bug perché lavora secondo le specifiche.
Questa sono le tipiche "deduzioni" di cui è, purtroppo, celebre travaglio, che però sono affette da evidenti carenze logiche. Infatti è una commistione indigesta di un paio di fallacie logiche: dello Spaventapasseri (https://www.linux.it/~della/fallacies/spaventapasseri.html) e Causa discutibile (https://www.linux.it/~della/fallacies/causa-discutibile.html).

Se è roba troppo raffinata, passiamo a qualcosa di più bovino, più rozzo: la prima affermazione NON è conseguenza della seconda.

A meno che, ovviamente, non lo DIMOSTRI.
Sono le specifiche che sono state poste più in basso.
Ah, sì? E mi faresti vedere allora cosa ci sarebbe di sbagliato in queste specifiche? Prendi pure il manuale delle architetture x86/x64, che puoi scaricare sia dal sito di Intel sia da quello di AMD, e fammi pure vedere dove e perché sarebbe state "poste più in basso".
Ma vanno più forti della concorrenza
Ma chi non progetta CPU muto deve stare, deve solo sganciare all'occorrenza ;)
Io non progetto CPU, ma parlo lo stesso. Quindi, come vedi, NON è condizione necessaria saper progettare CPU.

E', piuttosto, condizione sufficiente conoscere come funzionano le CPU, per discutere di questi argomenti.

In ogni caso, sì: chi non ci rientra farebbe bene rimanere in silenzio, perché altrimenti correrebbe il serio rischio di proferire bestialità a carrettate, come hai fatto finora tu.
Editato: purtroppo avendo solo cpu Intel non posso lamentarmi con AMD dei suoi bug, ma quando ryzen che ho preso a mio padre all'ultima tornata avrà problemi lo farò.
Anche i Ryzen sono affetti da alcune di queste vulnerabilità.
Io tifo per il rapporto prezzo/prestazioni del mio portafoglio non per la squadra del cuore.
Difendere a spada tratta anche se non ti pagano più è anche più grave.
Io difendo la conoscenza: quella che ti manca del tutto, come hai ampiamente dimostrato.

Per il resto, hai tirato fuori nuovamente l'attacco ad hominem: ma le adori proprio le fallacie logiche, eh!
Un certo meltdown che approfitta di una SCELTA progettuale più prestazionale implementata da intel e che non impatta sulla scelta meno prestazionale implementata da AMD non è sufficiente?
Direi proprio di no. A meno che non DIMOSTRI (lo so: non faccio altro che ripeterlo. Ma che ci vuoi fare: la mia laurea me la sono sudata, e ne ho dovute fornire parecchie di dimostrazioni. Mica passavo il tempo a scaldare i banchi) che sia stata volutamente sacrificata la "sicurezza" (notare le virgolette). E ovviamente dovresti dire pure in che modo.
Cercate in tutti i modi di travisare le mie parole per farmi ammettere che do degli incompetenti agli ingegneri Intel, ma in realtà siete voi a farlo dicendo che non è una cosa "voluta".
No, no, guarda la questione è chiarissima: non sei tu che dai degli incompetenti agli ingegneri Intel, dicendogli di andare a lavorare da McDonald's. Sia mai che questo significhi dargli degli incompetenti, eh! Questa deduzione è solo frutto dell'immaginazione di chi legge, mistificando, quello che hai scritto.

Sei semplicemente tu che hai dimostrato pienamente di essere totalmente incompetente in materia, visto che continui a snocciolare autentiche bestialità.
Continuo a confermare che gli ingegneri Intel hanno fatto perfettamente il loro lavoro, ma avevano obiettivi diversi da quelli che credete voi.
E visto che ci siamo, ormai facciamola completa: quali sarebbero stati questi obiettivi?
Ripeto, considerare una scelta progettuale che prevede un determinato rapporto prestazione/sicurezza come un errore "casuale" (o forse si dovrebbe definire errore statistico , non so) è fare retorica e far passare gli ingegneri per incapaci
Tranquillo: chi è incapace l'abbiamo già capito da un pezzo.

Poi se il genio incompreso delle CPU si degnerà di definire in maniera formale questo famigerato "rapporto prestazione/sicurezza", come da precedente richiesta, magari potremo finalmente cominciare a discutere di qualcosa di concreto, e non delle fantasie sfrenate del tipico tuttologo internettiano.

Che Intel peggio e più meschinamente di così non se la potesse gestire sono d'accordo: la conferenza stampa di qualche giorno fa è stata qualcosa di indecoroso e indegno, col tentativo di dar a credere che tutti i processori di tutte le aziende (di cui han pure fatto subdolamente i nomi) siano affetti in egual misura da questi problemi.
Non mi pare che abbia detto così, quanto che tutte le aziende hanno problemi. Il che è corretto.
Han lavorato bene solo al contenimento dei loro danni, diciamo, a esser garbati.
Beh, mi pare ovvio: che t'aspettavi da loro? :D
Sul resto.. bug o errori in fase di progettazione di cose così complesse come le moderne CPU non sono del tutto evitabili a priori.. c'è poco da farci.

Tra l'altro meltdown è più l'exploit di alcune soluzioni adottate dalle CPU Intel a livello di ottimizzazione interna che un bug vero e proprio.
*
Certo, come se la son giocata poi in Intel .. non fa molto a loro onore.
Più che altro dovrebbero rilasciare aggiornamenti anche per i processori più vecchi. Difendersi pubblicamente è ovvio, ma Intel è famosa per la massiccia campagna di richiamo dei Pentium a causa del famigerato bug della divisione (cosa che nessun'altra azienda mi pare abbia fatto. Nemmeno AMD quando i Phenom avevano problemi con la cache L2 che poteva portare a corrompere i dati, o i recenti Ryzen che andavano in segmentation fault), e dunque per una questione di immagine -> solidità dei suoi prodotti, mi aspetterei il supporto anche per i processori più datati.

concordo sul discorso "dove sta andando linux",...
non piace piu tanto neanche a me.. tra systemd e glitch grafici un po' troppo frequenti... mi sa che migro il pc domestico a FreeBSD 11 :read:
Prima riferivo alla complessità di Linux. Personalmente uso systemd e mi trovo bene. :D

Anzi, la maggior parte del codice che ho scritto finora è basato proprio sull'utilizzo dei dati provenienti principalmente da systemd (opportunamente patchato). :fagiano:

D'altra parte, e come ho già chiesto altre volte, non mi pare che esista un progetto / macro-package di componenti che riesca a sostituire TUTTE le funzionalità di systemd.

Riguardo ai glitch grafici, immagino che ti riferisca all'arrivo di Wayland. Anche questa è una cosa che mi piace, perché ho sempre trovato ridicolo X11 & co. :D

/OT

La critica alla patch di Intel ci sta tutta. E' tutto il resto che poteva tranquillamente risparmiarsi, ma sappiamo che Torvalds è avvezzo alle sue sfuriate e/o sparate (come nel caso specifico, dove parla a sproposito di CPL: evidentemente non ha idea di come funzionino gli attacchi "side channel").

... Ci sono anche le parac*late dei PR, a me sembra lecito che le abbia criticate...

IMHO non credo che LT sia ignorante rispetto ad alcunché quando si parla di funzionamento di una CPU.

A me sembra che Torvalds debba partire da una critica "giusta" per poi spalare mer*a su tutti elevandosi a mente superiore.

Non mi pare che in Transmeta abbia fatto il botto, e il suo kernel viene attivamente sviluppato interamente da altri. E' uno Stallman senza l'ideologia ormai.

illuminatemi

https://www.darknet.org.uk/2007/07/intel-core-2-duo-vulnerabilities-serious-say-theo-de-raadt/

è in qualche modo riconducibile a queste problematiche?

Non mi pare che in Transmeta abbia fatto il botto, e il suo kernel viene attivamente sviluppato interamente da altri. E' uno Stallman senza l'ideologia ormai.

E` esattamente quello che penso, il kernel Linux prima che ci mettessero mano IBM, Intel, AMD & c era solo un "giocattolo", quindi il signorino dovrebbe abbassare un po' la cresta ed essere ben lieto che questi big si abbassano ad aggiustare i suoi "casini".

Se IBM, Intel e AMD si mettessero a fare Pull Request ai sorgenti di Cosmos io mi toglierei tanto di cappellino altro che :D

Nei fatti del progetto Linus Torvalds ha perso il controllo da tempo, fa queste "sparate", ma nessuno se lo c*ga più :D

Non crederete mica che Google, IBM, Intel e Microsoft nei loro server usano davvero il kernel alla "vaniglia" vero?

Prima riferivo alla complessità di Linux. Personalmente uso systemd e mi trovo bene. :D

Anzi, la maggior parte del codice che ho scritto finora è basato proprio sull'utilizzo dei dati provenienti principalmente da systemd (opportunamente patchato). :fagiano:

D'altra parte, e come ho già chiesto altre volte, non mi pare che esista un progetto / macro-package di componenti che riesca a sostituire TUTTE le funzionalità di systemd.

Riguardo ai glitch grafici, immagino che ti riferisca all'arrivo di Wayland. Anche questa è una cosa che mi piace, perché ho sempre trovato ridicolo X11 & co. :D

/OT
che te devo dire... sicuramente e' comodo per chi ha bisogno di controllare i servizi.. io pero' preferisco SysV.. tutti i cgroups montati in automatico... non me piacciono per niente :stordita:
i glitch si, probabilmente dipendono dalle nuove librerie, anche se su stretch non ho ancora installato nulla.. comunque freebsd mi pare meno glitchosa della debian...per ora mi soddisfa :ciapet:

Non crederete mica che Google, IBM, Intel e Microsoft nei loro server usano davvero il kernel alla "vaniglia" vero?

non sono informato ma non sarebbe strano. più che altro col kernel linux è possibile farlo

ps: la mailing list non riesco più ad aprirla, o ci sono godzilioni di lurkers che incartano il server, o hanno chiuso ai 'guest' :D

Dimostralo, come ti è stato già chiesto. Altrimenti sei un bugiardo e un pubblico mentitore.

Non serve un ingegnere, ma le PROVE che dimostrino che sia una scelta progettuale.



cioè mi chiedi di dimostrare qulcosa che non sei in grado di dimostrare manco tu?
a sapere i segreti industriali di intel la prima cosa che farei è mandare una mail ai cinesi di via.
ovviamente se ti chiedo di dimostrare che non è intenzionale non puoi farlo neanche tu, la retorica delle dichiarazioni intel viene abbracciata con trasporto anche dai suoi exdipendenti a quanto pare.
non credo nell'intenzionalità dovuti a finanziamnti di qualcun (tipo NSA, e questo sarebbe complottismo e tuttologia come ti piace continuamente dire) ma nella scelta progettuale.
non è dimostrabile, ma il fatto che AMD utilizzava la stessa soluzione e ad un certo punto l'ha modificata per inserire un passaggio in più quando c'è un cambio di privilegi che non permette di andare avanti (o qualcosa del genere, i paper dovresti capirli meglio tu) per me è sufficiente.
sono tuttologo, le tue nondimostrazioni valgono tanto quanto le mie.
poi un tempo c'era un paper risalente al 2007 che parlava di criticità dell'istruzione OoO, però hai già ampiamente detto che per te non è valida e che parla di altro, giustamente, non c'è scritto meltdown ma "criticità di istruzione", viene comunicata e 10 anni dopo qualcuno ha usato proprio quella criticità per notare degli effetti per niente desiderati.
due cose totalmente diverse e sconnesse.
bugiardo e pubblico mentitore perchè la mia deduzione non ti piace?
azz...
io ho riscaldato i banchi, ma qualcuno non è andato oltre la scuola dell'obbligo...


Allora, visto che la metti in questi termini tirando in ballo a sproposito titoli di ingegneri et similia, passiamo alla dimostrazione di quanta ignoranza stai vomitando.

Hai parlato di "limite minimo di sicurezza". Bene, DEFINISCI FORMALMENTE (quindi IN MANIERA OGGETTIVA / INCONTROVERTIBILE):
- cosa s'intende per "sicurezza" (e quindi per sistema "sicuro");
- una metrica che consenta di misurare il livello di "sicurezza" di un sistema;
- quali limiti sono raggiungibili da tale metrica, e dunque quale dovrebbe essere questo "minimo".

Se riesci a sopravvivere a questo (cosa di cui dubito fortemente, perché altrimenti ci sarebbe la rivoluzione di cui parlavo negli altri commenti, visto che tutte le problematiche di questo tipo si riconducono allo stesso problema di cui ho portato le fonti prima), poi dovresti anche dirci:
- chi l'avrebbe determinato;
- cosa intendi per "a monte".


per meltdown è lo stesso limite minimo di sicurezza definito da AMD, quando uno da guest vuole diventare amministratore senza avere i diritti viene bloccato (è una esemplificazione di quello che ho capito).
sarò ignorante ed ingenuo, ma mi piace come approccio e da intel leader della sicurezza non mi aspettavo niente di più e niente di meno.
per spectre spero per loro (amd e arm compresi) che le patch non rallentino ulteriormente, perchè altrimenti anche loro devono chiedere scusa e rifondare il danno come dovrebbe fare intel, ma che sappiamo bene non faranno mai, basta usare un "la cpu funzona secondo le specifiche" e tutto finisce bene.
chi ha definito le specifiche di progetto a monte?
ma sei serio?
sai almeno cos'è un progetto (proprio la definzione) e quali sono i passaggi che si fanno?
vabbè ti risparmio la ricerchina su google, si decidono quali sono i target di progetto: prestazioni X in questo caso e si cerca di raggiungerle.
si vede che c'è un'istruzione particolare che in determinati casi abbassa il livello di sicurezza (tipo il cambio di privilegi) e si decide se permettere di farlo o meno, cioè se si ritiene all'interno del margine di sicurezza Y o meno.
non l'hanno modificata? vuol dire che quel margine di sicurezza per loro è sufficiente.
qualcuno capisce come sfruttarlo, assumiti le responsabilità di una scelta al ribasso, la concorrenza ha scelto diversamente dimostrando che sapeva di questa falla e sicuramente la conoscevi anche tu che l'hai "ideata".
però un ignorante che usa i 3 neuroni in testa per fare collegamenti logici non può confrontarsi con un supponente, forse non mi sarei dovuto permettere di spondere, qualunque cosa non è sufficiente per uno che non argomenta mai (argomentare = dimostrazioni secondo il tuo modo di pensare, ma non l'hai mai fatto) ma dice la sua perchè "lavoro per X quindi ne capisco più di tutti", come ammiocuggino ;)


Ah, sì? E mi faresti vedere allora cosa ci sarebbe di sbagliato in queste specifiche? Prendi pure il manuale delle architetture x86/x64, che puoi scaricare sia dal sito di Intel sia da quello di AMD, e fammi pure vedere dove e perché sarebbe state "poste più in basso".


a parte chiedere una cosa 10 volte, argomenta dimostrando il contrario, come continui a fare, ti ripeto per un'altra volta (e se me lo hai chiesto ancora te lo ripeterò ulteriormente, tempo di leggere) che una certa AMD ad un certo punto ha fatto quello che avrebbe dovuto fare anche intel.aggiungere un passaggio di sicurezza e tac, immune a metdown.
io sostengo che non lo hanno fatto perchè avrebbe rallentato l'esecuzione.
sostieni che non è così?
devo ripetere che devi dimostrarmi il contrario? :D



Io non progetto CPU, ma parlo lo stesso. Quindi, come vedi, NON è condizione necessaria saper progettare CPU.


Direi proprio di no. A meno che non DIMOSTRI (lo so: non faccio altro che ripeterlo. Ma che ci vuoi fare: la mia laurea me la sono sudata, e ne ho dovute fornire parecchie di dimostrazioni. Mica passavo il tempo a scaldare i banchi) che sia stata volutamente sacrificata la "sicurezza" (notare le virgolette). E ovviamente dovresti dire pure in che modo.



cioè gli ultimi messaggi da "io sono io e sono migliore di tutti perchè credo di saperne di più ecc..." da chi arrivano?

quindi andiamo sul personale perchè non si è in grado di DIMOSTRARE niente manco da parte tua, ma cmq il tuo titolo è superiore ad altri?
potrei andare sul personale come fai tu, ma la scuola dell'obbligo l'ho finita decenni fa, lascio fare a te ;)


Sei semplicemente tu che hai dimostrato pienamente di essere totalmente incompetente in materia, visto che continui a snocciolare autentiche bestialità.

considerando che dal primo messaggio ho scritto che non è argomento di mia competenza e che non ho mai usato linguaggio tecnico per dare non spiegoni come fai tu, ma ho basatato le mie deduzioni sui fatti e sulla cronaca degli ultimi 10 giorni, posso tranquillamente affermare di non aver scritto neanche mezza bestialità, ma che tu abbia serie difficoltà con la comprensione dell'italiano e della logica.
non ti piace la mia logica? esiste l'ignore che ti consiglio di usare come suggerisci spesso tu, ma la cieca fede in un marchio senza logica e senza dimostrazioni che si basa solo sui comunicati stampa di un ceo ti rendono peggio di me.
le offese ad un supponente che non accetta dialogo nè confornto a me vengono facili, ma avendo 35 anni su un blog/forum cerco confronti con gente matura, che siano anche in grado di argomentare e spiegare certe cose, non con ragazzini con la sciarpa della squadra del cuore al collo anche quando sono davanti al pc.



Poi se il genio incompreso delle CPU si degnerà di definire in maniera formale questo famigerato "rapporto prestazione/sicurezza", come da precedente richiesta, magari potremo finalmente cominciare a discutere di qualcosa di concreto, e non delle fantasie sfrenate del tipico tuttologo internettiano.


un'altra volta?
il tuttologo continua a ripetere che se uno dei concorrenti ha modificato proprio quell'istruzione particolare un motivo ci sarà.
il tuttologo pensa che sia un motivo molto preciso, il sedicente esperto dice che è un altro ma non sa nemmeno quale (attendi nuovo comunicato stampa al riguardo?).
uno non può dimostrarlo, l'altro manco (ripeto, ti sfido a farlo)
ma se non dico di lavorare per steve jobs (anche solo per preparargli il caffè) le mie parole valgono zero.
infatti su un forum/blog si parla sempre in maniera personale, non in assoluti, dovevo aggiungere "imho, non sono ceo amd".
a parte qualcuno ovviamente, che non spiega nulla ma che pretende che le sue teorie vengano prese per dogma religioso. :mc:
deve essere bello un mondo così sempliciotto.

giusto un'ultima teoria complottista, ma tu da esperto del settore ma che non progetta cpu avrai la conoscenza della verità anche su questa.

sai che non è mai stato dimostrato in nessun caso che le vare porte sw e a questo giro anche hw sono state volute e finanziate dall'NSA? :read:
ma ovviamente per risponderti non ho dimostrato nulla, quindi ho perso solo tempo.
tale e quale al leggere i tuoi spiegoni senza dimostrazioni ma che si basano sulla logica del dipendente.


il tutto imho (forse avrei dovuto aggiungerlo ad ogni messaggio, gli esperti credono che tutti siano come loro e nei blog vanno a dettare legge)

ti mancano solo le scie chimiche e poi hai detto tutto

:doh: :D

:mc:

si però se esordisci dicendo che non sei un tecnico, perchè spari complotti fake se non sai di cosa parli? :muro:
cioè, tu deduci le tue ipotesi partendo dal presupposto che intel sapeva ma ha fatto finta di nulla. Se riesci a dimostrare questo sunto ok, siccome è impossibile fornire una dimostrazione che non sia frutto di teorie complottiste, stoppati :sofico:

se no fai la figura del solito lamerone che oltre a non sapere nulla (e su questo sei stato onesto) spara a dx e manca solo per sfogarsi :doh: :banned:

Cioe', stai forse affermando che se (ad esempio) Intel facesse una pull-request nel main repo di Cosmos che penalizza immotivatamente CPU di altri produttori tu la accetteresti solo perche' viene da qualcuno di importante??
E' questa forse la politica di Cosmos?? :eek: :eekk: :ops2:


Beh ovviamente, no però la sede per discutere dei cambiamenti al codice è appunto la Pull Request non una mailing list pubblica e di sicuro si deve sempre tenere un tono civile quando si parla con persone che - in fondo - sono lì per aiutarti!

Non voglio intromettermi nella discussione più di tanto, ma siccome parli di logica e poi "argomenti" dimostrando che ti mancano le basi, voglio farti notare i tuoi errori:

cioè mi chiedi di dimostrare qulcosa che non sei in grado di dimostrare manco tu?
[...]
ovviamente se ti chiedo di dimostrare che non è intenzionale non puoi farlo neanche tu
[...]
a parte chiedere una cosa 10 volte, argomenta dimostrando il contrario
[...]
sai che non è mai stato dimostrato in nessun caso che le vare porte sw e a questo giro anche hw sono state volute e finanziate dall'NSA? :read:
[...]
devo ripetere che devi dimostrarmi il contrario? :D


La logica non funziona così. La "burden of proof" (fardello della prova) è sempre (= di default) di chi afferma qualcosa: se tu affermi che Intel ha volutamente sacrificato la sicurezza a vantaggio della prestazioni sta a te dimostrarlo, e conseguentemente non è ammesso chiedere di dimostrare che quello che affermi non sia vero, perché dimostrare i negativi è spesso molto difficile, se non impossibile.
Per esempio io posso affermare che esistono dei maiali che volano, e a questo punto sta a me dimostrare che esistano: se tu obietti, non posso risponderti "be', dimostra tu che non esistono", perché tutti i maiali privi di ali che esistono a questo mondo non potranno mai dimostrare che non esistono maiali alati.

Non tanto tempo fa ho visto questo video in cui John Oliver (https://youtu.be/7VG_s2PCH_c?t=11m47s) esemplifica in modo terra terra, tanto ridicolo quanto efficace, quello che ho appena detto, di cui consiglio vivamente la visione (anche per intero).

si vede che c'è un'istruzione particolare che in determinati casi abbassa il livello di sicurezza (tipo il cambio di privilegi) e si decide se permettere di farlo o meno, cioè se si ritiene all'interno del margine di sicurezza Y o meno.
non l'hanno modificata? vuol dire che quel margine di sicurezza per loro è sufficiente.

Tutto questo partendo dal presupposto, non dimostrato e non dimostrabile, e soprattutto ipotizzato sempre e solo col senno di poi, che:
1. In Intel fossero consci del problema;
2. Abbiano deciso di ignorarlo in favore delle prestazioni.

In realtà l'unico fatto indiscutibile è che questi problemi si sono trascinati per anni per diverse release di CPU, coinvolgendo tutti i produttori di processori, e fino ad oggi questa "chiarissima" - ripeto, solo con il senno di poi - vulnerabilità non è emersa. Questo fatto, da solo, è sufficiente per dire che:
- O c'è stato un megacomplotto, in cui tutti i partecipanti erano a conoscenza del problema, molti ricercatori l'avevano scoperto, ma tutto s'è tenuto in silenzio per anni ed anni, e poi qualcuno ha arbitrariamente deciso di rivelarlo in questo momento;
- Oppure il problema non era affatto così chiaro ed è sfuggito a tutti, per cui non solo ci sono voluti anni, ma anche la scintilla d'arguzia - sempre con un pizzico di fortuna - di qualche ricercatore tanto ostinato quanto illuminato.

Capisci bene - spero - che la prima ipotesi è molto più da complottista, nonché priva di basi, della seconda.


qualcuno capisce come sfruttarlo, assumiti le responsabilità di una scelta al ribasso, la concorrenza ha scelto diversamente dimostrando che sapeva di questa falla e sicuramente la conoscevi anche tu che l'hai "ideata".
[...]
per spectre spero per loro (amd e arm compresi) che le patch non rallentino ulteriormente, perchè altrimenti anche loro devono chiedere scusa e rifondere il danno come dovrebbe fare intel


E qui stai dicendo, "AMD al contrario di Intel ha scelto sicurezza a sfavore delle prestazioni... a meno che invece non l'abbia fatto".

Fra l'altro in un aggiornamento (https://www.amd.com/en/corporate/speculative-execution?sf178974629=1) proprio delle ultime ore, AMD ha dichiarato:

"We believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture and no mitigation is required."

Ho evidenziato "believe" perché è esemplificativo che AMD abbia scelto questa parola: se AMD fosse assolutamente sicura che i suoi processori non possano essere bersaglio di quell'attacco non userebbe certo un'espressione così incerta e anzi, se gli attacchi che non coinvolgono i loro processori fossero stati evitati per scelta, in una situazione del genere, non si farebbe alcun problema ad affermarlo chiaramente.


il tuttologo continua a ripetere che se uno dei concorrenti ha modificato proprio quell'istruzione particolare un motivo ci sarà.

Che il motivo ci sia è praticamente indiscutibile: è invece estremamente dubbio, e tutto da dimostrare, che sia quello che ipotizzi tu.
Su ArsTechnica (https://arstechnica.com/gadgets/2018/01/heres-how-and-why-the-spectre-and-meltdown-patches-will-hurt-performance/) stanno trattando il problema in un modo abbastanza bilanciato fra il tecnico e il divulgativo (nonché imparziale), cosa che sicuramente può aiutare/ti a capire meglio l'origine e le implicazioni di queste scoperte. Consiglio di leggerlo con attenzione e riporto (ed evidenzio) un passaggio inerente alla discussione:

"Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address. This seems to be a product of good fortune; AMD switched to a different kind of branch predictor in Zen (like Samsung in its Exynos ARM processors, AMD is using simple neural network components called perceptrons), and the company happened to pick a design that was protected against this problem."

Questa non è ovviamente una dimostrazione, ma in mancanza di prove di complotti e dolo, è ragionevole: ogni produttore ha usato i propri metodi per aumentare le performance, e alcuni, probabilmente per pura fortuna, non sono vulnerabili.


poi un tempo c'era un paper risalente al 2007 che parlava di criticità dell'istruzione OoO, però hai già ampiamente detto che per te non è valida e che parla di altro, giustamente, non c'è scritto meltdown ma "criticità di istruzione", viene comunicata e 10 anni dopo qualcuno ha usato proprio quella criticità per notare degli effetti per niente desiderati.
[...]
non è dimostrabile, ma il fatto che AMD utilizzava la stessa soluzione e ad un certo punto l'ha modificata per inserire un passaggio in più quando c'è un cambio di privilegi che non permette di andare avanti (o qualcosa del genere, i paper dovresti capirli meglio tu) per me è sufficiente.

Qui stai dicendo: "ho visto un grosso animale volare, tu dici che non è un maiale e io non capisco niente di zoologia, però io una sagoma assomigliante ad un maiale - o qualcosa del genere - l'ho vista, e per me è sufficiente per dire che i maiali volano".
Spero che tu ti renda conto di quanto debole sia il tuo "argomento".

https://hackaday.com/2018/01/10/spectre-and-meltdown-attackers-always-have-the-advantage/

https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf

Marco71.

In teoria. Gli stracci poi in un modo o nell'altro volano sempre. Solo che, mentre in un progetto come linux tutto e' alla luce del sole, Nelle grosse corporation si vede solo quello che l'azienda vuole far vedere (dubito fortemente che nessun sviluppatore/designer di intel non si sia scambiato internamente qualche email piena di bestemmie. Tutti siamo umani :D ).

Questo e' sicuro, ovviamente. Ma, appunto, rimane all'interno dell'azienda.

Tra l'altro, il punto principale e' che non c'e' alcun motivo per cui Torvalds debba rispondere in quel modo. Nessuno gli ha puntato una pistola alla testa. Avrebbe potuto semplicemente rigettare la patch spiegandone i motivi e amen. Anche perche', ripeto, la sua fortuna sono proprio quelli su cui di tanto in tanto spala mer*a.

... Ci sono anche le parac*late dei PR, a me sembra lecito che le abbia criticate...
C'è modo e modo di criticare, e lui lo fa sicuramente in quello sbagliato. Ma non mi voglio impelagare in giudizi sulla persona, visto che è stato già fatto e concordo con quanto detto da altri.
IMHO non credo che LT sia ignorante rispetto ad alcunché quando si parla di funzionamento di una CPU.
Qui si parla di soluzioni micro-architetturali per una precisa problematica (Meltdown), e quella che ha proposto è "overkill".

Ci sono modi precisi per cambiare CPL all'interno di x86 & x64, ma la problematica in oggetto si verifica quando dalla normale esecuzione in user land (CPL=3) si passa poi a quella in kernel land (CPL < 3), e SOLO in questo caso.

Se il codice viene eseguito in CPL 2 (usualmente per "system libraries"), CPL 1 (usualmente per "drivers"", e CPL 0 (kernel), sei già in kernel mode e quindi non si applica il caso in oggetto.

Per cui, se proprio vogliamo aggiungere dei bit in più nella cache dati L1 per marcare il livello d'esecuzione, aggiungere l'intero CPL è, come già detto, "troppo abbondante" come soluzione.

Lascio agli altri la soluzione (banale) al problema, che richiede meno spazio (che, in questo componente, è molto prezioso).
illuminatemi

https://www.darknet.org.uk/2007/07/intel-core-2-duo-vulnerabilities-serious-say-theo-de-raadt/

è in qualche modo riconducibile a queste problematiche?
Ne abbiamo già discusso in un altro thread su questo tema: non c'entra. Riguarda la sfruttabilità delle falle elencate negli errata.

I nuovi attacchi sono, invece, di tipo "side-channel", e non fanno uso di errata: sfruttano elementi esterni all'ISA (tempo d'esecuzione, temperatura del processore, utilizzo di determinate risorse interne, e chi più ne ha più ne metta) per carpire / ricostruire informazioni altrimenti inaccessibili.
che te devo dire... sicuramente e' comodo per chi ha bisogno di controllare i servizi.. io pero' preferisco SysV.. tutti i cgroups montati in automatico... non me piacciono per niente :stordita:
i glitch si, probabilmente dipendono dalle nuove librerie, anche se su stretch non ho ancora installato nulla.. comunque freebsd mi pare meno glitchosa della debian...per ora mi soddisfa :ciapet:
So che systemd è odiato da chi è abituato ai meccanismi consolidati da SysV.

Però oggettivamente consente di risolvere determinate problematiche in maniera più semplice ed efficiente.

Da informatico preferisco la pratica: un tool che funziona e risolve i miei problemi. :fagiano:
beh Cesare, si parla di 1994 (coi volumi del 1994). Se adesso si scoprisse lo stesso problema, dubito fortemente che Intel (o chiunque altro) possa attuare le stesse politiche.
Assolutamente d'accordo. Intel produce circa 400 milioni di processori l'anno. I produttori ARM circa 15 miliardi. Con questi numeri è ormai è impensabile realizzare massicce campagne di richiamo.
In teoria. Gli stracci poi in un modo o nell'altro volano sempre. Solo che, mentre in un progetto come linux tutto e' alla luce del sole, Nelle grosse corporation si vede solo quello che l'azienda vuole far vedere (dubito fortemente che nessun sviluppatore/designer di intel non si sia scambiato internamente qualche email piena di bestemmie. Tutti siamo umani :D ).
Verbalmente possono volare turpiloqui et similia, ma via e-mail e documentazione di vario tipo... no.

Ci sono codici di condotta che vengono fortemente imposti e devono essere rispettati.

Ovviamente le beghe interne capitano, con discussioni anche accese. Ma ci sono dei limiti invalicabili. Ad esempio mettere anche soltanto un dito addosso a un collega porta alla "terminazione" immediata, chiunque sia l'autore del gesto.

giuliop ha ampiamente spiegato i termini delle questioni, per cui evito di ripetere le stesse e mi concentro solo su alcune parti.
cioè mi chiedi di dimostrare qulcosa che non sei in grado di dimostrare manco tu?
Io quello che dovevo dimostrare, TEOREMI ALLA MANO, l'ho dimostrato. Come ha chiarito giuliop, adesso tocca A TE dimostrare le TUE affermazioni, visto che l'onere della prova in questi casi è tutto tuo.

A me è sufficiente attendere che finalmente ti decida a dimostrare (quindi niente fantasie e speculazioni personali) le tue tesi. Anche se il problema, nell'era dei tuttologi internettiani, è che più facile morire di vecchiaia che ricevere una qualche risposta concreta.
la retorica delle dichiarazioni intel viene abbracciata con trasporto anche dai suoi exdipendenti a quanto pare.
Solita fallacia logica dell'attacco Ad Hominem. Immagino non ti sia preso nemmeno la briga di aprire il link che ti avevo passato e che lo descrive, visto che lo riproponi nuovamente.
il fatto che AMD utilizzava la stessa soluzione e ad un certo punto l'ha modificata per inserire un passaggio in più quando c'è un cambio di privilegi che non permette di andare avanti (o qualcosa del genere, i paper dovresti capirli meglio tu) per me è sufficiente.
Come mostrato da giuliop, il caso di AMD è fortuito, e peraltro avvenuto soltanto coi suoi ultimi processori (che sono stati commercializzati soltanto lo scorso marzo).
poi un tempo c'era un paper risalente al 2007 che parlava di criticità dell'istruzione OoO, però hai già ampiamente detto che per te non è valida e che parla di altro, giustamente, non c'è scritto meltdown ma "criticità di istruzione", viene comunicata e 10 anni dopo qualcuno ha usato proprio quella criticità per notare degli effetti per niente desiderati.
due cose totalmente diverse e sconnesse.
Infatti sono due cose completamente diverse e disconnesse, e ne avevo già parlato con un altro utente.

Continuare a ripetere la solita solfa senza nemmeno comprendere la differenza fra le due cose non renderà automatica vera la tua tesi, ma contribuirà soltanto a renderti ancora una volta ridicolo perché parli di cose di cui non hai la minima conoscenza.

Ovviamente se sei convinto le due cose siano collegate, beh, l'onere della prova è tutto tuo: DIMOSTRALO! Visto che è la TUA tesi.
bugiardo e pubblico mentitore perchè la mia deduzione non ti piace?
azz...
Perché affermi il falso, e nient'altro che per questo. Dalle mie parti uno che mente è... rullo di tamburi... un bugiardo.

Dunque o porti le prove delle tue affermazioni (che non sono semplici deduzioni: hai addossato a Intel delle precise responsabilità), oppure rimani un pubblico mentitore.

Tertium non datur.
io ho riscaldato i banchi, ma qualcuno non è andato oltre la scuola dell'obbligo...
Sempre dalle mie parti, lo specchio riflesso era in uso alle elementari.
per meltdown è lo stesso limite minimo di sicurezza definito da AMD,
Non hai ancora definito riguardo niente al tuo "limite minimo di sicurezza". Chi l'avrebbe mai detto. Ma nel dubbio che ti fosse sfuggito, ti riporto nuovamente la mia precisa richiesta in merito:

DEFINISCI FORMALMENTE (quindi IN MANIERA OGGETTIVA / INCONTROVERTIBILE):
- cosa s'intende per "sicurezza" (e quindi per sistema "sicuro");
- una metrica che consenta di misurare il livello di "sicurezza" di un sistema;
- quali limiti sono raggiungibili da tale metrica, e dunque quale dovrebbe essere questo "minimo".

L'onere della prova, come già detto, è tutto tuo: devi DIMOSTRARE le TUE affermazioni. :read:
quando uno da guest vuole diventare amministratore senza avere i diritti viene bloccato (è una esemplificazione di quello che ho capito).
sarò ignorante ed ingenuo, ma mi piace come approccio e da intel leader della sicurezza non mi aspettavo niente di più e niente di meno.
Ed è proprio quello che viene effettuato, SE avessi letto il paper di Meltdown.

Ecco perché ho affermato che i processori di Intel si comportano come da specifiche. Le stesse specifiche che puoi trovare indifferentemente nei manuali (dell'architettura) di Intel quanto in quelli di AMD (tanto le specifiche sono sempre le stesse).
chi ha definito le specifiche di progetto a monte?
ma sei serio?
Mai stato più falsamente serio.
sai almeno cos'è un progetto (proprio la definzione) e quali sono i passaggi che si fanno?
vabbè ti risparmio la ricerchina su google, si decidono quali sono i target di progetto: prestazioni X in questo caso e si cerca di raggiungerle.
si vede che c'è un'istruzione particolare che in determinati casi abbassa il livello di sicurezza (tipo il cambio di privilegi) e si decide se permettere di farlo o meno, cioè se si ritiene all'interno del margine di sicurezza Y o meno.
non l'hanno modificata? vuol dire che quel margine di sicurezza per loro è sufficiente.
Ancora una volta, è TUO onere dimostrare che nella definizione del target di progetto sia stata VOLUTAMENTE sacrificata la "sicurezza" (concetto che, peraltro, non hai ancora definito) con le prestazioni.

Rimane una TUA tesi INDIMOSTRATA, e pertanto non vale nulla.

Ciò precisato, ancora no: non si tratta di una singola istruzione a cui è stato (volutamente, A TUO DIRE) cambiato il comportamento.

Ma poi è chiedere troppo che ti legga il paper e magari finalmente riuscire a capire che l'istruzione (UNA delle DIVERSE possibili!) si comporta ESATTAMENTE come da specifiche? E, come tale, viene UCCISA (provoca un'eccezione che viene immediatamente intercettata ed elaborata dal kernel) senza far danni; e le istruzioni seguenti, che avevano fatto uso del valore letto illecitamente, vengono ELIMINATE. Tutto come da manuale, insomma.
però un ignorante che usa i 3 neuroni in testa per fare collegamenti logici non può confrontarsi con un supponente, forse non mi sarei dovuto permettere di spondere, qualunque cosa non è sufficiente per uno che non argomenta mai (argomentare = dimostrazioni secondo il tuo modo di pensare, ma non l'hai mai fatto) ma dice la sua perchè "lavoro per X quindi ne capisco più di tutti", come ammiocuggino ;)
Come abbiamo ampiamente avuto modo di vedere, se i tuoi 3 neuroni NON sono supportati dalla logica, allora falliscono miseramente.

Peraltro pretendi di affibbiarmi una frase, che ti sei addirittura permesso di mettere fra virgolette e quindi come se fosse qualcosa scritta direttamente da me, in cui ricadrei in un'altra comune fallacia logica: quella del Ricorso all'Autorità (https://www.linux.it/~della/fallacies/ricorso-all-autorita.html).

Cosa che non mi sono mai sognato di affermare (anche perché NON sono avvezzo alle fallacie logiche, che invece sono il tuo dominio indiscusso), e quindi adesso arrivi perfino a mistificare.

Diciamo che non ti fai mancare proprio niente, eh! E poi ti lamenti pure se uno ti dà, giustamente, del bugiardo.
cioè gli ultimi messaggi da "io sono io e sono migliore di tutti perchè credo di saperne di più ecc..." da chi arrivano?
Altra mistificazione. Ormai spari menzogne a briglie sciolte...
quindi andiamo sul personale perchè non si è in grado di DIMOSTRARE niente manco da parte tua, ma cmq il tuo titolo è superiore ad altri?
Ancora mistificazioni. E a questo punto sorge anche il dubbio che tu non comprenda la lingua italiana, visto che dimostri di capire cose tutte tue, che gli altri non si sono sognati di affermare.
potrei andare sul personale come fai tu, ma la scuola dell'obbligo l'ho finita decenni fa, lascio fare a te ;)
Hai già fatto abbastanza, non ti preoccupare. Come vedi chiunque ne capisce un po', ma anche solo di logica, ti bacchetta.

Ovviamente il dubbio che tu stia sbagliando non te lo poni nemmeno: l'immensa ignoranza condita dalla superbia hanno ormai accecato il buon senso (sempre che ne avessi avuto uno).
considerando che dal primo messaggio ho scritto che non è argomento di mia competenza e che non ho mai usato linguaggio tecnico per dare non spiegoni come fai tu, ma ho basatato le mie deduzioni sui fatti e sulla cronaca degli ultimi 10 giorni, posso tranquillamente affermare di non aver scritto neanche mezza bestialità, ma che tu abbia serie difficoltà con la comprensione dell'italiano e della logica.
Intanto vedi sopra. Poi nessuno t'ha mai insegnato che in mancanza di conoscenza di un argomento è sempre meglio astenersi dal parlarne?
non ti piace la mia logica? esiste l'ignore che ti consiglio di usare come suggerisci spesso tu,
Non lo farò, perché se affermi delle bestialità o menzogne ho tutto il diritto di poter mostrare che sono tali.
ma la cieca fede in un marchio
Di nuovo la fallacia logica dell'attacco Ad Hominen.
senza logica
Questa è surreale, detta da te.
e senza dimostrazioni
Ho dimostrato ciò che era di mia competenza.

Come ti hanno fatto notare, per le TUE affermazioni l'onere delle dimostrazioni è esclusivamente TUO. Io mi devo limitare ad aspettare che tu le fornisca. Cosa che, ovviamente, sistematicamente fai mancare.
che si basa solo sui comunicati stampa di un ceo ti rendono peggio di me.
Altra mistificazione: mai affermato nulla del genere. Come ho già detto, e a differenza di te, il paper di Meltdown me lo sono letto e so su quale base si fonda la vulnerabilità. E conosco anche il manuale dell'architettura. Per cui per me è facile stabile che il processore si comporta come da specifiche.

Cosa che, peraltro, emerge anche dalla sola lettura del paper, che spiega in dettaglio, passo passo, e istruzione dopo istruzione, cosa succede quando il processore le esegue.


Dunque non serve andare a prendere le dichiarazioni del CEO. E comunque son cose che avevo già affermato PRIMA.

Per cui continui ancora a raccontar frottole.
le offese ad un supponente che non accetta dialogo nè confornto a me vengono facili, ma avendo 35 anni su un blog/forum cerco confronti con gente matura, che siano anche in grado di argomentare e spiegare certe cose,
Quindi tu dovresti tirartene fuori, visto che finora le hai soltanto sparate grosse, senza argomentare e inventandoti cose di sana pianta.

Bel modo di "argomentare". :D
non con ragazzini con la sciarpa della squadra del cuore al collo anche quando sono davanti al pc.
Solita fallacia logica dell'attacco Ad Hominem. Chissà quando imparerai a non caderci nuovamente, ma visto il tenore delle tue risposte non credo ci siano speranze ormai, perché appare evidente che la natura sia stata matrigna con te.
un'altra volta?
il tuttologo continua a ripetere che se uno dei concorrenti ha modificato proprio quell'istruzione particolare un motivo ci sarà.
Non c'è nessuna istruzione modificata. Continui a sparare colossali sciocchezze perché non ti sei letto il paper, e dunque non sai come realmente stiano le cose. Inoltre riporti presunte modifiche di cui non fornisci alcuna prova, tanto per cambiare.

Dunque sì: sei il tipico tuttologo internettiano che pretende di discutere su un argomento di cui è palese la sua macroscopica ignoranza.
ma se non dico di lavorare per steve jobs (anche solo per preparargli il caffè) le mie parole valgono zero.
Solita fallacia logica del Ricorso all'autorità, che mistificando come tuo solito pretendi di appioppare agli altri.

Oltre che ignorante hai ampiamente dimostrato di essere un gran bugiardo, nonché intellettualmente disonesto.
tale e quale al leggere i tuoi spiegoni senza dimostrazioni ma che si basano sulla logica del dipendente.
Ancora fallacia logica dell'attacco Ad Hominem.
il tutto imho (forse avrei dovuto aggiungerlo ad ogni messaggio, gli esperti credono che tutti siano come loro e nei blog vanno a dettare legge)
Più che altro internet è ormai infestata da tuttologi ignoranti che vanno continuamente a parlare di cose a loro sconosciute.

«I social media danno diritto di parola a legioni di imbecilli che prima parlavano solo al bar dopo un bicchiere di vino, senza danneggiare la collettività. Venivano subito messi a tacere, mentre ora hanno lo stesso diritto di parola di un Premio Nobel. È l’invasione degli imbecilli». (Umberto Eco)

non sta a me difendere Juanito.82, ma voglio solo evidenziare quelli, che a mio parere, sono i motivi per il quale non riesce a "capire" quanto state dicendo (da ciò escluderò tutte le considerazioni ed attacchi personali):

- gli manca un minimo di conoscenza di teoria della computabilità e relativi teoremi. Dovrebbe darsi un'occhiata da profano a qualche semplice spiegazione almeno per intuire di cosa state parlando. Dunque intuire complessità, computabilità, terminazione, ecc. (All'epoca non era nel mio piano di studi e non lo scelsi neanche come complemetare, ma poi ho cercato di fare ammenda con un po' di appunti). Faccio presente a Juanito.82 che sono stati riportati teoremi matematici in quest'ambito. Ma qui per non scivere castronerie, su argomenti che conosco poco più che a livello intuitivo, chiederei un intervento mooolto divulgativo a chi ha studiato seriamente l'argomento.

- gli manca totalmente una conoscenza di architettura e microarchitettura dei calcolatori. Forse, non ne ha proprio bisogno per la discussione ma differenziare "istruzione" da "esecuzione OoO" sarebbe meglio.

- non di rado fa errori di logica elementare che lo portano a conclusioni errate (non che io non le faccia ma difficilmente con questo "tasso"). Mentre i due punti precedenti sono materia specialistica, non mi riesco a spiegare queste mancanze da primo anno (all'epoca lo trattavano nel "corso di azzeramento" e serviva per chi aveva zoppicato durante le scuole superiori).

- Per quanto riguarda la sicurezza, probabilmente, la sua forma mentis ed il suo mindset lo portano a ragionare in termini di ingegneria civile: "il ponte resisterà a tali sollecitazioni per "tot" anni se correttamente manutenuto". Questo concetto non è applicabile nell'informatica a priori. Tant'è vero che i contratti riguardanti la sicurezza, in generale, sono definiti "aleatori", c'è la promessa dell'impegno non la garanzia del risultato!

Ps: non ho volutamente trattato l'argomento "complottistico" e le "offese personali".

Infatti il personaggetto in questione non si fa mancare proprio nulla.

Riguardo al primo punto (teoria della computabilità e problema dell'arresto), non mi è chiaro cos'altro si potrebbe divulgare (immagino collegato alle falle di cui stiamo discutendo). Qualche idea?
Beh. Però l'aggressione fisica è reato indipendentemente dal fatto di essere assunti in una grande azienda. :stordita:
Non è necessaria l'aggressione fisica: un contattato fisico che semplicemente non sia rispettoso della persona è sufficiente per una terminazione.

Finalmente ho avuto modo di leggere questi interessanti link, grazie.
https://hackaday.com/2018/01/10/spectre-and-meltdown-attackers-always-have-the-advantage/
Non condivido proprio tutto, ma certamente lo spirito col quale è stato scritto il pezzo è totalmente condivisibile. Suggerisco anche agli altri di leggerlo.
https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf
Incredibile come questo vecchio paper abbia, già all'epoca, introdotto una notevole panoramica sui cosiddetti "building-blocks" che poi sono stati usati dai nuovi attacchi "side-channel".

Non possiamo ancora parlare di attacchi side-channel, ma ci sono diversi elementi e strumenti comuni.

Meno male che un bel po' di quella roba non si applica più, perché i s.o. moderni non fanno più sostanzialmente uso di alcune caratteristiche "legacy" dell'ISA x86. :fagiano:

letti pure io, me sa che tra poco esce il p.o.c. in javascript :asd:

Tra l'altro, il punto principale e' che non c'e' alcun motivo per cui Torvalds debba rispondere in quel modo.

Management by Perkele (http://enacademic.com/dic.nsf/enwiki/2016571), non è il massimo ma a livello strettamente verbale e limitato a fatti oggetivi è un opzione da prendere in considerazione quando hai solo le parole per fare pressione su chi evidentemente non ascolta ripetuti richiami (non è che Torvalds "esploda" la prima volta che succede un certo problema, di solito succede quando la cosa era già avvenuta in passato più volte e di doveva capire non ha capito o a fatto finta di non capire).

Sinceramente lo hanno fatto anche nella mia azienda a volte partono mail in cui poveri cristi costretti a fare i salti mortali per far andare hardware normalissimo su Linux vengono definiti "teste di m*nchia", "c*glioni", ecc... i "migliori" stufi di questo modo di fare hanno preso la porta e se ne sono andati... noi continuiamo a subire, ma, sinceramente, a me quando mi becco sti epiteti passa la voglia di lavorare per un po' :cry:

Ma poi dai scherziamo quel tizio in Finliandia è il manager di cosa? Di chi?
Si prende troppo sul serio...

Sinceramente lo hanno fatto anche nella mia azienda a volte partono mail in cui poveri cristi costretti a fare i salti mortali per far andare hardware normalissimo su Linux vengono definiti "teste di m*nchia", "c*glioni", ecc... i "migliori" stufi di questo modo di fare hanno preso la porta e se ne sono andati... noi continuiamo a subire, ma, sinceramente, a me quando mi becco sti epiteti passa la voglia di lavorare per un po' :cry:

Ma poi dai scherziamo quel tizio in Finliandia è il manager di cosa? Di chi?
Si prende troppo sul serio...

Management by Perkele non significa avere dei manager teste di caXXo
(avuti pure io e mandati a quel paese, quando si ha già un lavoro è molto più facile trovarne un altro).

A me pare proprio un "manager" testa di razzo invece, un altro esempio tra tanti:

https://www.ibm.com/developerworks/community/blogs/58e72888-6340-46ac-b488-d31aa4058e9c/entry/linus_torvalds_gets_angry_says_shut_the_f_up_on_official_mailing_list51?lang=en

la cosa "brutta" è che Linus Torvalds aveva ragione in quel caso, ma così è passato dalla parte del torto.

Poi - per carità - io non sono un'educanda dovreste essere accanto a me tutto il giorno per sentire cosa mi esce dalla bocca:

- Ma perché non funziona il copia & incolla, c*zzo!
- Linux M****
- Guarda come è tutto imputt*nito...
[...]

Ma è diverso il caso quando stai facendo il Manager o stai facendo "tutoring" gli insulti, mai, al massimo si "gioca" un po'... poi in una mail "pubblica" è totalmente inaccettabile.

Sinceramente lo hanno fatto anche nella mia azienda a volte partono mail in cui poveri cristi costretti a fare i salti mortali per far andare hardware normalissimo su Linux vengono definiti "teste di m*nchia", "c*glioni", ecc... i "migliori" stufi di questo modo di fare hanno preso la porta e se ne sono andati... noi continuiamo a subire, ma, sinceramente, a me quando mi becco sti epiteti passa la voglia di lavorare per un po' :cry:

Ma poi dai scherziamo quel tizio in Finliandia è il manager di cosa? Di chi?
Si prende troppo sul serio...

non ho capito molto la situazione dei tuoi colleghi etichettati come cog**oni..
però se uno si fa assumere come sistemista linux, e all'atto pratico NON sa fare il sistemista linux, allora un COGL**NE se lo merita tutto :read:

non ho capito molto la situazione dei tuoi colleghi etichettati come cog**oni..
però se uno si fa assumere come sistemista linux, e all'atto pratico NON sa fare il sistemista linux, allora un COGL**NE se lo merita tutto :read:

Io sarei programmatore, poi visto che per "risparmiare" il sistemista lo hanno licenziato ci tocca ricompilare il kernel, fare i "kludge" per fargli vedere i device, sbattersi a configurare X per fare una cosa per me banale come il dual head (ma ogni volta ci vuole almeno una giornata di tentativi :muro: )... e poi ti senti dire quando - ovviamente - non funziona una mazza che tu sei un c*glione!

non ho capito molto la situazione dei tuoi colleghi etichettati come cog**oni..
però se uno si fa assumere come sistemista linux, e all'atto pratico NON sa fare il sistemista linux, allora un COGL**NE se lo merita tutto :read:

Primo rispetto e competenza sono due cose diverse, e secondo, ma non meno importante, uno "non si fa assumere", perché non ti punta una pistola alla testa: lo assumi tu, e se hai assunto un incapace, allora il "COGL**NE" sei solo tu.

Primo rispetto e competenza sono due cose diverse, e secondo, ma non meno importante, uno "non si fa assumere", perché non ti punta una pistola alla testa: lo assumi tu, e se hai assunto un incapace, allora il "COGL**NE" sei solo tu.

assolutamente d'accordo.. tipi infelici finiscono sempre in coppia o alle dipendenze di gente infelice :sofico:

Io sarei programmatore, poi visto che per "risparmiare" il sistemista lo hanno licenziato ci tocca ricompilare il kernel, fare i "kludge" per fargli vedere i device, sbattersi a configurare X per fare una cosa per me banale come il dual head (ma ogni volta ci vuole almeno una giornata di tentativi :muro: )... e poi ti senti dire quando - ovviamente - non funziona una mazza che tu sei un c*glione!

Primo rispetto e competenza sono due cose diverse, e secondo, ma non meno importante, uno "non si fa assumere", perché non ti punta una pistola alla testa: lo assumi tu, e se hai assunto un incapace, allora il "COGL**NE" sei solo tu.
però nel caso in esame nessuno ha puntato la pistola ai programmatori per fare i sistemisti.. io non so programmare in OGL, per es., se me lo chiedono lo dico chiaramente..onde evitare figure appunto dimm... che sicuramente verranno.. :fagiano: