Ricerca Microsoft, ecco il punto sulla sicurezza

[WarDuck]

Originariamente inviato da wlog

no no non sto parlando di attacchi. Sto parlando di te che magari per sbaglio scrivi una locazione di memoria non allocata... se lo fai troppe volte in un modo particolare sotto win crasha, sotto linux interrompe l'esecuzione.

Crasha cosa, il SO o l'applicazione (che cmq termina?).

Originariamente inviato da wlog

Fallire ovviamente vuol dire compiere un operazione non legale, e per non succedere nulla intendo che le altre locazioni di memoria non si corrompono.

In Win si corrompono addirittura? Secondo me come molti utenti sono rimasti indietro negli sviluppi di Linux, te sei rimasto indietro nello sviluppo di Windows, credendo ancora di trovarti davanti Windows 98.

A meno che ti riferissi ad eventuali falle che possono portare a corruzione della memoria, perché non mi risulta che un processo che in windows viene terminato in automatico (cosa che tu chiami crashare, che secondo me è un concetto un po' diverso) causi corruzione della memoria di per se.

[wlog]

Originariamente inviato da WarDuck

Crasha cosa, il SO o l'applicazione (che cmq termina?).

il SO

In Win si corrompono addirittura?

Beh succede in tutti i sistemi operativi.

Ti spiego: Tu stai risolvendo un sistema di equazioni lineari vincolate , quindi diciamo che hai 12 gb di ram (come il mio pc) e puoi tenere circa 20.000 variabili in ram (lasciando 1 gb al SO e usando tutto il resto). Su un supercalcolatore il modello non farà nientaltro che scalare tranquillamente. Immaginiamo di lavorare in C, e supponiamo che il calcolo ci impieghi 4*(numero di variabili ^3/ Gflops) secondi (dato reale). Io ho un quad core da 2 ghz e ci impiego circa 10 ore, quindi non è un tempo da sottovalutare. Se voglio n variabili, avrò bisogno di n*n locazioni di memoria, con almeno 32 bit cadauna. Si cerca di far rimanere tutto in ram, cosi l'applicazione scala piu dolcemente quando si fa girare su piu processori.

Ora tu per un bug nel tuo codice provi a scrivere la posizione 11 di un vettore lungo 10. Succede, non è nulla di cosi grave, se il programma è veloce da eseguire. Se però sei al 80% di calcolo di un task complesso la cosa ti fa girare un po le scatoline.... Quindi gli ingegnieri hanno provato ad inventarsi dei modi per salvare baracca e burattini. Iniziamo a capire cosa succede:

La memoria del processore è divisa in settori, ed ogni settore è diviso in matrici bi o tri dimensionali (a seconda dell'architettura) ognuna contente una locazione da 1 bit di memoria. Ovviamente noi considereremo sempre 32 bit alla volta.
Quando tu dichiari un vettore lungo 10, ti prendi fisicamente nella memoria 10 locazioni di spazio, e il processore sa che sono riservate per te: per questo in C non esiste la locazione dinamica della memoria: perchè è una cosa impossibile da fare. Il processore HA bisogno di sapere in ogni momento quali celle sono usate e quali no. In realtà il workaround nei normali programmi è quello di: -fermare il calcolo -allocare un nuovo vettore della lunghezza desiderata - copiare il vecchio vettore nel nuovo - eventualmente cancellare il vecchio -dare l'ok al processore per ripartire. Il problema è che questo workaround è LENTOOO.... e per questo molti programmatori (come me) preferiscono usare il C quando molta potenza bruta è richiesta.
Dicevamo quindi che il mio programma prova a scrivere l'11esima cella di un vettore lungo 10, il problema è che in quella cella ci potrebbe essere qualcos'altro e per questo tu stai compiendo un azione illegale che fa corrompere la memoria.
A quel punto il programma dovrebbe terminare (a meno che non usi visual "bleah" basic) e possono succedere varie cose:
-Quella cella non era usata, ok no problemo. Esistono delle tecniche che salvano una copia della ram sull'hard disk, salvano il punto a cui sei arrivato, e poi lo studente certosino andrà ad analizzarsi il memory dump, lo riavvolgerà all'indietro fino al punto in cui l'errore potrà venir evitato, corregge il codice macchina e fa ripartire il programma. Ho visto e letto molto sull'argomento, comprese le promesse di molti venditori, ma non l'ho mai visto funzionare in un caso reale, la parte difficile è correggere il codice mantenendolo compatibile con il vecchio memory dump, è possibile farlo solo usando particolari astrazioni sui dati.
-Quella cella era usata, magari da qualcosa di importante, che quando come me usi tutta la memoria è il caso piu frequente. Che ne sò, chiami una libreria matlab, che a sua volta chiama una libreria opengl, che a sua volta chiama una libreria di sistema importante (caso reale), e in quella locazione di memoria c'era qualcosa di quella libreria. Il SO in teoria dovrebbe impedirti di fare danni, ma in realtà data la libertà che il linguaggio C ha in realtà il tuo programma fa davvero dei danni. Allora per questo i SO dividono la memoria in macro-settori, o space, e due space non dovrebbero essere linkati tra loro. Perchè quando corrompi una cella di memoria si corrompono automaticamente tutte le celle linkate, e se linkata abbiamo una libreria di sistema otteniamo un bel crash.
Sotto linux, essendo open source, si possono mettere in concerto i vari driver e il tuo software in modo che il kernel space e lo user space siano tra loro separati, e collegabili tra di loro solo attraverso speciali chiamate. Questo garantisce che le tue esecuzioni, a meno di bug nel compilatore o nel SO, non saranno mai in grado di farti crashare la macchina. E ti assicuro che far riavviare magari 128 processori su una macchina non è bello, perchè quasi sicuramente vorrà dire che avrai spezzato la rete in 2 rendendo automaticamente inservibili TUTTI i processori.
Sotto windows questo concerto di intenti non è altrettanto facilmente raggiungibile, perchè quando microsoft scriveva il codice non aveva accesso ai driver ati/nvidia, e viceversa. Stessa cosa per tutti gli altri pezzi di hardware. Quindi sotto windows andiamo a trovare nel kernel space pezzi di software che starebbero meglio nello user space, perchè magari vengono chiamati durante l'esecuzione di codice (matlab-opengl-SO è quello che incontro piu spesso sulle macchine monoprocessore) e fanno crashare la macchina, facendoti perdere tutto il lavoro.

[wlog]

Originariamente inviato da cavaliereombra

Ma dove? Hai detto delle sciocchezze, come il fatto che Windows non sia usato come server se non che per "Sono tutte soluzioni piccole, in cui il budget a disposizione è cosi piccolo da costringere ad usare soluzioni già sviluppate, come per l'appunto windows. E comunque le banche in maggior parte usano linux."

Beh è vero, e tutti gli sviluppatori fanno questa scelta basata sulla quantità di risorse/tempo a disposizione. E' il motivo per cui esistono i linguaggi di alto livello: Posso spendere anni scrivendo il codice direttamente in assembler e avere del codice che va alla velocità della luce, oppure giorni in C e avere del codice velocissimo, oppure giorni in java e avere del codice medio.

Posso anche decidere da dove partire: posso riscrivermi tutte le librerie, posso usare librerie o codice sviluppato da terzi. E il sistema operativo è tra questi.

Quando io devo realizzare un programma e devo scegliere se usare matlab o C penso ad una cosa: quanto sarà lo speedup. Anche se il nostro professore ci ha mostrato un caso in cui passare da Matlab a C porta uno speedup teorico del 1200% (1200, però confrontando 4 processori contro uno, quindi la cache era molto piu grande) io so che C mi richiederà molto tempo, mentre matlab userà molto tempo del processore, che a me non costa niente (se non attendere, ma nel frattempo posso fare altro).

Stessa cosa per uno che fa elaborazione immagini, possono essere degli utenti amatori o piccole imprese, e quindi useranno tendenzialmente photoshop e combriccola (non me ne intendo personalmente).

O magari sono la pixar, devono elaborare tonnellate di roba, e quindi gli conviene scrivere del codice ad hoc appoggiandosi alla flessibilità di linux. Ciò non vuol dire che non useranno piu MacOs o Windows per i lavoretti veloci, cosi come io uso matlab. E' tutta una questione di analizzare il rapporto costo/benefici

http://linux.slashdot.org/article.pl...51250&from=rss

Innanzitutto mi chiedo in quali banche hai lavorato (nessuna, lo so già),

che arroganza amico. Ma come fai a sapere della mia vita?

Una volta una persona come te, che lavora in banca, mi disse:

"ma no, non è possibile, la nostra banca [unicredit] non bada a spese per quanto riguarda il pricing, abbiamo i migliori calcolatori e modelli che il mercato ci possa offrire"

Sai quando ho sentito questa frase?

4 settimane fa, a riguardo della crisi derivati

Questo perchè gli spiegavo che anche al Los Alamos National Laboratory usano delle approssimazioni nelle loro equazioni, approssimazioni che sono ben lontane dal caso ideale.

E tu mi avresti smontato? Va a studiare un po' cosa è lo sviluppo TDD peraltro prima di parlare di regression.

Sono andato a leggermi qualcosa sul TDD, in università mi hanno insegato qualcosa di simile come analisi terminale:

a) non c'è una correlazione tra sviluppo TDD e una migliore qualità del software:

http://theruntime.com/blogs/jacob/ar...-or-is-it.aspx

b) Esiste un teorema che dice che dato un programma p, non è possibile stabilire, a meno di programmi triviali, se il programma p terminerà per qualsiasi imput finito. Equivalentemente possiamo dire non è possibile scrivere codice i cui bug non crescano ALMENO linearmente con la quantità di codice.

Originariamente inviato da cavaliereombra

Fossi in te eviterei di parlare di cose che non conosco. Nello specifico mi chiedo come tu, studente di matematica con non mi pare esperienze lavorative, faccia a dire ciò. Anzi, lo so...

Sempre che ti interessa parlare del mondo del lavoro, se vuoi puoi venire a trovarmi in banca (suggerimento, da poco è la prima banca europea) e vedere che server si usano qui.

Come ti ho fatto vedere, per ora la ricerca pubblica in europa e nel mondo è davanti alla ricerca dei privati. Come macchine, come idee, e come risultati.

L'unica cosa in cui il privato primeggia sono i profitti. Esatto, e lo si è visto nelle settimane passate, come i modelli di pricing delle banche hanno fallito.

[_goofy_]

[WarDuck]

@wlog: aspetta un momento, tu dici che il dato si corrompe perché l'applicazione tenta di scrivere in una cella in cui non conosci il contenuto e questo lo so anche io, ma in questo il SO ti protegge che io sappia adottando meccanismi di memory protection no? Così facendo termina l'applicazione (il SO).

Cioè se provo a scrivere un programma che dici te in C++, C#, Java il programma semplicemente viene terminato dal SO ("il programma ha smesso di funzionare...").

Cmq con Vista hanno cominciato ad introdurre dei drivers in user space...

