From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73607 invoked by alias); 29 Oct 2018 00:12:28 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 73594 invoked by uid 89); 29 Oct 2018 00:12:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=extracting, Property, sys X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Oct 2018 00:12:26 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2F8AB301470D for ; Mon, 29 Oct 2018 01:12:24 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 2A7FA46765F2; Mon, 29 Oct 2018 01:12:24 +0100 (CET) Message-ID: <1540771944.6768.6.camel@klomp.org> Subject: Re: [PATCH] Recognize and parse GNU Property notes. From: Mark Wielaard To: elfutils-devel@sourceware.org Date: Mon, 29 Oct 2018 00:12:00 -0000 In-Reply-To: <1539944810-15792-1-git-send-email-mark@klomp.org> References: <1539944810-15792-1-git-send-email-mark@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-14.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00088.txt.bz2 On Fri, 2018-10-19 at 12:26 +0200, Mark Wielaard wrote: > GNU Property notes are different from normal notes because they use > variable alignment/padding of their fields. They are 8 byte aligned, > but use 4 byte fields. The name is aligned at 4 bytes and padded so > that, the desc is aligned at 8 bytes. The whole note is padded to > 8 bytes again. For normal notes all fields are both 4 bytes wide and > 4 bytes aligned. >=20 > To recognize these new kind of ELF Notes a new Elf_Type is > introduced, > ELF_T_NHDR8. This type is used in the xlate functions to determine > how to align and pad the various fields. Since the fields themselves > can now have different alignments we will have to keep track of the > current alignement and use either NOTE_ALIGN4 or NOTE_ALIGN8 tor > determine the padding. >=20 > To set the correct Elf_Type on the Elf_Data we use either the section > sh_addralign or the segment p_align values. Assuming 8 means the > section or segment contains the new style notes, otherwise normal > notes. >=20 > When we cannot determine the "alignment" directly, like when parsing > special kernel sys files, we check the name "GNU" and type > "GNU_PROPERTY_TYPE_0" fields. >=20 > ebl_object_note now parses the new NT_GNU_PROPERTY_TYPE_0 and can > extract the GNU_PROPERTY_STACK_SIZE, > GNU_PROPERTY_NO_COPY_ON_PROTECTED > and GNU_PROPERTY_X86_FEATURE_1_AND types > GNU_PROPERTY_X86_FEATURE_1_IBT > and GNU_PROPERTY_X86_FEATURE_1_SHSTK. >=20 > Tests are added for extracting the note from sections or segments > as set by gcc -fcf-protection. I pushed this to master. There is some other information that might come from these notes, but there are various open questions about what, how and the backwards compatibility story. See https://sourceware.org/ml/libc-alpha/2018-10/msg00495.html Cheers, Mark