Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753031AbdHIS0N (ORCPT ); Wed, 9 Aug 2017 14:26:13 -0400 Received: from mail-it0-f48.google.com ([209.85.214.48]:34680 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752231AbdHIS0M (ORCPT ); Wed, 9 Aug 2017 14:26:12 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Kees Cook Date: Wed, 9 Aug 2017 11:26:10 -0700 Message-ID: Subject: Re: new ELF marking To: "H.J. Lu" Cc: LKML , Binutils 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: 2066 Lines: 56 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