My use case for Qubes is less security-focused and more 
separation/compartmentalization of systems-focused. If XenClient was still 
a thing, I'd be using it. I even tried to hack at ESXi to get X11 running 
and maybe use it as a client hypervisor, but no luck.

That said, while I take security seriously, I also weigh it against things 
like risk and performance. I recently upgraded my BIOS to take care of an 
issue I had with my fans going at 100% after resuming from suspend:
https://groups.google.com/forum/#!topic/qubes-users/hkj5BkR8Z8E

Here is the BIOS I flashed:
https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=MJ0KC&oscode=W732&productcode=precision-m6800-workstation

However, the new BIOS appears to allow kernel modules that address the 
Spectre/Meltdown vulnerabilities to run . . . and WOW, did my system get 
slow. Running updates on one of my templates resulted in the VM crashing 
repeatedly and never successfully updating. VMs are regularly taking up a 
large percentage of CPU. I added the nospectre_v1, nospectre_v2, and 
nospec_store_bypass_disable kernel parameters, and that seemed to help 
somewhat, but I have two questions:

   - In GRUB, do I add those kernel params to the multiboot /xen-XXXX line, 
   the module /vmlinuz-XXXX line, or somewhere else?
   - Are there other modules that I could disable to improve performance?

Obviously, I completely understand that this is not recommended and goes 
against the purpose of Qubes as an OS, but from a risk perspective, I'm 
willing to take the trade-off for a bit of extra performance.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ec8fce57-a87c-43c0-b36e-d9a46339b40c%40googlegroups.com.

Reply via email to