This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new ELF marking

On Wed, Aug 9, 2017 at 11:26 AM, Kees Cook <> wrote:
> On Wed, Aug 9, 2017 at 10:16 AM, H.J. Lu <> wrote:
>> On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
>> <> 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:
>  \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


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]