Add options for making performance tweaks/enhancements with disclaimers?

[arthur....@gmail.com]

So, I've been following Qubes since version 1.0. At that time, I used it as a lab demo for interns at work to show them just how far you can go with visualization. It was clunky back then, but I kept my eye on the project.

I've toyed with using 3.x as a daily driver, lately. From a non-security perspective, it works great at helping me compartmentalize my life, and that's the main reason that I like it. From a security perspective . . . I mean, it goes without saying. I'm way more of a Debian and VMware person, and I'm definitely cutting my teeth on Fedora and Xen, so please excuse my ignorance of them.

The thing that's keeping me from using Qubes regularly is that it is so resource-hungry. I understand why and that many of these reasons are security considerations. I have a M6800 laptop with 16GB of RAM, so I've got plenty of power. However, it pains me to see an AppVM running a single instance of Firefox eating up just under 4GB of RAM. Yes, much of that is the fault of the application developer, but some of it is also overhead needed to provide the high degree of isolation and security that exists in Qubes.

I've searched around for "performance tuning" guides for Qubes, but I haven't been able to find any. Does one exist, or is it possible to start to put something together? By "performance tuning," I even mean potentially changing settings that may include the sacrifice of some security for added performance and resource handling. I know, I know - that goes against everything that the project stands for. I used to work on the pen testing team at a Fortune 10 company, I understand why Qubes works the way it does, so hear me out. Some people (like myself) have different use cases, understand the risks, and are willing to give a little to gain a little. Much like rooting a phone, enabling "unknown sources"/USB debugging on Android, or even typing "sudo" at the command prompt, many power users are willing to take the risk because they know what they are doing.

Beyond just making a list, it would be nice to eventually make such settings available in the GUI. Add a checkbox somewhere to allow full-screen playback, but give a disclaimer to the user (again, just like enabling unknown sources on Android gives a warning). Have options to tune Xen's resource management, but make the user aware of what they are wishing to do. I'm not saying give checkboxes to do things like connecting dom0 to the network, but having options to decrease resource isolation from VM to VM would be great for those who prefer a little more performance over absolute security.

Thoughts?

[Alex]

On 07/06/2016 05:57 PM, arthur....@gmail.com wrote:
> [...]

> Beyond just making a list, it would be nice to eventually make such
> settings available in the GUI. Add a checkbox somewhere to allow
> full-screen playback, but give a disclaimer to the user (again, just
> like enabling unknown sources on Android gives a warning). Have
> options to tune Xen's resource management, but make the user aware of
> what they are wishing to do. I'm not saying give checkboxes to do
> things like connecting dom0 to the network, but having options to
> decrease resource isolation from VM to VM would be great for those
> who prefer a little more performance over absolute security.

Actually you can allow full-screen playback by fiddling in dom0 with
/etc/qubes/guid.conf, the same place where you can allow utf8 window
titles and change some other bits.

As for the memory usage, RAM is balanced by Xen but you can set your
preferred limits (or force the usage of a specific amount) using Qubes
Manager: right click on a Qube, choose "VM Settings" and go to the
"Advanced" tab. There you can also set the number of VCPU for the VM.

This seems to me an entry-level set of performance tuning knobs, and
some are already exposed in the GUI... To achieve more you should just
tune the operating system inside the virtual machines, and if you use
the provided templates (or a clone of them you can customize), they are
already a little stripped of useless things.

I don't know if Xen allows for memory page deduplication, which I
understand is the only actual "performance" boost (actually, memory
pressure easing feature) that the hypervisor can give, and if this can
be enabled in Qubes. This would still be safe, wouldn't it? Are there
other performance tools that an hypervisor can implement?

I'm writing from my main Qubes workstation, where I develop for Android
with a .NET backend, and usually have a couple firefox instances
(personal+work), a couple thunderbird instances (persoal+work), a skype
instance (separate AppVM), MonoDevelop + Android Studio + Android
emulator, with 32 GB of RAM, and a plain intel i5, and still it is a
little faster and nicer than my fedora-only laptop, with 8 GB RAM and a
recent intel i3.

Give it RAM and it will rock.. YMMV, though.

--
Alex

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-07-06 08:57, arthur....@gmail.com wrote:
> So, I've been following Qubes since version 1.0. At that time, I
> used it as a lab demo for interns at work to show them just how far
> you can go with visualization. It was clunky back then, but I kept
> my eye on the project.
>
> I've toyed with using 3.x as a daily driver, lately. From a
> non-security perspective, it works great at helping me
> compartmentalize my life, and that's the main reason that I like
> it. From a security perspective . . . I mean, it goes without
> saying. I'm way more of a Debian and VMware person, and I'm
> definitely cutting my teeth on Fedora and Xen, so please excuse my
> ignorance of them.
>
> The thing that's keeping me from using Qubes regularly is that it
> is so resource-hungry. I understand why and that many of these
> reasons are security considerations. I have a M6800 laptop with
> 16GB of RAM, so I've got plenty of power. However, it pains me to
> see an AppVM running a single instance of Firefox eating up just
> under 4GB of RAM. Yes, much of that is the fault of the application
> developer, but some of it is also overhead needed to provide the
> high degree of isolation and security that exists in Qubes.
>

