View Full Version : Traduzione indirizzi virtuali in indirizzi fisici
Supponiamo di trovarci in una piattaforma Windows (NT-based) e che in un certo momento in un certo processo sia allocata una pagina di memoria virtuale, leggibile, scrivibile e senza nessun page guard impostato. supponiamo anche che in un momento in cui la pagina è residente (cioè si trova in memoria fisica) il processo tenti di accedere ad una sua locazione, in lettura o in scrittura a vostra scelta. in una tale situazione, secondo voi, l'HAL (Hardware Abstraction Layer) di Windows o qualche altro componente del sistema operativo sono tenuti a fare una qualsiasi operazione? durante questa operazione di accesso in memoria, viene eseguita una qualsiasi riga di codice del sistema operativo, in particolare qualche parte di codice relativa alla traduzione da indirizzi virtuali ad indirizzi fisici? e in caso di risposta affermativa, tali operazioni vengono eseguite anche al fetch di ogni singola istruzione di codice del programma?
mi scuso con l'utente ekerazha se ho mal posto la questione (si tratta di una nostra discussione proveniente da altrove che stiamo spostando qui).
Supponiamo di trovarci in una piattaforma Windows (NT-based) e che in un certo momento in un certo processo sia allocata una pagina di memoria virtuale, leggibile, scrivibile e senza nessun page guard impostato. supponiamo anche che in un momento in cui la pagina è residente (cioè si trova in memoria fisica) il processo tenti di accedere ad una sua locazione, in lettura o in scrittura a vostra scelta. in una tale situazione, secondo voi, l'HAL (Hardware Abstraction Layer) di Windows o qualche altro componente del sistema operativo sono tenuti a fare una qualsiasi operazione? durante questa operazione di accesso in memoria, viene eseguita una qualsiasi riga di codice del sistema operativo, in particolare qualche parte di codice relativa alla traduzione da indirizzi virtuali ad indirizzi fisici? e in caso di risposta affermativa, tali operazioni vengono eseguite anche al fetch di ogni singola istruzione di codice del programma?No, se la pagina virtuale è mappata ad una pagina fisica, il S.O. non interviene in alcun modo durante l'accesso alla memoria.
Sui processori x86 che operano in modalità protetta le cose funzionano così: il selettore (che fa riferimento ad un descrittore di segmento) viene usato insieme all'offset a 32 bit per comporre un indirizzo lineare. Se il sistema di paging è disabilitato, l'indirizzo lineare è già a tutti gli effetti l'indirizzo fisico.
Quando il sistema di paging è attivato, le cose cambiano un pochino. Una pagina ha tipicamente una dimensione di 4 KByte (anche se sui x86 si possono avere pagine da 2MB o 4MB).
L'indirizzo lineare è suddiviso in 3 parti: Directory, Table e Offset. Senza entrare nei dettagli (si veda la documentazione Intel), tramite una serie di tabelle organizzate su 2 livelli, il processore è in grado di convertire l'indirizzo lineare in un indirizzo fisico.
Il nocciolo di tutta la gestione del paging è 1 bit che è presente nelle entry di queste tabelle. Se il bit di 'Present' indica che la pagina è mappata in memoria fisica, l'accesso è immediato da parte del processore e non richiede l'intervento di alcun altro componente hardware/software. Se il bit indica che la pagina non è presente, allora viene generata una eccezione di Page-Fault (#PF). A quel punto è esclusivamente compito del S.O. gestire la cosa: dovrà certamente caricare la pagina dal file di swap, scegliere una pagina fisica in cui metterla, risistemare le entry nelle tabelle, invalidare nella TLB la entry della pagina e quindi alla fine, riavviare l'istruzione che ha generato il #PF.
bene bene, concordo al 100% :read:
aspetto solo che quel troll ignorante di ekerazha legga :asd:
grazie andbin.
h1jack3r
11-09-2007, 13:40
Provo a rispondere, vediamo se ho ben capito la domanda.
Se un processo ha allocata della memoria (non importa se fisica o virtuale), a quello spazio può accedere solo quel processo.
Quando si swappa dal processo A al processo B il sistema operativo si preoccperà di salvare i registri contenuti nel processore relativi al processo A, per poter poi ritornare all'esecuzione del processo A quando sarà il caso.
Mettiamo caso che ora sul processore stia girando il processo B.
La fase di decodifica degli indirizzi avviene a livello HW, dato la complessità delle operazioni e la quantità richiesta.
Se il processo B chiede di accedere ad un indirizzo riservato al processo A si scatena un interrupt e il controllo passa al Kernel del sistema operativo che genera un'eccezione.
In sostanza il processore non sa se una locazione di memoria è in memoria fisica o in swap, lui cerca comunque in memoria fisica, se non è presente è il sistema operativo che prende il controllo e trasferisce quella porzione di dati in memoria fisica.
Se il processo B chiede di accedere ad un indirizzo riservato al processo A si scatena un interrupt e il controllo passa al Kernel del sistema operativo che genera un'eccezione. 1) un processo non può tentare di accedere ad una locazione di memoria di un altro processo: a ciascun processo sono assegnati 2 (a volte 3) GB di memoria virtuale, di cui una minima parte è allocata; qualsiasi indirizzo un programma tenti di leggere o scrivere farà sicuramente parte del suo spazio di indirizzamento, non di quello di un altro processo.
2) un'eccezione non richiede uno switch in kernel-mode, o almeno non mi risulta
qualsiasi indirizzo un programma tenti di leggere o scrivere farà sicuramente parte del suo spazio di indirizzamento, non di quello di un altro processo. aggiungo: al massimo potrebbe non far parte di quei 2 o 3 GB, nel qual caso sarebbe un indirizzo che si riferisce al kernel space, ma di certo non allo spazio di indirizzamento di un altro processo.
h1jack3r
11-09-2007, 14:02
era da prendere con le pinze :)
non avevo visto che Andbin aveva già ampiamente risposto alla domanda.
ekerazha
11-09-2007, 14:06
No, se la pagina virtuale è mappata ad una pagina fisica, il S.O. non interviene in alcun modo durante l'accesso alla memoria.
Quindi stai dicendo che su piattaforma Windows NT-based, un eventuale applicazione avrebbe accesso diretto alla memoria centrale senza "passare" dal sistema operativo?
Tratto da "Finnel, Lynn (2000). MCSE Exam 70-215, Microsoft Windows 2000 Server. Microsoft Press. ISBN 1-57231-903-8" (riportato su Wikipedia):
The architecture of Windows NT is highly modular and consists of two main layers: a user mode and a kernel mode. Programs and subsystems in user mode are limited in terms of what system resources they have access to, while the kernel mode has unrestricted access to the system memory and external devices. The kernels of the operating systems in this line are all known as hybrid kernel, although this term is disputed, with the claim that the kernel is essentially a monolithic kernel that is structured somewhat like a microkernel. The architecture comprises a hybrid kernel, hardware abstraction layer (HAL), drivers, and a range of services (collectively named Executive), which all exist in kernel mode.
ekerazha
11-09-2007, 14:12
Aggiungo anche uno schemino che sembra piuttosto intuitivo: http://en.wikipedia.org/wiki/Image:Windows_2000_architecture.svg
The3DProgrammer
11-09-2007, 14:15
no, sta dicendo che la cpu è in grado di interpretare autonomamente un eventuale linear address se la pagina è caricata in memoria (cioè nn è richiesto swap). Nel caso di page fault, allora il sistema operativo deve intervenire come tutti sappiamo.
ciauz
ekerazha
11-09-2007, 14:22
no, sta dicendo che la cpu è in grado di interpretare autonomamente un eventuale linear address se la pagina è caricata in memoria (cioè nn è richiesto swap). Nel caso di page fault, allora il sistema operativo deve intervenire come tutti sappiamo.
ciauz
Quindi rimane il fatto che su piattaforma con architettura NT-based, una applicazione per effettuare operazioni sulla memoria deve passare attraverso il sistema operativo?
ilsensine
11-09-2007, 14:25
2) un'eccezione non richiede uno switch in kernel-mode, o almeno non mi risulta
[se per eccezione intendi "page fault"] Sì invece, chi vuoi che procuri al processo la pagina che manca? ;)
ilsensine
11-09-2007, 14:27
Quindi stai dicendo che su piattaforma Windows NT-based, un eventuale applicazione avrebbe accesso diretto alla memoria centrale senza "passare" dal sistema operativo?
Il sistema operativo provvede a scegliere e procurare le pagine fisiche e mapparle negli indirizzi lineari del processo; fatto questo, la pagina _è_ del processo e ci accede tramite l'MMU -- il lavoro del s/o è finito.
The3DProgrammer
11-09-2007, 14:28
Ma nn ho capito bene, che intendi per operazioni sulla memoria?
Allocazione/deallocazione?
O, come avevo capito prima, si vuole chiarire se ad es in un'istruzione tipo mov eax,00FFAxxh (indirizzo a ca@@) interviene anche il sistema operativo nella traduzione di quell'indirizzo?
The3DProgrammer
11-09-2007, 14:31
Ecco mentre scrivevo forse ilsensine ha chiarito la questione ;)
ciau
Quindi stai dicendo che su piattaforma Windows NT-based, un eventuale applicazione avrebbe accesso diretto alla memoria centrale senza "passare" dal sistema operativo?Sì e se hai letto la mia spiegazione tecnica sopra, capisci anche il perché. Il processore esegue le istruzioni e sempre il processore, grazie a quel sistema di paging descritto, determina autonomamente, prima di tutto, se la pagina è mappata in memoria fisica o no.
Tratto da "Finnel, Lynn (2000). MCSE Exam 70-215, Microsoft Windows 2000 Server. Microsoft Press. ISBN 1-57231-903-8" (riportato su Wikipedia):
Programs and subsystems in user mode are limited in terms of what system resources they have access to, while the kernel mode has unrestricted access to the system memory and external devices.
Aggiungo anche uno schemino che sembra piuttosto intuitivo: http://en.wikipedia.org/wiki/Image:Windows_2000_architecture.svgTutto ciò è solo per descrivere il fatto che sui moderni sistemi operativi ci possono essere diversi livelli di privilegio. Sui processori x86 tecnicamente ci sono 4 livelli (o "ring" come sono chiamati): 0 (il più alto), 1, 2 e 3 (il più basso).
Concettualmente in genere ne bastano solo due: User e Supervisor (in altri processori come i Motorola in effetti ce ne sono solo 2 di livelli, appunto quelli appena menzionati).
Questo significa solamente che in modalità supervisor è possibile eseguire tutte le istruzioni che si vuole, pure quelle "privilegiate" e accedere a qualunque locazione di memoria indirizzabile. In modalità user invece non è possibile eseguire istruzioni privilegiate e non è possibile accedere a zone di memoria che il codice in modalità supervisor ha chiaramente marcato come non accessibili dal livello user.
no, sta dicendo che la cpu è in grado di interpretare autonomamente un eventuale linear address se la pagina è caricata in memoria (cioè nn è richiesto swap). Nel caso di page fault, allora il sistema operativo deve intervenire come tutti sappiamo.Esatto.
ekerazha
11-09-2007, 14:40
Sì e se hai letto la mia spiegazione tecnica sopra, capisci anche il perché. Il processore esegue le istruzioni e sempre il processore, grazie a quel sistema di paging descritto, determina autonomamente, prima di tutto, se la pagina è mappata in memoria fisica o no.
Si, però come ha detto "ilsensine" (se non ho frainteso) ciò avviene comunque a posteriori di quella che è una chiamata dell'applicazione al sistema operativo.
Per andare sul banale: se nella mia applicazione ho una malloc() o una realloc() (o qualcosa di simile) la chiamata deve comunque passare dal sistema operativo o no?
Detto questo, devo fare una parziale rettifica in quanto pensavo che il sistema operativo intervenisse sempre durante l'accesso alla MMU e non che su x86 la cosa venisse gestita direttamente dalla CPU.
ilsensine
11-09-2007, 14:53
Si, però come ha detto "ilsensine" (se non ho frainteso) ciò avviene comunque a posteriori di quella che è una chiamata dell'applicazione al sistema operativo.
Per andare sul banale: se nella mia applicazione ho una malloc() (o qualcosa di simile) la chiamata deve comunque passare dal sistema operativo o no?
I dettagli sono un pò più complicati di quello che sembra.
Innanzitutto, le chiamate al s/o non servono per allocare memoria; smetti di pensare in termini di "memoria" e pensa in termini di "indirizzi virtuali". La malloc non ritorna memoria (lo faceva ai tempi del DOS), ritorna indirizzi virtuali. Per far questo, occorre sì una chiamata al s/o -- chi vuoi che abbia i diritti per manipolare le tabelle di pagine? (chiamate comunque ottimizzate e ridotte tramite una gestione di un heap in user space).
Solo quando accedi alle pagine il s/o si pone il problema di fornirti la pagina di memoria, ma lo fa in maniera trasparente tramite la gestione dei page fault.
Fatto questo, la pagina è tua -- per il momento. Può accadere che il s/o si "riprenda" la pagina (mettendo il contenuto in swap, durante il page reclaim o per "anzianità"), oppure che il contenuto venga spostato su una pagina fisica diversa da quella inizialmente assegnata (perché ad es. un driver sta richiedendo una serie di pagine fisicamente continue per operazioni dma). Questo avviene su tutti i s/o che utilizzano l'mmu.
Una volta però che la pagina fisica è associata ai tuoi indirizzi virtuali, ripeto, il s/o è come se non esistesse, puoi utilizzarla liberamente senza impatti prestazionali.
Per andare sul banale: se nella mia applicazione ho una malloc() (o qualcosa di simile) la chiamata deve comunque passare dal sistema operativo o no?Stiamo parlando di cose diverse: una cosa è la traduzione da un indirizzo virtuale a un indirizzo fisico e un'altra cosa è la chiamata di determinati servizi di sistema.
Ora ... malloc è solo una funzione della libreria standard del "C". Non so esattamente cosa faccia (dipende dalla implementazione). Su Windows posso solo presumere che chiami una delle API Win32 per la allocazione di memoria, che a sua volta chiamerà presumibilmente funzioni kernel-mode per fare quello che serve per allocare la memoria nel processo.
ekerazha
11-09-2007, 15:12
Stiamo parlando di cose diverse: una cosa è la traduzione da un indirizzo virtuale a un indirizzo fisico e un'altra cosa è la chiamata di determinati servizi di sistema.
Ora ... malloc è solo una funzione della libreria standard del "C". Non so esattamente cosa faccia (dipende dalla implementazione). Su Windows posso solo presumere che chiami una delle API Win32 per la allocazione di memoria, che a sua volta chiamerà presumibilmente funzioni kernel-mode per fare quello che serve per allocare la memoria nel processo.
I dettagli sono un pò più complicati di quello che sembra.
Innanzitutto, le chiamate al s/o non servono per allocare memoria; smetti di pensare in termini di "memoria" e pensa in termini di "indirizzi virtuali". La malloc non ritorna memoria (lo faceva ai tempi del DOS), ritorna indirizzi virtuali. Per far questo, occorre sì una chiamata al s/o -- chi vuoi che abbia i diritti per manipolare le tabelle di pagine? (chiamate comunque ottimizzate e ridotte tramite una gestione di un heap in user space).
Esatto... questo intendevo quando dicevo che l'applicazione, su piattaforma NT-based, non accede direttamente alla memoria ma passa dal sistema operativo.
[...]
Una volta però che la pagina fisica è associata ai tuoi indirizzi virtuali, ripeto, il s/o è come se non esistesse, puoi utilizzarla liberamente senza impatti prestazionali.
Questo invece è il particolare punto sul quale ho parzialmente rettificato, in quanto, indipendentemente da quanto scritto sopra, pensavo erroneamente che il sistema operativo intervenisse anche ad ogni accesso alla MMU.
ilsensine
11-09-2007, 15:14
Esatto... questo intendevo quando dicevo che l'applicazione, su piattaforma NT-based, non accede direttamente alla memoria ma passa dal sistema operativo.
[a parte che è vero per qualsiasi *-based ;) ] detta così in effetti è fuorviante; l'applicazione _accede_ direttamente (per mezzo della mmu) alla memoria, ma non accede direttamente alle tabelle di pagine. Visto che sono quest'ultime a determinare quali pagine fisiche stai utilizzando, la sicurezza è garantita.
in quanto, indipendentemente da quanto scritto sopra, pensavo erroneamente che il sistema operativo intervenisse anche ad ogni accesso alla MMU.
bum ti servirebbe un cluster solo per giocare a campo minato :D
ekerazha
11-09-2007, 15:21
[a parte che è vero per qualsiasi *-based ;) ] detta così in effetti è fuorviante; l'applicazione _accede_ direttamente (per mezzo della mmu) alla memoria, ma non accede direttamente alle tabelle di pagine. Visto che sono quest'ultime a determinare quali pagine fisiche stai utilizzando, la sicurezza è garantita.
A me sembra di ricordare che ad esempio nei sistemi DOS-based l'applicazione potesse avere accesso diretto all'hardware.
bene bene, concordo al 100% :read:
aspetto solo che quel troll ignorante di ekerazha legga :asd:
grazie andbin.
Ne potevi anche fare a meno. 3gg di sospensione.
ilsensine
11-09-2007, 15:23
A me sembra di ricordare che ad esempio nei sistemi DOS-based l'applicazione potesse avere accesso diretto all'hardware.
La * non comprende il DOS ;)
ekerazha
11-09-2007, 15:24
La * non comprende il DOS ;)
;)
Esatto... questo intendevo quando dicevo che l'applicazione, su piattaforma NT-based, non accede direttamente alla memoria ma passa dal sistema operativo.No. Ripeto ancora una volta che una cosa è richiedere dei servizi al sistema operativo ad esempio per allocare memoria o gestire un dispositivo hardware (perché solo il livello Supervisor può eseguire istruzioni privilegiate e accedere alle strutture dati che mappano la memoria).
E un'altra cosa è la gestione dell'accesso fisico alla memoria, che viene fatto dall'unità MMU nel processore. Quando il processore esegue una istruzione come:
MOV AX,[123456h]
il sistema operativo non c'entra nulla immediatamente. Il processore prima va a vedere se l'indirizzo lineare può essere convertito in fisico. Se la pagina fisica è presente bene, altrimenti genera un page-fault. A quel punto è il S.O. che deve operare per sistemare le cose. Ma una volta che sono sistemate (la pagina è mappata a una fisica), è il processore che ritorna con la sua MMU ad accedere finalmente alla locazione di memoria.
A me sembra di ricordare che ad esempio nei sistemi DOS-based l'applicazione potesse avere accesso diretto all'hardware.Ma ritorniamo alla questione dei livelli di privilegio. Il DOS, nella modalità "reale" dei processori x86, non comprende alcun sistema di gestione dei privilegi del tipo Supervisor/User. Si poteva eseguire qualunque istruzione, qualunque I/O, accedere a qualunque locazione di memoria indirizzabile.
ekerazha
11-09-2007, 15:36
l'applicazione _accede_ direttamente (per mezzo della mmu) alla memoria, ma non accede direttamente alle tabelle di pagine
Questo mi era sfuggito... più che l'applicazione direi il processo (infatti non ho appositamente detto "processo").
Durante il task switching l'indirizzo della tabella primaria delle pagine (può essere anche a due livelli) del processo viene caricato in un registro della CPU. Da qui in poi la risoluzione degli indirizzi è trasparente al task in esecuzione e svolto automaticamente dalla CPU senza intervento del kernel, ovviamente a meno di un page fault, in talc aso succede quanto ti hanno spiegato sopra.
ekerazha
11-09-2007, 15:47
No. Ripeto ancora una volta che una cosa è richiedere dei servizi al sistema operativo ad esempio per allocare memoria o gestire un dispositivo hardware (perché solo il livello Supervisor può eseguire istruzioni privilegiate e accedere alle strutture dati che mappano la memoria).
E un'altra cosa è la gestione dell'accesso fisico alla memoria, che viene fatto dall'unità MMU nel processore. Quando il processore esegue una istruzione come:
MOV AX,[123456h]
il sistema operativo non c'entra nulla immediatamente. Il processore prima va a vedere se l'indirizzo lineare può essere convertito in fisico. Se la pagina fisica è presente bene, altrimenti genera un page-fault. A quel punto è il S.O. che deve operare per sistemare le cose. Ma una volta che sono sistemate (la pagina è mappata a una fisica), è il processore che ritorna con la sua MMU ad accedere finalmente alla locazione di memoria.
Si questo è già stato chiarito... riformulo la frase cercando di essere il più chiaro possibile: non accede direttamente alla memoria, bensì deve prima farla allocare al sistema operativo, che in seguito alla SVC può mappare la memoria.
Ma ritorniamo alla questione dei livelli di privilegio. Il DOS, nella modalità "reale" dei processori x86, non comprende alcun sistema di gestione dei privilegi del tipo Supervisor/User. Si poteva eseguire qualunque istruzione, qualunque I/O, accedere a qualunque locazione di memoria indirizzabile.
Si, infatti ha proprio a che fare con i livelli di privilegio, come avevi già detto.
ekerazha
11-09-2007, 15:57
Si, infatti ha proprio a che fare con i livelli di privilegio, come avevi già detto.
Precisazione: questione che comunque non esclude il ruolo di un eventuale Hardware Abstraction Layer presente all'interno del sistema operativo.
Precisazione: questione che comunque non esclude il ruolo di un eventuale Hardware Abstraction Layer presente all'interno del sistema operativo.
Come già detto l'HAL non fa niente per la risoluzione degli indirizzi e il kernel non entra in gioco fino a quando non c'è un page fault o un'interruzione.
ekerazha
11-09-2007, 16:05
Come già detto l'HAL non fa niente per la risoluzione degli indirizzi e il kernel non entra in gioco fino a quando non c'è un page fault o un'interruzione.
Certo... però teoricamente (dipende dall'implementazione) entra in gioco al momento della richiesta di allocazione o più genericamente: quando "gioca" il sistema operativo e questo accede all'hardware, teoricamente (dipende sempre dall'implementazione) entra in gioco anche l'HAL.
Certo... però teoricamente (dipende dall'implementazione) entra in gioco al momento della richiesta di allocazione o più genericamente: quando "gioca" il sistema operativo e questo accede all'hardware, teoricamente (dipende sempre dall'implementazione) entra in gioco anche l'HAL.
L'allocazione non è altro che la chiamata ad una primitiva di sistema ed è equivalente a qualsiasi altra chiamata di sistema, quindi è chiaro che se chiami una primitiva di sistema entri in gioco il sistema operativo ;)
Non capisco dove vuoi arrivare :confused:
ekerazha
11-09-2007, 16:18
L'allocazione non è altro che la chiamata ad una primitiva di sistema ed è equivalente a qualsiasi altra chiamata di sistema, quindi è chiaro che se chiami una primitiva di sistema entri in gioco il sistema operativo ;)
Non capisco dove vuoi arrivare :confused:
Esattamente... arrivo (relativamente a questo particolare punto) al fatto che se una applicazione vuole allocare memoria, non avendo accesso "proprio" all'hardware (per la questione dei livelli di privilegio ai quali si è accennato) deve appunto eseguire una chiamata al sistema operativo... e quindi sistema operativo e presumibilmente anche il suo eventuale HAL, entrano ovviamente in gioco.
ilsensine
11-09-2007, 16:24
Mah la memoria è memoria...l'HAL ha ben poco da astrarre...
Esattamente... arrivo (relativamente a questo particolare punto) al fatto che se una applicazione vuole allocare memoria, non avendo accesso "proprio" all'hardware (per la questione dei livelli di privilegio ai quali si è accennato) deve appunto eseguire una chiamata al sistema operativo... e quindi sistema operativo e presumibilmente anche il suo eventuale HAL, entrano ovviamente in gioco.
In teoria non servirebbe nemmeno l'intervento del sistema operativo, ma si chiama il sistema operativo per evitare che ci debba essere una routine per la gestione dell'allocazione della memoria all'interno del programma eseguibile.
Visto che è il sistema che alloca le porzioni di codice e dati, è il sistema a sapere dove andare a sistemare nel migliore dei modi la quantità di dati richiesti dalla mia applicazione ;)
Anche in questo non c'è alcuno intervento dell'HAL, se non in caso page fault.
Nota che per le variabili allocate staticamente non c'è alcun bisogno di richiamare una routine del sistema operativo perché la quantità di memoria sufficiente (si spera) per l'allocazione di queste variabili è stata allocata preventivamente, cioè lo stack.
L'applicazione volendo potrebbe anche andare a scrivere questi dati all'indirizzo 0xABD4G344, ma per evitare di incappare nella sovrascrittura di altri dati usa una chiamata di sistema.
ekerazha
11-09-2007, 16:44
In teoria non servirebbe nemmeno l'intervento del sistema operativo, ma si chiama il sistema operativo per evitare che ci debba essere una routine per la gestione dell'allocazione della memoria all'interno del programma eseguibile.
Visto che è il sistema che alloca le porzioni di codice e dati, è il sistema a sapere dove andare a sistemare nel migliore dei modi la quantità di dati richiesti dalla mia applicazione ;)
Anche in questo non c'è alcuno intervento dell'HAL, se non in caso page fault.
Nota che per le variabili allocate staticamente non c'è alcun bisogno di richiamare una routine del sistema operativo perché la quantità di memoria sufficiente (si spera) per l'allocazione di queste variabili è stata allocata preventivamente, cioè lo stack.
L'applicazione volendo potrebbe anche andare a scrivere questi dati all'indirizzo 0xABD4G344, ma per evitare di incappare nella sovrascrittura di altri dati usa una chiamata di sistema.
Dovrebbe avere i privilegi di Supervisor per farlo. Sei davvero sicuro che su NT (cito NT perchè si stava parlando di quello) un programma qualsiasi possa andare in giro indisturbato a giocare con la memoria?
ekerazha
11-09-2007, 16:47
Ci risentiamo tra un paio di giorni...
ilsensine
11-09-2007, 16:48
Dovrebbe avere i privilegi di Supervisor per farlo. Sei davvero sicuro che su NT (cito NT perchè si stava parlando di quello) un programma qualsiasi possa andare in giro indisturbato a giocare con la memoria?
a giocare con gli "indirizzi virtuali", sì.
continuo a non capire dove è il problema, mi sembra semplice... :stordita:
Dovrebbe avere i privilegi di Supervisor per farlo. Sei davvero sicuro che su NT (cito NT perchè si stava parlando di quello) un programma qualsiasi possa andare in giro indisturbato a giocare con la memoria?
Sì perché quell'indirizzo fa parte della SUA memoria virtuale (non è un indirizzo fisico) e se la pagina è accessibile in scrittura e in lettura allora ci può andare ;)
ekerazha
11-09-2007, 16:49
a giocare con gli "indirizzi virtuali", sì.
continuo a non capire dove è il problema, mi sembra semplice... :stordita:
Quindi posso fare un software che va a sovrascrivere aree di memoria a caso? Su NT?
ilsensine
11-09-2007, 16:50
Quindi posso fare un software che va a sovrascrivere aree di memoria a caso? Su NT?
No ma può sovrascrivere a caso i _suoi_ indirizzi virtuali, se proprio ha tendenze suicide.
Cancella il termine "memoria" dalla tua testa per un attimo.
ekerazha
11-09-2007, 16:51
No ma può sovrascrivere a caso i _suoi_ indirizzi virtuali, se proprio ha tendenze suicide.
Cancella il termine "memoria" dalla tua testa.
Ah ecco, i "suoi".
ilsensine
11-09-2007, 16:53
Ah ecco, i "suoi".
...che sono uguali a quelli degli "altri" :asd:
(ok adesso mi picchi :D )
Quindi posso fare un software che va a sovrascrivere aree di memoria a caso? Su NT?
Si tratta di memoria virtuale e quindi al massimo può danneggiare solo se stesso. In ogni caso le pagine destinate al codice sono soltanto leggibili.
Ah ecco, i "suoi".
Non ne vede altri...
In un sistema con memoria virtuale un programma vede come a sua disposizione l'intero spazio di indirizzamento flat a 32 bit...quindi qualsiasi indirizzo generato (visto che in un'applicazione a 32 bit si generano indirizzi a 32 bit) è all'interno del spazio di indirizzamento virtuale dell'applicazione.
E' impossibile con metodi standard andare a scrivere nello spazio di indirizzamento di un'altra applicazione in quanto la pagina fisica relativa all'altra applicazione non fa parte delle pagine allocate alla mia applicazione nella mia tabella delle pagine.
ekerazha
13-09-2007, 17:38
Appunto...
... io mi riferivo al fatto che vi è il supporto alla memoria protetta (al contrario di altri sistemi come quelli DOS-baed).
P.S.
Tornato :D
ekerazha
13-09-2007, 22:43
In che senso protetta ?
Nel senso di memoria protetta :p
Questa per intenderci: http://en.wikipedia.org/wiki/Memory_protection
(che è implementata attraverso i livelli di privilegio... Supervisor etc. come è già stato detto).
variabilepippo
14-09-2007, 00:15
E' impossibile con metodi standard andare a scrivere nello spazio di indirizzamento di un'altra applicazione in quanto la pagina fisica relativa all'altra applicazione non fa parte delle pagine allocate alla mia applicazione nella mia tabella delle pagine.
Se l'area è contrassegnata come writable si può modificare la memoria di un altro processo con una banalissima WriteProcessMemory (http://msdn2.microsoft.com/en-us/library/ms681674.aspx). :D
Se l'area è contrassegnata come writable si può modificare la memoria di un altro processo con una banalissima WriteProcessMemory (http://msdn2.microsoft.com/en-us/library/ms681674.aspx). :D
Certo...ma non sono metodi standard...per standard intendevo normali istruzioni assembler che non dipendano dalla particolare implementazione. Se il kernel non mettesse a disposizione quella API non ci riuscirei. Chiaramente passando dal kernel si può fare qualsiasi cosa ;)
Nel senso di memoria protetta :p
Questa per intenderci: http://en.wikipedia.org/wiki/Memory_protection
(che è implementata attraverso i livelli di privilegio... Supervisor etc. come è già stato detto).
Sinceramente non sono tanto d'accordo con quella definizione di protezione della memoria, appunto ti ho chiesto cosa intendevi. Quella protezione della memoria è un side effect dell'uso della memoria virtuale ;) Cioè si ottiene perché si permette ad ogni processo un accesso flat al proprio spazio di indirizzamento e non tramite i livelli di privilegio.
Per me la protezione della memoria sono i classici bit di scrittura/lettura e ora anche di esecuzione presenti nella tabella delle pagine...che vengono modificati dal sistema operativo, ma la generazione di una eccezione in caso non vengano rispettati viene generata automaticamente dalla CPU...
ekerazha
14-09-2007, 08:56
Per me la protezione della memoria sono i classici bit di scrittura/lettura e ora anche di esecuzione presenti nella tabella delle pagine...
Questa (quella che hai appena scritto) è la descrizione che dà anche il mio testo di informatica 2, ma presumo sia tutto collegato... ovvero questi bit siano impostabili dal sistema operativo al momento dell'allocazione etc. e quindi in seguito all'esecuzione di una SVC, altrimenti un qualsiasi programma potrebbe andare ad alterare la cosa.
Ovviamente sono impostati dal sistema operativo...
Comunque ritornando al quesito iniziale ? Hai ancora qualche dubbio ?
ekerazha
14-09-2007, 09:21
Ovviamente sono impostati dal sistema operativo...
Comunque ritornando al quesito iniziale ? Hai ancora qualche dubbio ?
Nein... comunque ho scoperto che su alcune architetture (anche se la minoranza e comunque non la x86) la MMU non è direttamente connessa alla CPU e quindi ogni accesso alla MMU viene sempre gestito dal sistema operativo :fagiano:
Se l'area è contrassegnata come writable si può modificare la memoria di un altro processo con una banalissima WriteProcessMemory (http://msdn2.microsoft.com/en-us/library/ms681674.aspx). :D non se la OpenProcess ti ha dato picche :asd:
e se invece non l'ha fatto allora nella maggior parte dei casi puoi anche scrivere in un'area a sola lettura sproteggendola prima con VirtualProtectEx. dico la maggior parte dei casi perché VirtualProtectEx naturalmente richiede un permesso diverso sull'HANDLE del processo.
comunque non era di questo discorso che si stava parlando
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.