Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2524955pxa; Fri, 7 Aug 2020 13:21:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1cFzrFHKenfhcZX8F/JW21/scu1Yn7p5ja8PA+7ihjHfOER9U7DUZc9u1k1u3Iy8tJOzc X-Received: by 2002:a05:6402:748:: with SMTP id p8mr10914098edy.305.1596831716464; Fri, 07 Aug 2020 13:21:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596831716; cv=none; d=google.com; s=arc-20160816; b=lAbEkAAFYtRbtOsfj5wprupYZ8okulDEXXRD6gQcAB2qXFLRffJx6bRuGjta8iooOm cEb5h5go2F2OCg5U0yS/bXIuOgSVQYp528wC+5+6Mz5ENJoYywbVKvkg6pMqFI594PnX 3y325FPBV6L5eIp1IvaXkXnO+/1KDI3LecqXsJr4IKWGRxHUjHaOU7k7LM2fVNa1TB3/ hFHz3I/Gvq3sh4wSvZPINJnm7Ksbpf5i4MmSmljQ4OXb+38YkKkA3cwtLXexuI3UYV3p +CaRlPapTcaH1BgfFdA+E6qWEmUD2Hp2729vJNS6WQ5jFRUGuFocLrHjyylMCtce9KFS +hyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :dkim-signature; bh=B7Fctmg3cVLvQt7Pqxb1gnXBcCgs6NDZ66tmQ5JI0zg=; b=foYRKBkLnkl4Ai00MDOjsKDT1MYN5148vLuB2dFmGiXi9GUZIBKS/U6MR7Z8jAChzW 8lAc67SpHKFMCmhzl/pSZbSCA7sXOIABj656cYqZ+m9C9U9eH2L2u/Dv4gaV4Se6Px3T wpo/wrdK3XBhkXaUQV7TZBkr977PJ7+zR04ei/vv4Kdgr4OOQF3GiWota42HFukGXlJ5 d04V5YWBO4ZRnH0lFqdYdbMNbvoFpfHONzoItEJurM4K2AwMK93b2txiLXci0cc1l2EF AV3t1cHIHQvxfVq6a2MrrwfBpyU9SgZTJoFLFjDruAhwLPkGV3DimzNB56ZE3Zs/BVmW sdbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=M6Snqi+5; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dk14si5637144edb.61.2020.08.07.13.21.33; Fri, 07 Aug 2020 13:21:56 -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=fail header.i=@gmail.com header.s=20161025 header.b=M6Snqi+5; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726242AbgHGUVB (ORCPT + 99 others); Fri, 7 Aug 2020 16:21:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725893AbgHGUVB (ORCPT ); Fri, 7 Aug 2020 16:21:01 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB045C061756; Fri, 7 Aug 2020 13:21:00 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id o22so2233734qtt.13; Fri, 07 Aug 2020 13:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=B7Fctmg3cVLvQt7Pqxb1gnXBcCgs6NDZ66tmQ5JI0zg=; b=M6Snqi+5vU8MfS8JcxyXJ40DbOeNxstioyDIQ7RipbYSbN7JQ3Zh8YKulYvpWIfWMG eUMR1fQ+G6brVpm3EcSR81uT1VEg6XoL0pSdXn7PToQ63fvzZRxpWr3J6buyDNMuckpG 4Z5Ya2CnVn4fwpk7BFvYU91TRFyq9H8Thqax+U+MjxCQvmHtoD/2PZSEZcgCzNmuIf4t NnYgkjSYnqyQdRf/hbeSE358rBIHUE5LW0OvBTxreq4sKC88qCa34IlIHFrdpswidJ5/ WKci7ur3XnSKEEqXlCjTetdOmz8QPZzvjlK8a/y87yuY09ekPaVnHTsgldHwqdiuyOqL PwrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:date:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=B7Fctmg3cVLvQt7Pqxb1gnXBcCgs6NDZ66tmQ5JI0zg=; b=U8/hQL0wJVnRjYlu/1cCOnaDb2OLPOzCQ4maTGlE5ax0KKQBhdlB1eSPPc8k9FzUDY gDYplOBwb+p1M8tJL1c8m9CxMCuFYKWbo/sTmcoxhxSKeJVnBkrQXZBwFFPYvsMKL1+5 byp62lEo9GB+nK9hwUDzTdpwfO+WIg/7kBVlx4dEhml0TL6C0G84C2pcxq+TDWBq0K1z u62++guuKNfLHALFNBqRll54wMdHd21Z1Tv5szjphTbOPBFHvpKeIp05ODEZHXfRG4V0 G7yRwFVuJ96aKGyh0py03sklLeGWAJCZqF211gQb/YW1JHaPd9ykh9FIEtibJAHxXc8L I4gQ== X-Gm-Message-State: AOAM530ZjET0FG0x8BiKmsW4q4RVz0RcIFpt6bnSl1xsTRBc6vrpT1NV 0cEOOfJFiex/uUFZ8woP8l4= X-Received: by 2002:ac8:7152:: with SMTP id h18mr15653535qtp.44.1596831659768; Fri, 07 Aug 2020 13:20:59 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id y26sm8158811qto.75.2020.08.07.13.20.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2020 13:20:59 -0700 (PDT) From: Arvind Sankar X-Google-Original-From: Arvind Sankar Date: Fri, 7 Aug 2020 16:20:56 -0400 To: Nick Desaulniers Cc: Kees Cook , Arvind Sankar , Thomas Gleixner , Will Deacon , Ard Biesheuvel , Fangrui Song , Sedat Dilek , Catalin Marinas , Mark Rutland , Peter Collingbourne , James Morse , Borislav Petkov , Ingo Molnar , Russell King , Masahiro Yamada , Nathan Chancellor , Arnd Bergmann , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , clang-built-linux , linux-arch , linux-efi , Linux ARM , LKML Subject: Re: [PATCH v5 06/36] x86/boot: Remove run-time relocations from head_{32,64}.S Message-ID: <20200807202056.GA1454138@rani.riverdale.lan> References: <20200731230820.1742553-1-keescook@chromium.org> <20200731230820.1742553-7-keescook@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 07, 2020 at 11:12:29AM -0700, Nick Desaulniers wrote: > On Fri, Jul 31, 2020 at 4:08 PM Kees Cook wrote: > > > > From: Arvind Sankar > > > > The BFD linker generates run-time relocations for z_input_len and > > z_output_len, even though they are absolute symbols. > > > > This is fixed for binutils-2.35 [1]. Work around this for earlier > > versions by defining two variables input_len and output_len in addition > > to the symbols, and use them via position-independent references. > > > > This eliminates the last two run-time relocations in the head code and > > allows us to drop the -z noreloc-overflow flag to the linker. > > > > Move the -pie and --no-dynamic-linker LDFLAGS to LDFLAGS_vmlinux instead > > of KBUILD_LDFLAGS. There shouldn't be anything else getting linked, but > > this is the more logical location for these flags, and modversions might > > call the linker if an EXPORT_SYMBOL is left over accidentally in one of > > the decompressors. > > > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25754 > > > > Tested-by: Nick Desaulniers > > Reviewed-by: Kees Cook > > Reviewed-by: Ard Biesheuvel > > Reviewed-by: Fangrui Song > > Tested-by: Sedat Dilek > > Signed-off-by: Arvind Sankar > > Signed-off-by: Kees Cook > > --- > > arch/x86/boot/compressed/Makefile | 12 ++---------- > > arch/x86/boot/compressed/head_32.S | 17 ++++++++--------- > > arch/x86/boot/compressed/head_64.S | 4 ++-- > > arch/x86/boot/compressed/mkpiggy.c | 6 ++++++ > > 4 files changed, 18 insertions(+), 21 deletions(-) > > > > diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile > > index 489fea16bcfb..7db0102a573d 100644 > > --- a/arch/x86/boot/compressed/Makefile > > +++ b/arch/x86/boot/compressed/Makefile > > @@ -51,16 +51,8 @@ UBSAN_SANITIZE :=n > > KBUILD_LDFLAGS := -m elf_$(UTS_MACHINE) > > # Compressed kernel should be built as PIE since it may be loaded at any > > # address by the bootloader. > > -ifeq ($(CONFIG_X86_32),y) > > -KBUILD_LDFLAGS += $(call ld-option, -pie) $(call ld-option, --no-dynamic-linker) > > -else > > -# To build 64-bit compressed kernel as PIE, we disable relocation > > -# overflow check to avoid relocation overflow error with a new linker > > -# command-line option, -z noreloc-overflow. > > -KBUILD_LDFLAGS += $(shell $(LD) --help 2>&1 | grep -q "\-z noreloc-overflow" \ > > - && echo "-z noreloc-overflow -pie --no-dynamic-linker") > > -endif > > -LDFLAGS_vmlinux := -T > > +LDFLAGS_vmlinux := $(call ld-option, -pie) $(call ld-option, --no-dynamic-linker) > > Oh, do these still need ld-option? bfd and lld both support these > flags. (Though in their --help, they mention single hyphen and double > hyphen respectively. Also, if we don't build this as PIE because the > linker doesn't support the option, we probably want to fail the build? > The check for pie doesn't, it's dropped in the next patch and pie is used unconditionally. no-dynamic-linker still needs the check as it was only supported from binutils-2.26.