Gestion mémoire : présentation

Gestion mémoire : présentation
CE4.2 Gestion mémoire Présentation jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Objectif du chapitre Organisation de la mémoire Découpage en slots Rôle du slot 0 Passage d’adresses entre le slot 0 et le slot de l’application jc/md/lp-01/05 Gestion mémoire : présentation

Architecture mémoire (1)
CE4.2 Architecture mémoire (1) Espace virtuel de 4 GB Séparation de la mémoire en deux espaces De 0 à 2GB user mode (process) De 2GB à 4GB kernel mode (system) Mémoire user mode 33 slots de 32MB 32 slots pour les process (numéros 1 à 32) 1 slot pour le process en cours (numéro 0) le reste (1GB moins 32MB) est partagé entre tous les processus Références utiles dans la documentation : Windows CE .NET Advanced Memory Management Memory Architecture and Addressing Memory Architecture Memory Access Virtual Memory VirtualAlloc Memory Management Memory Addressing System Memory Management in Windows CE .NET Creating Physical to Virtual Mappings jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Architecture mémoire (2)
CE4.2 Architecture mémoire (2) Quand un process est créé le système lui attribue un slot disponible (« ouvert ») parmi les slots 1 à 32 Maximum de 32 processus ouverts Quand un process s’exécute, il est cloné dans le slot 0 Source : documentation Microsoft Windows CE .NET 4.2 : Memory Architecture jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Adressage d’un process en mémoire
jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

