From: Richard Weinberger <richard@nod.at>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Linux-Arch <linux-arch@vger.kernel.org>, octavian.purdila@intel.com
Subject: [RFC] Limiting linker scope
Date: Thu, 19 Nov 2015 23:50:26 +0100 [thread overview]
Message-ID: <564E5232.201@nod.at> (raw)
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
next reply other threads:[~2015-11-19 22:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 22:50 Richard Weinberger [this message]
2015-11-19 23:34 ` [RFC] Limiting linker scope Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564E5232.201@nod.at \
--to=richard@nod.at \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=octavian.purdila@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox