Examen des adresses mmaped à l'aide de GDB

Je suis en utilisant le pilote que j'ai posté au Accès Direct à la Mémoire sous Linux à mmap certains de ram physique dans un espace utilisateur de l'adresse. Cependant, je ne peux pas utiliser GDB pour regarder tout de l'adresse; c'est à dire, x 0x12345678 (où 0x12345678 est la valeur de retour de mmap) échoue avec une erreur "Impossible d'accéder à la mémoire à l'adresse 0x12345678".

Est-il une manière de dire GDB que cette mémoire peut être consulté? Sinon, est-il quelque chose de différent que je peux faire dans le mmap (ni de l'appel ou de la mise en œuvre de foo_mmap) qui lui permettent d'accéder à cette mémoire?

Remarque que je ne suis pas de demander à propos de /dev/mem (comme dans le premier extrait de là), mais sur un mmap à la mémoire acquis par l'intermédiaire de ioremap(), virt_to_phys() et remap_pfn_range()

source d'informationauteur Mikeage

gdb mmap

Je crois que Linux ne permet pas de faire des I/O mémoire accessible via ptrace(). Vous pouvez écrire une fonction qui lit simplement le mmap ed adresse et a gdb appeler. Voici une version légèrement modifiée de votre foo-utilisateur.programme en c avec la sortie d'une session gdb.

#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/mman.h>

char *mptr;

char peek(int offset)
{
    return mptr[offset];
}

int main(void)
{
    int fd;
    fd = open("/dev/foo", O_RDWR | O_SYNC);
    if (fd == -1) {
        printf("open error...\n");
        return 1;
    }
    mptr = mmap(0, 1 * 1024 * 1024, PROT_READ | PROT_WRITE,
             MAP_FILE | MAP_SHARED, fd, 4096);
    printf("On start, mptr points to 0x%lX.\n", (unsigned long) mptr);
    printf("mptr points to 0x%lX. *mptr = 0x%X\n", (unsigned long) mptr,
           *mptr);
    mptr[0] = 'a';
    mptr[1] = 'b';
    printf("mptr points to 0x%lX. *mptr = 0x%X\n", (unsigned long) mptr,
           *mptr);
    close(fd);
    return 0;
}



$ make foo-user CFLAGS=-g
$ gdb -q foo-user
(gdb) break 27
Breakpoint 1 at 0x804855f: file foo-user.c, line 27.
(gdb) run
Starting program: /home/me/foo/foo-user 
On start, mptr points to 0xB7E1E000.
mptr points to 0xB7E1E000. *mptr = 0x61

Breakpoint 1, main () at foo-user.c:27
27          mptr[0] = 'a';
(gdb) n
28          mptr[1] = 'b';
(gdb) print peek(0)
$1 = 97 'a'
(gdb) print peek(1)
$2 = 98 'b'

10

J'ai la réponse à votre énigme 🙂 j'ai cherché partout, en ligne sans beaucoup d'aide et enfin une mise au point moi-même.

Ce post a été un bon point de départ pour moi. Je voulais faire quelque chose dans le genre, j'avais mis en place un pilote de char avec MMAP à la carte de mon géré personnalisé de mémoire pour un processus de l'espace utilisateur. Lors de l'utilisation de GDB, ptrace coup d'oeil à des appels access_process_vm() pour accéder à toute la mémoire de votre VMA. Cela provoque une erreur EIO depuis le générique d'accès ne peut pas obtenir la PA de votre mémoire. Il s'avère, vous avez à mettre en œuvre une fonction d'accès à cette mémoire par la mise en œuvre .l'accès de votre VMA est vm_operations_struct. Ci-dessous est un exemple:
```
//Below code needs to be implemented by your driver:
static struct vm_operations_struct custom_vm_ops = {
    .access = custom_vma_access,
};

static inline int custom_vma_access(struct vm_area_struct *vma, unsigned long addr,
          void *buf, int len, int write)
{
    return custom_generic_access_phys(vma, addr, buf, len, write);
}

static int custom_generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
            void *buf, int len, int write)
{
    void __iomem *maddr;
    //int offset = (addr & (PAGE_SIZE-1)) - vma->vm_start;
    int offset = (addr) - vma->vm_start;

    maddr = phys_to_virt(__pa(custom_mem_VA));
    if (write)
        memcpy_toio(maddr + offset, buf, len);
    else
        memcpy_fromio(buf, maddr + offset, len);

    return len;
}
```
2

C'est ma compréhension que GDB va être à l'aide de ptrace à fouiller dans votre espace mémoire du processus. Peut-être que vous devriez écrire un programme simple qui vient s'attache aux processus et utilise ptrace à lire à partir de cette mémoire. Cela pourrait aider à réduire ce que le problème sous-jacent est. Si cela n'a pas de problèmes, alors vous savez soit je me trompe :), ou autre chose de louche se passe avec GDB.

vous allez "info les fichiers"

(gdb) help info files
Names of targets and files being debugged.
Shows the entire stack of targets currently in use (including the exec-file,
core-file, and process, if any), as well as the symbol file name.
(gdb) info files
Symbols from "/bin/ls".
Unix child process:
        Using the running image of child Thread 4160418656 (LWP 10729).
        While running this, GDB does not access memory from...
Local exec file:
        `/bin/ls', file type elf32-powerpc.
        Entry point: 0x10002a10
        0x10000134 - 0x10000141 is .interp
        0x10000144 - 0x10000164 is .note.ABI-tag
        0x10000164 - 0x100008f8 is .gnu.hash
        0x100008f8 - 0x10001728 is .dynsym
        0x10001728 - 0x100021f3 is .dynstr
        0x100021f4 - 0x100023ba is .gnu.version
...
        0x0ffa8300 - 0x0ffad8c0 is .text in /lib/libacl.so.1
        0x0ffad8c0 - 0x0ffad8f8 is .fini in /lib/libacl.so.1
        0x0ffad8f8 - 0x0ffadbac is .rodata in /lib/libacl.so.1
        0x0ffadbac - 0x0ffadd58 is .eh_frame_hdr in /lib/libacl.so.1
        0x0ffadd58 - 0x0ffae4d8 is .eh_frame in /lib/libacl.so.1
        0x0ffbe4d8 - 0x0ffbe4e0 is .ctors in /lib/libacl.so.1
        0x0ffbe4e0 - 0x0ffbe4e8 is .dtors in /lib/libacl.so.1
...

(gdb) info sh
From        To          Syms Read   Shared Object Library
0xf7fcf960  0xf7fe81a0  Yes         /lib/ld.so.1
0x0ffd0820  0x0ffd5d10  Yes         /lib/librt.so.1
0x0ffa8300  0x0ffad8c0  Yes         /lib/libacl.so.1
0x0ff6a840  0x0ff7f4f0  Yes         /lib/libselinux.so.1
0x0fdfe920  0x0ff1ae70  Yes         /lib/libc.so.6
0x0fda23d0  0x0fdb0db0  Yes         /lib/libpthread.so.0

À défaut, vous pouvez utiliser le bouton "mem" pour configurer les plages de mémoire.

(gdb) mem 1 1414
(gdb) info mem
Num Enb Low Addr   High Addr  Attrs
1   y   0x00000001 0x00000586 rw nocache
(gdb) disable mem 1
(gdb) info mem
Num Enb Low Addr   High Addr  Attrs
1   n   0x00000001 0x00000586 rw nocache

1

Pour accéder à la mmapped mémoire, GDB fera appel ptrace, qui va alors appeler __access_remote_vm() pour accéder à la mmapped de la mémoire. Si la mémoire est mappée avec des indicateurs tels que VMIO | VM_PFNMAP (par exemple, remap_pfn_range() fixe), GDB va accéder à la mémoire si la vm à la méthode d'accès définis par les utilisateurs.

Plutôt que d'écrire notre propre mise en œuvre pour l'accès (des), le noyau fournit déjà une version générique appelé generic_access_phys(), et cette méthode peut être facilement relié via vm_operations_struct comme /dev/mem de l'appareil:
```
static const struct vm_operations_struct mmap_mem_ops = {
        .access = generic_access_phys };

int mmap_mem()
{
    .... ....
    vma->vm_ops = &mmap_mem_ops;
    .... ....
}
```
0

Je pense que si cette mémoire n'est pas accessible par GDB alors il n'est pas mappé dans votre espace d'adressage du processus et si vous obtenez le message "Impossible d'accéder à la mémoire à l'adresse 0x12345678". Si cette demande a été exécutée normalement, vous obtiendrez une erreur de segmentation. Aussi, peut-être que votre pilote est vissé et vous devriez vérifiez si vous pouvez accéder à la mémoire à partir de l'intérieur du noyau. Essayez avec exemple ici:
```
#include <cstdio>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main() {
    int fd = open("/dev/zero", O_RDONLY);
    void* addr = mmap(NULL, 1024, PROT_READ, MAP_PRIVATE, fd, 0);
    for (int x = 0; x < 10; x++) {
        printf("%X\n", ((char*)addr)[x]);
    }
    close(fd);
    return 0;
}
```
0

Si vous ouvrez un AF_PACKET socket et mmap, gdb ne pouvez pas accéder à cette mémoire. Donc, il n'y a pas un problème avec votre pilote. C'est soit un problème avec ptrace ou avec gdb.

Vous devez vous connecter pour publier un commentaire.