Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751958AbdHITBP (ORCPT ); Wed, 9 Aug 2017 15:01:15 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:36240 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751536AbdHITBN (ORCPT ); Wed, 9 Aug 2017 15:01:13 -0400 MIME-Version: 1.0 In-Reply-To: References: From: "H.J. Lu" Date: Wed, 9 Aug 2017 12:01:12 -0700 Message-ID: Subject: Re: new ELF marking To: Kees Cook Cc: LKML , Binutils , Kostya Serebryany Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5583 Lines: 141 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 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: . [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.