[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5e12ab67701adf81834dfb88fc3cb6fdf55f676d.camel@xry111.site>
Date: Thu, 22 Sep 2022 19:19:10 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Youling Tang <tangyouling@...ngson.cn>,
Jinyang He <hejinyang@...ngson.cn>,
Huacai Chen <chenhuacai@...nel.org>
Cc: linux-kernel@...r.kernel.org, loongarch@...ts.linux.dev,
Xuerui Wang <kernel@...0n.name>,
Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support
On Thu, 2022-09-08 at 16:01 +0800, Youling Tang wrote:
> After adding KBUILD_CFLAGS_KERNEL += -mdirect-extern-access, the
> kernel
> will not generate .got, .plt and .got.plt sections (in the new
> toolchain), we should unexpectedly detect that the kernel has these
> sections, maybe add similar patch [1] to detect, x86_64 has the same
> operation.
>
> But when adding LDFLAGS_vmlinux += -pie (or -shared), there will be
> .got, .plt and .got.plt sections generated, I don't know how the
> toolchain handles it :(?
Hi Youling,
I've pulled your code and make some adjustments for it:
https://github.com/xry111/linux/commits/xry111/la-dev/pie
One adjustment is for FDT removal, another uses a static-PIE style
LDFLAGS as the kernel is more "similar" to a static PIE than a shared
library. In userspace, a static PIE is linked with [1]:
-static -pie --no-dynamic-linker -z text
[1]: https://gcc.gnu.org/r13-2728
But we have to use "-z notext" for vmlinux. I'm not an expert on kernel
hacking, and I guess it's because the kernel doesn't really care the RWX
permission of itself (I heard this during some discussion about a W/X
page warning added in Binutils-2.39 which is triggered for vmlinux).
With "-static -pie --no-dynamic-linker -z notext" (and GCC trunk &
Binutils trunk), .plt and .got.plt are gone.
.got is still there but it only contains one entry (8 bytes). AFAIK
this entry (`_GLOBAL_OFFSET_TABLE_[0]`) is set to the link-time address
of _DYNAMIC for a userspace static PIE [2], but vmlinux does not need it
at all. We can tell the linker to discard it IIUC.
[2]:
https://maskray.me/blog/2021-08-29-all-about-global-offset-table#global_offset_table_0
I've boot the kernel successfully and it seems KASLR is in-effect:
$ sudo cat /proc/kallsyms | grep ' _printk$'
90000000023b28f4 T _printk
$ grep ' _printk$' /boot/System.map-6.0.0-rc6-pie+
90000000009828f4 T _printk
--
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University
Powered by blists - more mailing lists