new ELF marking

new ELF marking

[Kees Cook]

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?

-Kees

[1] https://lkml.org/lkml/2017/8/7/770

-- 
Kees Cook
Pixel Security

Re: new ELF marking

[H.J. Lu]

On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
<binutils@sourceware.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?

-- 
H.J.

Re: new ELF marking

[Kees Cook]

On Wed, Aug 9, 2017 at 10:16 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
> <binutils@sourceware.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

Re: new ELF marking

[H.J. Lu]

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

Re: new ELF marking

[Kees Cook]

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

Re: new ELF marking

[H.J. Lu]

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

Nothing so far:

[hjl@gnu-6 elf]$ readelf -l ./sln

Elf file type is DYN (Shared object file)
Entry point 0x8830
There are 8 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x00000000000a1466 0x00000000000a1466  R E    0x200000
  LOAD           0x00000000000a2240 0x00000000002a2240 0x00000000002a2240
                 0x00000000000050a0 0x0000000000006590  RW     0x200000
  DYNAMIC        0x00000000000a4d48 0x00000000002a4d48 0x00000000002a4d48
                 0x00000000000001a0 0x00000000000001a0  RW     0x8
  NOTE           0x0000000000000200 0x0000000000000200 0x0000000000000200
                 0x0000000000000020 0x0000000000000020  R      0x4
  TLS            0x00000000000a2240 0x00000000002a2240 0x00000000002a2240
                 0x0000000000000020 0x0000000000000060  R      0x8
  GNU_EH_FRAME   0x0000000000096298 0x0000000000096298 0x0000000000096298
                 0x0000000000001a14 0x0000000000001a14  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x00000000000a2240 0x00000000002a2240 0x00000000002a2240
                 0x0000000000002dc0 0x0000000000002dc0  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00     .note.ABI-tag .hash .dynsym .dynstr .rela.dyn .rela.plt
.init .plt .plt.got .text __libc_freeres_fn __libc_thread_freeres_fn
.fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
   01     .tdata .init_array .fini_array .data.rel.ro .dynamic .got
.got.plt .data __libc_subfreeres __libc_IO_vtables __libc_atexit
__libc_thread_subfreeres .bss __libc_freeres_ptrs
   02     .dynamic
   03     .note.ABI-tag
   04     .tdata .tbss
   05     .eh_frame_hdr
   06
   07     .tdata .init_array .fini_array .data.rel.ro .dynamic .got
[hjl@gnu-6 elf]$ ./sln
Usage: sln src dest|file

For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
[hjl@gnu-6 elf]$

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

if it is an output only bit, "-z fobar" should work, like

  -z ibt                      Generate GNU_PROPERTY_X86_FEATURE_1_IBT
  -z shstk                    Generate GNU_PROPERTY_X86_FEATURE_1_SHSTK

Or you can put it in the input file and linker will copy it to output, like
GNU_PROPERTY_STACK_SIZE.

>>> (And should the kernel already be parsing GNU_PROPERTY_STACK_SIZE?)
>>
>> Kernel should.
>
> Have there been patches proposed for this yet?
>

Not I am aware of.

-- 
H.J.

Re: new ELF marking

[Kostya Serebryany]

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

I don't, hopefully H.J's suggestion works.
Will it be backward compatible?
(i.e. will the binaries built in the new way work on the old kernels?)

Thanks!

--kcc
>
>
> if it is an output only bit, "-z fobar" should work, like
>
>   -z ibt                      Generate GNU_PROPERTY_X86_FEATURE_1_IBT
>   -z shstk                    Generate GNU_PROPERTY_X86_FEATURE_1_SHSTK
>
> Or you can put it in the input file and linker will copy it to output, like
> GNU_PROPERTY_STACK_SIZE.

Re: new ELF marking

[H.J. Lu]

On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany <kcc@google.com> wrote:
>> >
>> > 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?
>
> I don't, hopefully H.J's suggestion works.
> Will it be backward compatible?
> (i.e. will the binaries built in the new way work on the old kernels?)
>
>

Yes,  it is backward compatible by design.


-- 
H.J.

Re: new ELF marking

[Carlos O'Donell]

On 08/09/2017 05:24 PM, H.J. Lu wrote:
> On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany <kcc@google.com> wrote:
>>>>
>>>> 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?
>>
>> I don't, hopefully H.J's suggestion works.
>> Will it be backward compatible?
>> (i.e. will the binaries built in the new way work on the old kernels?)
>>
>>
> 
> Yes,  it is backward compatible by design.

... only as long as the semantics implied by the flags are hints that
can be ignored.

-- 
Cheers,
Carlos.