Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3067839ybt; Mon, 29 Jun 2020 14:26:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfOqxOk3OCfobiDCAZFPeru/tNUX1iomGCRRDWTSg7t7IRGhuFPqdKOZ/iALKqIYdlKcqc X-Received: by 2002:aa7:c1d8:: with SMTP id d24mr20022808edp.178.1593465980173; Mon, 29 Jun 2020 14:26:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593465980; cv=none; d=google.com; s=arc-20160816; b=ibGaxbOxsxYO5dHaq7tfmbWRyG4gN9K10BZb723HhLGTPBbwn9KVgeb1PAsau/AXOw 7fUH6jpH41TSSCqb0EM0/JsnSxfRuq9PnzXZ4Xim1JQTMQgNlM/ZGKao42U7nrG5iEiK 9oy3QwYofLrv86hJDWnHVWW2wOZq7GVS6EqqCLnC0nHSAzj70Wt6Sp4PzYo7Zl5lin2S aEB2SLl6NgllF2jjSs+2NmYP42NluYGhlIGlWhtB3Jw0F3mVGXFqzY97f71kEykxoVDP k52HYuTGanLODpGhvxq/1gn82CNDK5Jyz/yCMxvfv4tl9oMSaFmywUjh4TW7vdhtsCZb CiVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=XPqVKxCTxbefqR5O5kGm6jHUHovR95wFNbmfjLVaZJo=; b=gjjJBNOnOXaQW8xwPXKdzAwB8xtKQthwK0GrBVEtsIvr5xbOgdEurA2Dpt+wtYRvSv fLeY0ImlmhjsRhxZCORKHiGU28V5Kfgd0W/gmQrev8fs4nQY2P9AFk2bbH9LAHN+sGZR TvUs4C88GRzhPq4Q4YNe4yusHwJBPJq1UCTR6p0duGMyB+L6PL7g2xQasa+7niofypcD Ibuhyhe8z5j2htzIuIdPY5/l69SXzw1Y5R4y8U9h/L800e3szaw9a+OqC/0GaGyajn4u 0bozBfn1x9x7zuQUTH7XMEloxUAu29s7c0bvSwt0Qn8HJMxKbzK3uqFrgWt8Z5ndhcqO dIvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DiNV0rrk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si524071ejd.479.2020.06.29.14.25.57; Mon, 29 Jun 2020 14:26:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=DiNV0rrk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388719AbgF2VYc (ORCPT + 99 others); Mon, 29 Jun 2020 17:24:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:38878 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729486AbgF2SuQ (ORCPT ); Mon, 29 Jun 2020 14:50:16 -0400 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D49BD255D1 for ; Mon, 29 Jun 2020 18:12:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593454320; bh=ReZPNCCJ/K8FhCzM6IWgUGCUkf/Lpb/MqZLHZJkjp6Q=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DiNV0rrk4nxNWP2xmZ6XvSg5tLQJUxPmbUHZ7WJ3PeCJNRMmGZo74Si++VJ22FSeB 7gx19IER85mfjjr+KDi4Oz8Hfx/c/O82rTfc3aesS+JAU1RPDj8+qBXY2FPxTzmpXk XgnaC0PFOEg8aPua+51eU3v+iNtkYThYhhIknY0I= Received: by mail-ot1-f51.google.com with SMTP id 95so5706119otw.10 for ; Mon, 29 Jun 2020 11:12:00 -0700 (PDT) X-Gm-Message-State: AOAM5309BYLjEBXTUCGofcaTymrt9Vn0pIdvxBWh8LQ9nT0lFdiw81UG PyVhp/UAvbkkThucBjlFKNifjRcqnJp2SsgYBQY= X-Received: by 2002:a9d:4a8f:: with SMTP id i15mr15291584otf.77.1593454320102; Mon, 29 Jun 2020 11:12:00 -0700 (PDT) MIME-Version: 1.0 References: <20200629140928.858507-1-nivedita@alum.mit.edu> <20200629140928.858507-8-nivedita@alum.mit.edu> <202006290907.E5EF18A@keescook> <202006290919.93C759C62@keescook> <20200629165603.GD900899@rani.riverdale.lan> <20200629173735.l3ssrj7m3q5swfup@google.com> In-Reply-To: <20200629173735.l3ssrj7m3q5swfup@google.com> From: Ard Biesheuvel Date: Mon, 29 Jun 2020 20:11:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 7/7] x86/boot: Check that there are no runtime relocations To: Fangrui Song Cc: Kees Cook , Arvind Sankar , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , Nick Desaulniers , Dmitry Golovin , clang-built-linux , Masahiro Yamada , Daniel Kiper , Sedat Dilek , Nathan Chancellor , Arnd Bergmann , "H . J . Lu" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Jun 2020 at 19:37, Fangrui Song wrote: > > On 2020-06-29, Arvind Sankar wrote: > >On Mon, Jun 29, 2020 at 09:20:31AM -0700, Kees Cook wrote: > >> On Mon, Jun 29, 2020 at 06:11:59PM +0200, Ard Biesheuvel wrote: > >> > On Mon, 29 Jun 2020 at 18:09, Kees Cook wrote: > >> > > > >> > > On Mon, Jun 29, 2020 at 10:09:28AM -0400, Arvind Sankar wrote: > >> > > > Add a linker script check that there are no runtime relocations, and > >> > > > remove the old one that tries to check via looking for specially-named > >> > > > sections in the object files. > >> > > > > >> > > > Drop the tests for -fPIE compiler option and -pie linker option, as they > >> > > > are available in all supported gcc and binutils versions (as well as > >> > > > clang and lld). > >> > > > > >> > > > Signed-off-by: Arvind Sankar > >> > > > Reviewed-by: Ard Biesheuvel > >> > > > Reviewed-by: Fangrui Song > >> > > > --- > >> > > > arch/x86/boot/compressed/Makefile | 28 +++----------------------- > >> > > > arch/x86/boot/compressed/vmlinux.lds.S | 8 ++++++++ > >> > > > 2 files changed, 11 insertions(+), 25 deletions(-) > >> > > > >> > > Reviewed-by: Kees Cook > >> > > > >> > > question below ... > >> > > > >> > > > diff --git a/arch/x86/boot/compressed/vmlinux.lds.S b/arch/x86/boot/compressed/vmlinux.lds.S > >> > > > index a4a4a59a2628..a78510046eec 100644 > >> > > > --- a/arch/x86/boot/compressed/vmlinux.lds.S > >> > > > +++ b/arch/x86/boot/compressed/vmlinux.lds.S > >> > > > @@ -42,6 +42,12 @@ SECTIONS > >> > > > *(.rodata.*) > >> > > > _erodata = . ; > >> > > > } > >> > > > + .rel.dyn : { > >> > > > + *(.rel.*) > >> > > > + } > >> > > > + .rela.dyn : { > >> > > > + *(.rela.*) > >> > > > + } > >> > > > .got : { > >> > > > *(.got) > >> > > > } > >> > > > >> > > Should these be marked (INFO) as well? > >> > > > >> > > >> > Given that sections marked as (INFO) will still be emitted into the > >> > ELF image, it does not really make a difference to do this for zero > >> > sized sections. > >> > >> Oh, I misunderstood -- I though they were _not_ emitted; I see now what > >> you said was not allocated. So, disk space used for the .got.plt case, > >> but not memory space used. Sorry for the confusion! > >> > >> -Kees > > About output section type (INFO): > https://sourceware.org/binutils/docs/ld/Output-Section-Type.html#Output-Section-Type > says "These type names are supported for backward compatibility, and are > rarely used." > > If all input section don't have the SHF_ALLOC flag, the output section > will not have this flag as well. This type is not useful... > > If .got and .got.plt were used, they should be considered dynamic > relocations which should be part of the loadable image. So they should > have the SHF_ALLOC flag. (INFO) will not be applicable anyway. > I don't care deeply either way, but Kees indicated that he would like to get rid of the 24 bytes of .got.plt magic entries that we have no need for. In fact, a lot of this mangling is caused by the fact that the linker is creating a relocatable binary, and assumes that it is a hosted binary that is loaded by a dynamic loader. It would actually be much better if the compiler and linker would take -ffreestanding into account, and suppress GOT entries, PLTs, dynamic program headers for shared libraries altogether.