From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751975AbdHISwK (ORCPT ); Wed, 9 Aug 2017 14:52:10 -0400 Received: from mail-it0-f52.google.com ([209.85.214.52]:35787 "EHLO mail-it0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751536AbdHISwJ (ORCPT ); Wed, 9 Aug 2017 14:52:09 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Kees Cook Date: Wed, 9 Aug 2017 11:52:07 -0700 Message-ID: Subject: Re: new ELF marking To: "H.J. Lu" 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 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