linux-kernel - Re: [PATCH v7 0/5] LoongArch: Support toolchain with new relocation types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAhV-H6wzw-MV+h225rM4PfK_HY0tAdSXcUG-2Hx+_gfhzQ4_g@mail.gmail.com>
Date:   Thu, 1 Sep 2022 10:17:01 +0800
From:   Huacai Chen <chenhuacai@...nel.org>
To:     Xi Ruoyao <xry111@...111.site>
Cc:     Jinyang He <hejinyang@...ngson.cn>,
        WANG Xuerui <kernel@...0n.name>, loongarch@...ts.linux.dev,
        LKML <linux-kernel@...r.kernel.org>,
        Youling Tang <tangyouling@...ngson.cn>
Subject: Re: [PATCH v7 0/5] LoongArch: Support toolchain with new relocation types

Hi, Ruoyao,

On Wed, Aug 31, 2022 at 11:15 PM Xi Ruoyao <xry111@...111.site> wrote:
>
> On Wed, 2022-08-31 at 22:40 +0800, Huacai Chen wrote:
> > On Wed, Aug 31, 2022 at 4:09 PM Xi Ruoyao <xry111@...111.site> wrote:
> > >
> > > On Wed, 2022-08-31 at 14:58 +0800, Jinyang He wrote:
> > > > That's right. Also I am wondering why new toolchain produce .got* in
> > > > kernel. It's unneeded. In the past, gcc create la.global and parsed
> > > > to la.pcrel by gas, and kernel works well. Now it seems we lost this
> > > > feature in gcc. I checked the x86 asm code just now. And some info
> > > > follows,
> > > >
> > > > LoongArch64, ./net/ipv4/udp_diag.s, *have reloc hint*
> > > >           pcalau12i       $r4,%got_pc_hi20(udplite_table)
> > > >           ld.d    $r4,$r4,%got_pc_lo12(udplite_table)
> > > >           b       udp_dump
> > > >
> > > > x86_64, ./net/ipv4/udp_diag.s
> > > >           movq    $udplite_table, %rdi
> > > >           jmp     udp_dump
> > > >
> > > > It seems related to -fno-PIE and -cmodel=kernel on x86_64.
> > > > Hope new gcc with this feature now.
> > >
> > > On x86_64 -mcmodel=kernel means "all code and data are located in [-
> > > 2GiB, 0) range.  We actually don't strictly require a "high" range as
> > > we're mostly a PIC-friendly architecture: note that we use a
> > > pcalau12i/addi.d pair for PIC addressing in [PC-2GiB, PC+2GiB, and a
> > > lu12i.w/addi.d pair for "non-PIC" addressing in [-2GiB, 2GiB), both are
> > > 2-insn sequence.
> > >
> > > If we can put the main kernel image and the modules in one 2GiB VA
> > > range, we can avoid GOT completely.  But it's not possible for now
> > > because main kernel image is loaded in XKPRANGE but the modules are in
> > > XKVRANGE.  So the best we can achieve before implementing
> > > CONFIG_RELOCATION is using GOT in modules, and avoid GOT in the main
> > > kernel image (with a new code model in GCC, which will benefit both the
> > > kernel and statically linked executables).
>
> > Emmm, can you implement this new code model in the near future?
>
> I have a plan to make our toolchain addressing the symbols better:
>
> (1) https://sourceware.org/pipermail/binutils/2022-August/122682.html.
> This change will allow the linker to link a main executable image
> (dynamically linked or statically linked, PIE or non-PIE, kernel or
> userspace) with R_LARCH_COPY instead of GOT.  (Note that R_LARCH_COPY
> will not show up in the kernel because we don't link to shared objects,
> but GOT will be gone.)
>
> (2) Change GCC to stop using GOT unless -fPIC.  (Technically it's a one-
> line change.)
>
> (3) In kernel, for main kernel image the default of toolchain will be
> good enough (no GOT).  For modules we have two options:
>
>   (a) get rid of XKPRANGE.
>   (b) force -mcmodel=extreme globally.
>   (c) use -Wl,nocopyreloc to produce GOT.
>
> (a) is the best, the performance of (b) and (c) will be worse than (a).
> I'm not sure which one in (b) and (c) is better, but as (a) will be the
> final solution we can just choose one in (b) and (c) "randomly" for now.
>
> I don't want to add a new code model now, because if (1) works fine
> we'll not need a new code model.  (1) is also the most tricky step in
> the plan (I've sent the patch but not sure if it's completely correct),
> (2) and (3) should be trivial.
Now all global variable accesses are via got, I think the performance
may be much worse than before when we didn't use explicit-relocs.
I don't know whether "a new code model" or your "(1)(2)(3)" is easier
to implement, but I think it is better to solve the performance issue
before 6.1-rc1.

Huacai

> --
> Xi Ruoyao <xry111@...111.site>
> School of Aerospace Science and Technology, Xidian University
>