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

[daniels@xxxxxxxxxxxxx]

Hi all,

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.

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.

> > >>>>> 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.

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'.

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.

Cheers,
Daniel


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

View/Reply Online (#8092): https://lists.automotivelinux.org/g/agl-dev-community/message/8092
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]
-=-=-=-=-=-=-=-=-=-=-=-