Re: [agl-dev-community] ?utf-8?q?_=5Bagl-dev-community=5D?= af-binder and af-main start-up issues and windowmanager/libhomescreen dependencies

["Jose Bollo" <jose.bollo@xxxxxxx>]

On Tue, 11 Feb 2020 04:54:13 +0000
daniels@xxxxxxxxxxxxx wrote:

> Hi all,

Hi Daniel

> On Tuesday, January 21, 2020 13:56 GMT, "Jose Bollo"
> <jose.bollo@xxxxxxx> wrote:
> > On Mon, 20 Jan 2020 16:49:27 +0200 "Marius Vlad"
> > <marius.vlad@xxxxxxxxxxxxx> wrote:
> > > On 1/20/20 3:56 PM, José Bollo wrote:
> > > > On 10/01/2020 17:45, Marius Vlad wrote:
> > > >> On 1/10/20 2:37 PM, José Bollo wrote:
> > > >>> On 09/01/2020 23:50, Marius Vlad wrote:
> > > [ ... a lot snipped ... ]
> > > Regarding this part, on launching applications, I've been having
> > > some talks with the guys in the meeting, last week, and they've
> > > revealed something equivalent to what I was trying to achieve,
> > > that resides in agl-service-homescreen. In the homescreen binder
> > > there are calls towards afm-system-daemon using `afb_api_call()`.
> > > These are all quite hidden, such that  'showWindow()' (or
> > > something equivalent to that) calls into this, if the application
> > > is not already started, which is not obvious at first hand.
> > >
> > > Launcher application also seems to use this
> > > agl-service-homescreen for it, as to retrieve the runnables
> > > applications array and also calls into `afb_api_call()`.
> >
> > These service are designed to run on top of the AGL framework binder
> > (/usr/bin/afb-daemon) and are coded as AGL bindings. It use the
> > interface that the binder offers to them. Here the function
> > afb_api_call.
> > https://docs.automotivelinux.org/docs/en/master/apis_services/reference/af-binder/reference-v3/func-api.html#afbapicall
> >
> > Advantage is that the setup (connections) is made for them, the
> > binder knows how to connect code to system.
> >
> > > On the same page, I'm currently in the process of modifying
> > > agl-service-homescreen as to be able to expose some of the
> > > requests from agl-shell, and I'm wondering how feasible is it to
> > > serialize object (a.k.a pointers) over JSON.
> >
> > Several algorithms exist. I have no special advice.
> >
> > However if you intend to use pointer values directly, note that the
> > used JSON library is able to handle 64 bits integers but to be as
> > safe as possible, it is probably better to use a string (hexa?
> > %p?), it will ensure that the accuracy is kept (no unexpected
> > conversion to lower bit capacities).
> >
> > > To give you a better view of the things, if agl-service-homescreen
> > > will be one binding to the agl-shell interface it needs to be
> > > able to use wayland objects (wl_surface/wl_output) and they have
> > > be passed from homescreen to libhomescreen and from there
> > > serialized to agl-service-homescreen. Clients can create on their
> > > own wayland objects and call into the binder service.
> > >
> > > Then, agl-service-homescreen has to de-serialize those to wayland
> > > type of data, and use those in the requests for agl-shell
> > > interface.
> > >
> > > This kind of reflection is obviously not available in C/C++ and
> > > only passing pointers disguised as ints does not seem to do the
> > > "trick", though I haven't really tried (but will soon). Will have
> > > a look to other potential ways of doing this, maybe there is a
> > > way to identify them, but not sure what could be atm.
> >
> > Then I have to assume that Wayland/Weston/agl-shell enforces use of
> > pointers that can be passed from on process to an other process. In
> > that case, just use it that way with the caution I pointed out.
> 
> Wayland itself does not require the passing of pointers between
> processes.

Good

> I think here it is better to step back to interfaces. It would be
> helpful to have a diagram showing the launch flow between different
> processes.

Agreed

