Limiting linker scope

Hi!

UML recently had an interesting bug[1] where the host side of UML tried to call sigsuspend() but as the kernel itself offers a function with the same name it called sigsuspend() on
the UML kernel side and funny things happened.

The root cause of the problem is that the UML links userspace code like glibc, libpcap, etc. to the kernel image and symbols can clash. Especially if one side is a shared library it will not noticed at compile time.

As this is not the first bug of this kind I'm facing on UML I've started to think how to deal with that.

Is it somehow possible to limit the linker scope? Such that we can force LD no not blindly link every symbols of vmlinux into another object? Maybe using a white list? I have do admit I've never used LD scripts nor GNU export maps, maybe they can help. Currently I'm reading their docs and hope to find a way to implement my idea.

The problem is also not specific to UML, the emerging Linux Kernel Library will suffer from the same issue.
As random programs will link the kernel as library the chance is high to face similar symbol conflicts.

Maybe we can also find a nice generic solution to limit the linker scope within the kernel. Such that it does not hurt when a random device driver exports a symbol like "i".
It would also help to define subsystem interface more strict manner.

Thanks,
//richard

[1] https://lkml.org/lkml/2015/11/16/601

Am 19.11.2015 um 23:50 schrieb Richard Weinberger:

I take this back. LKL continues to impress me.
It creates a new kernel object using objcopy -G and marks only some symbols as global. This approach could work for UML too.

Thanks,
//richard