On mar, 2014-07-01 at 15:26 +0200, Patrick Ohly wrote: > On Fri, 2014-06-27 at 15:14 +0200, José Bollo wrote: > > On ven, 2014-06-27 at 14:09 +0200, Patrick Ohly wrote: > > > More interesting for the discussion is something else: how much slower > > > (in percent) will SAPI be compared to CAPI? For that, one needs to look > > > at which method calls will be wrapped by SAPI - all of the CAPI methods > > > or only some? > > > > No. > > I assume that this is a "no, all of the CAPI methods get wrapped" (which > you confirmed below).
You are right. It may change in the futur but it is the current case of study. > This leads to another question: suppose we have a "some_struct > *some_struct_new()" and a second method using that pointer, for example > as in "void do_something(some_struct *p)". > > At the moment, a misbehaving app process will crash or at least only > corrupt its own memory if it passes an invalid pointer to > do_something(). > > What kind of checks are done by the SAPI proxy server when it receives > the parameter for do_something()? Does it validate the pointer or does > it fully trust the app to behave? > > Remember, the proxy runs with higher privileges than the app talking to > it. Using data from the app without checking is insecure; I bet one > could easily crash the proxy daemon or worse, use this for privilege > elevation. > > If validation fails, how is that handled? This is relevant for debugging > buggy apps. This is a really serious topic that you are pointing here. Using direct address is bad. Using handles is also bad for the same reasons: it could be a lying handle too. So the only answer is checking and accept the price to pay for it. However, the server process of SAPI forks for each incoming client. Thus, a client would only crash its server instance not the instances of the other clients. The main reason for doing a fork is that the encapsulated core APIs are free to define static data/state that must not be shared between instances. Best regards José > > > As Carsten pointed out in his email from June 16th, if CAPI has method > > > calls which execute locally in the process at the moment and SAPI > > > replaces that with remote procedure calls, then performance will be > > > considerably slower. If these methods get called often, then this will > > > matter. > > > > But this have issues: where is the context? In the client or in the > > server? That might be a nightmare. Thus, for first, we are studying the > > worst case, when all call are passed to the server. > > Handling context in the server is also tricky. > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
