linux-kernel - Re: [PATCH] binfmt_elf: Extract .note.gnu.property from an ELF file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190502161424.GQ3567@e103592.cambridge.arm.com>
Date:   Thu, 2 May 2019 17:14:24 +0100
From:   Dave Martin <Dave.Martin@....com>
To:     Yu-cheng Yu <yu-cheng.yu@...el.com>
Cc:     x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-mm@...ck.org,
        linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...capital.net>,
        Balbir Singh <bsingharora@...il.com>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        "H.J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Nadav Amit <nadav.amit@...il.com>,
        Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
        Peter Zijlstra <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Vedvyas Shanbhogue <vedvyas.shanbhogue@...el.com>,
        Szabolcs Nagy <szabolcs.nagy@....com>,
        libc-alpha@...rceware.org
Subject: Re: [PATCH] binfmt_elf: Extract .note.gnu.property from an ELF file

On Thu, May 02, 2019 at 08:47:06AM -0700, Yu-cheng Yu wrote:
> On Thu, 2019-05-02 at 12:10 +0100, Dave Martin wrote:
> > On Wed, May 01, 2019 at 02:12:17PM -0700, Yu-cheng Yu wrote:
> > > An ELF file's .note.gnu.property indicates features the executable file
> > > can support.  For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> > > indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> > > GNU_PROPERTY_X86_FEATURE_1_SHSTK.
> 
> [...]
> > A couple of questions before I look in more detail:
> > 
> > 1) Can we rely on PT_GNU_PROPERTY being present in the phdrs to describe
> > the NT_GNU_PROPERTY_TYPE_0 note?  If so, we can avoid trying to parse
> > irrelevant PT_NOTE segments.
> 
> Some older linkers can create multiples of NT_GNU_PROPERTY_TYPE_0.  The code
> scans all PT_NOTE segments to ensure there is only one NT_GNU_PROPERTY_TYPE_0. 
> If there are multiples, then all are considered invalid.

I'm concerned that in the arm64 case we would waste some effort by
scanning multiple notes.

Could we do something like iterating over the phdrs, and if we find
exactly one PT_GNU_PROPERTY then use that, else fall back to scanning
all PT_NOTEs?

> > 2) Are there standard types for things like the program property header?
> > If not, can we add something in elf.h?  We should try to coordinate with
> > libc on that.  Something like
> > 
> > typedef __u32 Elf_Word;
> > 
> > typedef struct {
> > 	Elf_Word pr_type;
> > 	Elf_Word pr_datasz;
> > } Elf_Gnu_Prophdr;
> > 
> > (i.e., just the header part from [1], with a more specific name -- which
> > I just made up).
> 
> Yes, I will fix that.
> 
> [...]
> > 3) It looks like we have to go and re-parse all the notes for every
> > property requested by the arch code.
> 
> As explained above, it is necessary to scan all PT_NOTE segments.  But there
> should be only one NT_GNU_PROPERTY_TYPE_0 in an ELF file.  Once that is found,
> perhaps we can store it somewhere, or call into the arch code as you mentioned
> below.  I will look into that.

Just to get something working on arm64, I'm working on some hacks that
move things around a bit -- I'll post when I have something.

Did you have any view on my other point, below?

Cheers
---Dave

> > For now there is only one property requested anyway, so this is probably
> > not too bad.  But could we flip things around so that we have some
> > CONFIG_ARCH_WANTS_ELF_GNU_PROPERTY (say), and have the ELF core code
> > call into the arch backend for each property found?
> > 
> > The arch could provide some hook
> > 
> > 	int arch_elf_has_gnu_property(const Elf_Gnu_Prophdr *prop,
> > 					const void *data);
> > 
> > to consume the properties as they are found.
> > 
> > This would effectively replace the arch_setup_property() hook you
> > currently have.
> > 
> > Cheers
> > ---Dave
> > 
> > [1] https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
>