[PATCH 1/6] Add weston randr protocol

[Hardening]

Le 05/03/2014 03:07, Wang, Quanxian a écrit :
> Hi, All
>
> With the first version of randr protol, I got many useful idea and comments. Thanks.
>
> Before I send the email, I have make it happen in real world but need more deep testing.
>
> Here are new changes and idea for that protocol based on the idea and comments, welcome your input.
>
> 1) Unique operation issue
> Given that one client has two more threads to do mode setting on the same output at the same time, how to identify what response (done event) is belong to one or another request when they want to get response?
>
> This is a design flaw in the first version of randr protocol.
>
> The solution is to use the wayland/weston mechanism, every request will generate a resource which be used to send done event to the owner who start it. Owner could set the listener on that and keep tuning on the response event.
>
> For example
> In client:
> randr_transform = wl_randr_set_transform(randr.randr,wayland_output,argument.transform);
>
> /* Here will will add listen callback to get the response for this unique request */
> wl_randr_add_listener(randr_transform, &randr_transform_listener, &randr);
>
> In compositor:
> randr_resource = wl_resource_create(client,&wl_randr_interface,1, action);
> wl_randr_send_action_done(randr_resource, 1<<WL_RANDR_ACTION_TRANSFORM, ret, action);
> wl_resource_destroy(randr_resource);
>
> 2) Security and mess up issue
> Will take randr protocol implementation as a module or plugin. This will keep compositor clear and avoid messing up in compositor.c. Also it is will be fine for compositor when this could be public.
> The security should be a general issue for wayland instead of for randr protocol only. Take randr protocol as a module for user to determine if they want to public randr interface for their clients. Once security mechanism is built up in wayland, randr could adopt the mechanism to enhance the security of randr protocol.
>
> weston --tty=1 --modules=wrandr.so
> or set it in weston.ini like that
> [core]
> modules=wrandr.so
>
> 3) Group randr operations
> After talking with PQ, in order to avoid glitches, group operation is needed. However, if operate on two outputs more at one time, it will bring more issues which could not control. In this randr design, will not provide group operation on multiple outputs. We provide atomic operation on one output, multi outputs operation logic are left to designer/developers. Group operation on one output will be designed. For example, you can set mode, scale, and transform at one time with one randr request.
>
> 4) Configuration interface
> Weston randr protocol will be taken as configuration interface for output mode setting in wayland. So the permission for that will be strictly under the control. Before security mechanism is ready, randr module will be designed for compositor as a choice. It is just a loadable module or plugin for special compositors. User will take the decision if start it when boot up compositor as a module.
>
> 5) mode setting parameters control
> Mode and output will be under the control. User could not randomly to set their mode. They have to select the available modes and outputs provided by compositor. Don't allow random mode setting. The mode and output information could be provided by weston-randr apps or wl_output interface.

I don't think that allowing to set only announced modes is a good idea. 
The RDP compositor is a good example where you can't know the supported 
modes (as nearly all modes can be supported).

IIRC depending on the drivers, drm can also set arbitrary modes.

[...]

Apart from that I think we really have to find a way to offer randr like 
interface, this leads to the security requirements that have been talked 
extensively here.

Haven't you noticed that most recent talks on big subjects always end 
with "but what about security ?"

Regards

-- 
David FORT
website: http://www.hardening-consulting.com/