puntatori NEAR e FAR: perché non esistono più?

[71104]

è da un po' che rifletto su questa cosa: sugli odierni processori di tipo Intel a 32 bit, qualsiasi puntatore da 32 bit è NEAR: un puntatore FAR infatti richiede 48 bit.
in Visual C++ (e credo anche in qualsiasi altro compilatore C/C++) l'asterisco, che serve a dichiarare puntatori, definisce sempre un tipo a 32 bit: sizeof(void*) infatti è uguale a 32, come anche sizeof(char*), sizeof(int*) e sizeof(<tipo_qualsiasi>*); ma i puntatori FAR che fine hanno fatto??
immaginiamo di avere un bel programma che viene distribuito su 4 segmenti: codice, dati, heap e stack (situazione tipica); se ho un puntatore ad un byte che sta nel segmento dati posso riferirmi a quel byte con soli 32 bit, e lo stesso se si trova nell'heap, ma come fa il compilatore a sapere il segmento a cui voglio riferirmi (heap o dati) quando la situazione non lo rende implicito?
e un'altra cosa: è risaputo che l'indirizzo 0x00000000, cioè NULL, non è accessibile: ma perché mai questa cosa??? si tratta semplicemente di un puntatore che punta al base address di qualche segmento, a seconda che io in un puntatore FAR (appunto) specifichi il segmento dati, codice, heap o stack, ma il punto è che di qualunque segmento si tratti, se il segmento sta nel mio programma in teoria io dovrei avere lecito accesso al suo byte numero 0, o sbaglio?!?
quello che in realtà può provocare il seg.fault è quando io specifico o un segmento inesistente, o un segmento di un altro programma, no?
cos'è che mi manca di sapere e che mi impedisce di capire?

[71104]

ehm, un imperdonabile leggerezza: tutti quei sizeof naturalmente è sottinteso che non restituiscono 32, ma 4 ^^

[fek]

Originariamente inviato da 71104

cos'è che mi manca di sapere e che mi impedisce di capire?

Che la gestione della memoria segmentata fu stata sostituita dalla paginazione una decina di anni fa

I puntatori che dichiari non sono indirizzi di memoria fisici, ma sono indirizzo logici nello spazio di indirizzamento di un processo che poi la CPU mappa verso indirizzi fisici in base a determinate look up table che variano ovviamente da processo a processo.

Si possono fare giochini tipo mappare piu' indirizzi logici allo stesso indirizzo fisico, mappando ad esempio le pagine di piu' processi che contengono il codice del processo stesso vero le stesse pagine fisiche dove il SO mantiene una sola copia del codice da condividere.

E' un sistema piu' semplice ed efficacie della vecchia memoria segmentata il cui supporto e' mentenuto per motivi di compatibilita'.

[71104]

guarda che oggi segmentazione e paginazione esistono entrambe e la segmentazione sulla IA32 in modalità protetta a 32 bit non la si può eludere...

