linux-kernel - Re: new ELF marking

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: <CAGXu5jLnYZ0r5-utq_YNASdCYk84if3Gs7o+J3K=_GKGEOMcKw@mail.gmail.com>
Date:   Wed, 9 Aug 2017 11:52:07 -0700
From:   Kees Cook <keescook@...gle.com>
To:     "H.J. Lu" <hjl.tools@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Binutils <binutils@...rceware.org>,
        Kostya Serebryany <kcc@...gle.com>
Subject: Re: new ELF marking

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

Why does pr_padding exist if pr_data is always the correct multiple already?

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

What kernel-support is needed for static PIE?

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

Okay.

> Is this an output only bit?  Will it appear in an input file?

I believe this would only be an output bit, but I'm not sure how it
would be wired into binutils. Kostya, do you know any details about
how AddressSanitizer might be able to create this ELF note?

>> (And should the kernel already be parsing GNU_PROPERTY_STACK_SIZE?)
>
> Kernel should.

Have there been patches proposed for this yet?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security