[wlog]

Originariamente inviato da cavaliereombra

E basi tutte le tue affermazioni su quanto ti ha riferito quel tuo amico?

Amico? Era una manager con uno stipendio a 5 zeri che era venuta in università per avere consulenza dal mio prof, ovviamente pagando.

Comunque a monte di tutto nel tuo ambito puoi essere bravo (e nessuno lo nega e di certo non ti vengo a fare lezioni su ciò su cui sei esperto... non ho l'arroganza di insegnare agli altri ambiti che conoscono molto meglio di me), ma se questo ha creato in te la falsa illusione di sapere tutto... è abbastanza "strano" che si venga a insegnare agli altri cosa è il TDD senza nemmeno averlo mai usato (ma solo dopo averne letto qualche documento), o venendo a parlare di realtà lavorative che manco si è mai vissuto. Detto questo, chiudo qui i miei interventi (reputo per nulla fruttuosa questa discussione che è nata in mezzo a fanboysmi irrefrenabili) e ti auguro tutto il bene nel mondo del lavoro.

Nel link che ti ho postato ti fa vedere che non esiste un legame provato tra programmazione TDD e qualità del codice. E non sono io a dirlo, ma le statistiche.

Comunque la maggior parte del codice che scrivo io è usa e getta, quindi il tuo modello non è applicabile perchè non esiste un risultato intermedio: io ho un obbiettivo, raggiunto quell'obbiettivo di solito il codice lo salvo nella casella mail e me ne dimentico.

[wlog]

Originariamente inviato da WarDuck

@wlog: aspetta un momento, tu dici che il dato si corrompe perché l'applicazione tenta di scrivere in una cella in cui non conosci il contenuto e questo lo so anche io, ma in questo il SO ti protegge che io sappia adottando meccanismi di memory protection no? Così facendo termina l'applicazione (il SO).

Cioè se provo a scrivere un programma che dici te in C++, C#, Java il programma semplicemente viene terminato dal SO ("il programma ha smesso di funzionare...").

Java ha la memoria managed e quindi non ti permette di fare ciò di cui parlavo.

Per quanto riguarda la protezione del OS: beh si hai ragione, il programma termina e il OS difende la memoria. Ma se quella routine per caso doveva dare in ritorno un valore ad una importante libreria di sistema? sei fregato.

E comunque anche in java o c sharp esistono modi molto piu subdoli del mio grezzo esempio per farlo accadere.

Cmq con Vista hanno cominciato ad introdurre dei drivers in user space...

Non è un fattore positivo. I driver devono stare in kernel space perchè vengono usati spesso e servono a costruire l'astrazione dell'hardware che tutti i programmi usano. L'obbiettivo è quel concerto di intenti, che per forza di cose col software closed è irraggiungibile.

[WarDuck]

Originariamente inviato da wlog

Java ha la memoria managed e quindi non ti permette di fare ciò di cui parlavo.

Era per dire, è addirittura meglio C# poiché in modalità Debug con Visual Studio ad esempio gestisce le eccezioni direttamente nell'ide e ti seleziona in quale parte di codice è avvenuta l'eccezione (con tutti i dettagli del caso), potendo modificare il codice a run-time.

Originariamente inviato da wlog

Per quanto riguarda la protezione del OS: beh si hai ragione, il programma termina e il OS difende la memoria. Ma se quella routine per caso doveva dare in ritorno un valore ad una importante libreria di sistema? sei fregato.

Questo non lo so onestamente, penso che dipenda tutto da come è strutturato l'OS in questo caso e le chiamate a librerie.

Originariamente inviato da wlog

E comunque anche in java o c sharp esistono modi molto piu subdoli del mio grezzo esempio per farlo accadere.

Si ma quello che dico io, ci dev'essere un bug nel SO per far avvenire la corruzione di memoria giusto? Se i bug in tal senso sono risolti non ci dovrebbero essere problemi.

Originariamente inviato da wlog

Non è un fattore positivo. I driver devono stare in kernel space perchè vengono usati spesso e servono a costruire l'astrazione dell'hardware che tutti i programmi usano. L'obbiettivo è quel concerto di intenti, che per forza di cose col software closed è irraggiungibile.

Più che altro mi vorrai dire che sono più lenti in user space che in kernel space.

Il punto è che se crasha un driver in user space non sei costretto a riavviare la macchina.

Il concerto di intenti lo fai con gli sviluppatori hardware (e quindi di drivers), ovviamente avendo accesso al codice è tutta un'altra cosa, però bisogna vedere quali API mette a disposizione Windows in tal senso.

IMHO cmq l'informatica come tutte le scienze è fatte di compromessi, e io credo che Windows in tal senso sia uno dei più grandi compromessi (da un po' di tempo a questa parte) mai fatto nella storia dell'informatica.

