> -----Original Message----- > From: Łukasz Stelmach [mailto:[email protected]] > Sent: Tuesday, October 15, 2013 12:39 AM > To: Schaufler, Casey > Cc: [email protected]; Jussi Laako; [email protected] > 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:[email protected]] > > 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
