* new ELF marking @ 2017-08-09 17:07 Kees Cook 2017-08-09 17:16 ` H.J. Lu 0 siblings, 1 reply; 9+ messages in thread From: Kees Cook @ 2017-08-09 17:07 UTC (permalink / raw) To: LKML, binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 17:07 new ELF marking Kees Cook @ 2017-08-09 17:16 ` H.J. Lu 2017-08-09 18:26 ` Kees Cook 0 siblings, 1 reply; 9+ messages in thread From: H.J. Lu @ 2017-08-09 17:16 UTC (permalink / raw) To: Kees Cook; +Cc: LKML, Binutils 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 17:16 ` H.J. Lu @ 2017-08-09 18:26 ` Kees Cook 2017-08-09 18:46 ` H.J. Lu 0 siblings, 1 reply; 9+ messages in thread From: Kees Cook @ 2017-08-09 18:26 UTC (permalink / raw) To: H.J. Lu; +Cc: LKML, Binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 18:26 ` Kees Cook @ 2017-08-09 18:46 ` H.J. Lu 2017-08-09 18:52 ` Kees Cook 0 siblings, 1 reply; 9+ messages in thread From: H.J. Lu @ 2017-08-09 18:46 UTC (permalink / raw) To: Kees Cook; +Cc: LKML, Binutils 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 18:46 ` H.J. Lu @ 2017-08-09 18:52 ` Kees Cook 2017-08-09 19:01 ` H.J. Lu 0 siblings, 1 reply; 9+ messages in thread From: Kees Cook @ 2017-08-09 18:52 UTC (permalink / raw) To: H.J. Lu; +Cc: LKML, Binutils, Kostya Serebryany 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 18:52 ` Kees Cook @ 2017-08-09 19:01 ` H.J. Lu 2017-08-09 20:32 ` Kostya Serebryany 0 siblings, 1 reply; 9+ messages in thread From: H.J. Lu @ 2017-08-09 19:01 UTC (permalink / raw) To: Kees Cook; +Cc: LKML, Binutils, Kostya Serebryany 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 19:01 ` H.J. Lu @ 2017-08-09 20:32 ` Kostya Serebryany 2017-08-09 21:24 ` H.J. Lu 0 siblings, 1 reply; 9+ messages in thread From: Kostya Serebryany @ 2017-08-09 20:32 UTC (permalink / raw) To: H.J. Lu; +Cc: Kees Cook, LKML, Binutils > > > > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 20:32 ` Kostya Serebryany @ 2017-08-09 21:24 ` H.J. Lu 2017-08-09 22:37 ` Carlos O'Donell 0 siblings, 1 reply; 9+ messages in thread From: H.J. Lu @ 2017-08-09 21:24 UTC (permalink / raw) To: Kostya Serebryany; +Cc: Kees Cook, LKML, Binutils 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: new ELF marking 2017-08-09 21:24 ` H.J. Lu @ 2017-08-09 22:37 ` Carlos O'Donell 0 siblings, 0 replies; 9+ messages in thread From: Carlos O'Donell @ 2017-08-09 22:37 UTC (permalink / raw) To: H.J. Lu, Kostya Serebryany; +Cc: Kees Cook, LKML, Binutils 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-08-09 22:37 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-09 17:07 new ELF marking Kees Cook 2017-08-09 17:16 ` H.J. Lu 2017-08-09 18:26 ` Kees Cook 2017-08-09 18:46 ` H.J. Lu 2017-08-09 18:52 ` Kees Cook 2017-08-09 19:01 ` H.J. Lu 2017-08-09 20:32 ` Kostya Serebryany 2017-08-09 21:24 ` H.J. Lu 2017-08-09 22:37 ` Carlos O'Donell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®