From patchwork Wed Jun 7 07:23:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 104296 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp75039vqr; Wed, 7 Jun 2023 00:36:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ45mMAp7f6MBTvatXmnP6ntlfMnt54m8GcDUXC5Q3xkvGW/K8GcsaXSbkHnxp8F7bjrPGfE X-Received: by 2002:a05:6a21:6da4:b0:10f:d1d4:40d4 with SMTP id wl36-20020a056a216da400b0010fd1d440d4mr2619587pzb.14.1686123381933; Wed, 07 Jun 2023 00:36:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686123381; cv=none; d=google.com; s=arc-20160816; b=s1i2wmz8K93mjqU73W97ky3rIjbneKikVwr70n31v/jYVP1kX0y8DJXdHr11vD8Ptr SP7fTjjcJ+vHpfK57lAMb1s/gxIQIjOe31G9/5JAt5F3Bnvxu18fi8HXJzYdFUdhJhJK BWbCl1vO6Cy6oAG1mntXltpgzuW3Z8VX/DgpkFaVsKrm8U11qvus0dKeV/A9wYcSBpPr v+JzX8n/JFJzAIc2tokTZeCMc8aHWNqGZhnIjOtVpEkJUhq3qSSNOoEYO25DQFLZcN4a sXwiVldClOQE1t+TNgskQCvNh+NnEgTurauHkjsjio2HhvV5h2ApP4yDY9Ge/34+YN4r 306Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=S3lEqGjsTGw1NWcFmbt4O+4A6ddMT7nl/cAxjp7Py8E=; b=pA4H/iA3sGhHmrO3cS1pnxH1MFsjv5Bj4JeY8wUIXVUHvEZbKzpgtPUECEHVegrqqz PxPa0Cf7f9j0jxy3/vbJOQtbrsiwwGCpO5KDdtiWy472Av++ecNAP8JHqBU+g69Y44oZ b+2XfglzodsYkqza/d7c+9Dr0lOkuAFPikqgbUICZq5t03dsiw1MTLvepIoytUcj/4/A KNVuU/wY8UBpDxTnPjCEq8u9+L+dUQwUDD/rHrOD/UXi6qNDS2iiAC7NZnLZ5hyDQWd9 6/wEPppF/h9FwqzHnM68waOEKXbJAb7UdEVRGHQ8FMJNLQKdJeMZYIfttiJx3B1jgGyo jnkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=S+XySU4G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y192-20020a638ac9000000b0052856ce370asi8658451pgd.426.2023.06.07.00.36.08; Wed, 07 Jun 2023 00:36:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=S+XySU4G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S239213AbjFGHZe (ORCPT + 99 others); Wed, 7 Jun 2023 03:25:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235142AbjFGHY5 (ORCPT ); Wed, 7 Jun 2023 03:24:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1493B2684; Wed, 7 Jun 2023 00:24:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2714C63B61; Wed, 7 Jun 2023 07:24:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC4AAC4339E; Wed, 7 Jun 2023 07:24:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686122657; bh=ygI81p6SqewQoIn6tCgoZLUH2Qo5tPVgo3BNvwGSS3U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S+XySU4GwLNBlMd01swdW/4ofacMcN3PCM0wAMFxZJIQZtyqzm3dyafUMPMzwfPPR rXW4w0ECIdYGnEmh9EbLWCs5nyRrjKi3oBOUlg6nb3Z3//UDTpCFYbE3/Ukn6FS7l1 ROYcWld6wrG3koLGVRx0jdCFi7ozGFcsU8xxn+n2WD/hLk5VWJCvBCV4wILQhQp4Fw VT99ZoRnXtt7wQBxBCLRfx4DKeO1iunxTuOIHJ5FwDnYpsVH7d9ZVHsGNTqJhFnHER sf+bFE1zJjlZHkJFkiyynFh6hp7LyePiPNJq8R4tsYVU1VSMFL48nq17hcRXeIaS8+ 16919uac1tTFw== From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel , Evgeniy Baskov , Borislav Petkov , Andy Lutomirski , Dave Hansen , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Alexey Khoroshilov , Peter Jones , Gerd Hoffmann , Dave Young , Mario Limonciello , Kees Cook , Tom Lendacky , "Kirill A . Shutemov" , Linus Torvalds , Joerg Roedel Subject: [PATCH v5 05/20] x86/decompressor: Use proper sequence to take the address of the GOT Date: Wed, 7 Jun 2023 09:23:27 +0200 Message-Id: <20230607072342.4054036-6-ardb@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230607072342.4054036-1-ardb@kernel.org> References: <20230607072342.4054036-1-ardb@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1770; i=ardb@kernel.org; h=from:subject; bh=ygI81p6SqewQoIn6tCgoZLUH2Qo5tPVgo3BNvwGSS3U=; b=owGbwMvMwCFmkMcZplerG8N4Wi2JIaXBIGtfjGz12WInw7ydqfPDJ7Ukb5i9b7FGVn2Z7oyqH cdfVGp0lLIwiHEwyIopsgjM/vtu5+mJUrXOs2Rh5rAygQxh4OIUgIksucPI8Ik7Pn35zuQ7Hp/C nC9+dF6mGnKjPzXqmjWPa6XbHPVffxgZ5mVe+BW5tCnk+YZFLF9Fe2IW7xSvsf+7r1S15+fH5q4 ZzAA= X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768028511524373975?= X-GMAIL-MSGID: =?utf-8?q?1768028511524373975?= The 32-bit decompressor does not actually use a global offset table (GOT), but as is common for 32-bit position independent code, it uses the magic symbol _GLOBAL_OFFSET_TABLE_ as an anchor from which to derive the actual runtime addresses of other symbols, using special @GOTOFF symbol references that are resolved at link time, and populated with the distance between the address of the magic _GLOBAL_OFFSET_TABLE_ anchor and the address of the symbol in question. This means _GLOBAL_OFFSET_TABLE_ is the only symbol whose actual runtime address needs to be determined explicitly, which is one of the first things that happens in startup_32. However, it does so by taking the absolute address via the immediate field of an ADD instruction (plus a small offset), which seems to defeat the point. Fortunately, the assembler knows that _GLOBAL_OFFSET_TABLE_ is magic, and emits a special relative relocation instead, and so the resulting code works as expected. However, this is not obvious for someone reading the code, and the use of LEA with an explicit relative addend is more idiomatic so use that instead. Signed-off-by: Ard Biesheuvel --- arch/x86/boot/compressed/head_32.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/boot/compressed/head_32.S b/arch/x86/boot/compressed/head_32.S index 8876ffe30e9a4819..3530465b5b85ccf3 100644 --- a/arch/x86/boot/compressed/head_32.S +++ b/arch/x86/boot/compressed/head_32.S @@ -58,7 +58,7 @@ SYM_FUNC_START(startup_32) leal (BP_scratch+4)(%esi), %esp call 1f 1: popl %edx - addl $_GLOBAL_OFFSET_TABLE_+(.-1b), %edx + leal (_GLOBAL_OFFSET_TABLE_ - 1b)(%edx), %edx /* Load new GDT */ leal gdt@GOTOFF(%edx), %eax