CE4.2 Gestion mémoire Mémoire gérée par pages de 4KB ou 1KB suivant les microprocesseurs Gestion par le mécanisme de page à la demande, mais on a aussi la possibilité de charger une application complète en mémoire Possibilité de réserver des régions Possibilité d’accéder à de vastes espaces mémoires dans une partie gérée comme des fichiers en RAM En général, la dimension de la page est 4KB, mais certains processeurs utilisent une page de 1 KB, par exemple dans la famille ARM le 920. jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Mémoire locale du process (1)
0 à 32 MB 64 KB réservés Code Données ROM Données RAM Tas Pile Espace allouable Dll « dynamiques » Dll dynamiques ou « RAM-based dll » ; ce sont des dll chargées et gérées par un process, dans son espace virtuel personnel de 32 MB, par opposition aux dll statiques qui seront utilisables par plusieurs process et chargées de façon figée dans l’espace commun aux processus qui va de 32 à 64 MB. jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Code et données RAM ou ROM suivant le programme Heap (tas) jusqu’à 192KB avec une granularité de 4 ou 8 bytes suivant les processeurs (LocalAlloc(), LocalFree(), etc. Possibilité de créer de nouveaux Heap si nécessaire (HeapCreate(), HeapAlloc(),…) Stack (pile), paramètre de l’édition de liens (link), 64KB par défaut jc/md/lp-01/05 Gestion mémoire : présentation

32 à 64 MB Extension CE 4.x par rapport à CE 3.0 Dll systèmes Dll « statiques » en ROM avec les problèmes posés par l’interdiction du recouvrement des dll Les dll statiques ou systèmes sont réutilisables par plusieurs processus. Après le chargement d’une dll, n’importe quel processus doit pouvoir la retrouver au même endroit. De plus, ces dll sont prévues pour être installées dans des ROM et par conséquent, leur adresse de chargement est immuable après génération de la ROM ; les processeurs utilisés ne supportent pas la création de code ne dépendant pas de son adresse d’implantation en mémoire (PIC ou position independent code) et par conséquent après l’édition de liens, on ne peut plus modifier l’adresse d’implantation en mémoire. jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Extension d’allocation à la demande avec les fonctions VirtualAlloc, VirtualFree Sur des frontières de 64KB Allocation suivant la taille Dans l’espace virtuel du process ou dans l’espace partagé si la taille atteint ou dépasse deux MB Problèmes de protection d’accès à prendre en considération Microsoft Windows CE .NET 4.2 VirtualAlloc This function reserves or commits a region of pages in the virtual address space of the calling process. Memory allocated by VirtualAlloc is automatically initialized to zero. LPVOID VirtualAlloc( LPVOID lpAddress, DWORD dwSize, DWORD flAllocationType, DWORD flProtect ); Parameters lpAddress [in] Long pointer to the desired starting address of the region to be allocated. If the memory is being reserved, the specified address is rounded down to the next 64-KB boundary. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary. To determine the size of a page on the host computer, use the GetSystemInfo function. If this parameter is NULL, the system determines where to allocate the region. dwSize [in] Specifies the size, in bytes, of the region. If the lpAddress parameter is NULL, this value is rounded up to the next page boundary. Otherwise, the allocated pages include all pages containing one or more bytes in the range from lpAddress to lpAddress+dwSize. This means that a 2-byte range straddling a page boundary causes both pages to be included in the allocated region. flAllocationType [in] Specifies the type of allocation. The following table shows flags you can specify for this parameter in any combination. ValueDescriptionMEM_COMMITAllocates physical storage in memory or in the paging file on disk for the specified region of pages. An attempt to commit an already committed page will not cause the function to fail. This means that a range of committed or decommitted pages can be committed without having to worry about a failure.MEM_RESERVEReserves a range of the virtual address space of the process without allocating any physical storage. The reserved range cannot be used by any other allocation operations, such as the malloc and LocalAlloc functions, until it is released. Reserved pages can be committed in subsequent calls to the VirtualAlloc function.MEM_RESETNot supported.MEM_TOP_DOWNAllocates memory at the highest possible address. This flag is ignored in Windows CE .NET. flProtect [in] Specifies the type of access protection. If the pages are being committed, any one of the flags shown in the following table can be specified, along with the PAGE_GUARD and PAGE_NOCACHE protection modifier flags, as desired. The following table shows the flags with their descriptions. ValueDescriptionPAGE_READONLYEnables read access to the committed region of pages. An attempt to write to the committed region results in an access violation. If the system differentiates between read-only access and execute access, an attempt to execute code in the committed region results in an access violation.PAGE_READWRITEEnables both read and write access to the committed region of pages.PAGE_EXECUTEEnables execute access to the committed region of pages. An attempt to read or write to the committed region results in an access violation.PAGE_EXECUTE_READEnables execute and read access to the committed region of pages. An attempt to write to the committed region results in an access violation.PAGE_EXECUTE_READWRITEEnables execute, read, and write access to the committed region of pages.PAGE_GUARDPages in the region become guard pages. Any attempt to read from or write to a guard page causes the system to raise a STATUS_GUARD_PAGE exception and turn off the guard page status. Guard pages thus act as a one-shot access alarm. The PAGE_GUARD flag is a page protection modifier. An application uses it with one of the other page protection flags, with one exception: It cannot be used with PAGE_NOACCESS. When an access attempt leads the system to turn off guard page status, the underlying page protection takes over. If a guard page exception occurs during a system service, the service typically returns a failure status indicator.PAGE_NOACCESSDisables all access to the committed region of pages. An attempt to read from, write to, or execute in the committed region results in an access violation exception, called a general protection (GP) fault.PAGE_NOCACHEAllows no caching of the committed regions of pages. The hardware attributes for the physical memory should be specified as no cache. This is not recommended for general usage. It is useful for device drivers; for example, mapping a video frame buffer with no caching. This flag is a page protection modifier and is only valid when used with one of the page protections other than PAGE_NOACCESS. Return Values The base address of the allocated region of pages indicates success. NULL indicates failure. To get extended error information, call GetLastError. Remarks The following flProtect flags are not supported: PAGE_WRITECOPY PAGE_EXECUTE_WRITECOPY VirtualAlloc can perform the following operations: Commit a region of pages reserved by a previous call to the VirtualAlloc function. Reserve a region of free pages. Reserve and commit a region of free pages. You can use VirtualAlloc to reserve a block of pages and then make additional calls to VirtualAlloc to commit individual pages from the reserved block. This enables a process to reserve a range of its virtual address space without consuming physical storage until it is needed. Each page in the virtual address space of the process is in one of three states: Free, in which the page is not committed or reserved and is not accessible to the process. VirtualAlloc can reserve, or simultaneously reserve and commit, a free page. Reserved, in which the range of addresses cannot be used by other allocation functions, but the page is not accessible and has no physical storage associated with it. VirtualAlloc can commit a reserved page, but it cannot reserve it a second time. The VirtualFree function can release a reserved page, making it a free page. Committed, in which physical storage is allocated for the page, and access is controlled by a protection code. The system initializes and loads each committed page into physical memory only at the first attempt to read or write to that page. When the process terminates, the system releases the storage for committed pages. VirtualAlloc can commit an already committed page. This means that you can commit a range of pages, regardless of whether they have already been committed, and the function will not fail. VirtualFree can decommit a committed page, releasing the page's storage, or it can simultaneously decommit and release a committed page. If the lpAddress parameter is not NULL, the function uses the lpAddress and dwSize parameters to compute the region of pages to be allocated. The current state of the entire range of pages must be compatible with the type of allocation specified by the flAllocationType parameter. Otherwise, the function fails and none of the pages are allocated. This compatibility requirement does not preclude committing an already committed page. VirtualAlloc will automatically reserve memory at the shared memory region if you call this function with dwSize >= 2 MB, flAllocationType set to MEM_RESERVE, and flProtect set to PAGE_NOACCESS. This preserves per-process virtual memory. Requirements OS Versions: Windows CE 1.0 and later. Header: Winbase.h. Link Library: Coredll.lib. See Also GetSystemInfo | LocalAlloc | VirtualFree | VirtualProtect | VirtualQuery Last updated on Tuesday, February 03, 2004 © Microsoft Corporation. All rights reserved. jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Mémoire externe au process
1 Go moins l’espace du slot 32 (32 Mo) Dans l’espace entre 1GB (+32MB) et 2GB Allocation à la demande de zones privées ou partageables VirtualAlloc(), VirtualFree(),… Fonctions fichiers jc/md/lp-01/05 Gestion mémoire : présentation

Passage de pointeurs Il peut être intéressant pour une application de passer à un driver des pointeurs créés dynamiquement Les adresses de ces pointeurs sont créées en slot 0, pendant l’exécution et par conséquent l’application ne connaît que l’adresse locale Le driver doit donc établir la correspondance entre cette adresse en slot 0 et son image dans l’espace virtuel de l’application pour pouvoir les réutiliser jc/md/lp-01/05 Gestion mémoire : présentation

Correspondance des pointeurs
Le système propose deux fonctions pour résoudre le problème technique Le driver récupère le handle du process appelant par : GetCallerProcess(void) Puis le driver demande au système d’établir, grâce à ce handle, la correspondance pour le même pointeur vu dans l’autre slot par : MapPtrToProcess( LPVOID lpv, HANDLE hProc) jc/md/lp-01/05 Gestion mémoire : présentation

GetCallerProcess(void)
HANDLE GetCallerProcess(void); Parameters None. Return Values A handle to the caller process indicates success. jc/md/lp-01/05 Gestion mémoire : présentation

MapPtrToProcess LPVOID MapPtrToProcess( LPVOID lpv, HANDLE hProc ); Parameters lpv [in] Long pointer to be mapped. hProc [in] Handle to the process into which the lpv pointer is to be mapped. Return Values If successful, returns a mapped version of the lpv pointer; otherwise, the return value is NULL. jc/md/lp-01/05 Gestion mémoire : présentation

CE4.2 Driver à réaliser Écrire un driver qui recevra dans un IOCTL, non pas un buffer avec des données, mais un buffer contenant deux adresses, l’une d’un buffer de texte unicode pour les entrées, l’autre d’un buffer de texte unicode pour les sorties (WCHAR) In et Out. L’IOCTL devra établir la correspondance pour ces pointeurs chez l’appelant L’IOCTL lira le buffer In, le modifiera (passage majuscule vers minuscule), et le réécrira dans la zone Out Le terme anglais map et ses dérivés mapped, mapping sont très employés et plus ou moins passés dans le jargon technique : ils sont difficiles à éviter en français. Une traduction du verbe to map par « établir la correspondance, faire correspondre, définir une application au sens mathématique du terme » serait utilisable, mais pour les dérivés, ce n’est pratiquement pas possible et nous conserverons quelquefois les termes maping, etc. jc/md/lp-01/05 Gestion mémoire : présentation Gestion mémoire_presentation_V1.0.ppt

Driver (1) jc/md/lp-01/05 Gestion mémoire : présentation

Driver : fichier .cpp fourni
jc/md/lp-01/05 Gestion mémoire : présentation

Insertion Créer et insérer dans le projet le fichier des entêtes PTR.h Créer et insérer dans le projet le fichier PTR_DRV.def jc/md/lp-01/05 Gestion mémoire : présentation

PTR.h #include <Windev.h> typedef struct { WCHAR *lpInBuffer; WCHAR *lpOutBuffer; }MYPTRS,*PMYPTRS; #define IOCTL_POINTEURS CTL_CODE( FILE_DEVICE_UNKNOWN, 2048, METHOD_BUFFERED,FILE_ANY_ACCESS) jc/md/lp-01/05 Gestion mémoire : présentation

PTR_DRV.def LIBRARY PTR_DRV EXPORTS PTR_Init PTR_Deinit PTR_Open PTR_Close PTR_IOControl jc/md/lp-01/05 Gestion mémoire : présentation

Structure du driver jc/md/lp-01/05 Gestion mémoire : présentation

Entête du driver //includes // TODO //définitions et réservations globales //entrée du driver BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { return TRUE; } jc/md/lp-01/05 Gestion mémoire : présentation

PTR_Init DWORD PTR_Init(DWORD dwContext) { DWORD dwRet =1; RETAILMSG(1,(TEXT("PTR_DRV: PTR_Init\n"))); //Initialisation du buffer de travail à zéro // TODO return dwRet; } jc/md/lp-01/05 Gestion mémoire : présentation

PTR_Deinit BOOL PTR_Deinit(DWORD hDeviceContext) { BOOL bRet = TRUE; RETAILMSG(1,(TEXT("PTR_DRV: PTR_Deinit\n"))); return bRet; } jc/md/lp-01/05 Gestion mémoire : présentation

PTR_Open DWORD PTR_Open(DWORD hDeviceContext, DWORD AccessCode, DWORD ShareMode) { DWORD dwRet = 1; RETAILMSG(1,(TEXT("PTR_DRV: PTR_Open\n"))); return dwRet; } jc/md/lp-01/05 Gestion mémoire : présentation

PTR_Close BOOL PTR_Close(DWORD hOpenContext) { BOOL bRet = TRUE; RETAILMSG(1,(TEXT("PTR_DRV: PTR_Close\n"))); return bRet; } jc/md/lp-01/05 Gestion mémoire : présentation

IOCTL (1) BOOL PTR_IOControl(DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut) { jc/md/lp-01/05 Gestion mémoire : présentation

IOCTL (2) //Réservations // TODO switch(dwCode) { jc/md/lp-01/05 Gestion mémoire : présentation

IOCTL (3) case IOCTL_POINTEURS: // TODO //Récupération du handle de l'appelant //Mappage des adresses des pointeurs //Impression des valeurs des pointeurs remappés //(RETAILMSG)… // TODO //Lecture du buffer In //Modification dans le buffer //Écriture dans le buffer Out bRet = TRUE; break; jc/md/lp-01/05 Gestion mémoire : présentation

IOCTL (4) default: RETAILMSG(1,(TEXT("PTR_DRV: erreur IOCTL \n"))); bRet=FALSE; break; }//Fin du switch return bRet; } //Fin Ioctl jc/md/lp-01/05 Gestion mémoire : présentation

Génération du driver jc/md/lp-01/05 Gestion mémoire : présentation

Création de l’image noyau & driver

Application PTR_APP Préparation jc/md/lp-01/05 Gestion mémoire : présentation

Application à réaliser
L’application créera 2 buffers prévus pour des textes codés en unicode : In et Out In contiendra un texte en majuscule Out contiendra XXXXXXXXX L’application passera au driver une structure contenant l’adresse de ces 2 buffers Un IOCTL modifiera le buffer OUT L’application imprimera le buffer modifié jc/md/lp-01/05 Gestion mémoire : présentation

Application (1) jc/md/lp-01/05 Gestion mémoire : présentation

Application PTR_APP Code jc/md/lp-01/05 Gestion mémoire : présentation

Entête de l’application
// TODO : Include et définitions int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { jc/md/lp-01/05 Gestion mémoire : présentation

Création et initialisation des buffers
// TODO: définition du nom de la structure à passer // TODO: allocation des buffers In et Out // TODO: initialisation des 2 buffers (wcscpy) // TODO: affichage du buffer Out (MessageBox) // TODO: impression des adresses des buffers (RETAILMSG) jc/md/lp-01/05 Gestion mémoire : présentation

Chargement du driver // TODO: inscription du driver (RegisterDevice) if(hDriver == 0) { MessageBox(NULL, _T("Pb au chargement de PTR_DRV.dll"),_T("PTR_APP"),MB_OK); return 0; } jc/md/lp-01/05 Gestion mémoire : présentation

Ouverture du driver // TODO: ouverture du driver en Read/Write if (INVALID_HANDLE_VALUE == hPtr) { MessageBox(NULL, _T("Pb Open driver"), _T("PTR_APP"), MB_OK); //TODO: déchargement du driver return 0; } jc/md/lp-01/05 Gestion mémoire : présentation

IOCTL // TODO: appel de l'IOCTL pour modifier le contenu du buffer // TODO: affichage du buffer de sortie modifié jc/md/lp-01/05 Gestion mémoire : présentation

Libération des ressources
// TODO: libération des buffers // TODO: déchargement du driver et fermeture de tous les handles driver return 0; } jc/md/lp-01/05 Gestion mémoire : présentation

Génération de l’application

Exécution de l’application
Télécharger dans la cible l’image du noyau avec le driver STR_DRV Lancer l’application Target→Run Program→STR_APP jc/md/lp-01/05 Gestion mémoire : présentation

Début de l’exécution jc/md/lp-01/05 Gestion mémoire : présentation

Exécution jc/md/lp-01/05 Gestion mémoire : présentation

Messages dans la fenêtre se sortie

Adresses avant et après remapping
PTR_APP: InBuffer avant remapping:30050 PTR_APP: OutBuffer avant remapping:30260 PTR_DRV: InBuffer après remapping: PTR_DRV: OutBuffer après remapping: jc/md/lp-01/05 Gestion mémoire : présentation

Target→Ce Processes jc/md/lp-01/05 Gestion mémoire : présentation

Conclusion Première approche de l’organisation mémoire Exemple pratique de communication d’adresses créées dynamiquement dans le slot 0 à un driver jc/md/lp-01/05 Gestion mémoire : présentation

Gestion mémoire : présentation

Présentations similaires

Présentation au sujet: "Gestion mémoire : présentation"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Gestion mémoire : présentation

Présentations similaires

Présentation au sujet: "Gestion mémoire : présentation"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back