No a Explorer, c'è la Francia

[ConteZero]

Originariamente inviato da gugoXX

Ma non e' mica vero. Il buffer overflow nelle librerie e' un esempio che mi viene in mente di programma del sistema operativo scritto male.
Il fatto che il programma non controlli in anticipo la lunghezza dei dati in arrivo posso tranquillamente leggerlo nel sorgente.

Ma tu hai idea di quanto dovresti leggere per trovare "a mano" un buffer overflow ?

[gugoXX]

Originariamente inviato da ConteZero

Ma tu hai idea di quanto dovresti leggere per trovare "a mano" un buffer overflow ?

E pensa se non potessi nemmeno leggere

[k4ez4r]

Ottimo l'effetto ottenuto

People in Germany Are Switching Browsers



Fonte: Blog di Mozilla

[trallallero]

Originariamente inviato da gugoXX

Fa finta di essere un potenziale scrittore di virus, in grado di scrivere virus sia sotto Windows che sotto Linux.
Quale sistema preferisci approcciare, uno del quale hai il codice o uno del quale non ce l'hai?
A rigor di logica, se il ragionamento fosse "singola societa'" vs open-source la quantita' di virus circolante sotto Windows dovrebbe essere analoga a quella circolante sotto Mac.
E invece non e' cosi'.
La quantita' di virus e' proporzionale alla diffusione del sistema operativo. Se Linux divenisse il sistema piu' diffuso, allora i crack per giochi che girano in rete, oppure i programmini come le renne di babbo natale, sarebbero scritti per funzionare sotto Linux.
E poiche' gli utenti sarebbero sempre gli stessi qualcuno che ci clicca sopra lo si trova sempre. Con conseguenze immaginabili.

Son d'accordo, come già avevo scritto, sulla parte in grassetto, ma sul open o non open source no, non penso che incida molto sulla qualità e/o quantità dei virus e neanche sulla scelta degli scrittori di virus.
Non intendevo "singola societa'" vs open-source ma "singola societa'" vs "sistema con diverse possibilità di scelta". È molto più difficile indovinare com'è configurato un sistema Linux che uno Windows perchè quello Windows esce "pronto" dalla fabbrica con parecchie features fisse e non modificabili e il virus potrebbe appoggiarsi proprio su queste. Su Linux non sai neanche che interfaccia audio si sta usando

C'e' anche l'effetto "fama" da considerare, soprattutto davanti a quei virus il cui payload non fa nulla di male, scritti appunto per salire alla cronaca come il Neo del momento.
Nella community degli scrittori di virus, se scrivi un virus per Windows sali agli onori e sei deificato. Se scrivi un virus per Linux ti tirano le pietre.

Ecco, a questo non c'avevo pensato ma mi sembra un'acuta osservazione.
Scrivere un virus per 4 nerd sfigati è da bastardi

[cdimauro]

Originariamente inviato da guyver

Guarda il ragionamento del "più utilizzato" può anche filare...
Ma nessuno che raccoglie la sfida? Nessuno che pensa: <Linux inviolabile? ora ci penso io e incasino tutte le distro del pianeta>

O devo pensare che tutti quelli che scrivono virus lo fanno per commessa (cioè li viene commissionato)?

Alla fine non occorrerebbe che il virus infetti molte macchine... basterebbe la sua esistenza(del virus) e la capacità di infettare nuovi sistemi in modo efficace, per distruggere il mito di "linux no virus"

Dai un'occhiata a questo.

Originariamente inviato da trallallero

Allora non capisco la tua uscita su di me prima: potresti essere più chiaro?

Se sia cambiata la filosofia di MS non lo so, ma è risaputo che Windows fino ad XP è un unico monolite infatti, guarda caso, se crasha un programma può succedere che ti crashi tutto il sistema con un bel blue screen.

Questo non capita dai tempi di NT. E se escludiamo le zone di memoria condivise col DOS che si teneva in memoria, nemmeno con Windows 3.0 e 9x.

Si lo so, tu con Fedora hai avuto un kernel panic per delle semplici malloc C, ma detto da uno che in firma eslcude qualsiasi linguaggio che non sia il Python per imparare a programmare, vale poco come testimonianza.

Avvelenamento del pozzo.

Poi in sezione Programmazione possiamo parlare quanto vuoi di quale linguaggio possa essere migliore per imparare a programmare.

In dieci anni di Linux-Windows non ho MAI avuto un kernel panic ma tanti blue screens

E questo vuol dire soltanto che trallallero in 10 anni non ha avuto KP. Null'altro.

Vedi perchè preferisco non discutere con te, ti giri sempre il dicorso a tuo vantaggio facendo credere di non aver capito un cazzo (ma comincio ad avere qualche dubbio).
Ci riprovo:

L'utente Windows di solito, parlo proprio della massa non di chi ci lavora col PC, non sa manco che si può aprire una finestra cmd con la quale eseguire qualche comando più low level di quello che potresti fare tramite il menu avvio o aprendo una finestra browser.
L'utente medio di Windows se ha problemi con una dll (che non sa manco cos'è) od un servizio (idem) porta il PC in assistenza o s'attacca.
L'utente medio Linux è abituato ad avere a che fare con shell quindi non si va a spulciare il codice del kernel come dici tu tanto per buttarla in caciara, ma è più a contato con esso, come ho scritto, essendo abituato ad eseguire comandi da tastiera per il controllo del sistema.
È vero che ormai con Ubuntu ed altri sistemi Linux non serve quasi più la shell, ma non conosco un utente Linux che non sia capace di gestire il proprio sistema in maniera indipendente via comandi manuali.

Quindi l'esistenza dei sorgenti o meno non è in discussione. Lo sono soltanto le skill individuali, e su questo non ho nulla da dire.

Originariamente inviato da ConteZero

