Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Mark Wielaard <mjw@redhat.com>,
	Cary Coutant <ccoutant@google.com>,
	       Doug Evans <dje@google.com>,
	       "Metzger, Markus T" <markus.t.metzger@intel.com>,
	       "gdb@sourceware.org" <gdb@sourceware.org>,
	       "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: vdso handling
Date: Thu, 13 Mar 2014 14:59:00 -0000	[thread overview]
Message-ID: <5321C7C8.6000707@redhat.com> (raw)
In-Reply-To: <20140313130322.GA3384@bubble.grove.modra.org>

On 03/13/2014 01:03 PM, Alan Modra wrote:
> On Thu, Mar 13, 2014 at 10:52:16AM +0100, Mark Wielaard wrote:
>> On Thu, 2014-03-13 at 11:31 +1030, Alan Modra wrote:
>>> It wouldn't
>>> help in the vdso case anyway, since the problem there is that you only
>>> have the loaded part of the original ELF file.
>>
>> Note that the vdso is often special, compared to other ELF dsos, because
>> the loaded part is just the complete ELF image in memory. Since they are
>> very simple they will just have one PT_LOAD at offset zero and if the
>> image is smaller than the page size then the whole file is just simply
>> mapped into memory completely. So by fetching the vdso ELF image from
>> remote memory you should be able to get the section headers and the
>> not-allocated sections too.
> 
> Yes, but if the vdso does not fit in a page (which incidentally is
> inferred by program header p_align), then you may lose the section
> headers.  I was assuming this was the case.

Hmm.  How so?  On x86 (arch/x86/vdso/vdso.S), the kernel just does:

        .globl vdso_start, vdso_end
        .align PAGE_SIZE
vdso_start:
        .incbin "arch/x86/vdso/vdso.so"
vdso_end:
        .align PAGE_SIZE /* extra data here leaks to userspace. */


And then arch/x86/vdso/vma.c has:

static int __init init_vdso(void)
{
        int npages = (vdso_end - vdso_start + PAGE_SIZE - 1) / PAGE_SIZE;
        int i;

        patch_vdso64(vdso_start, vdso_end - vdso_start);

        vdso_size = npages << PAGE_SHIFT;
        for (i = 0; i < npages; i++)
                vdso_pages[i] = virt_to_page(vdso_start + i*PAGE_SIZE);

#ifdef CONFIG_X86_X32_ABI
        patch_vdsox32(vdsox32_start, vdsox32_end - vdsox32_start);
        npages = (vdsox32_end - vdsox32_start + PAGE_SIZE - 1) / PAGE_SIZE;
        vdsox32_size = npages << PAGE_SHIFT;
        for (i = 0; i < npages; i++)
                vdsox32_pages[i] = virt_to_page(vdsox32_start + i*PAGE_SIZE);
#endif

        return 0;
}

And patch_vdso64 _relies_ on sections being present at runtime:

static void __init patch_vdso64(void *vdso, size_t len)
{
        Elf64_Ehdr *hdr = vdso;
        Elf64_Shdr *sechdrs, *alt_sec = 0;
        char *secstrings;
        void *alt_data;
        int i;

        BUG_ON(len < sizeof(Elf64_Ehdr));
        BUG_ON(memcmp(hdr->e_ident, ELFMAG, SELFMAG) != 0);

        sechdrs = (void *)hdr + hdr->e_shoff;
        secstrings = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;

        for (i = 1; i < hdr->e_shnum; i++) {
                Elf64_Shdr *shdr = &sechdrs[i];
                if (!strcmp(secstrings + shdr->sh_name, ".altinstructions")) {
                        alt_sec = shdr;
                        goto found;
                }
        }

        /* If we get here, it's probably a bug. */
        pr_warning("patch_vdso64: .altinstructions not found\n");
        return;  /* nothing to patch */

found:
        alt_data = (void *)hdr + alt_sec->sh_offset;
        apply_alternatives(alt_data, alt_data + alt_sec->sh_size);
}

On e.g., arch/powerpc/kernel/vdso.c, I see even a lot more
code looking at the sections of the vdso.

-- 
Pedro Alves


  parent reply	other threads:[~2014-03-13 14:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 13:05 Metzger, Markus T
2014-03-12  7:17 ` Alan Modra
2014-03-12 11:31   ` Mike Frysinger
2014-03-12 17:34   ` Doug Evans
2014-03-12 20:23     ` Cary Coutant
2014-03-13  1:01       ` Alan Modra
2014-03-13  8:25         ` Metzger, Markus T
2014-03-13  9:48           ` Metzger, Markus T
2014-03-13 10:07           ` Pedro Alves
2014-03-13 10:46             ` Pedro Alves
2014-06-01 20:32               ` Samuel Bronson
2014-06-06 12:45                 ` Pedro Alves
2014-03-13 13:13             ` Alan Modra
2014-03-13  9:52         ` Mark Wielaard
2014-03-13 13:03           ` Alan Modra
2014-03-13 14:38             ` Mark Wielaard
2014-03-13 14:59             ` Pedro Alves [this message]
2014-03-13 15:04               ` Pedro Alves
2014-03-13 15:26                 ` Pedro Alves
2014-03-13 23:53                   ` Alan Modra
2014-03-18 15:14                     ` Metzger, Markus T
2014-03-18 23:10                       ` Alan Modra
2014-03-19  8:11                         ` Metzger, Markus T
2014-03-19  8:31                         ` Metzger, Markus T
2014-03-19 12:04                           ` Pedro Alves
2014-03-20  2:00                           ` Alan Modra
2014-03-21 15:55                             ` Pedro Alves
2014-03-26  9:32                               ` Metzger, Markus T
2014-03-19 12:03                         ` Pedro Alves
2014-03-20  1:33                           ` Alan Modra
2014-03-21  8:10                             ` Metzger, Markus T
2014-03-21 15:48                             ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5321C7C8.6000707@redhat.com \
    --to=palves@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=ccoutant@google.com \
    --cc=dje@google.com \
    --cc=gdb@sourceware.org \
    --cc=markus.t.metzger@intel.com \
    --cc=mjw@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox