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,URIBL_BLOCKED,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 2C190C433E0 for ; Tue, 14 Jul 2020 02:38:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 135C4207E8 for ; Tue, 14 Jul 2020 02:38:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726798AbgGNCip (ORCPT ); Mon, 13 Jul 2020 22:38:45 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:43024 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726750AbgGNCil (ORCPT ); Mon, 13 Jul 2020 22:38:41 -0400 Received: by mail-qt1-f194.google.com with SMTP id k18so11730165qtm.10 for ; Mon, 13 Jul 2020 19:38:40 -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=iykKiRANC7xXp/f/XNUjhyD0XqXF5EqclqhdCGauL1FScKRvcPIxMbjuMP4q83rQV2 hk5eDDCUlzzr2Tui8Vxt3AoDBI6+yda+KseG9PbJqz0PxPN35CAzAmapE3rdEsPx68n/ OtOEsJHc4W4oxIKzsaEnDoFY4NdNzSmwwAF2xIXCupTbYm0gIrgo6H2Ym6mGW8wp6FUh XEQmq70JUiNGocd+IdU4Gqz/Uyak9Hqo5lmDg9CpzkP2qzFUk9/CRbMunxzVNLp8c0Kb 7Utdnpl04SEnOibUrzNIgBnI2QGEcdZDkf/Y4tXWxfOt2d7+QKVroB2cxRMBfx+PbpN1 UxXw== X-Gm-Message-State: AOAM533zOXRm4WWxXM9F3bh3ykD2W3z6lo/pUAWVKl4sIwgXicaOsU1P iocnf6SHfLzS/ZHUNZfnO0Y= X-Google-Smtp-Source: ABdhPJyD7qP9lZFweP4z1r5ZI0QeCeUktNqgeXftUuQcGKDSL65SMY53iJ2yXSuWDyFQd0OlU9U5gA== X-Received: by 2002:ac8:4714:: with SMTP id f20mr2481897qtp.141.1594694320024; Mon, 13 Jul 2020 19:38:40 -0700 (PDT) Received: from rani.riverdale.lan ([2001:470:1f07:5f3::b55f]) by smtp.gmail.com with ESMTPSA id a22sm21046291qka.64.2020.07.13.19.38.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2020 19:38:39 -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 v4 1/7] x86/boot/compressed: Move .got.plt entries out of the .got section Date: Mon, 13 Jul 2020 22:38:30 -0400 Message-Id: <20200714023836.2310569-2-nivedita@alum.mit.edu> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200629140928.858507-1-nivedita@alum.mit.edu> References: <20200629140928.858507-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