[Dev] Tizen 3.0 proposal for applications launch
casey.schaufler at intel.com
Tue Oct 15 14:18:28 GMT 2013
> -----Original Message-----
> From: Łukasz Stelmach [mailto:l.stelmach at samsung.com]
> Sent: Tuesday, October 15, 2013 12:39 AM
> To: Schaufler, Casey
> Cc: youngik.cho at samsung.com; Jussi Laako; dev at lists.tizen.org
> Subject: Re: [Dev] Tizen 3.0 proposal for applications launch
> 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.
There's a long story about Scott McNeally (CEO at Sun) and what happened when he first saw dynamic libraries, but that's a two beer story.
> No! This is madness. It means implementing dynamic linker in the kernel, which
> is exactly opposite to what we've got now. OTOH some help from the kernel
> side would be handy... I'll ponder this with kernel guys over cup of tea.
> Łukasz Stelmach
> Samsung R&D Institute Poland
> Samsung Electronics
More information about the Dev