Cmq ci sono già dei progetti in piedi per creare un nuovo SO da 0, come Midori, e personalmente non vedo l'ora di vedere che stanno combinando.

http://blogs.zdnet.com/microsoft/?p=1477

[wlog]

Originariamente inviato da WarDuck

Era per dire, è addirittura meglio C# poiché in modalità Debug con Visual Studio ad esempio gestisce le eccezioni direttamente nell'ide e ti seleziona in quale parte di codice è avvenuta l'eccezione (con tutti i dettagli del caso), potendo modificare il codice a run-time.

gnudebugger fa questo dal 1980 per tutti i linguaggi di programmazione

Si ma quello che dico io, ci dev'essere un bug nel SO per far avvenire la corruzione di memoria giusto? Se i bug in tal senso sono risolti non ci dovrebbero essere problemi.

No assolutamente. Se il linguaggio non è managed basta una istruzione scritta male. Sta al programmatore evitare che avvenga.

Un altro esempio è, se nel codice dichiari un puntatore, lo usi, poi ne cancelli il contenuto MA non cancelli il puntatore (errore comune) continuerai ad accumulare in memoria dati inutili. Se per caso non riavii mai la macchina, arriverai ad un certo punto in cui la ram finirà, causando il crash di windows.

E' quello che è successo al servizio di ambulanze londinese:

http://www.pcw.co.uk/computing/analy...h-again-expert

Da quando usano linux non hanno piu avuto di questi problemi.

Più che altro mi vorrai dire che sono più lenti in user space che in kernel space.

No no, un driver deve stare in kernel space perchè un programma a meno di casi eccezzionali non deve usarlo. I programmi devono vedere implementazioni trasparenti dell'hardware, sennò i programmatori impazzirebbero a stare dietro ogni singolo driver.

Il punto è che se crasha un driver in user space non sei costretto a riavviare la macchina.

Colpa di chi fa i driver: come vedi è una delle grosse limitazioni del mondo closed source, che impedisce l'adozione di windows per grandi server.

IMHO cmq l'informatica come tutte le scienze è fatte di compromessi, e io credo che Windows in tal senso sia uno dei più grandi compromessi (da un po' di tempo a questa parte) mai fatto nella storia dell'informatica.

Cmq ci sono già dei progetti in piedi per creare un nuovo SO da 0, come Midori, e personalmente non vedo l'ora di vedere che stanno combinando.

http://blogs.zdnet.com/microsoft/?p=1477

condivido.

[wlog]

Originariamente inviato da cavaliereombra

Hai trovato una fonte e l'hai riportata, ok, ma si dovrebbe anche conoscere ciò di cui si parla. Non basta una fonte per dire che è tutto una cagata.
Potrei inoltre spiegarti chi sono persone come Kent Beck e Martin Fowler e perché promuovono il TDD insieme allo sviluppo agile (che hanno co-fondato insieme ad altri eminenti personaggi dell'informatica mondiale), ma tanto temo non mi ascolteresti lo stesso e saresti capace di sostenere che sono degli sprovveduti perché hai trovato la fonte di cui sopra. Potrei spiegarti le differenze abissali tra uno sviluppo TDD e uno non a distanza di anni (e proprio a proposito di regressione... e non parlo di informazioni reperite su internet, ma di progetti "vissuti"), ma tanto anche qui credo che non ascolteresti nulla.

Date queste premesse mi fermo sul nascere.

Scusami se te lo dico, ma nella scienza non contano le persone ma i fatti. Lo so che tu puoi benissimo ammirare quei due programmatori perchè hanno fatto qualcosa di buono, ma ti ricordo che aver fatto delle cose intelligenti in passato non è legato con la qualità di quelle attuali: Einstein era il primo a remare contro la fisica quantistica.

Quello che conta sono i dati, gli studi, che sono fatti da organi imparziali (le università?). La statistica, se fatta bene, non mente....

Ancor di più si capisce perché tu abbia le idee tanto confuse. Meno si capisce come tu faccia a rapportare questa esperienza tanto particolare al mondo intero.

ma come prima mi parli di esperienze diverse, apertura mentale, e poi?...


comunque non puoi pretendere che sappia tutto di tutto... in fondo le cose ci mettono un po ad arrivare sui banchi delle università.... ancora di piu se come il TDD non è chiaro il loro beneficio....

Comunque se vai a vedere la definizione di wikipedia di TDD ti dice lei che il TDD è il peggior nemico del mio modello di sviluppo

[!fazz]

Originariamente inviato da WarDuck

@wlog: aspetta un momento, tu dici che il dato si corrompe perché l'applicazione tenta di scrivere in una cella in cui non conosci il contenuto e questo lo so anche io, ma in questo il SO ti protegge che io sappia adottando meccanismi di memory protection no? Così facendo termina l'applicazione (il SO).

Cioè se provo a scrivere un programma che dici te in C++, C#, Java il programma semplicemente viene terminato dal SO ("il programma ha smesso di funzionare...").

Cmq con Vista hanno cominciato ad introdurre dei drivers in user space...

Originariamente inviato da wlog

Java ha la memoria managed e quindi non ti permette di fare ciò di cui parlavo.

Per quanto riguarda la protezione del OS: beh si hai ragione, il programma termina e il OS difende la memoria. Ma se quella routine per caso doveva dare in ritorno un valore ad una importante libreria di sistema? sei fregato.

E comunque anche in java o c sharp esistono modi molto piu subdoli del mio grezzo esempio per farlo accadere.



Non è un fattore positivo. I driver devono stare in kernel space perchè vengono usati spesso e servono a costruire l'astrazione dell'hardware che tutti i programmi usano. L'obbiettivo è quel concerto di intenti, che per forza di cose col software closed è irraggiungibile.

se ti capica un indirizzamento al di fuori dai limiti con Java o .net semplicemente viene sollevata un'eccezione che permette di gestire il problema, quindi nessun blocco di s.o. e anche dell'applicazione , se gestisci in modo corretto il catch