AUG
2
2018
|
Engineering Plasma: Extensions and stability — Present and futureThis week, we have received a number of inquiries into how Plasma extensions, particularly those found on the KDE Store, relate to the stability and safety of a Plasma system. With an engineering focus, this blog hopes to provide answers. Crash Resilience By Process Isolation ![]() Present-day process architecture: Compositor and shell UI are isolated from each other In Plasma, the shell UI and the compositor are isolated into seperate processes ( In a Wayland session, it's kwin that plays host to your application clients and puts them on screen (on X11, both KWin and app are clients to the X Server, providing a further isolation - KWin can crash and restart without impacting apps). Shell UI extension live in the seperate plasmashell process. In the event that a shell extension crashes the shell, this allows it to be restarted without impacting KWin and therefore without impacting your applications. They continue to run undeterred while the shell takes steps to right itself. Beyond crash resilience, putting limits on untrusted code run in the compositor process also has a security dimension. Particularly on Wayland, where one of the design goals is not to allow untrusted code to introspect the windowing system globally. Meanwhile, to make KWin ready to taking over for the X Server in a Wayland session, we significantly upgraded our engineering story - requiring and dramatically raising unit test coverage for KWin and related library code, for one. Process Isolation: Next Steps The architecture discussed above shields applications and the compositor from shell UI extensions, but it doesn't shield the shell. We want to fix that next. ![]() Next: Isolate shell UI and extensions, too — individual or batch processes for extensions The always-stunning David Edmundson has been spearheading several engineering efforts to make the shell itself have a multi-process architecture. Some of this has already quietly been shipping in the Plasma 5.12 LTS release: Likewise, for shell UI extensions, he has been working on top off the library stack we initially built for the Wayland transition to allow them to be run out of process and then get composited into the shell UI. In addition to making the shell far more resilient to extension crashes, this would also create additional security domains for untrusted extension code - we can build on this to sandbox and drop privileges for them. All of this is broadly similar to application architecture improvements pioneered by multi-process web browsers in past years, albeit built squarely to leverage the shared free desktop stack (particularly Wayland and DBus). Unlike what took place in Firefox' project Electrolysis, however, we don't see a need to break extension compatibility in our case. For Plasma's extension API scope, we've always taken a conservative demand-based approach instead of allowing extensions free access to all data and code by default. This is paying dividends now, allowing us new shell architecture options while preserving the known, stable API contract it has with its extensions. David is set to show off the R&D proof of concept we have working now in his talk at this year's Akademy conference, which I can't wait to attend. Be sure to also keep your eyes peeled on his blog, where he will dive deeper into the details of this project after the conference excitement. In Summary Plasma today is architected to prevent shell UI extensions from being able to crash your session and interfere with your apps. We are working to expand on this and prevent extensions from interfering with the shell. In Context One of the broad goals of Plasma 5 has been raising quality. This is a user-driven process. Converting feedback we got during the first generation of Plasma into software, we worked hard to bring Plasma users tangible improvements to speed, resource usage and UI polish (this is by no means over, either). We also already implemented a LTS release process to improve our support story. Dove-tailing with the KDE community's Goals, climbing higher on the ladder of safety and security is one of our immediate next ones. Increasing process isolation in Plasma and achieving state of the art crash resilience and sandboxing, a likely first on the desktop, is a concrete engineering expression of this aim. Sounds interesting? If you want to be part of a team and a community that keeps pushing the desktop (and not just the desktop) forward in the days to come, join us in one of our channels. Of course: ![]() |
![]() |
Comments
Does it mean, that the bug
Does it mean, that the bug #155543, which I have filled in over 10 years ago and which was rejected as INVALID - is finally going to be properly addressed?
Let's put it this way:
Let's put it this way: Definitely your ticket falls into the scope of what the blog and the multi-process R&D is about.
Resilient Desktop
Have you considered the work from the developers of Arcan? Particularly Crash Resilient Wayland Compositing - it seems to me that that what you describe here as "state of the art crash resilience and sandboxing" is just what they demoed last year, they even go so far as to process separate and seccomp the processing of each individual wayland client.
Sounds very interesting!
Sounds very interesting! After a quick look, it's quite different but related in spirit (it doesn't cover dealing with the extension API, since it's about regular clients, and is about avoiding the compositor as single point of failure, not splitting up a shell app) - definitely something to look at and learn from, anyways.