Hardening consulting

An overview of the FreeRds backend of weston

Also available in:

Français

I have recently posted a first version for a FreeRds backend for weston, the reference compositor for wayland. In this post, I will talk about that new compositor, if you have already read my post on the FreeRdp compositor you won't be lost.

FreeRds and weston

FreeRds is a work-in-progress project that aims to provide a RDP server using the FreeRDP library. Xrdp was based on rdesktop, you can see FreeRds like its successor but with FreeRDP as the foundation classes.

Here's the architecture of FreeRds with weston providing the content to display:

FreeRDS compositor

FreeRds and the weston backend communicate with a unix socket and a shared memory. The socket is used for commands and the shared memory for the shared framebuffer. FreeRds takes care of all RDP related stuff, and the job of weston is to create the content to display.

At initialization, FreeRds connects on the unix socket created by the FreeRds backend of weston. Follows a negotiation:

  • FreeRds sends the keyboard layout of the RDP peer and the size of the desktop ;
  • weston creates a seat with a xkb file corresponding to the remote keyboard layout ;
  • weston creates a shared memory segment and sends the id through a SharedFramebufferInfo packet;
  • FreeRds replies with a vblank packet indicating that the shared framebuffer is available

When a weston client have activity:

  • wayland clients update their surface contents ;
  • weston builds the desktop image composing all the surfaces ;
  • weston updates the damaged region of the shared framebuffer, then it sends a refreshRect packet. Weston will accumulate damaged regions until it receives a VBlank packet from FreeRds ;
  • FreeRds receives the refreshRect packet, it encodes the damaged regions using the appropriate codec (raw, compressed or not, RemoteFx or NsCodec). A VBlank packet is sent to Weston.

Future

The proposed patch is a first shot but is fully functional, some improvements:

  • handle the SUPPRESS_OUTPUT packets: the compositor could be frozen when the RDP peer has disabled frame reception ;
  • handle extended keyboard events: code not implemented yet ;
  • implement a specific wayland protocol that would allow wayland clients to interact with FreeRds. Many interesting things could be done with the RDP channels: clipboard, playing videos on the client-side using the TSMF channel, playing sound, ...

Links

These links will help you to inquiry more on the subject: