linux-kernel - Re: [PATCH v4 0/4] LoongArch: Support 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-next>] [day] [month] [year] [list]

Message-ID: <5233653cceab9c2baf6510bd712cd53ef63e3aac.camel@xry111.site>
Date:   Sat, 30 Jul 2022 17:51:12 +0800
From:   Xi Ruoyao <xry111@...111.site>
To:     Lulu Cheng <chenglulu@...ngson.cn>,
        Huacai Chen <chenhuacai@...nel.org>
Cc:     Youling Tang <tangyouling@...ngson.cn>, loongarch@...ts.linux.dev,
        LKML <linux-kernel@...r.kernel.org>,
        WANG Xuerui <kernel@...0n.name>,
        Jinyang He <hejinyang@...ngson.cn>
Subject: Re: [PATCH v4 0/4] LoongArch: Support new relocation types

On Sat, 2022-07-30 at 14:44 +0800, Lulu Cheng wrote:
> > > If addr_global is rejected or not implemented (for example, building the
> > > kernel with GCC 12), *I expect* the following hack to work (I've not
> > > tested it because I'm AFK now).  Using visibility in kernel seems
> > > strange, but I think it may make some sense because the modules are some
> > > sort of similar to an ELF shared object being dlopen()'ed, and our way
> > > to inject per-CPU symbols is analog to ELF interposition.
> > > 
> > Sadly, I don't know what visibility is, does it have something to do
> > with __visible in include/linux/compiler_attributes.h?

They are different definitions of visibility and mostly unrelated. 
Unfortunately humans do not have enough words in the language to
disambiguate those different concepts :).

-fvisibility and __attribute__((visibility)) are for ELF shared objects.
Kernel developers usually do not need to take care of them (unless
working on VDSO).

-fvisibility=default (yes, it's the default) makes the symbol "possible
to be interposed" while -fPIC.  Say

$ cat main.c
extern int f(void);
extern int printf(const char *, ...);
int x = 1;
int main() { printf("%d\n", f()); }
$ cat shared.c
int x = 42;
int f(void) { return x; }
$ cc shared.c -fPIC -shared -o libshared.so
$ cc main.c -L. -Wl,-rpath,. -lshared
$ ./a.out
1

You may think it strange but it's so-called "symbol interposition"
mandated by ELF spec.  To make it work, the compiler has to use GOT
access for "x" instead of PC-relative access.

OTOH, a "hidden" visibility disallows interposition:

$ cat shared-1.c
__attribute__((visbility("hidden"))) int x = 42;
int f(void) { return x; }
$ cc shared-1.c -fPIC -shared -o libshared.so
$ ./a.out
42

Now the compiler will use PC-relative access for "x" in "f".

In my hack the combination of "-fPIC" and
"__attribute__((visibility("default")))" for per-CPU symbols makes per-
CPU symbols accessed via GOT, and "-fvisibility=hidden" keeps normal
symbols accessed via PC-relative within a TU.

Note that the visibility of a symbol is also recorded in the symtab, and
ld.so will refuse to access a hidden symbol in one shared object from
another.  But the kernel module loader just doesn't care the visibility
field in symtab so it won't affect us.

Basically the hack just uses visibility options & attributes *in a way
they are not designed for* to trick the compiler to emit GOT accesses
for per-CPU symbols.  A new attribute ("get_through_got"/"movable" or
whatever) is definitely wanted to avoid such a tricky approach, but the
hack can be used if we want modular kernel able to be built with GCC 12.
-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University