On 2015-07-28 18:01:56, Zoltán Balogh wrote: > If you have any experience or opinion about the topic please bring it up :) > > This idea looks very promising and piling off seconds from the app starts is > something we all are interest, but obviously not for the price of > compromising our platform's security.
I want to talk about the security concerns and areas that would need to change. I've not yet had a chance to closely review the code and I'm mostly going by the description that you linked to. I've pulled it into my reply: > 1. Start qml-boooster > 2. qml-booster: starts as the daemon process > --> Deamon::run() > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L159 > > 3. qml-booster: forks itself to become the actual booster (that will become > the app) > --> > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L184 > --> Daemon::forkBooster() > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L358 > > 4. preforked process: clean up after fork: > --> > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L374 This stage is not sufficient since there is no exec() performed here. This removes the possibility of per-process address space layout randomization (ASLR). All processes on the system that were spawned by qml-booster will have the same memory layout, even if the program authors are trying to do the right thing by building with -fPIE. The exec() will need to occur after special process initialization such as setting rlimits, configuring cgroups, etc., but before attempting to preload any libraries. I've prototyped the difference with a simple proof-of-concept of a booster daemon and app program and the exec() slows down things a considerable amount. Any benchmarks should definitely include such a change in order to not get any hopes up by looking at the non-exec()ing benchmark numbers. Also, AppArmor profile transitions are much more complete when they happen across an exec(). The qml-booster daemon process should be loosely confined by an AppArmor profile. When the exec() occurs, it'll transition to a much more confined profile for the preforked process. > 5. preforked process: > --> initializes the booster caches (load predefined QML components) and > waits for invoke > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L413 > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L68 > > 6. user requests app to start > > 7. preforked process: > --> send message to parent that it needs to prefork a new booster, then > closes the socket > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L141 > > --> start to execute the actual app: > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L424 The preforked process will now need to transition to the AppArmor profile for the app by means of aa_change_profile(). Tyler > > --> last cleanup before app is started > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L254 > > --> Dlopen the binary and load the "main" symbol to execute it: > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L424 > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L452 > > --> Finally execute main > > https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L443 > > 8. After the app was closed, the preforked process dies with it
signature.asc
Description: Digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
