Message ID | 20231108040447.288870-1-wangrui@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp682049vqo; Tue, 7 Nov 2023 20:05:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IGAmICIWaUJX4GH/71iZkNyxrXX6cbRdGSDAqbAwGqY7vugjfe3gnyHNFa4Z9Afp+ACGPI8 X-Received: by 2002:a17:90a:7307:b0:280:c316:63e1 with SMTP id m7-20020a17090a730700b00280c31663e1mr669343pjk.41.1699416344357; Tue, 07 Nov 2023 20:05:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699416344; cv=none; d=google.com; s=arc-20160816; b=Y7cnQodP4KcXyXhHqDqMCSOJoPOOq5UAjsPTR8einmCowASbStEkHsXliVEB6g0VBw wGFN997+h4BuUbpqVw0UzYjEr1L++ByeAPmCWOvx6C025cs+VtaFpBUnaX+VEszlV4dJ 8RsZ9/GcEvosOQPlv6kh+mWuJmF2VEuTXF6HmZoB2JCsHgQDbmzR0D6vTrhBmfNL5TU3 nQVmQucoLYo2r+vpz9tzhBK2va1Qmznhq6xTmLhEuQUQ0bUgeiiK9HaQhABzhqATOy8b FhCe/VPoMHB7I3iJC1irrJVL/w1dr6/n4jzja6Dixt/qkrlgmh+beK+mEJYwHjkuSX7I QgAA== 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 :message-id:date:subject:cc:to:from; bh=fnWn7ULZPRmzdI4wT6GAUfx33k2faVzYsv6hhHSim5w=; fh=lruchcXjz5KoE/oWbBoVmldo5ndEPdtlI8UCa1Yx5iI=; b=PDfpoK5rDuCkHXksBMnIDIzklxnceJDcEGoVmG8mzzys4X8ELz6AqHQLggjE33eEZl Us+sYm2LHb5+UkFTHDBK7oTDo5JE/6csSYzzCI5SQ1Q326CxohvVqLpxANrPEW65mRDL aGVxlrSi8YSlmrQvgietcDSHuiccumI5wrF8FJ2JnvePueooBtSs1QDCE0g8w3UPx4Fc zWGSx3c6/3Zpi+UatSQKWX/OSTtX+HkoyR0fls4BMzGyg3uoePYcvnme06YJBgCeJBza EwQY5mRcZIXoYem4WmsLPQPy3f31380YiyNwidWJfxuIhQhjhxZwwwruYjf17fuIkphq gFWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id s10-20020a17090a6e4a00b0027763b64ea1si1384578pjm.44.2023.11.07.20.05.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 20:05:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 2F1F682F08CB; Tue, 7 Nov 2023 20:05:43 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229873AbjKHEFi (ORCPT <rfc822;jaysivo@gmail.com> + 32 others); Tue, 7 Nov 2023 23:05:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbjKHEFg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 23:05:36 -0500 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 20E6610D8; Tue, 7 Nov 2023 20:05:32 -0800 (PST) Received: from loongson.cn (unknown [112.22.233.25]) by gateway (Coremail) with SMTP id _____8DxRvEJCUtlOOw3AA--.44432S3; Wed, 08 Nov 2023 12:05:29 +0800 (CST) Received: from localhost.localdomain (unknown [112.22.233.25]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxL90ECUtleMA7AA--.1906S2; Wed, 08 Nov 2023 12:05:27 +0800 (CST) From: WANG Rui <wangrui@loongson.cn> To: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name>, Xi Ruoyao <xry111@xry111.site>, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-kbuild@vger.kernel.org, llvm@lists.linux.dev, loongson-kernel@lists.loongnix.cn, WANG Rui <wangrui@loongson.cn> Subject: [PATCH] LoongArch: Disable module from accessing external data directly Date: Wed, 8 Nov 2023 12:04:47 +0800 Message-ID: <20231108040447.288870-1-wangrui@loongson.cn> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8BxL90ECUtleMA7AA--.1906S2 X-CM-SenderInfo: pzdqw2txl6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoW7Gry5XFWxCw47CrW7ArW3twc_yoW8JF17pF Z7ur1DGws5ur4vvFnFyFWxXa90yr4DJr4fZa4Ikr45ZFW3uryFvw4Fyrs0g3W2kw4kX34x Ww4fCF9rtFW5JwbCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUkFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2 Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE 42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6x kF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07URa0PUUUUU= Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 07 Nov 2023 20:05:43 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781967192722031574 X-GMAIL-MSGID: 1781967192722031574 |
Series |
LoongArch: Disable module from accessing external data directly
|
|
Commit Message
WANG Rui
Nov. 8, 2023, 4:04 a.m. UTC
The distance between vmlinux and the module is too far so that PC-REL
cannot be accessed directly, only GOT.
When compiling module with GCC, the option `-mdirect-extern-access` is
disabled by default. The Clang option `-fdirect-access-external-data`
is enabled by default, so it needs to be explicitly disabled.
Signed-off-by: WANG Rui <wangrui@loongson.cn>
---
arch/loongarch/Makefile | 2 ++
1 file changed, 2 insertions(+)
Comments
On Wed, 2023-11-08 at 12:04 +0800, WANG Rui wrote: > When compiling module with GCC, the option `-mdirect-extern-access` is > disabled by default. The Clang option `-fdirect-access-external-data` > is enabled by default, so it needs to be explicitly disabled. I'm wondering why it's enabled by default. For this simple test case: extern char **environ; int main() { __builtin_printf("%10s\n", environ[0]); } With Clang 17.0.4 and "clang t1.c -S -O2", it compiles to: main: addi.d $sp, $sp, -16 st.d $ra, $sp, 8 pcalau12i $a0, %got_pc_hi20(environ) ld.d $a0, $a0, %got_pc_lo12(environ) ld.d $a0, $a0, 0 ld.d $a1, $a0, 0 pcalau12i $a0, %pc_hi20(.L.str) addi.d $a0, $a0, %pc_lo12(.L.str) bl %plt(printf) move $a0, $zero ld.d $ra, $sp, 8 addi.d $sp, $sp, 16 ret So GOT is used for accessing the external variable environ. With "clang t1.c -S -O2 -fdirect-access-external-data", we get: main: addi.d $sp, $sp, -16 st.d $ra, $sp, 8 pcalau12i $a0, %pc_hi20(environ) addi.d $a0, $a0, %pc_lo12(environ) ld.d $a0, $a0, 0 ld.d $a1, $a0, 0 pcalau12i $a0, %pc_hi20(.L.str) addi.d $a0, $a0, %pc_lo12(.L.str) bl %plt(printf) move $a0, $zero ld.d $ra, $sp, 8 addi.d $sp, $sp, 16 ret then the linked binary triggers a SIGBUS. Ideally this should be detected by the linker at link time, but currently the BFD linker fails to detect this error (FWIW this flaw is caused by a really nasty method for the medium code model implementation). So to me -fno-direct-access- external-data is the default. I also grepped for -fdirect-access- external-data in the kernel building system but I've not found any match. Are you using a different version of Clang, or maybe Clang has some configuration-time option to make -fdirect-access-external-data the default? Note that to translate a TU for a normal (dynamically-linked user-space) executable on LoongArch Linux, -fdirect-access-external-data should not be used (because copy relocation is now considered a bad idea and we'll not support it for a new architecture). Fangrui? -fdirect-access-external-data can be used in KBUILD_CFLAGS_KERNEL for avoiding GOT in the main kernel image, OTOH.
On Wed, Nov 8, 2023 at 4:37 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Wed, 2023-11-08 at 12:04 +0800, WANG Rui wrote: > > When compiling module with GCC, the option `-mdirect-extern-access` is > > disabled by default. The Clang option `-fdirect-access-external-data` > > is enabled by default, so it needs to be explicitly disabled. > > I'm wondering why it's enabled by default. > > For this simple test case: > > extern char **environ; > > int main() > { > __builtin_printf("%10s\n", environ[0]); > } > > With Clang 17.0.4 and "clang t1.c -S -O2", it compiles to: > > main: > addi.d $sp, $sp, -16 > st.d $ra, $sp, 8 > pcalau12i $a0, %got_pc_hi20(environ) > ld.d $a0, $a0, %got_pc_lo12(environ) > ld.d $a0, $a0, 0 > ld.d $a1, $a0, 0 > pcalau12i $a0, %pc_hi20(.L.str) > addi.d $a0, $a0, %pc_lo12(.L.str) > bl %plt(printf) > move $a0, $zero > ld.d $ra, $sp, 8 > addi.d $sp, $sp, 16 > ret > > So GOT is used for accessing the external variable environ. With "clang > t1.c -S -O2 -fdirect-access-external-data", we get: > > main: > addi.d $sp, $sp, -16 > st.d $ra, $sp, 8 > pcalau12i $a0, %pc_hi20(environ) > addi.d $a0, $a0, %pc_lo12(environ) > ld.d $a0, $a0, 0 > ld.d $a1, $a0, 0 > pcalau12i $a0, %pc_hi20(.L.str) > addi.d $a0, $a0, %pc_lo12(.L.str) > bl %plt(printf) > move $a0, $zero > ld.d $ra, $sp, 8 > addi.d $sp, $sp, 16 > ret > > then the linked binary triggers a SIGBUS. Ideally this should be > detected by the linker at link time, but currently the BFD linker fails > to detect this error (FWIW this flaw is caused by a really nasty method > for the medium code model implementation). So to me -fno-direct-access- > external-data is the default. I also grepped for -fdirect-access- > external-data in the kernel building system but I've not found any > match. > > Are you using a different version of Clang, or maybe Clang has some > configuration-time option to make -fdirect-access-external-data the > default? The clang enables `direct-access-external-data` by default in PIC and disables it by default in no-PIC. This also applies to PIE. [1] I found that clang PIE in different default states for different environments. For instance, cross-compile is off, while native-compile is on. > > Note that to translate a TU for a normal (dynamically-linked user-space) > executable on LoongArch Linux, -fdirect-access-external-data should not > be used (because copy relocation is now considered a bad idea and we'll > not support it for a new architecture). Fangrui? > > -fdirect-access-external-data can be used in KBUILD_CFLAGS_KERNEL for > avoiding GOT in the main kernel image, OTOH. I also saw that compiling vmlinux already includes the `-fno-PIE` option, which for clang is `direct-access-external-data` enabled. > > -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University > [1] https://github.com/llvm/llvm-project/blob/llvmorg-17.0.4/clang/lib/Frontend/CompilerInvocation.cpp#L1654-L1659
On Wed, 2023-11-08 at 17:20 +0800, WANG Rui wrote: > > then the linked binary triggers a SIGBUS. Ideally this should be > > detected by the linker at link time, but currently the BFD linker > > fails > > to detect this error (FWIW this flaw is caused by a really nasty > > method > > for the medium code model implementation). So to me -fno-direct- > > access- > > external-data is the default. I also grepped for -fdirect-access- > > external-data in the kernel building system but I've not found any > > match. > > > > Are you using a different version of Clang, or maybe Clang has some > > configuration-time option to make -fdirect-access-external-data the > > default? > > The clang enables `direct-access-external-data` by default in PIC and > disables it by default in no-PIC. This also applies to PIE. [1] Oh sh*t: xry111@nanmen2 ~ $ clang t1.c -O2 -fno-pie -no-pie xry111@nanmen2 ~ $ ./a.out Bus error (core dumped) I'll consider it a Clang bug then.
On Wed, Nov 8, 2023 at 5:26 PM Xi Ruoyao <xry111@xry111.site> wrote: > > On Wed, 2023-11-08 at 17:20 +0800, WANG Rui wrote: > > > then the linked binary triggers a SIGBUS. Ideally this should be > > > detected by the linker at link time, but currently the BFD linker > > > fails > > > to detect this error (FWIW this flaw is caused by a really nasty > > > method > > > for the medium code model implementation). So to me -fno-direct- > > > access- > > > external-data is the default. I also grepped for -fdirect-access- > > > external-data in the kernel building system but I've not found any > > > match. > > > > > > Are you using a different version of Clang, or maybe Clang has some > > > configuration-time option to make -fdirect-access-external-data the > > > default? > > > > The clang enables `direct-access-external-data` by default in PIC and > > disables it by default in no-PIC. This also applies to PIE. [1] > > Oh sh*t: > > xry111@nanmen2 ~ $ clang t1.c -O2 -fno-pie -no-pie > xry111@nanmen2 ~ $ ./a.out > Bus error (core dumped) > > I'll consider it a Clang bug then. That's it, no copy relocations. As far as I know, copying relocations has some issues and is not recommended by Fangrui. For modules, if distance is not a problem, `no-pic` and `direct-access-external-data` can be together because the code is writable. Does it seem reasonable to exist? > > -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University >
On Wed, Nov 8, 2023 at 5:36 PM WANG Rui <wangrui@loongson.cn> wrote: > > On Wed, Nov 8, 2023 at 5:26 PM Xi Ruoyao <xry111@xry111.site> wrote: > > > > On Wed, 2023-11-08 at 17:20 +0800, WANG Rui wrote: > > > > then the linked binary triggers a SIGBUS. Ideally this should be > > > > detected by the linker at link time, but currently the BFD linker > > > > fails > > > > to detect this error (FWIW this flaw is caused by a really nasty > > > > method > > > > for the medium code model implementation). So to me -fno-direct- > > > > access- > > > > external-data is the default. I also grepped for -fdirect-access- > > > > external-data in the kernel building system but I've not found any > > > > match. > > > > > > > > Are you using a different version of Clang, or maybe Clang has some > > > > configuration-time option to make -fdirect-access-external-data the > > > > default? > > > > > > The clang enables `direct-access-external-data` by default in PIC and > > > disables it by default in no-PIC. This also applies to PIE. [1] > > > > Oh sh*t: > > > > xry111@nanmen2 ~ $ clang t1.c -O2 -fno-pie -no-pie > > xry111@nanmen2 ~ $ ./a.out > > Bus error (core dumped) > > > > I'll consider it a Clang bug then. > > That's it, no copy relocations. As far as I know, copying relocations > has some issues and is not recommended by Fangrui. > > For modules, if distance is not a problem, `no-pic` and > `direct-access-external-data` can be together because the code is > writable. Does it seem reasonable to exist? Of course, for LoongArch, it is better for `no-pic` to disable `direct-access-external-data` by default. I will send a patch.
On Wed, 2023-11-08 at 17:36 +0800, WANG Rui wrote: > > xry111@nanmen2 ~ $ clang t1.c -O2 -fno-pie -no-pie > > xry111@nanmen2 ~ $ ./a.out > > Bus error (core dumped) > > > > I'll consider it a Clang bug then. https://github.com/llvm/llvm-project/issues/71645 > That's it, no copy relocations. As far as I know, copying relocations > has some issues and is not recommended by Fangrui. > > For modules, if distance is not a problem, `no-pic` and > `direct-access-external-data` can be together because the code is > writable. Does it seem reasonable to exist? It may be usable, but the result is generally worse than relying on GOT. For example, consider a module referring two data symbols in vmlinux, foo and bar. The symbol foo is referred 10 times and bar is referred 8 times. With the current GOT-based approach, the total space usage is (2 GOT entry * (8 bytes / GOT entry)) + ((10 + 8) * 2 instruction * 4 (bytes / instruction)) = 160 bytes. With -fdirect-access-external-data, we must add -mcmodel=extreme too because the modules are too far away from vmlinux in the kernel address space, then the total space usage will be (10 + 8) * 5 instruction * 4 (bytes / instruction) = 360 bytes. One possible approach to resolve the issue is relocating vmlinux from XKPRANGE to XKVRANGE and fit vmlinux + all modules into a 2GiB range. Then the total space usage will be (10 + 8) * 2 instruction * 4 (bytes / instruction) = 144 bytes. But I don't know how to implement this, and running vmlinux in XKVRANGE may have a performance penalty.
diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile index b86f2ff31659..9eeb0c05f3f4 100644 --- a/arch/loongarch/Makefile +++ b/arch/loongarch/Makefile @@ -68,6 +68,8 @@ LDFLAGS_vmlinux += -static -n -nostdlib ifdef CONFIG_AS_HAS_EXPLICIT_RELOCS cflags-y += $(call cc-option,-mexplicit-relocs) KBUILD_CFLAGS_KERNEL += $(call cc-option,-mdirect-extern-access) +KBUILD_AFLAGS_MODULE += $(call cc-option,-fno-direct-access-external-data) +KBUILD_CFLAGS_MODULE += $(call cc-option,-fno-direct-access-external-data) KBUILD_AFLAGS_MODULE += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax) KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax) $(call cc-option,-Wa$(comma)-mno-relax) else