From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752169AbdHISq1 (ORCPT ); Wed, 9 Aug 2017 14:46:27 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:37505 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbdHISqZ (ORCPT ); Wed, 9 Aug 2017 14:46:25 -0400 MIME-Version: 1.0 In-Reply-To: References: From: "H.J. Lu" Date: Wed, 9 Aug 2017 11:46:24 -0700 Message-ID: Subject: Re: new ELF marking To: Kees Cook 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 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.