Re: new ELF marking

[H.J. Lu]

On Wed, Aug 9, 2017 at 11:26 AM, Kees Cook <keescook@xxxxxxxxxx> wrote:
> On Wed, Aug 9, 2017 at 10:16 AM, H.J. Lu <hjl.tools@xxxxxxxxx> wrote:
>> On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
>> <binutils@xxxxxxxxxxxxxx> 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.