On 10/18/2013 02:08 AM, Schaufler, Casey wrote:
*From:*Carsten Haitzler [mailto:[email protected]]
*Sent:* Wednesday, October 16, 2013 7:57 PM
*To:* Schaufler, Casey
*Cc:* [email protected]
*Subject:* Re: [Dev] Tizen 3.0 proposal for applications launch
On 10/17/2013 12:06 AM, Schaufler, Casey wrote:
But don't you have those same problems with a launcher? The
launcher pre-links
i never said i like the launcher either. :) i hate it. but it does
speed things up. :)
everything so the application doesn't get slowed by doing so. If
you change a library the launcher needs to do the relinking.
Granted, that's one place so it's a little bit better.
And let's be clear. On a deployed phone, how often are you
changing system libraries in an API incompatible way? Dynamic
libraries are a boon for developers. For product they add
unnecessary overhead and precious little else.
its not a matter of being incompatible at all. if the memory address
where a function is located chances at all (code is inserter or
removed from the binary, re-ordered etc.), as long as the abi stays
(at LEAST the same set of symbols as before with the same signatures
for arguments), then its compatible - but prelink makes any change in
address location an incompatible change. any change that could be a
security fix could break prelink (unless re-prelinked).
Ah! The misconception! A static shared library does not advertise the
addresses of the functions. It advertises the address of a table which
contains the actual addresses. So long as the order of the functions
in the table never changes and the table never shrinks no relinking is
required when the library changes.
i thought we were discussing prelink, not static linking for the above?
do you mean to say static shared lib == prelinked lib?
and as for "unnecessary overhead" - i will have to vehemently
disagree. if we just dumped shared libs entirely and statically linked
everything...
... which is not the case with static shared libraries. Static linking
is different from static shared libraries.
our memory footrpint AND disk footprint would bloat out immensely
Another understandable misconception. A system that supports shared
read-only pages, such as Linux, is not subject to bloat due to
multiple instances of shared library code. In fact, the pre-loading
would be a performance disaster without this behavior.
- but 10's or 100's of mb. we ALREADY are rather bloated in tizen. a
tizen mobile memory footrpint is between 2 to 5 TIMES that of my own
laptops/systems (give or take similar functionality ballpark).
statically linking everything will bloat out our i/o needs as we cant
re-cycle an already-loaded blob of shared code. we duplicate the
memory for it AND the i/o to load it. not to mention "if there is a
bug in a shared lib - security or otherwise, fix it once in one place
and everyone gets the fix". if we statically compile ONLY those that
re-build/link and re-ship their apps will get the fix. this is a major
problem for security and bugfix update distribution to users - it
massively bloats out the time and bandwidth needed to do it. :)
as a security guy you should also be concerned with prelink negating
address space randomization... :)
An address space randomizing application launcher. Thanks, I'll go
have those two beers now. J
See
http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/
http://www.macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-library-proposals/
_______________________________________________
Dev mailing list
[email protected] <mailto:[email protected]>
https://lists.tizen.org/listinfo/dev
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
