[Dev] Tizen 3.0 proposal for applications launch

Schaufler, Casey casey.schaufler at intel.com
Mon Oct 28 00:23:41 GMT 2013


From: Carsten Haitzler [mailto:c.haitzler at samsung.com]
Sent: Sunday, October 27, 2013 4:07 PM
To: Schaufler, Casey
Cc: dev at lists.tizen.org
Subject: Re: [Dev] Tizen 3.0 proposal for applications launch


On 10/18/2013 02:08 AM, Schaufler, Casey wrote:
From: Carsten Haitzler [mailto:c.haitzler at samsung.com]
Sent: Wednesday, October 16, 2013 7:57 PM
To: Schaufler, Casey
Cc: dev at lists.tizen.org<mailto:dev at lists.tizen.org>
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?

Well, the conversation has drifted. Prelinking is something you do to try to address the abominable performance of dynamic shared libraries. I brought up static shared libraries because they address the issues, and I sort of hoped that rather than adding more layers of complexity we might "regress" a few instead. I understand the differences, and the consequences of the various approaches.



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. :)





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

Dev at lists.tizen.org<mailto:Dev at lists.tizen.org>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131028/ac7720f1/attachment-0001.html>


More information about the Dev mailing list