linux-kernel - Re: Dynamic linking in the kernel

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: <20100220.125758.174837163.davem@davemloft.net>
Date:	Sat, 20 Feb 2010 12:57:58 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	weigelt@...ux.de
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Dynamic linking in the kernel

From: Enrico Weigelt <weigelt@...ux.de>
Date: Sat, 20 Feb 2010 19:22:40 +0100

> Starting up an dynamically linked executable tends to need a lot
> of syscalls. A kernel-based dynamic linker could cache a lot of
> relocation data (eg. when the same binary is called many times),
> share pages even w/o mmap(), and the ldstub wouldnt be needed
> anymore.

This is not practical.

In order to implement this the kernel would have to also save a copy
of all pieces of the processes's environment and compare all of the
environment variable settings on every execution.  This would be
needed to handle things like LD_PRELOAD, LD_LIBRARY_PATH, and LD_DEBUG
as just three examples.

What's more, any filesystem change involved in the shared libraries,
the executable, or the dynamic linker would have to be monitored as
well.

Really, this is not a good idea, and the cost is only ~3 system calls
per shared library and considering the amount of flexibility we get in
return it's not that bad at all.

Actually, the more expensive part of shared libraries are the page
faults from filling in the relocations and we already have a mechanism
to save that cost, it's called 'prelink'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/