Next major release of Qubes OS

[John Smiley]

I've read various things that hint at some major changes coming to Qubes OS and so I have been holding off continuing to invest my time in diving deep into the current implementation.  In particular, I've seen indications that Qubes is migrating away from Xen and toward KVM.  Xen seems to be "mostly dead" as Billy Crystal would say and many services either already have or are well on their way to replacing it with KVM.  There also seems to be movement toward more lightweight solutions for isolating processes than virtual machines, as seen in Subgraph/Citadel/Oz (which oddly have not seen much attention in recent years if GitHub is anything to go by).

I'm sure I'm not alone when I say I would like to hear from the Qubes developers what the roadmap looks like in this regard.  Some of us would probably be more inclined to devote our time to assisting you if we knew such projects were in the works.

Please share with us what you can.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 05, 2019 at 04:27:33PM -0800, John Smiley wrote:
> I've read various things that hint at some major changes coming to Qubes OS
> and so I have been holding off continuing to invest my time in diving deep
> into the current implementation. In particular, I've seen indications that
> Qubes is migrating away from Xen and toward KVM.

This is very much not true. We are considering adding support for KVM,
but Xen isn't going away anytime soon.

> Xen seems to be "mostly
> dead" as Billy Crystal would say and many services either already have or
> are well on their way to replacing it with KVM.

Well, yes and no, mostly no. There are some services that are starting
to use KVM, but the same applies to Xen. I think you mostly have Amazon in
mind, which indeed started to have some VMs on KVM. On the other
hand, this year their contributions to open source Xen have very much
intensified, including development of many new features. Besides that,
Xen is getting popularity in automotive sector, and there are ongoing
efforts for safety certification. Yet another thing that is totally
unrealistic with KVM architecture.

You may want to look at Xen Summit recap:
https://xenproject.org/2019/07/29/xen-project-developer-and-design-summit-recap/

> There also seems to be
> movement toward more lightweight solutions for isolating processes than
> virtual machines, as seen in Subgraph/Citadel/Oz (which oddly have not seen
> much attention in recent years if GitHub is anything to go by).

Well, people are using containers for a long time already. While indeed
it is much more lightweight, this approach have also severe limits -
everything running on the same (huge, monolithic) kernel. Leaving alone
much bigger attack surface of all the syscalls (which you can slightly
mitigate with seccomp and similar techniques), this makes it impossible
to isolate kernel components from each other. Including drivers, network
stack etc.

> I'm sure I'm not alone when I say I would like to hear from the Qubes
> developers what the roadmap looks like in this regard. Some of us would
> probably be more inclined to devote our time to assisting you if we knew
> such projects were in the works.

The current plan for major features of Qubes OS 4.1 is:
- experimental GUI VM and Audio VM (very limited and not yet ready for
daily usage)
- new qrexec policy format and significant qrexec performance
improvements
- major improvement for UEFI compatibility (grub2-efi is back, some
changes in Xen to make it more uniform with Linux)
- as usual, updated templates and dom0 (but still Fedora)

You can also see draft release notes:
https://github.com/QubesOS/qubes-doc/pull/828/files

I'd say the above is 80-90% done. There is a possibility the first
release candidate will be already this month.

In the meantime we're also working on a reliable GPU passthrough with
focus on Intel, without sacrificing security much (specifically, without
running unsandboxed qemu), but it's not going to be part of R4.1 yet.
Having that, and more tested and improved GUI VM integration would allow
to make it default and greatly reduce size of dom0.

With such reduced dom0, we can consider another distribution there. It
hasn't been decided on a specific one yet, but I'm strongly considering
Yocto/OpenEmbedded - for its ability to build small system. Maybe even
small enough to fit in RAM, which would allow running dom0 disk-less,
opening a path to many cool features like storage domain. But it would
also allow easier code sharing with OpenXT project.
Anyway, at this point, user would not directly interact with dom0, so it
will be very much transparent (i.e. even if that would be Debian - which
is another option - you won't have a chance to call apt-get there). What
user will interact with, is a GUI VM, which would be much more flexible
in distribution choice (basically - whatever template we currently
support).

But also, with GUI VM separated from all-powerful dom0, we can consider
some options for video acceleration access for selected VMs. There are
various paths here to be explored, with different hardware requirements,
and different security properties. But that's for late 2020 at the earliest.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3pvCsACgkQ24/THMrX
1yxVKggAgKOBn/KcV+aZELbKDRHEXDpIqZXaUBe0Xr2kDeu0QtprBG8HgCLax2GJ
4szkmBXa7LD7NHMb6Ee8wzTp/C3VTF/xqfpvXrveOQsgzNLyoitxWzDhOrSKABQq
DHFUrNNdCHqKpn6WGcqC2qEfdHM1rR5UdzzJIMyXIiSIYfJ6PdsJoW69DWw8iLeG
0U3/hq58bBR7j0Ymlw5Y/7liGZSD6Fj44CC21q/M1gq3g3rtgPbgN5r3mhTAAlNL
boQUmkkfy1GJ4Kxo/sYhpauLRxWnvQFhdWLfRyka+3W91nqK3qVUuALeaUaDcTQ3
jk0/tT1a2OkpKviWd2qv7dUIpjU4Yg==
=D6Lu
-----END PGP SIGNATURE-----

[Demi M. Obenour]

On 2019-12-05 21:25, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 05, 2019 at 04:27:33PM -0800, John Smiley wrote:
>> I've read various things that hint at some major changes coming to Qubes OS
>> and so I have been holding off continuing to invest my time in diving deep
>> into the current implementation. In particular, I've seen indications that
>> Qubes is migrating away from Xen and toward KVM.
>
> This is very much not true. We are considering adding support for KVM,
> but Xen isn't going away anytime soon.
>
>> Xen seems to be "mostly
>> dead" as Billy Crystal would say and many services either already have or
>> are well on their way to replacing it with KVM.
>
> Well, yes and no, mostly no. There are some services that are starting
> to use KVM, but the same applies to Xen. I think you mostly have Amazon in
> mind, which indeed started to have some VMs on KVM. On the other
> hand, this year their contributions to open source Xen have very much
> intensified, including development of many new features. Besides that,
> Xen is getting popularity in automotive sector, and there are ongoing
> efforts for safety certification. Yet another thing that is totally
> unrealistic with KVM architecture.

Sadly, the safety certification is focused on ARM, but I would love
to see this on x86 as well.

> You may want to look at Xen Summit recap:
> https://xenproject.org/2019/07/29/xen-project-developer-and-design-summit-recap/
>
>> There also seems to be
>> movement toward more lightweight solutions for isolating processes than
>> virtual machines, as seen in Subgraph/Citadel/Oz (which oddly have not seen
>> much attention in recent years if GitHub is anything to go by).
>
> Well, people are using containers for a long time already. While indeed
> it is much more lightweight, this approach have also severe limits -
> everything running on the same (huge, monolithic) kernel. Leaving alone
> much bigger attack surface of all the syscalls (which you can slightly
> mitigate with seccomp and similar techniques), this makes it impossible
> to isolate kernel components from each other. Including drivers, network
> stack etc.

Agreed. In some cases, one can get very strong isolation because
only a very small number of syscalls are required, but those cases
are rare for general-purpose software.

>> I'm sure I'm not alone when I say I would like to hear from the Qubes
>> developers what the roadmap looks like in this regard. Some of us would
>> probably be more inclined to devote our time to assisting you if we knew
>> such projects were in the works.
>
> The current plan for major features of Qubes OS 4.1 is:
> - experimental GUI VM and Audio VM (very limited and not yet ready for
> daily usage)
> - new qrexec policy format and significant qrexec performance
> improvements
> - major improvement for UEFI compatibility (grub2-efi is back, some
> changes in Xen to make it more uniform with Linux)
> - as usual, updated templates and dom0 (but still Fedora)

Will UEFI compatibility also include providing UEFI to VMs?

I will work on my socket-based qrexec PR this weekend.

> You can also see draft release notes:
> https://github.com/QubesOS/qubes-doc/pull/828/files
>
> I'd say the above is 80-90% done. There is a possibility the first
> release candidate will be already this month.
>
> In the meantime we're also working on a reliable GPU passthrough with
> focus on Intel, without sacrificing security much (specifically, without
> running unsandboxed qemu), but it's not going to be part of R4.1 yet.
> Having that, and more tested and improved GUI VM integration would allow
> to make it default and greatly reduce size of dom0.
>
> With such reduced dom0, we can consider another distribution there. It
> hasn't been decided on a specific one yet, but I'm strongly considering
> Yocto/OpenEmbedded - for its ability to build small system. Maybe even
> small enough to fit in RAM, which would allow running dom0 disk-less,
> opening a path to many cool features like storage domain. But it would
> also allow easier code sharing with OpenXT project.
> Anyway, at this point, user would not directly interact with dom0, so it
> will be very much transparent (i.e. even if that would be Debian - which
> is another option - you won't have a chance to call apt-get there). What
> user will interact with, is a GUI VM, which would be much more flexible
> in distribution choice (basically - whatever template we currently
> support).

How will debugging of dom0 work? Obviously, nobody who is not working
on Qubes itself will need to do this, but you probably will.

> But also, with GUI VM separated from all-powerful dom0, we can consider
> some options for video acceleration access for selected VMs. There are
> various paths here to be explored, with different hardware requirements,
> and different security properties. But that's for late 2020 at the earliest.

That is very exciting! I understand that that will take a long time, though.

Sincerely,

Demi

PS: Where can I verify your email signing key? That it isn’t
obvious to me is probably my fault.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 06, 2019 at 09:37:22AM -0500, Demi M. Obenour wrote:
> Sadly, the safety certification is focused on ARM, but I would love
> to see this on x86 as well.

Yes, but fortunately some of it also affects common code. For example
Kconfig and ability to disable various features at build time.

> Will UEFI compatibility also include providing UEFI to VMs?

It isn't strictly on the roadmap, but there is some code in half-working
state. I can bring it up to at least testable state.

> I will work on my socket-based qrexec PR this weekend.

That would be much appreciated!

> How will debugging of dom0 work? Obviously, nobody who is not working
> on Qubes itself will need to do this, but you probably will.

Short answer: you can enable qubes.VMShell into dom0 from a selected
VM. Obviously you don't do that on a production system.
But in practice, given much less services running directly in dom0 means
there is much less need to interact with it. Given access to logs
(either via some log-retrieval qrexec service, or proper Log VM) and
ability to install updates (including development builds) may be enough.

> PS: Where can I verify your email signing key? That it isn’t
> obvious to me is probably my fault.

I intentionally keep code and email signing keys very much separated.
But there is a path you can follow:
qubes-secpack -> doc signing keys -> qubesos.github.io repository -> key
fingerprint in _data/team.yml

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3qbEkACgkQ24/THMrX
1yz/vQf/RClUyvwADeTnKmwTcxuzY7sr3tymAnchWCQv/DF4i18Jiqz5kIQXtubX
1yIsYgCQqiqPnpfyP8wGyk3eoQnzbxyIJKyegUbqssmBdaNbBTXJ2+ABoR1QtuVt
BhgJkEp6pK8mRhNz2pyFYjQLwp6lTySLDg7rOux333FUNyaODh4ZLktjIBtTtgGR
1g6FzC5YBD5VFx6BL/VyM36caTFJQU738I3Inc7da0+XMxJlrTTqrxNNBIitjdkb
9hGADlEXy4PmvMeqQ3G5G+fcQyTNml79JfaAw51ESVImSm4lVlVniSHZoNeXVvFM
IUHhvyFlUPNklsaIrezf4JIJail0vg==
=QSqJ
-----END PGP SIGNATURE-----

[Charles Peters]

On Thu, Dec 5, 2019 at 9:25 PM Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

The current plan for major features of Qubes OS 4.1 is:
 - experimental GUI VM and Audio VM (very limited and not yet ready for
   daily usage)
 - new qrexec policy format and significant qrexec performance
   improvements
 - major improvement for UEFI compatibility (grub2-efi is back, some
   changes in Xen to make it more uniform with Linux)
 - as usual, updated templates and dom0 (but still Fedora)

You can also see draft release notes:
https://github.com/QubesOS/qubes-doc/pull/828/files

Any plans to use Stratis, https://stratis-storage.github.io/, and xfs instead of ext4 or lvm-thin pools?

The option for not encrypting backups is missing, and the man page -e or --encrypt is ignored, backups are always encrypted...  I would prefer to have backups without encryption, or some automated backup process.

Chuck

[John Smiley]

Thank you both for the detailed and prompt responses.  While I'm technical in some areas, virtualization is still new territory for me so I may not fully grasp the significance of what I read or hear or may attribute it greater significance than it actually has.  For example, I have read that Google Cloud uses KVM instead of Xen.  I inferred from that that any safety certification issues with KVM had been dealt with.  I would love to know more about why this is a problem.  Similarly for AWS, but that applies less for them since they are using a very stripped down and customized version of KVM.  They've even gotten as far as removing the need for a hypervisor entirely on their new stack.  Certainly, moving off of Xen and embracing KVM would open up the hardware requirements and make Qubes far more accessible.  My own experience of trying to get Xen 4.12 running on the various Intel platforms I have at home was quite a challenge.  KVM was a breeze.  Still, if KVM has significant security issues vs Xen, it doesn't matter how easy to use it is.  I assumed that Google's use of KVM put them in the same league security-wise as Xen.

It seems to me that the crux of any good secure endpoint OS is process isolation.  Qubes does this today with Xen domains, which are effective, but resource heavy.  Other efforts to build a secure OS seem to be focusing on more light-weight approaches such as various types of containers and/or leveraging the features of modern processors to create enclaves where such processes can run.  I thought Subgraph/Citadel/Oz was onto something there, but it seems to have fizzled out.  Another example where others are using lightweight process isolation are browsers like Chrome (which already has it) and Firefox (which is in Beta).  I know that browser process isolation is not even on the same playing field as Qubes in terms of security and privacy protection, but the idea of extending this to the OS and apps has a lot of merit.

[Qubes123]

The current plan for major features of Qubes OS 4.1 is:
 - experimental GUI VM and Audio VM (very limited and not yet ready for
   daily usage)
 - new qrexec policy format and significant qrexec performance
   improvements
 - major improvement for UEFI compatibility (grub2-efi is back, some
   changes in Xen to make it more uniform with Linux)
 - as usual, updated templates and dom0 (but still Fedora)

You can also see draft release notes:
https://github.com/QubesOS/qubes-doc/pull/828/files

I'd say the above is 80-90% done. There is a possibility the first
release candidate will be already this month.

In the meantime we're also working on a reliable GPU passthrough with
focus on Intel, without sacrificing security much (specifically, without
running unsandboxed qemu), but it's not going to be part of R4.1 yet.
Having that, and more tested and improved GUI VM integration would allow
to make it default and greatly reduce size of dom0.
 

In connection with this topic - how do you plan to pass the VBIOS binary to the Xen VM?  I assume this will be required - maybe not for Intel iGPUs, but for the rest..Some cards will need a blob to work in the guivm. And since these blobs are already there in dom0, it will even be more secure to have those only in the guivm.

Will it be done via Libvirt using the libxl xml's?

I did some testing already and it seems the <rom file='/path' /> in the pci.xml template seem to "survive" the schema validations, and therefore the file could be available for qemu to pass to the VM.  However, so far

I couldn't get it passed yet, some patching is still needed to be done..

 

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yes, this is one of the problems to be solved. In many cases what you
can express in libvirt doesn't always match what is specifically
implemented in the libxl driver.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3r1YUACgkQ24/THMrX
1yyjxAf/W+/CFfvGzcKrgZE3B3jBu7aLeGdnE1TfL6veeJbDja8FrZWd8Oyn/sUs
UDfA7HtMMnM6GVKW7rfKoig4GieOcvxSg0jNWRg7NZJmQf7yvkdonPTLMhoSR5wM
NQM/9HEAJ8W2RbTv2cOQiRkt2PVuphsUmirww0xSlIr6Fg3UrZna4c7dAGWTO6yV
9Bs8XM++uCLGgPt1IOvKRrOWBTHK06UuH8qf5DXrEMACVYR4NlN46aMId9fYgt7w
iL44L/FVv0yh3TMwUWq5JmywUQyq1sOy8wMWW8uvUSiDrH8YImW9P3rdkPSv4+bg
A2wn8/U3dWuIVlqxTth7FuEXf3D0qw==
=PWt8
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 06, 2019 at 09:59:47PM -0500, Charles Peters wrote:
> On Thu, Dec 5, 2019 at 9:25 PM Marek Marczykowski-Górecki <
> marm...@invisiblethingslab.com> wrote:
>
> The current plan for major features of Qubes OS 4.1 is:
> > - experimental GUI VM and Audio VM (very limited and not yet ready for
> > daily usage)
> > - new qrexec policy format and significant qrexec performance
> > improvements
> > - major improvement for UEFI compatibility (grub2-efi is back, some
> > changes in Xen to make it more uniform with Linux)
> > - as usual, updated templates and dom0 (but still Fedora)
> >
> > You can also see draft release notes:
> > https://github.com/QubesOS/qubes-doc/pull/828/files
>
>
> Any plans to use Stratis, https://stratis-storage.github.io/, and xfs
> instead of ext4 or lvm-thin pools?

There are no plans in this direction right now.

> The option for not encrypting backups is missing, and the man page -e or
> --encrypt is ignored, backups are always encrypted... I would prefer to
> have backups without encryption, or some automated backup process.

Backups encryption is forced intentionally. But you have an option to
save the encryption passphrase (on an encrypted disk) to allow
unattended backups. See qvm-backup --profile option, the actual profiles
are stored in /etc/qubes/backup (including the one created by the GUI tool).

For some nicer unattended backups, I consider incremental backups a
must. There are some nice solutions done by various qubes contributors,
but nothing is integrated into qvm-backup yet.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3wWEAACgkQ24/THMrX
1ywMHQf+LptVJ23SGgpH1a5JW2Ovkcw5XDgtNnsuTkya67CXEXcHlLEYn52QZXYM
62XWA3r+lDn2YT92WpF4aWmLqYGbD1d+3PLxYPHgh+4Os/WohLIeKqYyT0069V9b
ClGK4n01cLDQiV+wBrIU2u+OXn/9WMosNKs6Nr+QkDlcGMIcHlon7ctPg1u5EQ+P
z7lSf1aTxFAbcT72wOHHycHiszPLqY87Ycaa++4FMnveAnqOcjD4CZ0J4y5JfoQR
tN7g77jx+tzMy/SdeGmkvSXyiAh5/c+AUdtMz20xjiC0nyQiWLGXYH4HIkMg11ym
k2/+Vrfq42s9WfVZQlqD51/2hifrSA==
=chKf
-----END PGP SIGNATURE-----

[Foppe de Haan]

On Friday, December 6, 2019 at 3:25:55 AM UTC+1, Marek Marczykowski-Górecki wrote:

The current plan for major features of Qubes OS 4.1 is:
 - experimental GUI VM and Audio VM (very limited and not yet ready for
   daily usage)
 - new qrexec policy format and significant qrexec performance
   improvements
 - major improvement for UEFI compatibility (grub2-efi is back, some
   changes in Xen to make it more uniform with Linux)
 - as usual, updated templates and dom0 (but still Fedora)

You can also see draft release notes:
https://github.com/QubesOS/qubes-doc/pull/828/files

I'd say the above is 80-90% done. There is a possibility the first
release candidate will be already this month.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Maybe this month already? Cool. :) Will it be possible to simply restore r4.0 VMs, upgrade relevant packages, go?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 12, 2019 at 08:31:55AM -0800, Foppe de Haan wrote:
>
>
> On Friday, December 6, 2019 at 3:25:55 AM UTC+1, Marek Marczykowski-Górecki
> wrote:
> >
> > The current plan for major features of Qubes OS 4.1 is:
> > - experimental GUI VM and Audio VM (very limited and not yet ready for
> > daily usage)
> > - new qrexec policy format and significant qrexec performance
> > improvements
> > - major improvement for UEFI compatibility (grub2-efi is back, some
> > changes in Xen to make it more uniform with Linux)
> > - as usual, updated templates and dom0 (but still Fedora)
> >
> > You can also see draft release notes:
> > https://github.com/QubesOS/qubes-doc/pull/828/files
> >
> > I'd say the above is 80-90% done. There is a possibility the first
> > release candidate will be already this month.
>

> Maybe this month already? Cool. :) Will it be possible to simply restore
> r4.0 VMs, upgrade relevant packages, go?

