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

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

Re: new ELF marking

[H.J. Lu]

On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany  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

[H.J. Lu]

On Wed, Aug 9, 2017 at 1:32 PM, Kostya Serebryany  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

[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 shstkGenerate 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

[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 shstkGenerate 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 11:52 AM, Kees Cook  wrote:
> On Wed, Aug 9, 2017 at 11:46 AM, H.J. Lu  wrote:
>> On Wed, Aug 9, 2017 at 11:26 AM, Kees Cook  wrote:
>>> On Wed, Aug 9, 2017 at 10:16 AM, H.J. Lu  wrote:
 On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
  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
 FileSizMemSiz  Flags  Align
  LOAD   0x 0x 0x
 0x000a1466 0x000a1466  R E0x20
  LOAD   0x000a2240 0x002a2240 0x002a2240
 0x50a0 0x6590  RW 0x20
  DYNAMIC0x000a4d48 0x002a4d48 0x002a4d48
 0x01a0 0x01a0  RW 0x8
  NOTE   0x0200 0x0200 0x0200
 0x0020 0x0020  R  0x4
  TLS0x000a2240 0x002a2240 0x002a2240
 0x0020 0x0060  R  0x8
  GNU_EH_FRAME   0x00096298 0x00096298 0x00096298
 0x1a14 0x1a14  R  0x4
  GNU_STACK  0x 0x 0x
 0x 0x  RW 0x10
  GNU_RELRO  0x000a2240 0x002a2240 0x002a2240
 0x2dc0 0x2dc0  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:
.
[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 

Re: new ELF marking

[H.J. Lu]

On Wed, Aug 9, 2017 at 11:52 AM, Kees Cook  wrote:
> On Wed, Aug 9, 2017 at 11:46 AM, H.J. Lu  wrote:
>> On Wed, Aug 9, 2017 at 11:26 AM, Kees Cook  wrote:
>>> On Wed, Aug 9, 2017 at 10:16 AM, H.J. Lu  wrote:
 On Wed, Aug 9, 2017 at 10:07 AM, Kees Cook via binutils
  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
 FileSizMemSiz  Flags  Align
  LOAD   0x 0x 0x
 0x000a1466 0x000a1466  R E0x20
  LOAD   0x000a2240 0x002a2240 0x002a2240
 0x50a0 0x6590  RW 0x20
  DYNAMIC0x000a4d48 0x002a4d48 0x002a4d48
 0x01a0 0x01a0  RW 0x8
  NOTE   0x0200 0x0200 0x0200
 0x0020 0x0020  R  0x4
  TLS0x000a2240 0x002a2240 0x002a2240
 0x0020 0x0060  R  0x8
  GNU_EH_FRAME   0x00096298 0x00096298 0x00096298
 0x1a14 0x1a14  R  0x4
  GNU_STACK  0x 0x 0x
 0x 0x  RW 0x10
  GNU_RELRO  0x000a2240 0x002a2240 0x002a2240
 0x2dc0 0x2dc0  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:
.
[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 

Re: new ELF marking

[Kees Cook]

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

[Kees Cook]

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

[H.J. Lu]

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

[Kees Cook]

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

[H.J. Lu]

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

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

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