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: <CAMe9rOoXKbPKoUjWw4u-AbHRTnfU9A57dW+vJ3+diXZ04wCMYA@mail.gmail.com>
Date:   Wed, 9 Aug 2017 11:46:24 -0700
From:   "H.J. Lu" <hjl.tools@...il.com>
To:     Kees Cook <keescook@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Binutils <binutils@...rceware.org>
Subject: Re: new ELF marking

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