Just running to every motherboards. Everybody hate the HCL.
2 Likes
Improved support for potato hardware would be a nice bonus, specially when the CPU has to do two jobs for the price of one. I don’t need a GPU if it’s going to mess up my security. Then again they may have fixed this recently, I hear the new Qubes has xfce by default…
1 Like
That is like saying, “i want to fly to the Moon with my Tricycle”. If the hardware does not support secure virtualization there is no real safe way currently to make this happen.
The GPU problematic is being worked on in the LINUX community but if the Hardware Manufacturer does not supply open source drivers you should voice your concerns with each of them, nothing Qubes OS can do about it.
You always have the option to passthrough GPU that though requires working IOMMU / secure virtualization able Hardware otherwise the point of secure compartmentalized Qubes VMs becomes pointless.
1 Like
Do you really need to remove this ME stuff?
I run Qubes on 13980HX, and windows 10 VM feels very responsive and snappy. I guess im happy with it.
1 Like
- Undervolting of CPU. Under Linux I can undervolt my CPU by -160mV and get +300Mhz performance boost. For a CPU-based OS, it is must have.
- More colors
- Screenshots inside VM
1 Like
I’d like to see better changelogs, it’s currently hard to guess what changed between 4.1 and 4.2, and the item list in the RC announcements are really vague.
2 Likes
- I will find it nice that the default’s icons of the XFCE templates will be the same as those of Dom0. Like that, we’ll find a similar desktop in the sys-gui and sys-gui-gpu sessions.
- Have the Documentation available in other languages
(I’m from France and sometimes, it was difficult to understand it even with translation’s sites. I can help for that if you want. 
1 Like
I think a lot of people miss it! lol But from what I could understand, it seems quite difficult
1 Like
Unfortunately, it seem very difficult for these reason:
2 Likes
for hardened sys-usb and sys-net check liteqube.
2 Likes
here is my wishlist. qubes is awesome btw , thanks for working on it
in order of importance
1- full support for machine sleep / standy using s0x sleep state (i believe this has upstream dependency on xen to support fully). many modern laptops don’t support s3 sleep so this is a must have.
2-fido support for login (hardware key)
3-improved change management for dom0 - snapshots, rollbacks, etc.
4-optimize backups (incremental vs full backup).
thanks
2 Likes
suspend/resume compatibility improved a lot in the incoming 4.2 release 
2 Likes
thank you @solene
i have tested latest rc3 on my dell XPS, the machine doesn’t suspend properly. i am keeping an eye on this issue scheduled for 4.3 milestone
1 Like
4.2 isn’t out yet, so 4.3 is far far away
1 Like
yep , I will need to wait for 4.3 
more info on XPS sleep issue on this thread
2 Likes
I managed to get it working. It took me quite a bit of time and it’s not perfect. I can’t where I posted my setup right now but ping me if I forget to post some more context.
But in the very least it requires a discrete GPU
2 Likes
I think this is a great feature, which could be added in version 4.2
7 Likes
Controllable intrusion monitoring based on selinux in non-enforceing mode, with a daemon that offboards the triggered avc alerts to a central monitoring VM “sys-mon” or “sys-avc”. Once configured properly, if any system file is accessed or modified in an unexpected manner that would trigger an alert upstream in the sys-mon VM before it can have any real affect on that monitored VM. Doing this will not prevent the cow writes to the system files but it will send an alert as to what application triggered the alert so that the offending app or process session can be more closely monitored by the user.
Example: Should for any reason there be a breach in sys-net due to some exploit in a protocol or vulnerability in the network adaptor any subsequent searching and probing of that VM would trigger a cascade of avc events while That intruder is identifying the environment to decide how to exploit the OS and install their toolkit. The sys-mon would detect this before the malware has even dropped and installed.
Same deal with user apps and rogue plug-ins. Any plug in that reaches outside the configured bounds of the parent app would trigger avc alerts by those actions and sys-mon would alert the user of the nefarious operations currently underway.
The deal is to give warnings to the user/system before the VM is completely compromised. Selinux has many capabilities that could be tapped into and a complete rule set that can be modified and updated as necessary to customize the user’s system. We just need to trap the avc errors and forward them before the intruder has a chance to completely take over the VM. You may not be able to prevent an unknown adversary using unknown tools to circumvent your system but you can detect the tampering they are doing to set that up. Even doing a find or an ls in the wrong part of the file system from the wrong process context would be enough to trigger such an alert. Doing it from the proper context would not. The rules are configurable, and this capability is already there in the OS kernel software, it’s just not being compiled into the current distribution.
One lightweight service to propagate those alerts is a small price to pay for peace of mind. In the net-mon VM you could have processing that triggers rules for snapshots or automatically taking a VM offline in response to certain actions giving it the possibility for unattended mitigation where certain exploits may not be patched yet. Rules could be shared and updated across platforms. You would finally have a high level view of any unexpected tampering of your system and rules that can mitigate a real-time attack.
Qubes is designed for security, but it is completely blind to the common threats out in the wild. This model could change all that. It would also be adjustable based on your personal threat model, and using salt could even be managed across an enterprise.
10 Likes