From: Michael Raskin <7c6f434c@mail.ru>
To: hi@alyssa.is, discuss@spectrum-os.org
Cc: aaron@ajanse.me, puck@puckipedia.com, talex5@gmail.com
Subject: Re: Proxying Wayland for untrusted clients
Date: Sat, 22 May 2021 22:00:01 +0200 [thread overview]
Message-ID: <E1lkXgG-0004gD-AS.7c6f434c-mail-ru@smtp37.i.mail.ru> (raw)
In-Reply-To: <87eedyznsw.fsf@alyssa.is>
>> Considering how much works fine in Xvnc which kind of lacks half the
>> extensions, and considering that all the bad hardware stuff now needs to
>> be handled in each compositor, it is unclear how much worse it would
>> actually be.
>>
>> So OpenGL-first design sounds like the real reason for all the mess.
>
>What do you mean by bad hardware stuff? Most hardware should be handled
>by KMS and libinput, shouldn't it?
I think there is somehow still some buffer-management code which is not
fully indifferent to the GPU used, and apparently that goes beyond
proprietary drivers. Has it been completely cleaned up for nouveau?
>>>> … unsurprisingly, as these are typically WM teams who are now deprived
>>>> of what Xorg server did for everyone.
>>>
>>>Only the ones that don't use wlroots, I think. wlroots has its own
>>>problems, but in large part those are the problems we're trying to
>>>mitigate here.
>>
>> Yes, but it seems memory-unsafe even by the «careful C» standards, and
>> it seems to crash noticeably often with reasonably well-behaved clients,
>> so just a protocol compliance filter would not be enough.
>
>My experience with wlroots has been that when it crashes, it's because
>of quirks with monitor state and stuff, not anything from the Wayland
>protocol. Have you had a different experience?
I still avoid Wayland because it would be too much of a drop in features
compared to my X11 setup. I have just checked segmentation fault bugs in
the tracker…
Of course you do not get many crashes due to Wayland protocol quirks, if
only because your applications are not going out of their way to crash
wl_roots.
>Another thing the proxy would be really cool for that I didn't mention
>before is debugging. Potentially you could even record and replay
>Wayland messages, which would help with any crash that was from Wayland.
Indeed. Then if we have a good proxy codebase, yet another proxy might
even help some («good, clean») applications shrug off a compositor
crash.
>>>Aren't shared memory buffers usually handed out by the compositor, to
>>>the client? IIRC this was the reason virtio wayland can work when it
>>>only supports shared memory that was allocated by the host.
>>
>> Looks like for wl_shm the client creates and shm object and sends FD to
>> the server, then both sides mmap from there. Given that one could cook
>> an FD with approximately arbitrary combination of properties, I guess
>> some care should be taken about this, too.
>
>Hmm, yes, looks like you're right. I wonder how virtio wayland can work
>the way it does, then... But yes, that is something we could validate.
Wait, I remember you explaining a pretty complicated dance to make some
buffer host-allocated from the VM point of view but client-managed from
the Wayland point of view. Am I misremembering?
>>>>>no support in the Wayland protocol. It could even be used to modify
>>>>>surfaces, to implement things like Qubes-style unspoofable coloured
>>>>>window borders.
>>>>
>>>> I am tempted to ask how close it will be to providing a socket for WM
>>>> and window decorator implementation (with some suitably limited
>>>> compositor as the backend behind the proxy).
>>>>
>>>> (So basically, defining a scope will be hard, and defining a scope in
>>>> a usefully extensible way might be even harder)
>>>
>>>I don't understand this point. Can you rephrase / expand?
>>
>> Well, you start describing a proxy that is basically «only valid
>> messages pass» and that's it, then add that it could also implement some
>> more functionality. Then you say plugins for policy-heavy functionality.
>> (I guess at that point the natural next step is a socket so that
>> safety-handling and user logic could be in different processes)
>>
>> This sounds like a recipe for scope creep, although it might also be
>> good as a single well-vetted Thing being safety-critical and a lot of
>> policy decisions being pushed to restartable and
>> functionality-restricted separate processes is actually better than the
>> current recommended approach to Wayland compositors.
>>
>> If you want to try pushing the project to freedesktop, I suspect it is
>> a good idea to define how much scope you want to include into the pitch.
>> Although apparently they don't have any objections to hosting software
>> with heavy scope creep, when reaching for a high profile, it is a good
>> idea to set internal expectations before having to manage external ones.
>
>I actually think the scope is fairly limited?
>
>1. Receive request
>2. Validate request
This alone could become interesting really quickly.
>3. Asynchronously run request through plugins (you're right that
> external processes are probably a better idea, although I worry about
> complexity and performance).
And then it all depends on what we want the plugins and external
processes to do, as this functionality needs interfaces.
(Re: performance — I guess «simple but high-volume» and «complicated but
with small request and response» need to be separated, policy vs.
mechanism, and all that)
>4. Forward request to compositor
Re-serialise more than forward, I really hope.
next prev parent reply other threads:[~2021-05-22 19:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-22 13:05 Alyssa Ross
2021-05-22 13:45 ` Michael Raskin
2021-05-22 15:08 ` Alyssa Ross
2021-05-22 16:18 ` Michael Raskin
2021-05-22 17:22 ` Alyssa Ross
2021-05-22 18:48 ` Aaron Janse
2021-05-22 20:00 ` Michael Raskin [this message]
2021-05-22 17:13 ` Jean-Philippe Ouellet
2021-05-25 11:40 ` Alyssa Ross
2021-05-22 17:52 Josh DuBois
2021-05-22 20:05 ` Michael Raskin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1lkXgG-0004gD-AS.7c6f434c-mail-ru@smtp37.i.mail.ru \
--to=7c6f434c@mail.ru \
--cc=aaron@ajanse.me \
--cc=discuss@spectrum-os.org \
--cc=hi@alyssa.is \
--cc=puck@puckipedia.com \
--cc=talex5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).