Are you sure that's not just qmemman dynamically reallocating memory
across running VMs? If you only have a small number of VMs running,
it's not surprising that 4GB of memory would be allocated to them, but
that doesn't mean that the memory isn't available for starting other
VMs and running other programs.

> I've searched around for "performance tuning" guides for Qubes, but
> I haven't been able to find any. Does one exist, or is it possible
> to start to put something together? By "performance tuning," I even
> mean potentially changing settings that may include the sacrifice
> of some security for added performance and resource handling. I
> know, I know - that goes against everything that the project stands
> for. I used to work on the pen testing team at a Fortune 10
> company, I understand why Qubes works the way it does, so hear me
> out. Some people (like myself) have different use cases, understand
> the risks, and are willing to give a little to gain a little. Much
> like rooting a phone, enabling "unknown sources"/USB debugging on
> Android, or even typing "sudo" at the command prompt, many power
> users are willing to take the risk because they know what they are
> doing.
>

Security is the raison d'être of Qubes. Without security, Qubes
wouldn't be any better (and would arguably be much worse*) than
standard monolithic OSes.

* Mainly due to hardware compatibility and user-friendliness.

> Beyond just making a list, it would be nice to eventually make
> such settings available in the GUI. Add a checkbox somewhere to
> allow full-screen playback,

I'm not sure if your point here is about having a GUI checkbox or
about having the ability to enable fullscreen mode at all. In case
it's the latter, and you're not already aware, you can enable
fullscreen mode in a config file:

https://www.qubes-os.org/doc/full-screen-mode/#tocAnchor-1-1-4

(Obviously, this is not a GUI checkbox, but I just wanted to make sure
you're aware that the option is available.)

> but give a disclaimer to the user (again, just like enabling
> unknown sources on Android gives a warning). Have options to tune
> Xen's resource management, but make the user aware of what they are
> wishing to do. I'm not saying give checkboxes to do things like
> connecting dom0 to the network, but having options to decrease
> resource isolation from VM to VM would be great for those who
> prefer a little more performance over absolute security.
>
> Thoughts?
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXfS9wAAoJENtN07w5UDAwRFkP/icCejG41Cy0H7bMj0CpAlkA
SNXJu6T4Jv8VkUXh7ovPpHu0fN3Vo4/8pZKhX7l7TCLndfguL6qrdRbFA1zdXKY2
YaIdcYinGJGgj0aG/SzzyaT8RyIEzlezKa6UboTF9qt12WVgLdPRemiy7vqAyiuw
FTyMykPuDZX1x/LYaDkiixmvUocq232GLmv8GE9UTpxCUzNrVPFCN7Et+cWoximj
1U+d7UlRiKPAV7rXJ8BF0jiLmEJfzienYrLuf7qAFBDuJGA3ekg++VOmvKn0anhl
LMxn2IMkHMtnAYx8xp2C+LoDczn/7CoOTPSvOmawdpi6t0zMSj0w3S7+Ph0T8N/A
mexry0kic4yi4qyw4IQz7BYGwqnAXN+oYI//mq4AGGsLsmlY+GPgKPquNvqAEIpq
virPGPPiPYxKrqIjYi4StcbMbWrlrAREqwYOm1xjKy+6aYOBOZiYatTBhPcFgLos
sTuiqBYPZ2+Oh+KExpDB+UUvRQdGZLXa5UzT3xhZl1g3AbvqISwLep6zqJksnifl
vRKVKEmn3ZprB2D703d3kJ6b7K7hbwSmmVXJN5RZE2M4OsGnFiqnSeSiVDehmCpe
GfFbL0cNT2URdqL/m5l1W+VaviofSlCFQjaxn6SWnf4LuW/GxcVEvK+4nbKCb1JT
4e/XZhqSbg8DK+w90Rvv
=P+vD
-----END PGP SIGNATURE-----

[arthur....@gmail.com]

Wow, that was fast . . .

First, I was just using the full screen thing as an easy example because it's something that I /know/ can be modified. I didn't want to suggest something that isn't an option since I'm a Xen noob.

With that said, I'll pose some options as a Xen/Qubes noob. Doesn't Qubes isolate memory and vCPUs between VMs instead of allowing for shared resources (which I believe is something that Xen does)? Things like that is what I'm after, I suppose.

I'm sure you're sick of hearing it, but man, I really wish my FirePro card had support under Qubes or that I could "sneaker-net" the appropriate drivers into dom0. ;)