linux-kernel - Re: [PATCH 1/3] LoongArch: tools: Add relocs tool support

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]

Date:   Sun, 4 Sep 2022 00:23:04 +0800
From:   Jinyang He <hejinyang@...ngson.cn>
To:     Xi Ruoyao <xry111@...111.site>,
        Youling Tang <tangyouling@...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 2022/9/3 18:49, Xi Ruoyao wrote:

> On Sat, 2022-09-03 at 09:57 +0800, Youling Tang wrote:
>>>> Unlike (pre-r6) MIPS, LoongArch has a complete support for PIC, and
>>>> currently LoongArch toolchain always produces PIC (except, if -Wa,-mla-
>>>> {local,global}-with-abs or la.abs macros are used explicitly).
>>>>
>>>> So would it be easier to review and correct the uses of "la.abs" in the
>>>> code, and make the main kernel image a real PIE?  Then we can load it
>>>> everywhere w/o any need to do relocation at load time.
>> At the beginning I also wanted to make the main kernel image a real PIE
>> and tried it, some of the "la.abs" can be modified, but I encountered
>> difficulties in modifying the  exception handling code part, the kernel
>> will not  boot after modification :(, I will continue to work hard try.
> I just tried the same thing and get the same result :(.  Will spend
> several hours reading the LoongArch manual about exception...
>
Hi,

The following ideas are based on experience, without validation. Patches
show that three types of relocation are needed to be done.
1, GOT is generated by toolchain, so  I think eliminating them by 
toolchain is better.
2, Ex_table is generated but striped relocation info. We can plays pcrel
way to resolve this problem. One of ways like follows, (pseudo-code)

arch/loongarch/copy_user.S
...
.macro fixup_ex from, to, offset, fix
.if \fix
         .section .fixup, "ax"
\to:    addi.d  a0, a2, \offset
         jr      ra
         .previous
.endif
         .section __ex_table, "a"
         PTR     \from\()b, \to\()b - \from\()b   # fixup use pcrel
         .previous
.endm
...
...

arch/loongarch/mm/extable.c
         ...
         unsigned long era = exception_era(regs);
         fixup = search_exception_tables(era - relocate_offset); // 
Search by orig value
         if (fixup) {
                 regs->csr_era = fixup->fixup + era; // Fixup fixup address.
                 return 1;
         }

         ...

3, The left is the processed relocation table. It collect the relocation
type R_LARCH_ABS* (R_LARCH_MARK_LA?) and R_LARCH_64. Just do
as this patch does. The la.abs is used because of the different exception
entry on each CPUs and better NUMA performance IMHO. We can
do follows way to avoid R_LARCH_ABS* and produce R_LARCH_64, (data in text)

.text
la.pcrel t0,999f
ld.d t0,t0,0
...
PTR do_vint
...

*Not* important. For me, I really wish a bootstrap relocation while this
patch is KALSR. The bootstrap relocation meaning is the boot cpu enter
kernel_entry, check the real address itself, parse the cmdline whether
do kaslr, and then relocate itself. Then kdump capture process is easier.
Some past info links,
https://lore.kernel.org/loongarch/3002b2b3-2c2c-e32e-c474-d3876d3ef9b7@loongson.cn/
https://patchwork.kernel.org/project/linux-mips/patch/1618230494-6207-6-git-send-email-hejinyang@loongson.cn/