Autore Topic: Muen Separation Kernel  (Letto 8428 volte)

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #15 il: 05 Dicembre 2014, 18:42:51 »
C'è anche un debugger molto comodo perché hacker / cracker / reverser-oriented, solo per Windows, ma adesso non ricordo il nome. Open source.

Offline TheKaneB

  • Human Debugger
  • *****
  • Post: 5292
  • Karma: +20/-23
    • Mostra profilo
    • http://www.antoniobarba.org
Re:Muen Separation Kernel
« Risposta #16 il: 05 Dicembre 2014, 18:52:41 »
C'è anche un debugger molto comodo perché hacker / cracker / reverser-oriented, solo per Windows, ma adesso non ricordo il nome. Open source.

ce ne sono diversi, uno che mi viene in mente è IDA Pro: https://www.hex-rays.com/products/ida/debugger/index.shtml
Supporta il deASM da praticamente tutte le architetture, molto utile per reversare firmware di cose esotiche, compresi microcontroller :)

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #17 il: 05 Dicembre 2014, 18:56:46 »
IDA lo conosco, e mi sembra ci fosse già ai tempi dell'Amiga (dove c'era anche il fantastico Resourcer).

Ma quello a cui mi riferivo è un altro.

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #18 il: 05 Dicembre 2014, 20:21:18 »
tornando a quanto dicevo, anche OpenBSD !

Citazione
OpenBSD took an interesting approach in the 3.8 release:

During the development cycle of the 3.8 release, changes were made to the malloc memory management functions. In traditional Unix operating systems, malloc allocates more memory by extending the Unix data segment, a practice that has made it difficult to implement strong protection against security problems. The malloc implementation now in OpenBSD makes use of the mmap system call, which was modified so that it returns random memory addresses and ensures that different areas are not mapped next to each other. In addition, allocation of small blocks in shared areas are now randomized and the free function was changed to return memory to the kernel immediately rather than leaving it mapped into the process. A number of additional, optional checks were also added to aid in development. These features make program bugs easier to detect and harder to exploit: instead of memory being corrupted or an invalid access being ignored, they often result in a segmentation fault and abortion of the process. This has brought to light several issues with software running on OpenBSD 3.8, particularly with programs reading beyond the start or end of a buffer, a type of bug that would previously not be detected directly but can now cause an error. These abilities took more than three years to implement without considerable performance loss and are similar in goals to that of the Electric Fence malloc debugging library by Bruce Perens.
Utilizza l'MMU, come spiegavo sopra. Ma con tutti i limiti che ha un sistema di paginazione della memoria, che è legato a dimensioni fisse delle pagine, per cui tanti piccoli sforamenti dei buffer non possono essere rilevati.

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #19 il: 05 Dicembre 2014, 20:44:59 »
MPX arriverà a breve. Vedremo se quelli di OpenBSD, sempre così attenti alla sicurezza, saranno i primi ad adottarla.

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #20 il: 13 Dicembre 2014, 21:21:38 »
Aggiungi -> prima o poi lo spazio finisce e devi effettuare il resize (quindi, di nuovo, allocare e deallocare).

C'è una grossa differenza però, se io ho una struttura dati, posso deallocare solo alcune parti (e non ci sono operazioni di copia, etc). Nel riallocare un blocco intero di memoria, per esempio com'è comune nei buffer anche due mega o più, non è detto che l'allocator possa garantirti un'allocazione del genere (ovvero in una zona "continua" se c'è molta frammentazione)
Me ne rendo conto, ma in generale l'allocazione di memoria può fallire a prescindere che venga usato il resize o meno.

Con uno spazio d'indirizzamento a 64-bit (e le MMU) è estremamente difficile che ciò accada, data l'enorme disponibilità di zone di memoria.
Citazione
Utilizzare strutture dinamiche, come liste concatenate (FIFO), richiede più memoria ed è decisamente più lento rispetto a un array con accesso diretto alle sue entry.
[...]
Però immagina il tipo PyList, un altro di quelli che viene spesso utilizzato (oppure StringIO, che viene molto usato per generare pagine web o, in generale, buffer di dati che vengono costruiti): cosa utilizzeresti per implementarlo in maniera efficiente a run-time?

A parte il fatto che per evitare continui realloc dovresti partire con un buffer molto grande e non credo che questo consumi meno memoria rispetto ad una struttura dati.
La politica di allocazione per le liste è questa:
Codice: [Seleziona]
/* This over-allocates proportional to the list size, making room
* for additional growth.  The over-allocation is mild, but is
* enough to give linear-time amortized behavior over a long
* sequence of appends() in the presence of a poorly-performing
* system realloc().
* The growth pattern is:  0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
*/
Per cui c'è una preallocazione, ovviamente, ma in genere è minore rispetto alla necessità di creare una struttura "Node" per ogni entry, che comporta come minimo l'aggiunta di un puntatore "di link". Un oggetto PyList in Python viene implementato come un array di puntatori, dove questi ultimi puntano alla struttura dell'oggetto referenziato. Utilizzando una lista concatenata semplice, invece, ci sarebbero il doppio di puntatori.

Confrontando i due approcci e tenendo conto del pattern di allocazione attualmente utilizzato, soltanto nel caso secondo caso (4) la soluzione adottata in CPython occuperebbe più di memoria (4 puntatori anziché 2 nel caso di una PyList di un solo elemento). In tutti gli altri casi il consumo sarebbe al massimo uguale, con una generale tendenza a essere nettamente minore. Inoltre non serve continuamente allocare (e alla fine deallocare) le strutture Node richieste da un'implementazione che faccia uso di liste.

Grazie alla preallocazione il resize viene ammortizzato, e ha tempo lineare, che mi sembra un buon risultato.

Tirando le somme, mi sembra che la soluzione utilizzata attualmente sia senz'altro migliore rispetto a una possibile che faccia uso di liste concatenate per evitare il resize. Senza tenere conto, poi, che l'accesso agli elementi è costante attualmente, mentre sarebbe lineare nel caso della lista concatenata.
Citazione
Non conosco in dettaglio StringIO, ma se non utilizzano una lista che per il sequential access è davvero molto efficiente, sicuramente stanno adottando un strategia di ottimizzazione sbagliata.
La struttura dati usata internamente è questa:
Codice: [Seleziona]
typedef struct {
  PyObject_HEAD
  char *buf;
  Py_ssize_t pos, string_size;
} IOobject;
Citazione
Attualmente la linear list è la struttura dati più veloce per il sequential access ed anche per il direct access (se si hanno poche entry, ma vedi dopo).
Non è il caso di oggetti come StringIO, dove il buffer contiene generalmente diversi dati (è per questo che viene usata questa struttura, altrimenti una normale lista sarebbe sufficiente allo scopo).

Inoltre, anche se più raramente utilizzato, un oggetto di questo tipo consente lo spostamento del "puntatore" all'interno del buffer, perché è sostanzialmente un file in memoria.

Nonostante tutto, sono d'accordo che utilizzare una classica lista concatenata sarebbe la soluzione migliore per come NORMALMENTE viene utilizzato l'oggetto (appendere roba fino a quando non si fa richiesta di ottenere una stringa unica che rifletta l'intero contenuto del buffer).

Il problema è cambiare l'implementazione attuale, mantenendo la stessa interfaccia (cioé far funzionare l'oggetto come un file, quando richiesto; ad esempio spostando il puntatore alla posizione attuale).
Citazione
Nel dictnotes.txt trovi che una possibile ottimizzazione per poche entry è il linear search, soprattutto se viene fatta in una zona continua di memoria. Mentre hashi la chiave, probabilmente il linear search ha già finito :-)
Infatti normalmente un dizionario utilizza poche entry già pre-allocate. ;)
Citazione
Per l'ottimizzazione del direct access, le tree sono abbastanza efficienti, ma in alcune librerie ho visto che molti per semplificare utilizzano sempre liste con skip-list (per saltare direttamente in alcune parti di memoria) ed offrono performance superiori alle tree (in realtà "dipende", ma il discorso è un po' lungo).
Comprendo perfettamente. L'idea del tree può essere interessante, ma è da valutare per bene.
Citazione
Ovviamente non sono paragonabili a delle zone di memoria allocate, ma come detto prima non è sempre possibile garantire una riallocazione più grande (ed il fatto che oggi il computer più scarso ha 4gb di ram, non è un motivo per adottare tale soluzione).
Su questo vedi sopra. Comunque la riallocazione si faceva già coi computer a 32 bit, senza particolari problematiche. D'altra parte dobbiamo tenere conto del fatto che il carico di lavoro è stato generalmente commisurato alla potenza di calcolo e allo storage a disposizione in un determinato momento.

