[Dev] Tizen 3.0 proposal for applications launch
l.stelmach at samsung.com
Tue Oct 15 15:35:13 GMT 2013
It was <2013-10-15 wto 16:18>, when Schaufler, Casey wrote:
> -----Original Message-----
> From: Łukasz Stelmach [mailto:l.stelmach at samsung.com]
> Sent: Tuesday, October 15, 2013 12:39 AM
>> It was <2013-10-14 pon 17:42>, when Schaufler, Casey wrote:
>>> -----Original Message-----
>>> From: Łukasz Stelmach [mailto:l.stelmach at samsung.com]
>>> Sent: Monday, October 14, 2013 7:12 AM
>>>> It was <2013-10-14 pon 14:51>, when YOUNG IK CHO wrote:
>>>>>> The easy and, to my mind correct, solution is to let the kernel
>>>>>> take care of setting the security attributes and throw out the
>>>>>> whole "launcher" thing.
>>>>> On the TIZEN 2.1 (previous version) mobile profile, it gives the
>>>>> huge difference. My test app shows:
>>>>> - launch without preloading : 950msec
>>>>> - launch with proper preloading : 630msec
>>>>> When my colleague analized the performance bottle neck, he found
>>>>> that around 100~200msec is consumed on the dynamic loader. I know
>>>>> there are several solutions like prelink or readlink but
>>>>> preloading works better. For WebApp, wrt_launchpad performs
>>>>> pre-initialization heavily and it has much more number than
>>>>> Core/Osp App in terms of performance gain.
>>>> Preloading, however, has a great security issue (please correct me
>>>> if I am wrong). The "preloaded" application inherits entire address
>>>> space of the launcher. If I am not missing anything it might try,
>>>> and what is worst it might succeed in modifying launcher's memory.
>>>> execve(2) provides a form isolation between parent and child
>>>> executing different code.
>>> Yes, this is a significant issue. The launcher must completely
>>> emulate the behavior of exec(). Some behaviors, such as close on
>>> exec and file based capabilities, are tricky to get right.
>> OK, I think I am catching the point. Is it even possible without
>> making the "preloading" exec() no faster than the real one? Is it
>> possible to implement preloading *and* security in userland? This
>> seems even harder.
>> --- WARNING: MADNESS AHEAD! ---
>> How about preloading in kernel? This seems much easier to do
>> right. You could for example configure which libraries to load via a
>> file in /proc.
> This is not madness. Before we had dynamic shared libraries we had
> static shared libraries. No runtime linking required, everything is
> done via table lookups. You can't delete interfaces from a static
> shared library, so they make development slightly more difficult. They
> are lots faster.
a.out? I may be too young to remember.
Samsung R&D Institute Poland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: not available
More information about the Dev