From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5026 invoked by alias); 13 Mar 2014 14:59:36 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 5002 invoked by uid 89); 13 Mar 2014 14:59:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Mar 2014 14:59:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2DExOq7003998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Mar 2014 10:59:24 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2DExKxh016456; Thu, 13 Mar 2014 10:59:21 -0400 Message-ID: <5321C7C8.6000707@redhat.com> Date: Thu, 13 Mar 2014 14:59:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mark Wielaard , Cary Coutant , Doug Evans , "Metzger, Markus T" , "gdb@sourceware.org" , "binutils@sourceware.org" Subject: Re: vdso handling References: <20140312071701.GW26922@bubble.grove.modra.org> <20140313010147.GZ26922@bubble.grove.modra.org> <1394704336.11818.115.camel@bordewijk.wildebeest.org> <20140313130322.GA3384@bubble.grove.modra.org> In-Reply-To: <20140313130322.GA3384@bubble.grove.modra.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00035.txt.bz2 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