From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=3.4.3 Received: by atuin.qyliss.net (Postfix, from userid 496) id 5BBD41D492; Mon, 13 Jul 2020 00:01:54 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id F227E1D423; Mon, 13 Jul 2020 00:01:35 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 0C44F1D3D0; Mon, 13 Jul 2020 00:01:34 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by atuin.qyliss.net (Postfix) with ESMTPS id 35BB41D3CE; Mon, 13 Jul 2020 00:01:30 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B0A4E5C00B6; Sun, 12 Jul 2020 20:01:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 12 Jul 2020 20:01:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:cc:subject:date:message-id:mime-version:content-type; s= fm3; bh=e7PYKlgFPdrBy5vnvqSo6oPYbtsxGz0jCQzziRuw0G0=; b=HEpM9k4v kdOviVXqjT+8urluJKm4rBQWbMZjfteLoYF2pv/C1yznsaQjkc0p/Xyr/JkhEOlM CGNhhodxQ++97KKjo89GqgqcHLmumihGH9tC2OeXnw9w8dZeyi1NyUzc30fgLR/r +A5tjpsFiXFfV2OsRblhkVot0K1qemK0oi9gHBv+Sv2Tgtn5fajUWLcAg/Xr/Owv JmtnzosvZQIWHcypx1P/2guz6xwaWAuS7SCcdyg7dsYHNn/jo3hrCh7g4nPZzMEg +jW4B23o+pjX/xVvFpSvUsGm/scYk5HJKheLGI0cbL7RFnds3MO7nI3M6EEUpz3S OpXq2XRPVWQdhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=e7PYKlgFPdrBy5vnvqSo6oPYbtsxG z0jCQzziRuw0G0=; b=BHEmX/OVNzlqdhqQX/n2+PDxIYtpfXB2/KPHKgCBEg8Nx eooXPvw047MttI7MoIEArvDkIPLjWwe4dOUHpMd8G/uQ4BK2ZMBaVqk91ROQb3yn BD4c857C+GDIWp51XT89otNci19gquDH+qtaqDznb/x9WwKiTz+Kxf3GldB02eJ7 eWre+ws800wxnDo1ffRwyCH7AePmhV0OAeV8RYw6zjtgyLc5UmqGyCadNBL6c+3T dxcrErEMQHZgKq2h7B3lH/ziJrOi8Iat99pXWRQEepQVV8YYiEJ25XZlXnAQFJLq ljlZYSBGd449qHKi72+bdZKdqS8MqaRpzMkeyx2rQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdejgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkgggtsehgtderredttddtnecuhfhrohhmpeetlhihshhsrgcutfho shhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpeevleehkeduke evheeggfejgffgieeiueethfehieeivdeugeeigeejhfehhfdtveenucffohhmrghinhep shhpvggtthhruhhmqdhoshdrohhrghdpohiilhgrsghsrdhorhhgpdhorghsihhsqdhoph gvnhdrohhrghenucfkphepgeeirdektddrudegvddrkeefnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrgdrihhs X-ME-Proxy: Received: from x220.qyliss.net (p2e508e53.dip0.t-ipconnect.de [46.80.142.83]) by mail.messagingengine.com (Postfix) with ESMTPA id B6C393060067; Sun, 12 Jul 2020 20:01:27 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 798A18B4; Mon, 13 Jul 2020 00:01:26 +0000 (UTC) From: Alyssa Ross To: discuss@spectrum-os.org, devel@spectrum-os.org Subject: This Week in Spectrum, Date: Mon, 13 Jul 2020 00:01:17 +0000 Message-ID: <87pn902she.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: TONFMUHCZSI7SFZFZPEM66ZJVBNLPZK7 X-Message-ID-Hash: TONFMUHCZSI7SFZFZPEM66ZJVBNLPZK7 X-MailFrom: hi@alyssa.is 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; suspicious-header CC: Cole Helbling X-Mailman-Version: 3.3.1 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain After I got an isolated Wayland compositor working last week, I wasn't really sure what to do next -- this was a big piece of work that I'd been very focused on for a while. The funding milestone I'm closest to is to do with implementing hardware isolation, which the Wayland work was a part of, so I decided to keep going with that, and explore other types of isolation. More on that in a bit. Wayland ------- Posted my patch for virtio_wl display socket support in libwayland-server[1]. This is what allows it to run in a VM, and receive connections from clients in other VMs. The patch description is very extensive, so I recommend reading it for more detail if you're interested. It introduces a libvirtio_wl, which should also be useful for porting other programs that we might want to communicate with across a VM boundary, if they are written with normal Unix sockets in mind (including transferring file descriptors). This is the evolution of code I previously had put in wlroots, moved to Wayland for convenience. If it ever acquires another user (or maybe even if it doesn't) it might make sense to make it its own package, since virtio_wl is useful even if Wayland isn't involved. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/SJ0PR03MB5581479F3388047230F36EB3B3670@SJ0PR03MB5581.namprd03.prod.outlook.com/T/#t crosvm ------ I pushed all my crosvm changes to get the isolated compositor working to the work-in-progress "interguest" branch[2]. Remember, I only got it working last week right before I needed to start writing the TWiS email, so I hadn't even done that yet! I also posted some patches[3] to the list to fix a bug in my previous crosvm deadlock fix, and to improve some related documentation. As usual, these were kindly reviewed by Cole. Next, I turned my attention to other forms of hardware isolation. Wayland was a bit special, because despite crosvm including a virtual "Wayland device", it's not really hardware, and so it required an approach to isolation that will be quite different to other crosvm virtual devices. My hope is that other virtual devices should all be substantially similar to each other. The basic idea for actual hardware isolation is that rather than having drivers in the host kernel for USB, network devices, etc. those will be exposed to dedicated VMs as virtual PCI devices. This should substantially reduce host kernel attack surface. crosvm virtual devices will be run in these device VMs, and communicate over virtio with application VMs as normal. This will require implementing in crosvm a virtio proxy device, than allows for the crosvm running an application VM to forward virtio communication to the virtual device running in userspace in the driver VM. (The reason devices aren't attached to application VMs directly but run in seperate device VMs is that hardware is probably not going to be very happy if multiple kernels are trying to talk to it at the same time. Additionally, this indirection means that application VMs only have to use the one virtio driver for that device category, rather than any of the hundreds of drivers for different hardware in that category. If one of those drivers had a vulnerability, this should help to contain it to the device VM.) So I started writing this virtio proxy. The basic idea is to copy virtio buffers from application VM guest memory into memory that can be shared with the userspace virtual device in the device VM. I can't find any prior art on this (which is not unusual -- not many systems isolate drivers in this way), so this has required a lot of looking back at the virtio paper[4] and spec[5] to make sure I understand what to do here. As I write this, the next problem to solve is integrating some sort of memory allocator that can manage buffer allocations in the shared memory that the virtual device looks at. This is a new area for me that I'd appreciate advice on if anybody can give it -- think of it like, I have a memfd, mmaped into my process, and I would like to dynamically allocate and release memory buffers of dynamic sizes in that region. I'm sure there's a library I'll be able to plug in for this. [2]: https://spectrum-os.org/git/crosvm/?h=interguest [3]: https://spectrum-os.org/lists/archives/spectrum-devel/SJ0PR03MB55819DE7E13B7AFC97321C3BB3670@SJ0PR03MB5581.namprd03.prod.outlook.com/T/#t [4]: https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf [5]: https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html As usual, big thank you to Cole for reviewing patches, and for finding room for improvement even in languages/areas he isn't familiar with. It feels nice to have done some thinking about the project at a slightly higher level than I have been recently, and to know where I am on the way to the next milestone. Having taken a lot of time away from the milestone list this year to work on fundamentals, it's good to feel like I'm getting back on track. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl8LpE4ACgkQ+dvtSFmy ccDVGQ/+NNK+Jbdd5drrmfaK2r9Cx8xF34N/+lLhM1SdHhSedmP9pj4D2mNYQQKQ UmKw++uj5D9VPTsIEHUYeSsQ7QOWpkIEgM6kZWSVVIOKfx00rbf4eO4pJlbCyEQU M9cupd6BUBOtBT+Vm38snlQYmuIa+Oau3jyp3/LspgvYhw2gxcgVsw9iFmWRE5OP bPb7n59wIuqmF3O9mnYlHFYcNhsafTEZe+8HPgAguPDaoyYylffidYJfcYwmnUWH HpvbUMAi/xrBijUTpmNZKCYOepkdFVh1Dil9eu4F5q27UzrDBW0yPEkRyfM7NQr7 Zw1Y89xcvkAhcKmPAo75fJ3MvfNwGC57n7ZPhvYfFIxz3TWSJUImJPKi8Rnvo3+w M+xg/slQn3NboQxHtrZLT7yX20mvFB2GJ5uMIfNBHO6EEUyX4KzEiwgjxPjs/jqW U7fvUX53qbqUcyP/rJWWqZYsSfUYl6WC9CM6YHs2baZMIbeMAWDiKqm/Nh7eQeI2 q/zuUA1r1zUGITUnm+YqKQ6L0WiEv97Qbpi/tc+BxszCitPBmt+TtOZpMrQbf3Qo cRFUz4XbAVqFD7qk+IBSszgmyWvLHlenoYyqAJXNQ7CoSCAE1mY2g9PftyCA6i4o X9jd9WQV4B9Qr9NXm8fNJlumEmdnrSPqZRFcaCrEuRNEgLFysCI= =qft9 -----END PGP SIGNATURE----- --=-=-=--