From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105017 invoked by alias); 11 Dec 2017 12:11:19 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 104983 invoked by uid 89); 11 Dec 2017 12:11:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pays, HX-Google-Smtp-Source:sk:ACJfBot X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-ot0-f179.google.com Received: from mail-ot0-f179.google.com (HELO mail-ot0-f179.google.com) (74.125.82.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Dec 2017 12:11:15 +0000 Received: by mail-ot0-f179.google.com with SMTP id h9so14521347oti.0 for ; Mon, 11 Dec 2017 04:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DZIJ9e36lotZvBZDgvKsPmLctaWQZfLFlp9Z3+PM5i8=; b=T38op0Ri3oqlK3W2uY4G6+rAscUGFOJKoX16iXZi3sMOL7+qp+6qgrV2MQGWgHLzke oIgI3f4eN/6bR296BL6jfT4fVjSX6J4zw2jdcO47zOWdntL+F/xYbQneUkbrKJctKz85 KtUbPDSs8Yga8lqNt6wK07KBUAE+vi5EzRn/dVhw13vQ+r/L2ChP6yBRIi996QwJree0 +keKUBTQDTrlN7P8aQ0u+gR5Sd1ejrYcgnDtSucLUjn0MLuMX6qGZJXYv2KXTGglGCPY pBCsUR/pt2wfO9P87vEKZUyIEWiTOEBmHrwamiJr5ncuxj65e7BjQHRC5Kdbn8OxHG/R uVnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DZIJ9e36lotZvBZDgvKsPmLctaWQZfLFlp9Z3+PM5i8=; b=AcwUWxQFvJQDGe41/n1b5okdBfn9CG/+6Peyrz+z2gWd9eJdR9WieRbiY629MSWj2i CRpeBOhvKxyv3qQRS4qnZXTVFX5t0QdH5HSNHtlTU88aSfE3+pFgoaEh3RsrS5ChGlh1 1tKHG5U36GP/ICpA2LiSddul+kA29DfkGSWbA1lPTMjZEC09B0KpxvDPaaSumTllAEEF f5A7Xir5doOpJFaGz4meYNqgGpSIzWczyABe+Kd5BxSkcmodoDm2g3iHXkanzSQZO2V8 7I/ts0E/LV2PIponyys4SCaqOXEu4wK18mi9we1RrR40MsF29/oWtSELGTh8mNg6Q2+R wiew== X-Gm-Message-State: AKGB3mKi0MITUzyCPv5eUV8T7/HIiuhi8kKtsaGlgx0HDHqmi4cmLTIb 9wBi0v8mboSJ8CT4wMlN8Cj1GLUScpOnX+rq9oo= X-Google-Smtp-Source: ACJfBotNd7XqaxQEBKfQadBg8hbSMvzUyPIgAseum1GbmAABO7Ivot7OQIBQDpFxwNLoaTmwX8cYCb9y7dsz3v2EhR8= X-Received: by 10.157.65.213 with SMTP id v21mr102451oti.392.1512994273635; Mon, 11 Dec 2017 04:11:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.151.42 with HTTP; Mon, 11 Dec 2017 04:11:12 -0800 (PST) In-Reply-To: <1512985389.15696.45.camel@klomp.org> References: <99c8440b-54d8-41bc-6e4d-cd1894536bb7@Oracle.COM> <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com> <1512985389.15696.45.camel@klomp.org> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: What integer type should ELF note header have? To: Mark Wielaard Cc: Generic System V Application Binary Interface , Suprateeka R Hegde , Cary Coutant , Mark Mentovai , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00013.txt.bz2 On Mon, Dec 11, 2017 at 1:43 AM, Mark Wielaard wrote: > On Sun, 2017-12-10 at 22:22 -0700, Ali Bahrami wrote: >> To my reading, the words of the gABI support what HP-UX did, and the >> comment in the Solaris code makes me think our definition of >> ELF64_Nhdr >> was a mistake. And given that the rest of us don't have any installed >> base (yet) of 8 byte alignment notes, it seems that the most >> compatible >> thing that we could do would be to also use 8-byte words for these >> fields. >> triggered by an sh_addralign, or p_align, of 8. That seems to match >> the >> gABI words, and preserves interoperability with HP-UX. >> >> An open question to you and Mark, and any others in the GNU world: >> Would you consider making that change? If so, I think we (Solaris) >> would have no problem in doing likewise. > > I am afraid changing ELF64_Nhdr/GElf_Nhdr now from 32bit Words, or Changing ELF64_Nhdr is going to be hard, but not impossible. In theory, an 64-bit object may have a note entry which is bigger than 4 GB. We can add a new note header: typedef struct { Elf64_Xword n_namesz; /* Length of the note's name. */ Elf64_Xword n_descsz; /* Length of the note's descriptor. */ Elf64_Xword n_type; /* Type of the note. */ } Elf64_Nhdr64; Note segments/sections with 8 byte alignment should use Elf64_Nhdr64. If we want to do it, we should do it now before NT_GNU_PROPERTY_TYPE_0 notes with the existing Elf64_Nhdr are generated by GCC 8 with -fcf-protection -mcet. > changing the alignment of the namesz or descsz from 4 byte alignment is I have updated glibc and binutils to support 4 byte and 8 byte alignments in 64-bit objects by checking p_align/sh_addralign, instead of assuming 4 byte alignment, like commit 8d81ce0c6d6ca923571e8b2bac132929f9a02973 Author: H.J. Lu Date: Tue Nov 28 09:56:47 2017 -0800 Properly compute offsets of note descriptor and next note [BZ #22370] A note header has 3 4-bytes fields, followed by note name and note descriptor. According to gABI, in a note entry, the note name field, not note name size, is padded for the note descriptor. And the note descriptor field, not note descriptor size, is padded for the next note entry. Notes are aligned to 4 bytes in 32-bit objects and 8 bytes in 64-bit objects. For all GNU notes, the name is "GNU" which is 4 bytes. They have the same format in the first 16 bytes in both 32-bit and 64-bit objects. They differ by note descriptor size and note type. So far, .note.ABI-tag and .note.gnu.build-id notes are always aligned to 4 bytes. The exsting codes compute the note size by aligning the note name size and note descriptor size to 4 bytes. It happens to produce the same value as the actual note size by luck since the name size is 4 and offset of the note descriptor is 16. But it will produce the wrong size when note alignment is 8 bytes in 64-bit objects. This patch defines ELF_NOTE_DESC_OFFSET and ELF_NOTE_NEXT_OFFSET to properly compute offsets of note descriptor and next note. It uses alignment of PT_NOTE segment to support both 4-byte and 8-byte note alignments in 64-bit objects. To handle PT_NOTE segments with incorrect alignment, which may lead to an infinite loop, if segment alignment is less than 4, we treate alignment as 4 bytes since some note segments have 0 or 1 byte alignment. > not going to work. It is too hardcoded in various GNU/Linux code bases > now to change. On GNU/Linux ELF notes have been used a lot already, if > only to parse the build-id embedded in every executable. So you will > find a lot of code that will simply do: > > /* > * Align offset to 4 bytes as needed for note name and descriptor data. > */ > #define NOTE_ALIGN(n) (((n) + 3) & -4U) > > GElf_Nhdr *nhdr = ptr; > size_t namesz = NOTE_ALIGN(nhdr->n_namesz), > descsz = NOTE_ALIGN(nhdr->n_descsz); > const char *name; > > ptr += sizeof(*nhdr); > name = ptr; > ptr += namesz; > [...] > ptr += descsz; > > The above is from the linux kernel perf tool (tools/perf/util/symbol- > elf.c), but I can easily find more examples of hard coded parsing of > ELF notes that simply assumes they are 32 bit Words, 4 byte aligned (it > is basically what elfutils libelf also does). > > You could play with the SHT_NOTE sh_align and PT_NOTE p_align values, > but I haven't actually found any code that pays attention to it. So a > lot of code would have to be rewritten. > These can be easily fixed with /* Compute the offset of the note descriptor from size of note entry's owner string and note alignment. */ # define ELF_NOTE_DESC_OFFSET(namesz, align) \ ALIGN_UP (sizeof (ElfW(Nhdr)) + (namesz), (align)) /* Compute the offset of the next note entry from size of note entry's owner string, size of the note descriptor and note alignment. */ # define ELF_NOTE_NEXT_OFFSET(namesz, descsz, align) \ ALIGN_UP (ELF_NOTE_DESC_OFFSET ((namesz), (align)) + (descsz), (align)) I have added them to glibc, binutils as well as the upcoming kernel patch to enable CET. -- H.J.