Yes, that should work. There is also a plan to support in-place upgrade,
but it hasn't been tested yet.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3ycFsACgkQ24/THMrX
1yy3mAf/R+/5GJEuIBFfl1L8tHKiEM3F3E7eO9FQ+jK2CTleyKwC7sNMZ1fbFhyT
HGcLMd1OUYL0+uHoL8Ktj99kH7o8dNcbPRKjKojcg+GxEDZ+tdeq7uPZU89InwJP
LAREPcy86gTBkQ74cfL+9mVzvWcouxofLFATI/xPoVVkdTpN30Z662G9cvaOMPUC
uD0Qu+DAXJzgQlD5CSltXb/gVAhvCVH6vYLf4b+BiVMM7m45+rRQT+v9X5P5DS5D
l/AwZDnv6aPxwGdvbw4oLZqUbNPaFPnnB/MSiyKHWIqFV/dPYRgsp03kUZPh4ccJ
YxmI411E9ThaQWr5M0T30EuVZG1dEg==
=y2P6
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 13, 2019 at 11:16:07AM +0700, OutBackdingo wrote:

>
> On 12/12/19 11:52 PM, Marek Marczykowski-Górecki wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Thu, Dec 12, 2019 at 08:31:55AM -0800, Foppe de Haan wrote:
> > >
> > > On Friday, December 6, 2019 at 3:25:55 AM UTC+1, Marek Marczykowski-Górecki
> > > wrote:
> > > > The current plan for major features of Qubes OS 4.1 is:
> > > > - experimental GUI VM and Audio VM (very limited and not yet ready for
> > > > daily usage)
>

> can we get some elaboration on this GUI and AudioVM ? do you mean all wm,
> desktop and gui functions will now be controlled by a VM and not dom0 ?

Basically yes. You can read more here:
https://github.com/QubesOS/qubes-issues/issues/833

For now, we're working on a few variants:
- "real" GUI VM, with direct access to GPU (similar to how sys-net
manage network interfaces) - this is in progress, but won't be part
of R4.1
- "fake" GUI VM, where GPU is still in dom0 (and X server running
there), but all the window manager and desktop environment is running
in a VM; this is done by chained qubes-gui protocol - basically dom0
displays just one application - a full screen environment of GUI VM
- "remote" GUI VM - the actual GUI is exposed not to the local display,
but over VNC to remote user; this remote access definitely needs
further defenses (VPN? Tor authenticated onion service?), but I think
that's interesting use case

You can also have multiple GUI VMs (for example one local and one
remote), to manage different set of qubes. But one qube can be managed
by only one GUI VM.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3zgDYACgkQ24/THMrX
1yysoAf/QJHnE/vboKc6uu1sWvAoAhSKi5NyB3+0QUfy+SzX1zsC2AqzccdakzD1
URaocblNc7GYuTltZLSr1HGPm2mkuXBZ+De/K6UsrCSr/NU5XOzvoQK6EGf2NZVb
/7sWA5jWrqZLV14sM6EccLswjRSxoRYVoTpEBOGNfDbpVDqNjQbgNlbRSW+zpWXz
VRn9ML8viWVgaKHlRnOwUWUChDyZSCHJCLWNaTVxnKquG5DeX50oJyNSowZgmA5w
VVeZxN+mWvw7vg4v7IvOylev9nbnIdLUS1PcUsvZxrlcoktKfn10YvFpvbTL6wGe
uLdJJhPEQS14nuncbyM1kcN/NmIm9Q==
=dyVV
-----END PGP SIGNATURE-----

[Rob Townley]

On Fri, Dec 6, 2019 at 4:20 PM John Smiley <jrsm...@gmail.com> wrote:

Thank you both for the detailed and prompt responses.  While I'm technical in some areas, virtualization is still new territory for me so I may not fully grasp the significance of what I read or hear or may attribute it greater significance than it actually has.  For example, I have read that Google Cloud uses KVM instead of Xen.  I inferred from that that any safety certification issues with KVM had been dealt with.  I would love to know more about why this is a problem.  Similarly for AWS, but that applies less for them since they are using a very stripped down and customized version of KVM.  They've even gotten as far as removing the need for a hypervisor entirely on their new stack.  Certainly, moving off of Xen and embracing KVM would open up the hardware requirements and make Qubes far more accessible.  My own experience of trying to get Xen 4.12 running on the various Intel platforms I have at home was quite a challenge.  KVM was a breeze. 

A third party company may have persuaded Citrix XEN to limit development, but that has only meant that xcp-ng.org / XOA / XOSAN has taken off.  But that is XenServer.

 

The hardware requirements for XenServer  XEN have been fairly minimal, but Qubes-OS XEN has a much much more restrictive set of hardware requirements in order to meet security goals.  Wish the rest of the industry embraced security hardware such  as much as Qubes.  

