It was <2013-10-15 wto 16:18>, when Schaufler, Casey wrote: > -----Original Message----- > From: Łukasz Stelmach [mailto:[email protected]] > 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:[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.
a.out? I may be too young to remember. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgp7rbgwcXdpC.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