In ogni caso oggi le architetture più comuni sono a 64-bit, e certi problemi possiamo sostanzialmente dimenticarceli. ;)
Citazione
E questa non è una cosa scoperta di recente, gli anni 80 sono stati gli anni del "linear search rediscovered". A tal proposito vorrei incollare una parte del libro The School of Niklaus Wirth, The Art of the Simplicity, un libro che da ex-Pascalliano ti consiglio cdimauro :-)
Codice: [Seleziona]
books_to_read.append("The School of Niklaus Wirth, The Art of the Simplicity");D
Citazione
Citazione
                                                          I still vividly remember the day that Wirth
decided to replace the elegant data structure used in the compiler’s symbol table
handler by a mundane linear list. In the original compiler, the objects in the symbol
table had been sorted in a tree data structure (in identifier lexical order) for fast
access, with a separate linear list representing their declaration order. One day Wirth
decided that there really weren’t enough objects in a typical scope to make the
sorted tree cost-effective. All of us Ph.D. students were horrified: it had taken time
to implement the sorted tree, the solution was elegant, and it worked well – so why
would one want to throw it away and replace it by something simpler, and even
worse, something as prosaic as a linear list? But of course, Wirth was right, and the
simplified compiler was both smaller and faster than its predecessor.
Molto interessante. Questo succede quando si tiene conto  del solo punto di vista teorico.
Citazione
All'inizio ero molto scettico, soprattutto dopo aver passato anni ad usare hash table e poi tree (che mi piacciono da morire) per ottimizzare il lookup o l'accesso,
La pensiamo allo stesso modo. :) Una ventina d'anni fa ho ideato e implementato (in Turbo Pascal 8)) un nuovo tipo di tree proprio per aiutarmi nella ricerca di stringhe per un mio algoritmo di compressione. Però oggi non so se lo rifarei, perché ho sputato sangue per implementarlo, con tutti quei casi particolari da gestire.
Citazione
ho dovuto fare vari benchmark e poi in alcuni programmi sostituire strutture dati incasinate con le liste per convincermi che dipende che dati vai a trattare, sono dannatamente veloci
Concordo. Anch'io sono per la soluzione più semplice per un problema. Se poi mi rendo conto che coi dati reali non funziona bene, ne cerco un'altra che meglio calzi in quel caso.

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #21 il: 14 Dicembre 2014, 09:07:25 »
Ma è per lavoro, o per "naturale" smanettamento da geek? ;D

Comunque riflettendo con quanto discusso con dsar m'è venuto in mente un algoritmo che stavo implementando una ventina d'anni fa in Turbo Pascal, e che potrebbe essere utile nel caso di strutture dati che contengono un numero dinamico di elementi. Non fa uso di riallocazione né di liste. E' un po' complicato, e infatti avevo implementato soltanto i casi di inserimento (append, sostanzialmente; il classico insert è problematico, ma lo è pure per un array o una normale lista), ma mancano ancora i casi per la rimozione.

