From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.5 Received: by atuin.qyliss.net (Postfix, from userid 496) id 24234135FA; Sat, 22 May 2021 19:53:26 +0000 (UTC) Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 9E9EC135D1; Sat, 22 May 2021 19:53:13 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 90E34135C6; Sat, 22 May 2021 19:53:11 +0000 (UTC) Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [94.100.177.97]) by atuin.qyliss.net (Postfix) with ESMTPS id 6F34E13655 for ; Sat, 22 May 2021 19:53:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail3; h=Message-Id:Content-Transfer-Encoding:Content-type:Mime-Version:REFERENCES:IN-REPLY-TO:Reply-To:Subject:Cc:To:From:Date:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=zN29/mDaeo1Zo59QYCtH/qpo60EpKKuAXy24+NHAZbU=; b=c72oGYTxQLReKrwaX+d1uU92bvDO1k92UkMS2R3g5KQHaJKmP80D0uNJ8lEznyjkQ0IF6WN40mefSKRsahWR46E1FkOmRDKeeIX9trGtOCXqXXpv/gkJhenmyEMAeYQYyUs6LdC9Dtoa/imh5xR1mutynm5qhB3NzIiCrX3qIjE=; Received: by smtp37.i.mail.ru with esmtpa (envelope-from <7c6f434c@mail.ru>) id 1lkXgG-0004gD-AS; Sat, 22 May 2021 22:53:05 +0300 Date: Sat, 22 May 2021 22:00:01 +0200 From: Michael Raskin <7c6f434c@mail.ru> To: hi@alyssa.is, discuss@spectrum-os.org Subject: Re: Proxying Wayland for untrusted clients X-Mailer: cl-smtp (SBCL 2.1.2.nixos) IN-REPLY-TO: <87eedyznsw.fsf@alyssa.is> REFERENCES: (<87eedyznsw.fsf@alyssa.is> . <87eedyznsw.fsf@alyssa.is> <87h7iuztz4.fsf@alyssa.is> <87h7iuztz4.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> <8735ueudel.fsf@alyssa.is> ) Mime-Version: 1.0 Content-type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-Id: Authentication-Results: smtp37.i.mail.ru; auth=pass smtp.auth=7c6f434c@mail.ru smtp.mailfrom=7c6f434c@mail.ru X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD91B019B01C53E51AFA94C0B24B2C939D4C80F0683D6F6F7C600894C459B0CD1B99E5AF2F1E5B9506767A2D4CEDAB9FE6855A2B6AD6949F4E500FFB266B5ED13F5 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7EED5D2FAB4CEB1EDEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063745D431239A8C7DA08638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8B1E4262EB37900B6A23FD089A72DFD32117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18E5D25F19253116ADD2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE140C956E756FBB7AC5236E9430F51F07D8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE3AD74539164518AE5302FCEF25BFAB345C4224003CC836476EA7A3FFF5B025636E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F7900637B5EAED125435346EEFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A2368A440D3B0F6089093C9A16E5BC824A2A04A2ABAA09D25379311020FFC8D4ADA8699EC71AD8E966D485D0241E2258C4 X-C1DE0DAB: 0D63561A33F958A555D050BEBA5E1C6259892CC849686B1BD33DBA0F6BE7A0AED59269BC5F550898DBE8DEE28BC9005C59FC9C0A2654C55EE87EB34E062A15A47BCC32E49D76C4CC2F8D89FC5850081E886A5961035A09600383DAD389E261318FB05168BE4CE3AF X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D343536C6A4332D8B8ACA16666F8DEB34DCBD976C0F564EB2014BCC07589F25C866B0E64B9AA561657D1D7E09C32AA3244CC6FC50024DF5AB55A4F26DAE7A20827BFE8DA44ABE2443F783B48618A63566E0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojzUqYFPhUCf9I/Fwmre7K0g== X-Mailru-Sender: 35B75D2CAA45F3130BB9478DFF6488F258CB1731D9543C709078AD8A723A3E5B3FB95AC75C549920286CF1FB17F948F1E66B5C1DBFD5D09D5BDABB69D8D2C502C003600472B6CB9B67EA787935ED9F1B X-Mras: Ok Message-ID-Hash: 2IOTSNKLENXZGXIJZEY6EBVCNZ5SZ66E X-Message-ID-Hash: 2IOTSNKLENXZGXIJZEY6EBVCNZ5SZ66E X-MailFrom: 7c6f434c@mail.ru X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: aaron@ajanse.me, puck@puckipedia.com, talex5@gmail.com X-Mailman-Version: 3.3.4 Precedence: list Reply-To: 7c6f434c@mail.ru List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: >> Considering how much works fine in Xvnc which kind of lacks half the >> extensions, and considering that all the bad hardware stuff now needs t= o >> be handled in each compositor, it is unclear how much worse it would=20 >> 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=20 fully indifferent to the GPU used, and apparently that goes beyond=20 proprietary drivers. Has it been completely cleaned up for nouveau? >>>> =E2=80=A6 unsurprisingly, as these are typically WM teams who are now deprive= d >>>> 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 =C2=ABcareful C=C2=BB 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=20 compared to my X11 setup. I have just checked segmentation fault bugs in the tracker=E2=80=A6 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=20 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=20 even help some (=C2=ABgood, clean=C2=BB) applications shrug off a compositor=20 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=20= >> 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=20 >>>> 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 =C2=ABonly valid=20 >> messages pass=C2=BB and that's it, then add that it could also implement som= e >> 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=20 >> policy decisions being pushed to restartable and=20 >> 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=20= >> 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=20 processes to do, as this functionality needs interfaces. (Re: performance =E2=80=94 I guess =C2=ABsimple but high-volume=C2=BB and =C2=ABcomplicated but with small request and response=C2=BB need to be separated, policy vs.=20 mechanism, and all that) >4. Forward request to compositor Re-serialise more than forward, I really hope.