This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: new ELF marking
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Kees Cook <keescook at google dot com>
- Cc: LKML <linux-kernel at vger dot kernel dot org>, Binutils <binutils at sourceware dot org>
- Date: Wed, 9 Aug 2017 11:46:24 -0700
- Subject: Re: new ELF marking
- Authentication-results: sourceware.org; auth=none
- References: <CAGXu5jL2iY8=VhWyqhhUqxAs1akywodrWezU77rnrq-Ksbzwow@mail.gmail.com> <CAMe9rOqH1=wOi_8AyZFURVpN999Ty1WFoTQwcOwHiBJWF_WeMA@mail.gmail.com> <CAGXu5jL1HRG7Dn9vraw8Hu7LF+69k3EDpztt1Ju7ijEzmvRdhA@mail.gmail.com>
On Wed, Aug 9, 2017 at 11:26 AM, Kees Cook <keescook@google.com> wrote:
> On Wed, Aug 9, 2017 at 10:16 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
>> <binutils@sourceware.org> wrote:
>>> Hi,
>>>
>>> I'd like to be able to mark an ELF binary in such a way that Linux's
>>> binfmt_elf.c will collapse a PIE text area into the mmap region
>>> (currently they are separately randomized in memory). This is desired
>>> by AddressSanitizer to avoid having an ASan-built binary have its text
>>> area moving into an unexpected location[1] (ASLR is still desired, but
>>> doesn't need to have a PIE/mmap split).
>>>
>>> I see a few ways:
>>>
>>> - Add parsing for NOTE program headers and add a new NOTE type
>>> (NT_GNU_EXEC_FLAGS), though notes tend to be strings...
>>>
>>> - Add a new Program Header (GNU_EXEC_FLAGS), which is similar to how
>>> GNU_STACK and GNU_RELRO were handled. This could sort of be like NOTE
>>> except just lots of bit flags.
>>>
>>> - Use a filesystem xattr. This is fragile, in the case of copying
>>> binaries between systems or filesystems.
>>>
>>> Thoughts?
>>>
>>>
>>
>> Why don't you use NT_GNU_PROPERTY_TYPE_0?
>
> Ah, interesting. I hadn't seen this before. Docs I found were:
> https://github.com/hjl-tools/linux-abi/commit/a24f6898c4172e09b2e476ae9f160621528a1d92
>
> \item[pr_datasz] The size of the \code{pr_data} field. A 4-byte
> integer in the format of the target processor.
> \item[pr_data] The program property descriptor. An array of 4-byte
> integers in 32-bit object or 8-byte integers in 64-bit objects, in
> the format of the target processor.
>
> Is pr_data length always a multiple of 4 (or 8)? I found this language
Yes.
> confusing, given that pr_datasz doesn't mention this.
>
> Also, given the definition, should the kernel examine these, or should
> it remain limited to the runtimer loader?
Both kernel and run-time loaders should check it. I am working on
static PIE, which is loaded by kernel.
> If the kernel should, would it be better to add
> GNU_PROPERTY_EXEC_FLAGS, for future bits, or should it be something
> like GNU_PROPERTY_NO_COPY_ON_PROTECTED with a pr_datasz == 0?
Please use bits. Is this an output only bit? Will it appear in an input file?
> (And should the kernel already be parsing GNU_PROPERTY_STACK_SIZE?)
>
Kernel should.
--
H.J.