> > > >>>>> I realize that a lexicon is missing! It is so easy to
> > > >>>>> confuse things here. Current AGL has:
> > > >>>>>
> > > >>>>>    - the IVI-shell
> > > >>>>>    - the windowmanager service
> > > >>>>>    - the homescreen service
> > > >>>>>    - the homescreen application
> > > >>>>>
> > > >>>>> My understanding was that you, collabora, rework the shell
> > > >>>>> and the windowmanager service. It implies modification to
> > > >>>>> other services and applications, of course.
> > > >>>>
> > > >>>> That's correct. I guess I'm also mashing the notion of a
> > > >>>> service with that of an application while you seem to make a
> > > >>>> clear separation of those. So far, current design removes
> > > >>>> the IVI shell the window manager service entirely and for
> > > >>>> now homescreen is just an application, which serves the role
> > > >>>> of the shell.
> > > >>>>
> > > >>>> Your description is missing the compositor which is still
> > > >>>> present, albeit in a stripped down form. The compositor is
> > > >>>> the one handling the switching but the command to
> > > >>>> spawn/switch apps comes from homescreen. Do
> > > >>>> note that there's no code in the compositor for launching
> > > >>>> apps.
> > > >>>>
> > > >>>> That is why it seems quite peculiar to me to have the
> > > >>>> compositor chat with the policy manager if it can display or
> > > >>>> not the surface. As homescreen serves the role of the shell,
> > > >>>> it *should* always be present, even if you start apps
> > > >>>> manually. I'm not 100% sure at this moment, but I
> > > >>>> don't believe you can display anything atm without homescreen
> > > >>>> being present. It then stands that the policy check should
> > > >>>> also happen in homescreen and not the compositor itself. But
> > > >>>> for now this is something that I need verify, before making
> > > >>>> any other speculation :-).
> > > >>>
> > > >>> Understood, but... So what you call homescreen is the policy
> > > >>> manager or more clearly speaking, the window manager. I'm not
> > > >>> sure of how you intend to separate that from homescreen. IMHO
> > > >>> the homescreen should not be the window manager. I mean that
> > > >>> policy should not be in the homescreen. You need to clarify
> > > >>> things because I'm getting lost.
> > > >>
> > > >> IMO the policy manager needs to be a distinct entity where
> > > >> other services (like homescreen, for instance) is able to talk
> > > >> to. It should also be connected to policy database (which
> > > >> seems to be represented by cynagorad).
> > > >>
> > > >> I'm advocating for a distinct entity as I don't think it is a
> > > >> good design to encompass mostly related graphic parts with
> > > >> security management, or security at all for that matter. I
> > > >> understand the need to have this integration and I agree with
> > > >> it, but I also get the feeling you might want to have
> > > >> independent services. And services/daemon talking to each
> > > >> other using some kind of a channel seems the unix way of doing
> > > >> things.
> > > >>
> > > >> In this sense I believe the shell needs to delegate the
> > > >> permission check to the policy manager. The shell only needs
> > > >> to "translate" the resources being accessed to that the policy
> > > >> manager understands.
> > > >
> > > > The wayland architectural pitch
> > > > https://wayland.freedesktop.org/architecture.html !!! I'm
> > > > thinking that it is very blur: it probably presume that window
> > > > manager (WM) is a client that pilots the compositor and
> > > > implement a policy engine (PE), also probably but not
> > > > mandatory. In that case, the WM/PE has to identify clients.
> > > > How? Either the client establishes a connection to the WM/PE or
> > > > the compositor helps.
> 
> No, the idea is that the window manager is a core and inseparable
> part of the compositor. This is one of the big changes with the move
> to the new compositor framework.
> 
> The compositor (the process running the Wayland server) should be the
> one in charge of most window management tasks. However, the UI/HMI
> part is somewhat separated from this: the rendering is done in a
> separate process. So there needs to be some communication between the
> UI process and the window management. If the user presses the HVAC
> button on the panel, then the HVAC process should be launched, and
> also switched to. This is handled by the homescreen sending the
> window manager a request to switch to the HVAC (identified by a
> string application ID) window.

It would be helpful to have a diagram showing the different processes
and fixing the vocabulary.

> The homescreen process can be launched securely through the
> compositor. The compositor process forks and launches the homescreen
> UI process, placing a file descriptor for a Wayland socket into its
> environment at startup. As the compositor has created between the
> pipe between the processes, it is able to expose private protocols to
> the homescreen process which is in effect 'pre-authenticated'.

It could but I'm not advocating to implement only that solution. We
have on AGL a powerful permission framework that could be used. Since
january that permission framework includes a token mechanic and is
compatible with OAuth2 framework.

I think that it has to be taken into account. In my opinion, relying
only on fork/exec for assuming security introduces a configuration
dependency between the compositor(+WM?) and the homescreen. That
dependency is probably not more than a simple config file but think
to what it implies to manage such item.

> Currently the process launching (via the binder) is handled from the
> homescreen. However it could be moved to the window manager
> component, which is in process with the compositor.
> 
> You're right that the policy engine can and should be delegated to a
> distinct entity. Our plan was to provide a minimal interface within
> the window manager which would provide a framework for vendors to
> implement their own policy engine as a plugin, an interprocess call,
> a remote call to a separate processor, or as a new kernel interface
> if that's what we don't want to do. We do not intend to provide a
> complete implementation of this policy engine ourselves.

Is it possible to provision in the policy engine the following topics?
 - receiving token compatible with RFC 6750
 - plugin mechanism to check token against a permission
 - allowing client to become "homescreen-like" application if permitted

Best regards
José

> Cheers,
> Daniel
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8098): https://lists.automotivelinux.org/g/agl-dev-community/message/8098
Mute This Topic: https://lists.automotivelinux.org/mt/71159035/2167316
Group Owner: agl-dev-community+owner@xxxxxxxxxxxxxxxxxxxxxxxxx
Unsubscribe: https://lists.automotivelinux.org/g/agl-dev-community/leave/4543822/883735764/xyzzy  [list-automotive-discussions82@xxxxxxxxxxx]
-=-=-=-=-=-=-=-=-=-=-=-