[agl-discussions] what's behind Tizen AppFW architecture model

Dominig Ar Foll dominig.arfoll at fridu.net
Mon Oct 31 21:12:30 UTC 2016


Xavier;

please find here a short description of the suite of events and
experiences which have lead the creation of the AppFW.

Dominig

1) History
========
a) Meego
-------------
When we did Meego, QT had a friendly license (lgplv2) and was
providing the OS abstraction.  Unfortunately as the lead architect for
Meego TV (at the time in 2009, I was CTO of Amino Communication in
Cambridge, UK) I had to provide a decent security model to pass PayTV
requirements. An issue that very few had serioulsy considered in Linux
embedded designs.
I came out with a concept of MAC (Mandatory Access Control) model, At
the same period, Nokia defined their own model and soution for their
MeeGo phone. Finally Smacks (one of 3 Linux upstream suppoted MAC
implementations) made it in the upstream Linux kernel after its
adoption for a smart TV project at Philips. For Meego, we all agreed
to use Smack Meego 3.x and then Meego was killed ...

b) Tizen
------------
While Tizen code based started with SLP (from Limo project), the
security model of Tizen 2 (Tizen 1 never made it)  was based on Meego
ideas. Smack was selected after extensive measurements done by
Samsung.
It was used for the entire security policy enforcement (>22000 rules
for a Tizen 2.2 phone).
Samsung did provide many performance related patches in Smack but
while the performance became rather good, the management complexity
remained out of control.

When I took the architecture responsibility for Tizen 3 (working for
Intel this time), we agreed with Samsung that we needed to split the
security policy in two domains. Access to the OS and low level
resources would be controlled via Smack while access to API by the
Apps would be controlled via a policy manager. This is when Cynara
(developed by Samsung Poland whith the support of José who is the key
contributor to AGL AppFW) came into play.

With that model we succeeded to simplify the system but we induced a
serious duplication as the privilege enforcement  needed to be
implemented in the web runtime (Crosswalk) and in the native services
support the APIs. Furthermore all services needed to be run with the
highest privilege requiring them to be provided only by the highest
trusted level of suppliers.

We never succeeded to implement a simple and stable security model in
the web-runtime due to the permanent changes induced by Google in
Chromium code (the base of Crosswalk) and API support by HTLM5 was
always behind as each API was requiring a dedicated Plug-in to provide
the specified isolation. Furthermore the security model was
incompatible with each series of new changes from Google requiring to
keep an entire team busy just to keep afloat.

c) AGL
----------
When Intel has decided to refocus Tizen team on the 'maker' market for
IoT with Zephyr and Ostro projects, the nascent AGL team (which
includes most of the key coders of the initial Tizen AppFW) had two
options :
 - take Tizen AppFW and deal with the Webrun time legacy for ever
 - take profit of the change of control to fix the issue

The later solution was selected.

2) Driver behind the AGL model
======================
a) Tizen 2 legacy
------------------------
Tizen 3 (on which is based Tizen IVI) needs to provide a backward
compatibility with Tizen 2.2 and 2.3 AppFW for which millions
commercial products (TV and phones) are deployed.
http://www.tizenstore.com/main/getMain.as
AGL had no interest to keep that legacy code. Furthermore only Samsung
can maintain it and does not care about IVI requirements.

Writting a Tizen 3 'only' AppFW was discussed but would keep open the
major issue with the Web runtime while still ending as a dedicated AGL
code because Samsung would have not been able to accept that code
(even if some key members of Samsung technical staff would have loved
too) which did not provide Tizen 2.x backward compatibility.

b) what needed fixing
-------------------------------
While getting through the pain of changing some code a few important
decisions were taken :
  - same code to implement API usable from any language (including HTML5)
  - no change required in the web run time to add new API
  - security not provided by the web run time
  - enable hybrid App (cloud-device-cloud)
  - use concepts/tools that web developers understand (there is not
enough embebed coders on the planet to support IoT growth)
  - API could support a move toward Containers if later desired
whithout requiring to recode them.

c) the solution
--------------------
The solution of the binder using websocket (and D-bus for legacy if
realy needed) associated with a web type authentication model was
providing a nice solution fitting the requirement while easy to
support.
The benchmark made on the Renesas Porter 3 and the Intel Minnow boards
demonstrated that the overhead was acceptable even with heavy load on
these type of low end CPU.

This model is implemented in AGL since release 2.0.

3) Summary
=========

                                     Tizen               AGL

App/OS isolation              yes                yes
Container option               no                 possible
Native App                       partial*            yes
HTML5 App                      yes                yes
Cloud App                        No                  yes
Unified API (HTLM/Native)  No               yes
service as App**                No                 yes
Adding API    ***                core               core or App
Devel model                      bespoke        Standard Web

* Tizen requires to implement any API twice
    1) for HTML inside the Crosswalk (Chromium base) browser - API
implemented by default in Cromium (e.g. file access) cannot be
protected via the App Mannifest without patching Chromium internal
code.
    2) for the Native App as a Core service in the OS.- Due to coding
constrain and Tizen 2.x compatibility, Security is not always possible
to be provided for all native API.

** AGL model allows to create an App which provide a service to other
App. This allows to create unified high level services (e.g. is there
free parking spot near me) while the implementation can be implemented
locally without requiring security vetting to patch the core OS.
Tizen 2.1 had a similar concept but it was removed in Tizen 2.2 due to
the induced security complexity (see*)

*** Due to the fact the in Tizen all services implementing API need to
be privileged (e.g. UID root), any new service requires to be
integrated in the core OS.
With AGL the option is open. Generic API can be added to the core OS,
but other can be left as App. The model could, for example, be used to
provide different services in different Geos or even to manage changes
in low level hardware sensors or car models while sharing a single
code for the core OS.

2016-10-29 11:40 GMT+02:00 Xavier Roirand <xavier.roirand at windriver.com>:
> Hello,
>
> I'am working on my spare time on AGL for Minnowboard, especially the
> security model.
>
> I would like to understand what requirements has motivated the creation of a
> dedicated AppFW and it's imbrication in the AGL security model.
>
> I found some information on how it works, but I'am almost blind on the why.
>
> Could some one enlight me ?
>
> Thx
>
> Xavier.
> _______________________________________________
> automotive-discussions mailing list
> automotive-discussions at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions



-- 
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre


More information about the automotive-discussions mailing list