Con la notevole differenza che se hai Windows hai sicuramente stoppardi.dll di Microsoft che può essere in versione "pre X" o "post X" (dove X è la data dell'exploit), se hai Linux puoi avere libstoppardi.a o libnonstoppardi.a o ancora niente, in 150 possibili versioni (a seconda della build).
Stoppardi.dll esisterà in tutte le installazioni di windows, e sarà diffuso solo nelle tre o quattro build che Microsoft ha rilasciato (il che vuol dire che se c'è una vulnerabilità è facile localizzarla e fare il "fine tuning" su quella specifica dll) mentre su Linux le cose si fanno decisamente più complicate.

Benissimo, ma alla fine si tratta di verificare ciò che ciò ed eseguire apposito codice. Che non mi pare poi tutta questa complicazione, specialmente per chi ha sviluppato skill adeguate (e chi scrive virus e trojan non sono gli ultimi arrivati).

Microsoft dice che Windows è un sistema operativo "arricchito", di esso fa parte anche tutto un set di librerie, funzioni ed add on vari che, di fatto, compongono il "sistema" pur essendo solo "contorno".
Linux è solo il kernel, GNU è il set minimo a disposizione... GNU/Linux è un linux per come lo si intende colloquialmente, ma questo non vuol dire che non esista (ad esempio) GNU/Hurd (MACH/FIASCO) o GNU/FreeBSD.
Se mi parli di "funzionalità minimali" devi specificarmi di COSA stiamo parlando nel dettaglio... mica siamo in Windows, dove tutto, dall'EXECUTIVE alle librerie per i font è "sistema".

In una distro non hai solo il kernel, per cui questa differenziazione con Windows lascia il tempo che trova, perché per essere usabile hai bisogno di QUALCOSINA di più del kernel.

Tutto ciò che serve per far partire un s.o., rientra nel discorso dei componenti "minimali" di cui parlavo prima.

Al di là dei nuovi layer di sicurezza (ASLR & co) aggiunti tanto su linux quanto su windows il punto è che su linux c'è molta meno unità di quanta non ve ne sia su windows.
Una distribuzione mainstream diffusissima come Ubuntu può annoverare tranquillamente venti o trenta diverse "build" per la stessa libreria (ed il "rampino" d'ingresso non puoi compilarlo sulla macchina bersaglio, dev'essere pronto PRIMA).

Questo non è affatto detto. Dipende dalle falle. Inoltre, ad esempio, se ne trovo una nuova... al 99,999% è disponibile per qualunque versione di Linux.

Peraltro trovare le falle è abbastanza facile (o meglio, trovare i REPORT in cui sono nominate),

A parte questo, le falle (nuove) le può trovare anche un malintenzionato.

sfruttarle è decisamente più complicato (e non "un po'", parliamo di diversi ordini di grandezza).
Se la libreria ha un "buco" questo può voler dire dover adattare il "codice d'ingresso" a ventri o trenta diverse "versioni"... e stiamo parlando di una sola distribuzione, in giro di distribuzioni ce ne sono diverse.
A questo aggiungi che su windows la piattaforma è bene o male "stabile" mentre su linux varia in base alle preferenze dell'utente ed arrivi alla situazione per cui su linux non puoi essere sicuro di poter agire anche dopo l'ingresso (perchè ti manca la libreria necessaria per il privilege excalation, perché non c'è il compilatore "compatibile", perché non c'è il perl e così via) ed hai come risultato che per fare un virus che funzioni sotto linux devi progettare leviatano che consideri una quantità enorme di variabili... mentre su windows lo sviluppo è semplicissimo.

Non lo metto in dubbio, ma come dicevo prima, non mi sembra siano problemi insormontabili / non gestibili da una persona esperta.

Originariamente inviato da gugoXX

Si chiamano sistemi operativi monolitici, che e' la modalita' di progettazione anche di Linux, come idea di Torvalds, contrastando le idee di Dijkstra.

Era Andrew Tanenbaum.

Comunque quanto dici non e' vero. L'unico modo per avere un blue screen sotto Windows comunque e' quello di avere un baco in posizioni ben precise (non un qualsiasi baco) in un processo che gira a livello 0, ovvero parti di sistema operativo stesso o driver scritti da terze parti.
Con un crash di un semplice programma a ring 4 (come quelli che vengono eseguiti quando l'utente clicca sulle icone) non lo vedo possibile, a meno che non faccia uso di "problemi" o "bachi" di cui presenti appunto su parti di SO o Driver di terze parti (che neppure sarebbero colpa di Microsoft)

A parte il ring 4 (che in realta è il 3), concordo.

Originariamente inviato da ConteZero

Intanto hai confuso un OS col suo kernel... poi hai detto che XP è monolitico (il suo kernel non lo è, chiedi a Digital Research... lo è il resto a causa dell'uso spregiudicato dei lock).

Hum. Avresti qualche informazione su questo uso dei lock?

Originariamente inviato da ConteZero

Non cambia nulla.
I "buchi" non sono falle evidenti del software (altrimenti i programmatori le avrebbero già trovate), sono glitch del codice compilato... quindi del sorgente te ne fai relativamente poco (a meno di non dover CHIUDERE quella falla).

Io penso proprio di sì, invece.

Originariamente inviato da ConteZero

Ma tu hai idea di quanto dovresti leggere per trovare "a mano" un buffer overflow ?

Ma tu hai idea del lavoro che fanno i cacciatori di bug con Windows? Analizzare il disassemblato della API interne di Windows non è esattamente la stessa cosa di spulciarsi i sorgenti originali, magari con tanto di commenti.

[gugoXX]

Originariamente inviato da cdimauro

Era Andrew Tanenbaum.

A parte il ring 4 (che in realta è il 3), concordo.

Hai ragione, era Tanenbaum, non Dijkstra. La memoria.
E anche sul ring. E' il quarto ring, ovvero il numero 3. Ma e' lo stesso errore dei cristiani, sono in buona compagnia

[ConteZero]

Originariamente inviato da cdimauro

Benissimo, ma alla fine si tratta di verificare ciò che ciò ed eseguire apposito codice. Che non mi pare poi tutta questa complicazione, specialmente per chi ha sviluppato skill adeguate (e chi scrive virus e trojan non sono gli ultimi arrivati).

Il punto è che l'universo windows è assimilabile ad un pianeta dove vivono milioni di persone aventi solo una decina di cariotipi (ie, milioni di copie di dieci persone)... fare un virus che sfrutta una fragilità genetica è facilissimo.
Il pianeta linux, oltre ad essere molto meno popolato, è anche molto più "vario", per cui fare un virus che possa fare le stesse "vittime" è praticamente impossibile.

In una distro non hai solo il kernel, per cui questa differenziazione con Windows lascia il tempo che trova, perché per essere usabile hai bisogno di QUALCOSINA di più del kernel.

Tutto ciò che serve per far partire un s.o., rientra nel discorso dei componenti "minimali" di cui parlavo prima.

Il "minimale" per linux è assimilabile al minimo assoluto, proprio perché si può "mettere a dieta" una distribuzione linux fino a farla entrare su un floppy... il minimale di windows non esiste, perché windows è solo quei cinque flavor per quelle tre versioni in commercio.
Indovina quale delle due come "minimo assoluto" è meno attaccabile ?
Quello che non si trascina dietro tonnellate di roba.

Questo non è affatto detto. Dipende dalle falle. Inoltre, ad esempio, se ne trovo una nuova... al 99,999% è disponibile per qualunque versione di Linux.

Si, ma a seconda della libreria, della versione, dell'os e dei layer sottostanti il codice d'exploit può variare in modo anche abbastanza radicale.
Il che può voler dire "tutte le macchine fino ad oggi possono essere bucate" -a patto di scrivere un inject personalizzato per ogni tupla "servizio/liberia/libreria/.../libreria/versione kernel/piattaforma".

Hum. Avresti qualche informazione su questo uso dei lock?

Dovrei cercare e non c'ho voglia

Ma tu hai idea del lavoro che fanno i cacciatori di bug con Windows? Analizzare il disassemblato della API interne di Windows non è esattamente la stessa cosa di spulciarsi i sorgenti originali, magari con tanto di commenti.

E, nonostante questo, buona parte dei bug viene da compilazioni/ottimizzazioni che lasciano aperte delle falle involontarie.
Senza andare lontani la falla con la quale hanno aperto la 360 è un errore di compilazione che produce un codice che azzera solo i primi 32 bit di un registro.

[cdimauro]

Originariamente inviato da ConteZero

Il punto è che l'universo windows è assimilabile ad un pianeta dove vivono milioni di persone aventi solo una decina di cariotipi (ie, milioni di copie di dieci persone)... fare un virus che sfrutta una fragilità genetica è facilissimo.
Il pianeta linux, oltre ad essere molto meno popolato, è anche molto più "vario", per cui fare un virus che possa fare le stesse "vittime" è praticamente impossibile.

Difficile sì, ma impossibile proprio no. D'altra parte se ci sono stati (e ci saranno) siti con Linux che vengono violati sfruttando delle falle, lo stesso approccio può essere sfruttato dai virus.

Il "minimale" per linux è assimilabile al minimo assoluto, proprio perché si può "mettere a dieta" una distribuzione linux fino a farla entrare su un floppy... il minimale di windows non esiste, perché windows è solo quei cinque flavor per quelle tre versioni in commercio.
Indovina quale delle due come "minimo assoluto" è meno attaccabile ?
Quello che non si trascina dietro tonnellate di roba.

Questo lo so, ma è anche vero che di Linux hai i sorgenti, e puoi spulciarteli a caccia di falle non trovate. Di Windows no, e andare a caccia di falle disassemblando codice richiede skill molto più elevate.

Penso sia molto più semplice scrivere dei tool di generazione automatica di codice che tiene in considerazione delle falle a seconda delle versioni del software.

Si, ma a seconda della libreria, della versione, dell'os e dei layer sottostanti il codice d'exploit può variare in modo anche abbastanza radicale.
Il che può voler dire "tutte le macchine fino ad oggi possono essere bucate" -a patto di scrivere un inject personalizzato per ogni tupla "servizio/liberia/libreria/.../libreria/versione kernel/piattaforma".

Cosa che, come dicevo, si può anche automatizzare. Inoltre non hai bisogno di scrivere n-mila versioni degli exploit, ma puoi anche realizzare un sistema che vada a caccia di queste informazioni, ove possibile, e le sfrutti, diminuendo di gran lunga il numero di possibilità.

Inoltre, come dicevo prima, se scopri una falla nel kernel, hai buone possibilità di sfruttarla a tuo piacimento.

Dovrei cercare e non c'ho voglia

OK

E, nonostante questo, buona parte dei bug viene da compilazioni/ottimizzazioni che lasciano aperte delle falle involontarie.
Senza andare lontani la falla con la quale hanno aperto la 360 è un errore di compilazione che produce un codice che azzera solo i primi 32 bit di un registro.

Mumble. Strano. Un errore di questo mi pare difficilmente generabile da un compilatore, specialmente considerando la vasta e lunga esperienza che MS ha nella loro scrittura.

Lo vedo più come un errore umano, da parte di uno sviluppatore che ha scritto un pezzo di codice che gira nella 360.

Hai per caso qualche link sull'argomento? Così ci butto un occhio, che l'argomento m'interessa molto.

[trallallero]

Originariamente inviato da cdimauro

Hum. Avresti qualche informazione su questo uso dei lock?

Ne so poco, ma effettivamente XP (uno dei 3 che ho) ha una patch aggiuntiva di nome unlocker che serve soprattutto per i file multimediali.
Se copio per esempio un mp3 da una chiavetta all'HD, poi devo usare dal menu di Windows "Unlocker" altrimenti non riesco a fare l'unmount.
Stessa cosa sull'HD, se voglio cancellare un .avi o .mp3 puntualmente è lockato e lo devo unlockare come detto prima.

[ConteZero]

Originariamente inviato da cdimauro

Difficile sì, ma impossibile proprio no. D'altra parte se ci sono stati (e ci saranno) siti con Linux che vengono violati sfruttando delle falle, lo stesso approccio può essere sfruttato dai virus.

Si ma con dei rootkit, con gente che interattivamente lancia comandi e simili per sfruttare le falle... siamo anni luce dal fare il programma stile "virus" che "fa da sè".

Questo lo so, ma è anche vero che di Linux hai i sorgenti, e puoi spulciarteli a caccia di falle non trovate. Di Windows no, e andare a caccia di falle disassemblando codice richiede skill molto più elevate.

Nella pratica è inutile guardare i sorgenti per cercare le falle, le falle le cerchi sempre dal disassemblato (e ci sono tool appositi che aiutano a trovare tali falle) perché è facile che ad introdurle sia qualche ottimizzazione del compilatore.
Per i sorgenti... sigh... windows 2000, parlando con quelli di microsoft, l'hanno dato in visione (anni addietro) a sedici università, e solo quattro sono riuscite a ricompilarlo... trattavasi di sedici CD di sorgenti.

Penso sia molto più semplice scrivere dei tool di generazione automatica di codice che tiene in considerazione delle falle a seconda delle versioni del software.

Cosa che, come dicevo, si può anche automatizzare. Inoltre non hai bisogno di scrivere n-mila versioni degli exploit, ma puoi anche realizzare un sistema che vada a caccia di queste informazioni, ove possibile, e le sfrutti, diminuendo di gran lunga il numero di possibilità.

Si, ma un virus dovrebbe comunque armarsi di "rampini multipli" e fare le euristiche per capire "che bestia" stà tentando di arpionare... capirai che come virus comincia a diventare abbastanza grassottello

Inoltre, come dicevo prima, se scopri una falla nel kernel, hai buone possibilità di sfruttarla a tuo piacimento.

Questo ovunque, c'è però il problema che non tutte le falle sono sfruttabili (mi ricordo una discussione su un tizio che aveva trovato un buffer overflow in un frammento di codice eseguibile solo da root) e che comunque accederci e sfruttarle a dovere non è facile.

OK

Per esempio : http://channel9.msdn.com/shows/Going...spatcher-Lock/

Mumble. Strano. Un errore di questo mi pare difficilmente generabile da un compilatore, specialmente considerando la vasta e lunga esperienza che MS ha nella loro scrittura.

E'l'errore tipico che si ha ad usare una variabile con una dimensione diversa dalla lunghezza del registro che deve contenerla.

Lo vedo più come un errore umano, da parte di uno sviluppatore che ha scritto un pezzo di codice che gira nella 360.

Hai per caso qualche link sull'argomento? Così ci butto un occhio, che l'argomento m'interessa molto.

Qui si descrive l'hack : http://free60.git.sourceforge.net/gi...ck.txt;hb=HEAD (abbastanza complicato, decisamente affascinante)
Qui si descrive la vulnerabilità : http://www.securityfocus.com/archive.../30/0/threaded

[cdimauro]

Originariamente inviato da trallallero

Ne so poco, ma effettivamente XP (uno dei 3 che ho) ha una patch aggiuntiva di nome unlocker che serve soprattutto per i file multimediali.
Se copio per esempio un mp3 da una chiavetta all'HD, poi devo usare dal menu di Windows "Unlocker" altrimenti non riesco a fare l'unmount.
Stessa cosa sull'HD, se voglio cancellare un .avi o .mp3 puntualmente è lockato e lo devo unlockare come detto prima.

No, quello è un altro tipo di lock (lock su risorsa).

Quello di cui parlavamo è un lock software, utilizzato nel codice per arbitrare l'accesso a una struttura dati in memoria.

Originariamente inviato da ConteZero

Si ma con dei rootkit, con gente che interattivamente lancia comandi e simili per sfruttare le falle... siamo anni luce dal fare il programma stile "virus" che "fa da sè".

I rootkit ci sono per tutte le piattaforme, e sono un'altra cosa rispetto a un virus.

Nella pratica è inutile guardare i sorgenti per cercare le falle, le falle le cerchi sempre dal disassemblato (e ci sono tool appositi che aiutano a trovare tali falle) perché è facile che ad introdurle sia qualche ottimizzazione del compilatore.

Se è così, quale sarebbe il vantaggio di avere sorgenti per trovare più facilmente le falle, come viene sostenuto dai fanatici dell'open source?

Comunque io le falle le trovo più comodamente con un sorgente davanti.
Tanto i compilatori C/C++ di sicuro di default non fanno controlli sugli indici degli array e sulla validità dei puntatori, che sono le cause prime dei buffer overflow.

Per i sorgenti... sigh... windows 2000, parlando con quelli di microsoft, l'hanno dato in visione (anni addietro) a sedici università, e solo quattro sono riuscite a ricompilarlo... trattavasi di sedici CD di sorgenti.

C'è una parte del kernel (il 3%, se non ricordo male) che non è mai stata rilasciata alle università: ecco perché non ci sono riusciti.

Si, ma un virus dovrebbe comunque armarsi di "rampini multipli" e fare le euristiche per capire "che bestia" stà tentando di arpionare... capirai che come virus comincia a diventare abbastanza grassottello

Bisogna vedere come lo scrivi, e in quale linguaggio.

Questo ovunque, c'è però il problema che non tutte le falle sono sfruttabili (mi ricordo una discussione su un tizio che aveva trovato un buffer overflow in un frammento di codice eseguibile solo da root) e che comunque accederci e sfruttarle a dovere non è facile.

Dipende da quello che si vuole fare. Per falla sfruttabile intendo una che come minimo permette di eseguire arbitrariamente del codice.

Poi se vogliamo spingerci più in là, ne serve una che consenta una priviledge escalation.

Tutte considerazioni che valgono per qualunque s.o., in ogni caso.

Per esempio : http://channel9.msdn.com/shows/Going...spatcher-Lock/

Qui parla di sistemi con parecchi core (più di 64), che è già un'altra cosa e non proprio a portata di mano.

Infatti: "Prior to Windows 7 (and therefore Windows Server 2008 R2) the Windows kernel dispatcher employed a single lock, the dispatcher lock, which worked well for a relatively small numbers of processors (like 64)."

E'l'errore tipico che si ha ad usare una variabile con una dimensione diversa dalla lunghezza del registro che deve contenerla.

Qui si descrive l'hack : http://free60.git.sourceforge.net/gi...ck.txt;hb=HEAD (abbastanza complicato, decisamente affascinante)
Qui si descrive la vulnerabilità : http://www.securityfocus.com/archive.../30/0/threaded

Grazie per i link. Appena ho un po' di tempo me li spolpo (adesso sto cascando dal sonno, e tra un po' vado a nanna).

[cdimauro]

Ho letto i link e quanto pare si tratta di un errore nella routine di validazione del codice presente nella SysCall.

Quindi, come immaginavo, un errore umano, che non dipende dal compilatore o dall'uso di variabili a 32 o 64 bit: chi ha scritto quella routine di dispatching ha "semplicemente" sbagliato a utilizzare un'istruzione, utilizzandone una che fa un confronto a 32 bit anziché a 64 bit.

[AntonioBO]

Come al solito, a parte i discorsi tecnici in cui non c'ho capito una beneamata fava e con ciò non sto mancando di rispetto a chi li ha fatti:beati voi che sapete farli, anche a me sarebbe piaciuto entrare più specificamente negli argomenti, ma ho scelto strade diverse (dicesi percorso giuridico.....), ci si dimentica nella giusta enfasi della disquisizione informatica che parliamo di un sistema operativo come "Finestre..." che è a pagamento e tanto (la versione ultimate retail si aggira intorno ai 300 euro) e dovrebbe sfiorare la perfezione. Ovviamente i S.O. essendo fatti fagli umani, possono essere vitima di dimenticanze, ma se faccio pagare agli utenti un sacco di soldi (ammettendo che qualcuno sia così folle da comprarlo e dubito, salvo le licenze oem dei pc imposte... dall'alto...), non posso propinare un servizio azzoppato e potenzialmente pericoloso con bug anche gravi soprattutto nel navigatore per la rete. Di linux dite pure quello che volete:è difficile, è primitivo, è incomprensibile (?) eccc.... ma è un sistema per cui non si tira fuori un soldo e te lo puoi copiare e distribuire come ti pare. Per cui se ti piace te lo prendi, se no paghi (diciamo così... salvo mulo e torrent...... ehm.....) e ti installi windows che non puoi/potresti copiare distribuire ecc..... Le cose stanno così ed è questa la verità.

[cdimauro]

La fiera dei luoghi comuni.

Hai detto tu stesso che non hai competenze in materia, e continui a tirare fuori storie di s.o. che dovrebbero "sfiorare la perfezione" solo perché sarebbero a pagamento.

Non hai la minima idea di quel che sta dietro, fra teoria e pratica, alla scrittura del software, e ciononostante continui a parlare.

L'abbiamo capito che ti piace di più Linux perché è "gratis", "libero", e quello che vuoi tu, per quanto poco possano valere discorsi come questi che sono avulsi dal contesto e da una marea di considerazioni. E che Windows lo vedi come la peste perché "costa", è nelle mani del signore del male, ecc. ecc.

Adesso, cortesemente, potresti almeno riflettere sul "contributo" che stai dando alla discussione, e se non sia il caso di smettere di inquinare il thread con affermazioni che lasciano il tempo che trovano?

Grazie

[ConteZero]

Originariamente inviato da cdimauro

Ho letto i link e quanto pare si tratta di un errore nella routine di validazione del codice presente nella SysCall.

Quindi, come immaginavo, un errore umano, che non dipende dal compilatore o dall'uso di variabili a 32 o 64 bit: chi ha scritto quella routine di dispatching ha "semplicemente" sbagliato a utilizzare un'istruzione, utilizzandone una che fa un confronto a 32 bit anziché a 64 bit.

Perché, tu pensi che il codice di validazione sia stato scritto in assembly ?

[cdimauro]

Ho visto il codice, e a naso direi di sì, perché mi sembra codice ben ottimizzato.

Poi i compilatori moderni generano dell'ottimo codice, e potrebbe anche essere questo il caso, eh!

Ma a supporto della mia tesi c'è anche un fatto: che lo stesso registro sia usato prima con un confronto a 32 bit, e poi invece con un'operazione a 64 bit.

Se il codice non fosse assembly ma, ad esempio, C vorrebbe dire che il compilatore è strabacatissimo, perché per lo stesso tipo di dato (il contenuto del registro che contiene l'indice dell'API di sistema da chiamare, che sarà identificato da una parametro, variabile, o quant'altro) ha generato prima un'istruzione che vi accede a 32 bit, e poi una che vi accede a 64 bit.

Altra cosa, stiamo parlando del codice che deve gestire una syscall, cioè una la chiamata di sistema (quindi qualcosa che fa passare la modalità d'esecuzione dallo user mode in cui gira normalmente l'applicazione, al supervisor mode in cui gira normalmente un kernel), e sempre "a naso" direi che l'handler per la sua gestione sia scritto proprio in assembly (poi internamente può richiamare codice C, C++, o quant'altro, sia chiaro).

Il tutto molto IMHO e potrei anche sbagliarmi, ma diciamo che sono estremamente convinto della mia ipotesi.

[ConteZero]

Originariamente inviato da cdimauro

Ho visto il codice, e a naso direi di sì, perché mi sembra codice ben ottimizzato.

Poi i compilatori moderni generano dell'ottimo codice, e potrebbe anche essere questo il caso, eh!

Ma a supporto della mia tesi c'è anche un fatto: che lo stesso registro sia usato prima con un confronto a 32 bit, e poi invece con un'operazione a 64 bit.

Se il codice non fosse assembly ma, ad esempio, C vorrebbe dire che il compilatore è strabacatissimo, perché per lo stesso tipo di dato (il contenuto del registro che contiene l'indice dell'API di sistema da chiamare, che sarà identificato da una parametro, variabile, o quant'altro) ha generato prima un'istruzione che vi accede a 32 bit, e poi una che vi accede a 64 bit.

Altra cosa, stiamo parlando del codice che deve gestire una syscall, cioè una la chiamata di sistema (quindi qualcosa che fa passare la modalità d'esecuzione dallo user mode in cui gira normalmente l'applicazione, al supervisor mode in cui gira normalmente un kernel), e sempre "a naso" direi che l'handler per la sua gestione sia scritto proprio in assembly (poi internamente può richiamare codice C, C++, o quant'altro, sia chiaro).

Il tutto molto IMHO e potrei anche sbagliarmi, ma diciamo che sono estremamente convinto della mia ipotesi.

Computa il fatto che Microsoft non ha grandi menti esperte di assembly PPC, non c'ha mai lavorato precedentemente.
E'facile che abbia semplicemente usato una versione "ottimizzata" di un compilatore "standard" passatole da IBM insieme ai progetti di Xenon.
Per il resto trovo difficile che si compia un errore del genere "a mano", è troppo palese.

[cdimauro]

Al contrario, è facile che possa accadere proprio perché ce l'errore umano (ne so qualcosa io, visto che per anni ho programmato quasi esclusivamente in linguaggio macchina e assembly).

Comunque alla MS hanno esperienza con diverse architetture. Non credo che manchino ingegneri che conoscano quella PPC.

Poi come errore dovuto al compilatore lo trovo estremamente improbabile.

[ConteZero]

Originariamente inviato da cdimauro

Al contrario, è facile che possa accadere proprio perché ce l'errore umano (ne so qualcosa io, visto che per anni ho programmato quasi esclusivamente in linguaggio macchina e assembly).

Tu non sei Microsoft... quello che segue la progettazione dell'XBox 360 (specie sul versante sicurezza) è stato attentamente esaminato da ben più che un gruppo d'analisti di codice.

Comunque alla MS hanno esperienza con diverse architetture. Non credo che manchino ingegneri che conoscano quella PPC.

Per Microsoft PPC è un architettura nuova.

Poi come errore dovuto al compilatore lo trovo estremamente improbabile.

Basta che il compilatore, non abbastanza sveglio, riceva dal sorgente un dato a 32 bit.
Se poi l'exception entry point è scritto in un codice ed il gestore delle syscall è scritto in un altro codice (es perché se ne occupavano "squadre" diverse) è facile che la compilazione sia "differita" e l'ambiguità non sia "saltata all'occhio".

[Unrue]

Originariamente inviato da cdimauro

La filosofia open source non ha dimostrato proprio niente. Se sei al corrente di una dimostrazione formale, fammelo sapere che me la vado a leggete, ma per favore: non tirare fuori la famigerata "legge" di Linus che è soltanto una bufala.

Ma scusami, se un codice è sotto gli occhi di migliaia di persone, è molto più probabile trovare un bug e correggerlo. Se invece è sotto gli occhi di pochi sviluppatori, allora le probabilità diminuiscono. Questo non significa ovviamente che il codice open source sia perfetto, ma che la tempistica di correzione dei bug è potenzialmente molto più veloce. Se tu sviluppi un progetto ma tieni i codici tutti per te, solo tu puoi scovare i bug da codice e correggerli, se li condividi con altri, molte altre persone possono trovare un bug e segnalarlo.

Originariamente inviato da cdimauro

Tanto per farti capire che non c'è nulla di "dimostrato", ti faccio un controesempio. Supponiamo che tu abbia due centrali nucleari nei pressi della residenza di George Bush jr. da collegare all'esterno. Supponiamo che entrambe facciano uso di un sistema open source, ma la prima espone tranquillamente il codice, mentre la seconda no, e come unica differenza rispetto alla prima abbia provveduto soltanto a offuscare le scritte che appaiono all'esterno (esempio: invece di Linux Debian 5.02, Apache 2.2, ecc. ecc. si presenti come NonSonoCazziTuoi 1.0 rock stable, NonSonoAncoraCazziTuoi 1.0 rock stable, ecc. e con tutte le altre scritte cambiate e ridotte all'osso).

Se è open source e non lo espone, non è open source..