From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 946E6C433E0 for ; Wed, 15 Jul 2020 00:41:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6724C20674 for ; Wed, 15 Jul 2020 00:41:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728096AbgGOAlm (ORCPT ); Tue, 14 Jul 2020 20:41:42 -0400 Received: from mail-qk1-f193.google.com ([209.85.222.193]:34183 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726963AbgGOAlh (ORCPT ); Tue, 14 Jul 2020 20:41:37 -0400 Received: by mail-qk1-f193.google.com with SMTP id b185so307863qkg.1 for ; Tue, 14 Jul 2020 17:41:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RhWnzCqvgTN++G31OGgg9qNDvvhiuki5nvpw8uOP67s=; b=avq/mm//mM99J3NGWPaZRTIASKUYrvJSAyb/qtY7GBGmoAmKFZJJGgIicmFq2RED6G N8LtkKu2p1yxJ9jCyG1SmkAtuxFGvMurvjqYbHLgmOm9rv+DrWsOrmasceY+k/JoGyWu sZBqEHfx2FycWdNGbN+qdAx+5PiaxzDvKgb2ZcSq6BVM45Np5PHdpev179wfyZ7Y8Bt2 vzLBx6k78DgbTEAfE8VDcDLQ1wcSpwa3XKr4WVOQaVx4syhGEedGYvFMM9R7q5rr1svN JvAO5KyQYbafVVaLyHQWUHBiTAkCuWT7VHPLK8aeEii33kL5WEoXa7uVc9oWx3kovwez el+A== X-Gm-Message-State: AOAM532jyXF2vQ1zt2OgxLqCmRPv+XhxlCZ2m9Yy94+Arb2xhI5t+nIz kMUQBgtrU8ujHHWLq2ZbfFU= X-Google-Smtp-Source: ABdhPJzUWprKhFBlzsWpnk8e/5spW+2HbTy10u91CllZzbAf3M1H9gmcqDQrOIqQ72v/FPzojMaNYg== X-Received: by 2002:a05:620a:165c:: with SMTP id c28mr7222101qko.52.1594773696262; Tue, 14 Jul 2020 17:41:36 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id c9sm524776qko.24.2020.07.14.17.41.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 17:41:35 -0700 (PDT) From: Arvind Sankar To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org Cc: Nick Desaulniers , Fangrui Song , Dmitry Golovin , clang-built-linux@googlegroups.com, Ard Biesheuvel , Masahiro Yamada , Daniel Kiper , Sedat Dilek , Kees Cook , Nathan Chancellor , Arnd Bergmann , "H . J . Lu" , linux-kernel@vger.kernel.org Subject: [PATCH v5 1/7] x86/boot/compressed: Move .got.plt entries out of the .got section Date: Tue, 14 Jul 2020 20:41:27 -0400 Message-Id: <20200715004133.1430068-2-nivedita@alum.mit.edu> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200714023836.2310569-1-nivedita@alum.mit.edu> References: <20200714023836.2310569-1-nivedita@alum.mit.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ard Biesheuvel The .got.plt section contains the part of the GOT which is used by PLT entries, and which gets updated lazily by the dynamic loader when function calls are dispatched through those PLT entries. On fully linked binaries such as the kernel proper or the decompressor, this never happens, and so in practice, the .got.plt section consists only of the first 3 magic entries that are meant to point at the _DYNAMIC section and at the fixup routine in the loader. However, since we don't use a dynamic loader, those entries are never populated or used. This means that treating those entries like ordinary GOT entries, and updating their values based on the actual placement of the executable in memory is completely pointless, and we can just ignore the .got.plt section entirely, provided that it has no additional entries beyond the first 3 ones. So add an assertion in the linker script to ensure that this assumption holds, and move the contents out of the [_got, _egot) memory range that is modified by the GOT fixup routines. While at it, drop the KEEP(), since it has no effect on the contents of output sections that are created by the linker itself. Reviewed-by: Kees Cook Signed-off-by: Ard Biesheuvel Acked-by: Arvind Sankar Signed-off-by: Arvind Sankar From: Ard Biesheuvel Link: https://lore.kernel.org/r/20200523120021.34996-2-ardb@kernel.org --- arch/x86/boot/compressed/vmlinux.lds.S | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/compressed/vmlinux.lds.S b/arch/x86/boot/compressed/vmlinux.lds.S index 8f1025d1f681..b17d218ccdf9 100644 --- a/arch/x86/boot/compressed/vmlinux.lds.S +++ b/arch/x86/boot/compressed/vmlinux.lds.S @@ -44,10 +44,13 @@ SECTIONS } .got : { _got = .; - KEEP(*(.got.plt)) KEEP(*(.got)) _egot = .; } + .got.plt : { + *(.got.plt) + } + .data : { _data = . ; *(.data) @@ -77,3 +80,9 @@ SECTIONS DISCARDS } + +#ifdef CONFIG_X86_64 +ASSERT(SIZEOF(.got.plt) == 0 || SIZEOF(.got.plt) == 0x18, "Unexpected GOT/PLT entries detected!") +#else +ASSERT(SIZEOF(.got.plt) == 0 || SIZEOF(.got.plt) == 0xc, "Unexpected GOT/PLT entries detected!") +#endif -- 2.26.2