From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1D4C43857C52; Fri, 22 Oct 2021 14:19:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D4C43857C52 From: "mark at klomp dot org" To: elfutils-devel@sourceware.org Subject: [Bug tools/28488] phdr[6]: unknown object file note type 32 with owner name '' at offset 48 Date: Fri, 22 Oct 2021 14:19:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: tools X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 14:19:05 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28488 --- Comment #9 from Mark Wielaard --- So the real difference is that with the Fedora the .note.gnu.property has alignment 4 and so it gets merged with the other (allocated) note sections.= But the opensuse version .note.gnu.property has alignment 8 and ends up in its = own phdr NOTE segment. I don't know whether this is buggy or if eu-elflint just gets confused about it. Creating NOTEs with an alignment of 8 was controversial since at least on G= NU systems all other NOTEs have alignment 4 whether or not using ELFCLASS32 or ELFCLASS64. Handling of gnu property notes was added with: commit 5199e15870e05e5b0b9f98c20fc9b5427aa6dd6a Author: Mark Wielaard Date: Mon Oct 15 23:35:47 2018 +0200 Recognize and parse GNU Property notes. 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. 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 to determine the padding. 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. 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. 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. Tests are added for extracting the note from sections or segments as set by gcc -fcf-protection. Signed-off-by: Mark Wielaard Another maybe (or maybe not) related bug: "unknown program header entry type 0x6474e553 (PT_GNU_PROPERTY)" https://sourceware.org/bugzilla/show_bug.cgi?id=3D25511 --=20 You are receiving this mail because: You are on the CC list for the bug.=