EDIT: mi sa che ti confondi con una roba che abbiamo studiato ad architettura 2 che non so cosa sia e che si chiama "partizionamento" (ho chiesto alla prof. se x caso c'entrava qualcosa con la segmentazione e ha detto di no).

[fek]

Originariamente inviato da 71104

guarda che oggi segmentazione e paginazione esistono entrambe e la segmentazione sulla IA32 in modalità protetta a 32 bit non la si può eludere...

EDIT: mi sa che ti confondi con una roba che abbiamo studiato ad architettura 2 che non so cosa sia e che si chiama "partizionamento" (ho chiesto alla prof. se x caso c'entrava qualcosa con la segmentazione e ha detto di no).

La segmentazione esiste ancora per motivi di compatibilita' e per supportare SO legacy.

I registri di segmento vengono semplicemente impostati a descrittori di segmento che puntano all'inizio dello spazio di indirizzamento (semplifico, non e' proprio cosi' in WinXP) e la memoria gestita mediante paginazione.

Non mi confondo col partizionamento

[71104]

scusa, ma allora perché i registri di segmento normalmente contengono valori diversi? (verificato in alcuni programmi su Win2k pro...)
perché usare segmenti diversi che puntano tutti allo stesso base address?

[71104]

mi rispondo da solo: perché i vari segmenti hanno caratteristiche diverse nel descrittore
ora ho capito, grazie dell'aiuto

[fek]

Originariamente inviato da 71104

scusa, ma allora perché i registri di segmento normalmente contengono valori diversi? (verificato in alcuni programmi su Win2k pro...)
perché usare segmenti diversi che puntano tutti allo stesso base address?

I registri puntano ai descrittori di segmento, due descrittori di segmento possono, ad esempio, puntare allo stesso indirizzo base ma avere diversi livelli di accesso. Succede se vuoi avere del codice automodificante, quando il segmento codice di solito e' marcato come read only (e le relative pagine marcate tutte come readonly). In quel caso carichi un altro descrittore con privilegi diversi. Dati e codice hanno anche diritti diversi, quindi valori diversi, sebbene puntino entrambi allo stesso indirizzo virtuale di base.

Qui ci sono tutte le spiegazioni del caso:
http://msdn.microsoft.com/msdnmag/issues/0700/hood/

E come ti dicevo la mia spiegazione era volutamente semplicistica, qui ti dice dove e quando Win32 fa chiamate a segmenti diversi:

The only time that a Win32 system changes segments is when it transitions between ring 0 and ring 3.

[71104]

Originariamente inviato da fek

I registri puntano ai descrittori di segmento, due descrittori di segmento possono, ad esempio, puntare allo stesso indirizzo base ma avere diversi livelli di accesso. Succede se vuoi avere del codice automodificante, quando il segmento codice di solito e' marcato come read only (e le relative pagine marcate tutte come readonly). In quel caso carichi un altro descrittore con privilegi diversi. Dati e codice hanno anche diritti diversi, quindi valori diversi, sebbene puntino entrambi allo stesso indirizzo virtuale di base.

si si, avevo capito tutto; l'unica cosa che non sapevo è che oggidì i segmenti fossero tutti completamente overlapped. tra parentesi la ritengo anche una cosa un tantino pericolosa, perché io ad es. potrei andare a modificare il codice di una libreria di sistema utilizzando DS piuttosto che CS: in tal modo non devo disturbarmi di andare a sproteggere le pagine di quella libreria, senza contare che se non sbaglio bypasserei qualsiasi protezione COW, e la modifica avrebbe effetto in tutto il sistema... o no?

Qui ci sono tutte le spiegazioni del caso:
http://msdn.microsoft.com/msdnmag/issues/0700/hood/

grande Matt, devo decidermi a leggerle prima o poi quelle colonne: finora di "Under the Hood" ne ho letti solo un paio sul formato PE.

E come ti dicevo la mia spiegazione era volutamente semplicistica, qui ti dice dove e quando Win32 fa chiamate a segmenti diversi:

buono a sapersi; cmq approfondirò con Pietrek

ciao

[71104]

Originariamente inviato da 71104

tra parentesi la ritengo anche una cosa un tantino pericolosa, perché io ad es. potrei andare a modificare il codice di una libreria di sistema utilizzando DS piuttosto che CS: in tal modo non devo disturbarmi di andare a sproteggere le pagine di quella libreria, senza contare che se non sbaglio bypasserei qualsiasi protezione COW, e la modifica avrebbe effetto in tutto il sistema... o no?

ehm, come non detto, risparmiami...
il mio problema è che ho ancora le idee un tantino confuse perché su queste cose sono fresco di studi...
mi propongo di migliorare
cmq adesso mi sembra finalmente tutto chiaro (... sarà vero? )

[fek]

Originariamente inviato da 71104

si si, avevo capito tutto; l'unica cosa che non sapevo è che oggidì i segmenti fossero tutti completamente overlapped. tra parentesi la ritengo anche una cosa un tantino pericolosa, perché io ad es. potrei andare a modificare il codice di una libreria di sistema utilizzando DS piuttosto che CS: in tal modo non devo disturbarmi di andare a sproteggere le pagine di quella libreria, senza contare che se non sbaglio bypasserei qualsiasi protezione COW, e la modifica avrebbe effetto in tutto il sistema... o no?

Al di sotto ci sono comunque le pagine ognuna con il suo livello di protezione che non puoi cambiare se non con chiamate al Kernel. Quindi, se il Kernel non vuole, tu non scrivi in una pagina neppure se preghi

Una cosa comoda che faccio per scovare i buffer overrun e di mettere in sola lettura pagine di dati che so di dover scrivere una volta sola, ad esempio le animazione che carico da disco, oppure la geometria dei modelli. Se qualcosa va in buffer overrun e prova a scrivere sulle mie pagine dati, parte un GP fault, molto meglio che sovrascrivere casualmente lo spazio d'indirizzamento del processo e causare bug che poi si rivelano sempre il giorno prima di una milestone.

[71104]

Originariamente inviato da fek

Al di sotto ci sono comunque le pagine ognuna con il suo livello di protezione che non puoi cambiare se non con chiamate al Kernel. Quindi, se il Kernel non vuole, tu non scrivi in una pagina neppure se preghi

ma oggi ricevi solo la metà dei miei post o sei solo ansioso di far vedere che hai letto Pietrek?
te l'avevo detto di risparmiarmi!!
scherzo, su!

Una cosa comoda che faccio per scovare i buffer overrun e di mettere in sola lettura pagine di dati che so di dover scrivere una volta sola, ad esempio le animazione che carico da disco, oppure la geometria dei modelli. Se qualcosa va in buffer overrun e prova a scrivere sulle mie pagine dati, parte un GP fault, molto meglio che sovrascrivere casualmente lo spazio d'indirizzamento del processo e causare bug che poi si rivelano sempre il giorno prima di una milestone.

e se la pagina contiene anche altra roba che devi scrivere frequentemente? e se quello che non devi sovrascrivere occupa più pagine? be' a dire il vero per evitare buffer overrun nella stragrande maggioranza dei casi sarebbe sufficiente proteggere solo la prima pagina, ma dai puntatori non validi non si salva nessuno!!!

[71104]

Originariamente inviato da 71104

ma oggi ricevi solo la metà dei miei post o sei solo ansioso di far vedere che hai letto Pietrek?

oggi o ieri, che dir si voglia

[end.is.forever]

48 bit = 16 bit di selettore di un descrittore di segmento appartenente a GDT (global descriptor table ad indirizzo virtuale fisso presente in un registro accessibile solo con istruzioni privilegiate) o alla LDT del task corrente (local descriptor table con indirizzo virtuale in LDTR) + 32 bit di offset

Poi ci sarebbero gli altri 4 bit dei 36 che sono fissi per ogni task e (se non sbaglio ) invisibili al programmatore, gestiti solo dal s.o.

Naturalmente tutto questo solo se il s.o. va in modalità protetta, altrimenti i 16 rappresentano l'indirizzo virtuale base e si usa l'indirizzamento classico e senza protezione.

Poi vabe la paginazione, se attiva, ottiene dalle tabelle delle pagine oppure dai TLB il mapping tra indirizzi virtuali e fisici (se non è cambiato dal Pentium dovrebbe essere 32 bit = 20 bit più significativi identificano una pagina da 4KB, 12 bit l'offset, oppure 10 bit identificano una pagina da 4MB, 22 l'offset).

[end.is.forever]

Originariamente inviato da 71104

oggidì i segmenti fossero tutti completamente overlapped. tra parentesi la ritengo anche una cosa un tantino pericolosa, perché io ad es. potrei andare a modificare il codice di una libreria di sistema utilizzando DS piuttosto che CS: in tal modo non devo disturbarmi di andare a sproteggere le pagine di quella libreria, senza contare che se non sbaglio bypasserei qualsiasi protezione COW, e la modifica avrebbe effetto in tutto il sistema... o no?

Però prima dovresti convincere il sistema operativo a passarti un selettore di descrittore di segmento dati aliased con quello di codice dove vuoi scrivere.
Non dimenticare che i descrittori di segmento li può creare solo il sistema operativo dato che le tabelle si trovano su segmenti a cui in generale accede solo lui.

[fek]

Originariamente inviato da 71104

ma oggi ricevi solo la metà dei miei post o sei solo ansioso di far vedere che hai letto Pietrek?
te l'avevo detto di risparmiarmi!!
scherzo, su!

Mai letto quel libro
Ma ho il brutto vizio di leggere un post e rispondere, puoi mi accorgo che ti eri gia' risposto.

e se la pagina contiene anche altra roba che devi scrivere frequentemente? e se quello che non devi sovrascrivere occupa più pagine? be' a dire il vero per evitare buffer overrun nella stragrande maggioranza dei casi sarebbe sufficiente proteggere solo la prima pagina, ma dai puntatori non validi non si salva nessuno!!!

Se la pagina contiene anche dati che devo scrivere, ovviamente non la posso mettere a sola lettura e perdo la protezione. E' un'idea che non protegge interamente da tutti i dangling pointer e i buffer overrun, ma se ne becca anche solo qualcuno ha ragione di essere. E me ne ha gia' beccati piu' di uno.

[71104]

Originariamente inviato da end.is.forever

48 bit = 16 bit di selettore di un descrittore di segmento appartenente a GDT (global descriptor table ad indirizzo virtuale fisso presente in un registro accessibile solo con istruzioni privilegiate) [...]

ti sbagli: GDTR contiene un indirizzo lineare (la GDT non è soggetta al paging).

Poi ci sarebbero gli altri 4 bit dei 36 che sono fissi per ogni task e (se non sbaglio ) invisibili al programmatore, gestiti solo dal s.o.

così diventano 52... gli indirizzi NEAR (cioè esclusi i segmenti) sono a 36 bit solo in una certa modalità (inutilizzata credo dalla maggior parte dei SO odierni) che permette di arrivare ad indirizzare 64 gigabyte.

Naturalmente tutto questo solo se il s.o. va in modalità protetta, altrimenti i 16 rappresentano l'indirizzo virtuale base e si usa l'indirizzamento classico e senza protezione.

che casino, non è così: in modalità reale gli indirizzi sono a 20 bit: 16 di segmento combinati a 16 di offset (i 16 di segmento vengono shiftati a sinistra di 4 e addizionati all'offset in maniera tale da formare 20 bit). non ci sono indirizzi virtuali.

[71104]

Originariamente inviato da end.is.forever

Però prima dovresti convincere il sistema operativo a passarti un selettore di descrittore di segmento dati aliased con quello di codice dove vuoi scrivere.
Non dimenticare che i descrittori di segmento li può creare solo il sistema operativo dato che le tabelle si trovano su segmenti a cui in generale accede solo lui.

il descrittore che cerchi ce l'ho già in DS, ma il problema non era quello... (leggi sopra)

[71104]

Originariamente inviato da fek

Mai letto quel libro

come "mai letto quel libro"? a parte che non è un libro, sono una serie di articoli, ma poi guarda che me ne hai linkato uno...

Se la pagina contiene anche dati che devo scrivere, ovviamente non la posso mettere a sola lettura e perdo la protezione. E' un'idea che non protegge interamente da tutti i dangling pointer e i buffer overrun, ma se ne becca anche solo qualcuno ha ragione di essere. E me ne ha gia' beccati piu' di uno.

ma scusa come fai a fare in modo che i tuoi dati a sola lettura, o a "lettura ogni morte di papa", vadano a cadere precisi proprio nel page boundary?!? cioè tu fai in modo che ad es. certi oggetti vengano allocati in maniera tale che i 12 bit inferiori dell'indirizzo siano esattamente uguali a 0??

[fek]

Originariamente inviato da 71104

come "mai letto quel libro"? a parte che non è un libro, sono una serie di articoli, ma poi guarda che me ne hai linkato uno...

Lascia perdere, fra ieri notte e stamattina sono totalmente fuso

ma scusa come fai a fare in modo che i tuoi dati a sola lettura, o a "lettura ogni morte di papa", vadano a cadere precisi proprio nel page boundary?!? cioè tu fai in modo che ad es. certi oggetti vengano allocati in maniera tale che i 12 bit inferiori dell'indirizzo siano esattamente uguali a 0??

Si', alloco io le pagine manualmente e poi butto dentro i dati.
Immagina che debba caricare 20 mb di animazioni, alloco 20 mb di pagine, le imposto a scrittura/lettura, carico le animazioni da disco, le cambio in sola lettura.

L'anno scorso avevo provato una cosa simpatica, ma alla fine non se n'era fatto nulla. L'idea era di prendere un blocco di dati a sola lettura ad esempio di 10 pagine, comprimerlo con un algoritmo non lossy ragionevolmente e memorizzarlo da qualche parte compresso. Poi chiedi al SO di darti 10 pagine di spazio di indirizzamento ma senza fare il commit a nessuna pagina fisica (cosi' non occupi memoria) e restituire il puntatore logico all'applicazione.

Ora immagina che l'applicazione tenti di accedere al blocco di dati che lei vede non compresso e l'indirizzo si riferisca alla pagina 1. Win32 ti da' un'eccezione perche' quella pagina non e' mappata su nessuna pagina fisica, tu trappi l'eccezione, prendi quella pagina dalla versione compressa, la decomprimi al volo, fai il commit della pagina su una pagina fisica che usi come buffer di decompressione temporaneo e restituisci il controllo. Dopo il GP fault l'applicazione vede la pagina 1 decompressa e non sa quello che e' successo

Funzionava benino ma la mia implementazione non era troppo robusta. Prova a farlo, e' un buon esercizio per imparare ad usare i servizi di Win32 per la paginazione.