People run the latest version of xcp-ng  8 on old desktops for testing purposes even using vGPUs from several year old Graphics cards.   

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/445e49f6-57d8-4073-a897-aecc24e65be0%40googlegroups.com.

[Brendan Hoar]

On Friday, December 13, 2019 at 8:06:56 AM UTC-5, RJT wrote:

A third party company may have persuaded Citrix XEN to limit development, but that has only meant that xcp-ng.org / XOA / XOSAN has taken off.  But that is XenServer.

The hardware requirements for XenServer  XEN have been fairly minimal, but Qubes-OS XEN has a much much more restrictive set of hardware requirements in order to meet security goals.  Wish the rest of the industry embraced security hardware such  as much as Qubes.  

People run the latest version of xcp-ng  8 on old desktops for testing purposes even using vGPUs from several year old Graphics cards.  

Openxt has similar workstation hardware requirements. Their downstream enterprise users are given predefined hardware options (similar to Qubes HCL).

[OpenXT is another Xen based workstation platform ("partitioning digital persona") and the underlying tech for US DOD/IC's SecureView workstation.]

An aside: from what I can see on the lists, in addition to Qubes team upstreaming fixes/requests to core Xen, Qubes and openxt teams have been sharing code/ideas.

... which reminds me a bit of this Looney Tunes cartoon with Sam (perhaps representing openxt user base) and Ralph (perhaps representing Qubes user base) clocking out together after a long day of work as adversaries ... maybe grabbing lunch break together ...

https://media1.giphy.com/media/K0JLfHTOJs8ZG/source.gif

https://imgflip.com/i/3jdpyf

https://imgflip.com/i/3jdq3j

:P

Brendan

PS - depending on your position, you might flip the characters of course.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I like this comparison :D
While the products are quite similar in goals and technology, we have
sufficiently different target user base to not compete against each
other in practice. And it's quite cool to share effort on this path.

> Brendan
>
> PS - depending on your position, you might flip the characters of course.
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl30N+YACgkQ24/THMrX
1yzeeAf/U36GHFBj/e2Fu+vSbpwZv+EpjeFRXMCtWdsuiWlJOyIiC/LvDgoyCvhB
0vkPQxfsqZxv6V67i39DQumbqQshEwZ/4EvIS0PhZD0Pr01FBXYMMT2qbBf2vWiN
qEmfqkkEkbxvhN7N3dMoX2DLiTce0i1XLcBrI/NbsPwMsf3uL1OoOLR/GqFzzATG
nmuJ4EJunz6XvJNjx0oDW8HbjJUtEAkpguedMoaqKM01amftY2jI8EHqb3o5jhnz
kz3w4YSzsiVWeQm6GLmVmwOQeuhrr5tCOAPTYYIrwROHABVi0uxpsyo86PmO3jGI
AJurJ1dwJetE3wctg+YpFXttjVTA0g==
=rIE7
-----END PGP SIGNATURE-----

[Foppe de Haan]

xen 4.13 is no longer planned for Qubes 4.1, btw?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Dec 16, 2019 at 10:43:55PM -0800, Foppe de Haan wrote:
> xen 4.13 is no longer planned for Qubes 4.1, btw?

It is planned, and in fact we just wait for the official release - all
our code is already adjusted.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl3497UACgkQ24/THMrX
1ywYnwf/TNqH8t/PdQoiJG6IfdYUH9FebFJ0XTilrZFvFaUzdfTc3GJNzHTpK0Vu
T74czSxQ0cqvk6XJft94D4FHdav4ll3cIcgqDRDn2xJ+NcCc4JUazVm2IT93jJRO
OaOqd0uwuBUCYe0L4cuFs75u/iuYBBp5UFWR9tGJWJy5YfmIvMv/1KFxRX+NSSo3
pcKBdZQvnkX05smZAoOpkymvFfHwaEKyn8h+SKOrM4tla0iNlDg/2WN3uprepUry
c3vbM50qh12GjhWNNFb3ugrAi+DLBA+lTg1a56vtG1LbK79kZy1/Io6Jv8zDq1Wt
5tSQLQlBoJNdCTFxS6RJV7ixYLcdBw==
=dkCL
-----END PGP SIGNATURE-----