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: <CAGXu5jL1HRG7Dn9vraw8Hu7LF+69k3EDpztt1Ju7ijEzmvRdhA@mail.gmail.com>
Date:   Wed, 9 Aug 2017 11:26:10 -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>
Subject: Re: new ELF marking

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

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?

(And should the kernel already be parsing GNU_PROPERTY_STACK_SIZE?)

-Kees

-- 
Kees Cook
Pixel Security