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.5 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 A863D73CA; Sat, 13 Jun 2020 11:20:17 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 41DF873A2; Sat, 13 Jun 2020 11:20:02 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id BE2407399; Sat, 13 Jun 2020 11:19:56 +0000 (UTC) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by atuin.qyliss.net (Postfix) with ESMTPS id 800F6733A for ; Sat, 13 Jun 2020 11:19:50 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 331E0399; Sat, 13 Jun 2020 07:19:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 13 Jun 2020 07:19:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=fm3; bh=UMfawcXHaPqQ2E5nRa+9hjT2L2 934bqrtbY01uKoTas=; b=dS2nzKqfkMY7HXvOGTuMgFqDMJQOQB2fjdR2bpwMKi DoB9EO0TsHxH2gyh8A4EuwHG2INHbS8SbPQtX+70IffD79sqquFOQrXSfraZa5lQ fQzCigAtVXli5P+1P/pIA2g6gzOwGsKxvHnWGsqjWyaYVpNmLyFlD+TyUHLpr1y4 pU39aGnyBVgKlrkbG26VJGByc2ccnI9/BuegpYRYo1chMxqRqHQPv5y4srIhzPTQ ckVCpuG+38EWuW7PFFAEkxOAjqXAMIH81wikPkCoIrjqSvv3M543xxpXx6Kd+ZEP BXO701IrtZ0oJ5uCLhERHLMdPorAF/3Jse5QaUgXHVvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=UMfawc XHaPqQ2E5nRa+9hjT2L2934bqrtbY01uKoTas=; b=oWdnFI3gMe3DSAnxvCwuoV i6qKeNdRnGoPZG848roWqlG0l66I/FusIAg1SvHdSuqXwbCs1+9KBZ7dOl0h0jk1 SwIGXyB1TNOI2MAwoe9oe6JKvSXDW5wkOSI3hLPQL+tG59SgzoSy8lII8mkiXL4Q 2lTD6NWXfdg7W1b/xe8N3sAGyV14KjGwht9tNCrGt7YkS1aJHJtGR7RA5KaS1aGu 5qQynUuTSvsJnV+GVpqqGpfiJgiKI13kgP/KCH59bUhIf+9Y3xsXAlVKih04P2A4 vRMO9TNyfDleXe5l4FbUlsEC4DFALcbLSFqXyww0XnvIzqsZmfbUqA9wkESUnnFw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeifedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgr ucftohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepkefgve ejteefgeethfehkeekjeeihffgjeeiffelvdefhefhvdekvdefgeelgeeunecuffhomhgr ihhnpehgihhtlhgrsgdrihhopdhlfihnrdhnvghtpdgrlhihshhsrgdrihhspdhnvggtlh grsgdrvghunecukfhppeekgedrudekgedrvdefledruddutdenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhihesrghlhihsshgrrdhish X-ME-Proxy: Received: from x220.qyliss.net (p54b8ef6e.dip0.t-ipconnect.de [84.184.239.110]) by mail.messagingengine.com (Postfix) with ESMTPA id CB1903060F09; Sat, 13 Jun 2020 07:19:46 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id 8B65355B; Sat, 13 Jun 2020 11:19:45 +0000 (UTC) From: Alyssa Ross To: =?utf-8?Q?Micha=C5=82?= "rysiek" =?utf-8?Q?Wo=C5=BAniak?= , infokiller =?utf-8?Q?=E2=80=8B?= Subject: Re: Comparison to Qubes OS In-Reply-To: <6017c296-7bcf-3f11-8410-9380ad4ee2a6@hackerspace.pl> References: <30b730a5-773e-41e8-e94e-5abec26018a4@hackerspace.pl> <159196284966.15924.16876974660333010445@localhost> <6017c296-7bcf-3f11-8410-9380ad4ee2a6@hackerspace.pl> Date: Sat, 13 Jun 2020 11:19:43 +0000 Message-ID: <87tuzfciwg.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: T6IVBZFAF6DZOGVO6673UTPSZDJFOTF4 X-Message-ID-Hash: T6IVBZFAF6DZOGVO6673UTPSZDJFOTF4 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: discuss@spectrum-os.org 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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Micha=C5=82 "rysiek" Wo=C5=BAniak writes: > On 6/12/20 11:54 AM, infokiller wrote: >> Micha=C5=82 "rysiek" Wo=C5=BAniak wrote: >>> Running virtual machines is extremely resource-intensive, there's no wa= y around it. >> >> But if the issues stem from running VMs (and not switching from Xen), th= ey won't be resolved with Spectrum's current design, right? > > Right you are about the performance issues *I think*. I would however exp= ect > hardware compatibility to improve with kvm. > > But I'd love somebody more knowledgeable to shed some light here. I am by no means a Xen expert (and so the following could be totally wrong, and I would appreciate being corrected), but my understanding is that Linux is likely to provide better power management than Xen due to being better optimised, and not being as focused as Xen on large data center deployments. Additionally, there are interesting Linux virtualization features that may allow for reduced overall hardware requirements by securely sharing resources between VMs. For example, it may be possible to share identical read-only memory pages between VMs. There's not necessarily any reason that running identical copies of Firefox in two different VMs should require two copies of Firefox in host memory. The most promising application of this principle at the moment in virtio-fs[1][2], which supports this page sharing. DAX[3] may also be of interest. Of course, there will be security considerations when deciding whether to adopt these systems, but the point is that this sort of development just isn't happening with Xen. It's all focused on the KVM ecosystem. [1]: https://virtio-fs.gitlab.io/ [2]: https://lwn.net/Articles/788333/ [3]: https://lwn.net/Articles/610174/ Hardware compatibility should certainly be better with KVM. Linux has extremely diverse hardware support, and a much larger user base than Xen, especially on consumer hardware. I'd be confident in saying most relatively recent consumer PC hardware will support Linux reasonably well (a notable exception of course being Nvidea GPUs), and I'd be surprised if Xen worked well on anywhere near as many devices. >>> I feel one needs to be an expert to use QubesOS, but a regular user (wi= th some >>> basic training) can use a Mint or Ubuntu-based system. And I think it m= akes a >>> lot of sense to offer a middle ground. >> >> Agreed, but I think the current design of Spectrum may improve Qubes' ha= rdware issues, but not the other issues the doc mentions. Possibly switchin= g to containers (which something like gVisor) may solve some of the other i= ssues of Qubes, though that would further degrade security. > > Fun fact, containers were in fact initially considered. :-) > > Here's a good blogpost from Alyssa on why move to kvm, and the advantages= of it > over Xen: https://alyssa.is/back-from-cccamp-2019/ Indeed, Spectrum was originally conceived as a Qubes-style operating system that used containers instead of VMs. The reason the focus shifted from containers to KVM is that as I researched the topic, I became less confident in the ability of containers to offer meaningful security, and learned that the overhead of VMs doesn't have to be as big as I thought. Of particular inspiration was "My VM is Ligther (and Faster) than your Container"[4], which demonstrates Xen-based virtual machines with resource requirements roughly equivalent to containers. I also think that Nix might put Spectrum in a unique position to provide lightweight virtual machines. Conventionally, VMs run full-featured Linux distributions, with all the memory and disk requirements that entails. It's not usually feasible to build tailored VM images running only the software that is critical to the task of the VM. With Nix, however, it suddenly is. A big part of the appeal of containers, I think, is that the tooling makes it easy to create small images focused on a single task. VM tooling has never really provided this. It's a sort of vicious cycle of assuming VMs are heavy and therefore it doesn't make sense to have a VM dedicated to a single task, which means that tooling for creating such a VM isn't developed, which means that VMs stay heavy. [4]: http://cnp.neclab.eu/projects/lightvm/lightvm.pdf --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl7ktk8ACgkQ+dvtSFmy ccC5MA//dqyrHXwIaAPD8ujwykXBYDZO8F4Vrmq3YxvKDssp7z7sip9IV3M6eUt7 rqDWj1aDaoFo8KoLtyUCb6ZmHqDRU37FCzM8DB7Sb5QXFgEoq/F5UFB2u2MVdCmg 45zZ5qDtN1pF/3YiEkXb8t/5Px9O5tAE1UiFgEFQIKvjZa4pL0JuUean3wWspfgh v0Ndz5YJ/5vSMFir7WzAWxYDRR2g64Xy0w6BdjcLF5Z6o+EMoa3Jme5bB6bfJ+3T vlxLtOjJSW2W0Jn5HQmsH43BWbsF8NlcW1FNBxBBJoBrKd6Qg3iw9PUaAMWJ64ov I2m6R3RhPe4lLwfCaPPNBrA0EArIhGbmaAPWl8ogQ2sj9ku2RtuyhpW0W1o1mFQh LLmaxD2H38JEMzdg0HTHh9BfwrWjB+IzEpmitu88x+NEcfe6ROM1IqwJLPGZS0lO Fm68bK/ZEcGZtHCPEDIwPaejJbaR2eQvtG2uiWOx6JToJGNF9O4RO6fso8SD/PY6 BiKyfSGSOhYA0QQJRFaTlwEfYJWGy617pi/Jq1HO0dOV9pWGFycsjFlgMugmHIc/ cQ/QMbDy1oSeJXmqarq+DfW8FdhJ9VrmsJ17pRrGEqzaf4cuhkMaGGhV/aTWW7C4 Ug1MFYxAPZhzma849EYo/laOB22B5OuASyZCfFkoNeCvPeOwZTw= =C8n8 -----END PGP SIGNATURE----- --=-=-=--