Intanto me lo segno, perché potrebbe essere utile recuperarlo quando (SE) avrò un po' di tempo per smanettare di nuovo con CPython. :P Però va contro "The Art of the Simplicity": è decisamente complicato. ;D

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #22 il: 14 Dicembre 2014, 10:39:56 »
stavo pensando, secondo me i 64bit di indirizzamento non mitigano troppo il problema anche per il fatto che poi la MMU si vede tipicamente block_size + larghi e quindi non vorrei che finisse per i discorsi analoghi che si fanno sui filesystem dove per il block_allocator, se non si prendono utili provvedimenti, dopo un po' non riesce piu' a garantire in modo alcuno continuità di blocco. Per il filesystem non e' critico, semplicemente le prestazioni calano (e la frammentazione aumenta), per un memory allocator invece potrebbe essere meno piacevole, e chiaro cmq che dipende da come lavora la MMU e da quanta memoria usano le tabelle. Meno memoria usa per le tabelle e + ram deve gestire la MMU + grossi si fanno i block_size.
Vero, ma lo spazio d'indirizzamento è talmente grande che riesci sempre a trovare un buco in cui infilare il megabuffer, fosse anche di diversi GB. ;)

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #23 il: 14 Dicembre 2014, 10:55:46 »
Can be, ma non posso giudicare, perché non conosco cosa fa OS X e come usa effettivamente la RAM. Lo sai che sono Windowsiano. :P

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #24 il: 14 Dicembre 2014, 13:41:24 »
Non mi pare che Windows attui queste politiche. E' anche vero che con 16GB di RAM è difficile accorgersene. ;D

Offline Z80Fan

  • Administrator
  • Guru
  • *****
  • Post: 1671
  • Karma: +13/-2
    • Mostra profilo
    • http://z80fan.altervista.org
Re:Muen Separation Kernel
« Risposta #25 il: 14 Dicembre 2014, 16:02:29 »
@legacy:

sei sicuro che quelle misure non siano riferite alla memoria virtuale allocata, e non quella fisica?
Cioè, un programma può anche avere 16 GB di memoria virtuale allocata, ma avere solo 8 KB fisici mappati. :P

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #26 il: 14 Dicembre 2014, 16:18:28 »
Lo swap (su Windows 8.1) l'ho disattivato. Con 16GB è del tutto inutile. 8)

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #27 il: 14 Dicembre 2014, 16:24:40 »
Ho preso un desktop apposta: no limits. 8) Ed è pure silenziosissimo: se non fosse perché all'avvio le ventole le spara al massimo, non si sentirebbe mai.

Offline Z80Fan

  • Administrator
  • Guru
  • *****
  • Post: 1671
  • Karma: +13/-2
    • Mostra profilo
    • http://z80fan.altervista.org
Re:Muen Separation Kernel
« Risposta #28 il: 14 Dicembre 2014, 16:35:18 »
Lo swap (su Windows 8.1) l'ho disattivato. Con 16GB è del tutto inutile. 8)
Lo volevo fare anche sul mio (sia su Windows che su Linux): 6 GB non sono mai riuscito a riempirli, tranne nel caso in cui avevo per sbaglio creato un ciclo infinito che allocava memoria a ripetizione. ;D

Sai dirmi come posso disattivarlo, in Windows 8.1? E' un'operazione indolore?

beati voi che potete  :D

Ho trovato questo, potresti provarlo:
http://wiki.summercode.com/how_to_disable_or_enable_swapping_in_mac_os_x
(ho visto anche altri link ma dicono tutti la stessa cosa)

Offline cdimauro

  • Human Debugger
  • *****
  • Post: 4291
  • Karma: +7/-95
    • Mostra profilo
Re:Muen Separation Kernel
« Risposta #29 il: 14 Dicembre 2014, 16:43:30 »
Esplora risorse. Tasto destro su Computer. Proprietà. Proprietà di sistema avanzate. Prestazioni / Impostazioni. Avanzate. Memoria Virtuale / Cambia.  Togli la prima spunta in alto. Seleziona Nessuna paginazione. Premi Imposta. OK, OK, OK, Riavvia.

Se hai abbastanza memoria, non dovrebbero esserci controindicazioni.

Tags: