AW: Re: [qubes-users] Using fedora-26-minimal sys-vms

2018-01-20 Thread '[799]' via qubes-users
Hello,

Unman wrote:

> You DO have a working network manager -
> see the response from systemctl.
> I assume what you want is a nice gui
> interface this is nm-applet. If  it is installed,
> start it and you will get the nice tray icon - if
> not installed, install it.

I was able to get Network Manager running and instead of using the default 
"fat" fedora-templates, I am now running the sys-VMs with fedora-26-minimal 
templates.
I was always wondering why Qubes doesn't come with a dedicated sys-template, so 
that the sys VMs (sys-net | sys-firewall | sys-usb) are running with a 
smaller/maybe even hardened template.

For the Google Archive a short how-to, how I have built the template for the 
sys-VMs:

--- --- --- 8# Install default minimal template in dom0
sudo qubes-dom0-update qubes-template-fedora-26-minimal

# Clone template to keep the original template
qvm-clone fedora-26-minimal t-sys

# Launch xterm in the new template as root
qvm-run -u root t-sys xterm

# Install basic applications in the template VM
sudo dnf -y install gnome-terminal terminus-fonts less vim-minimal nano 
dejavu-sans-fonts

# install basic tools
dnf -y install sudo pciutils psmisc gnome-keyring

# Install missing packages für Sys-VMs
dnf -y install qubes-core-agent-qrexec qubes-core-agent-systemd 
qubes-core-agent-passwordless-root qubes-core-agent-nautilus 
qubes-core-agent-networking qubes-core-agent-network-manager 
qubes-core-agent-dom0-updates pulseaudio-qubes usbutils

# Install missing drivers (to support the network devices)
dnf -y install linux-firmware iwl7260-firmware

# install additional packages to get network manager working
dnf install -y NetworkManager NetworkManager-wifi network-manager-applet 
wireless-tools

# shutdown template
shutdown -h now

# Change Templates for sys-VMs in dom0
qvm-prefs --set sys-net template t-sys
qvm-prefs --set sys-firewall template t-sys
qvm-prefs --set sys-usb template t-sys
--- --- --- 8
[799]

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/-BuSXf2YMvlH0cwfdLE7WPqqYBMjDeV3JAj5CIthJ0Ri61D74wyUpvaGiO_NZ2AVV8WxzXzdrH8Rwimf-IFACspMTgWegOvXXhb-8N4iYsw%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Another "Best Hardware" 4 VMs setup question.

2018-01-20 Thread taii...@gmx.com

On 01/20/2018 04:14 PM, Davidson H wrote:

As I understood it, its not *totally* disabled but is *partially* 
disabled (like the TCP/IP stack).
Anyway. Your KGPE-D16 suggestion is interesting (thx!), and that mobo+ 
a 12core 2014 opteron seems like it would be fairly speedy? Certainly 
compared to my old i3/8gb tower. This may sound silly but in the VM 
context, would a 12 core processor be excessive or would it be "fully 
utilized" by Qubes?



16 cores, 32 if you use dual 16 core CPU's.

As always it depends on how many VM's you run and how much CPU juice 
they need.

With 16 cores and 64GB RAM you would truly want for nothing.

--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/852eb1f0-1335-49db-747e-7ae6858f9e49%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


AW: Re: [qubes-users] Another "Best Hardware" 4 VMs setup question.

2018-01-20 Thread '[799]' via qubes-users
Davidson wrote:

> I am running 3.2, have 16gb mem, and a
> Samsung ssd drive and it still takes 10 sec
> (timed it) to put up a terminal in a new vm

I am also interested in comparing App(VM) start times, to compare the 
performance.

I have run the following test after boot and with only sys-firewall and sys-net 
running:

Test on my Lenovo x230
Intel Core i5-3320M @ 2.60Ghz
16 GB RAM
500 GB SanDisk SSD
Qubes 4.0rc3
Coreboot'able

startup/boot till xterm window = 17sec (normal AppVM)
startup/boot till xterm window = 21sec (Disposable AppVM)

Test on my Lenovo W540
Intel Core i7-4900MQ @ 2.8 Ghz
16 GB RAM
480 GB Samsung SSD
Qubes 4.0rc3
Not Coreboot'able

startup/boot till xterm window = 15sec (normal AppVM)
startup/boot till xterm window = 16sec (Disposable AppVM)

If the AppVM is already running launching new applications is done within in 1 
or 2 sec.

Your question regarding hardware recommendation:
I would look at the Coreboot HCL/Compatibility List and choose a model which 
fits your preferred display size and resolution.
https://www.coreboot.org/Supported_Motherboards

Using Coreboot you can also remove large parts of Intel ME.

Then as a 2nd test check the Qubes HCL
https://www.qubes-os.org/hcl/

[799]

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ZZb07xj5Bxb2MPWCOFsK9ggitygqGD_gIUiIs59RUxbFXiTR7ldGL9wqatBqd0Xynbp09egpUOUwCXSTwZHO_fZ8eWHB-y_FjGB_6PXo_Dw%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Using fedora-26-minimal sys-vms

2018-01-20 Thread Unman
On Sat, Jan 20, 2018 at 11:53:04AM -0500, '[799]' via qubes-users wrote:
> Hello,
> 
> I want to use fedora-26-minimal based sys-vms and followed the documentation 
> (https://www.qubes-os.org/doc/templates/fedora-minimal )
> 
> I have updated the default fedora-26-minimal template and installed all 
> packages mentioned in the docs (Qubes 4.0 part of the above documentation 
> link) plus all firmware packages.
> 
> What do I need to install to get the network manager icon working?
> 
> NetworkManager is installed in the template and I have verified in the 
> sys-net VM that it is running:
> 
> systemctl status NetworkManager
> 
> Says: active (running)
> 
> I tried to start NetworkManager from command line, but got the message:
> 
> You must be root to run NetworkManager.
> 
> I then started a xterm from dom0 as the Root user:
> 
> qvm-start -u root sys-net NetworkManager but nothing happened. I also try to 
> do this from a xterm session (qvm-start -u root sys-net xterm).
> 
> Any ideas how to get a sys-net which has a working network manager?
> 
> [799]
You DO have a working network manager - see the response from
systemctl.
I assume what you want is a nice gui interface - this is nm-applet. If
it is installed, start it and you will get the nice tray icon - if not
installed, install it.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180120224329.syxfnzaaplt2m4lh%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: [qubes-devel] Qubes Controller as the new Qubes-Manager

2018-01-20 Thread 'Tom Zander' via qubes-users
On Saturday, 20 January 2018 20:03:31 CET Davidson wrote:
> Hey, thanks again for your work, much appreciated.
> 
> Another thought just occurred to me, a collapsible tree like option. I
> have like "work" VMs (one for libre office stuff, another for email,
> another for vid confer) and for general communications (one for IRC,
> another for Signal, another for personal email) and anon stuff (crypto
> wallets, email via tor, browser, etc), the list I have is really quite
> long and I find myself sorting/re-sorting naming etc. I use tree-style
> addon in firefox which has the fantastic option to let you stack tabs
> among other things, considering that and how I have my file manager
> setup to show a tree of the folders I have it would really be quite
> handy to organize VMs into a collapsible tree.

As my list of VMs is growing, this speaks to me.
I really like this idea.

Thanks for sharing it!
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/33700686.oUyV2A9qP9%40mail.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: XFCE Settings menu gone

2018-01-20 Thread Unman
On Sat, Jan 20, 2018 at 10:24:24AM -0800, beso wrote:
> I have same problem.
> 
So do many people - if you search the list you will find many reports and
solutions.

You are probably missing the desktop files from /usr/share/applications
You can copy the files from out of a Fedora based qube if you have one.

If you still have the install medium then you can extract the desktop
files for applications that you want, by pulling them from the rpm
packages:

For example, to get the xterm .desktop file:

mount qubes.iso /mnt
rpm2cpio /mnt/Packages/x/xterm-318-2.fc23.86_64.rpm |cpio -idv "*.desktop" 
This will extract xterm.desktop in usr in the current directory, and you
can then move it in to /usr/share/applications

Alternatively, just reinstalling the packages you want will provide the
menu entries again.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180120222555.o7mdfdq5yaxlaoi4%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to get to command line for dom0?

2018-01-20 Thread Unman
On Sat, Jan 20, 2018 at 09:39:59PM -, 'awokd' via qubes-users wrote:
> On Sat, January 20, 2018 8:46 pm, Kyle Breneman wrote:
> > I am trying to follow these steps
> >  to
> > upgrade from Fedora 23 to Fedora 24 (and then from 24 to 26), but I got
> > stuck right away because I cannot figure out how to get to a command line
> > window for dom0.  Can someone please tell me, or point to documentation
> > which explains?  I've done several web searches without finding an answer.
> 
> Click the Q button, then Terminal Emulator.
> 
Or right-click on the desktop and select "Open Terminal".

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180120221424.jxbupcpjqdfdmbjp%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to get to command line for dom0?

2018-01-20 Thread 'awokd' via qubes-users
On Sat, January 20, 2018 8:46 pm, Kyle Breneman wrote:
> I am trying to follow these steps
>  to
> upgrade from Fedora 23 to Fedora 24 (and then from 24 to 26), but I got
> stuck right away because I cannot figure out how to get to a command line
> window for dom0.  Can someone please tell me, or point to documentation
> which explains?  I've done several web searches without finding an answer.

Click the Q button, then Terminal Emulator.

Recommend not trying to upgrade though, rather you "sudo qubes-dom0-update
qubes-template-fedora-26". This will start you off with a fresh template.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4fa7fbf62099ac88401f46c11bd964f3.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Another "Best Hardware" 4 VMs setup question.

2018-01-20 Thread Davidson H



On 20.01.2018 20:16, taii...@gmx.com wrote:

On 01/20/2018 02:08 PM, Davidson wrote:



I just forgot. I noticed that some places (librem I think, and 
System76 
) 
are selling computers with ME (partially) disabled on their intel 
procs, does anyone know about either buying just procs or mobo/proc 
combos with (partially) disabled intel ME procs?



Purism is a scam, ME can't be disabled.
Please note their "coreboot" is simply a shim loader layer, the
hardware init is done by the intel FSP binary blob moving the trust
layer from the vendor+intel to just intel which I argue is not a real
improvement to justify the high price of their devices.

https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
https://goblinrefuge.com/mediagoblin/u/onpon4/m/what-purism-s-road-to-fsf-ryf-endorsement-chart-should-look-like/

Google tried to get intel to free ME, if they can't do it then no one 
can.


System76, Purism etc are all using me_cleaner a tool which they didn't
develop so you can buy pretty much any laptop and get the same results
if ME is your only concern although considering the massive security
problems with intel CPU's now I wouldn't buy one.

My laptop recommendation as always is a lenovo G505S, no ME/PSP and
coreboot with open source cpu/ram init (blobs for video/power, but are
removable due to no hardware code signing enforcement unlike intel or
new amd stuff). It works with Qubes 4.0.

For a desktop/workstation I recommend the libre firmware available
KCMA-D8/KGPE-D16 (coreboot with entirely open source hardware init)
they also feature OpenBMC for libre remote management.


As I understood it, its not *totally* disabled but is *partially* 
disabled (like the TCP/IP stack).
Anyway. Your KGPE-D16 suggestion is interesting (thx!), and that mobo+ a 
12core 2014 opteron seems like it would be fairly speedy? Certainly 
compared to my old i3/8gb tower. This may sound silly but in the VM 
context, would a 12 core processor be excessive or would it be "fully 
utilized" by Qubes?


--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/663a4163cee48ba6c31a1f9c548f0185%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How to get to command line for dom0?

2018-01-20 Thread Kyle Breneman
I am trying to follow these steps
 to upgrade
from Fedora 23 to Fedora 24 (and then from 24 to 26), but I got stuck right
away because I cannot figure out how to get to a command line window for
dom0.  Can someone please tell me, or point to documentation which
explains?  I've done several web searches without finding an answer.

Kyle

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOtZr%3DFEG%2BBqYV%3DT%3DGgjGaNB7XzaAZBaOm4YTybd4QBOpxnPww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread Demi Obenour
Another thought I had was to do binary translation of GPU instructions
and/or Software Fault Isolation a la NaCl.

On Jan 20, 2018 10:29 AM, "Vít Šesták" <
groups-no-private-mail--contact-me-at--contact.v6ak@v6ak.com> wrote:

> When Qubes gets a separate GUIVM, the risks of GUI virtualization could
> become lower, because the GUIVM is expected to be more up-to-date (and thus
> have recent security updates for the drivers) than the current dom0.
>
> The GUI virtualization should be optional (so user can choose the
> reasonable tradeoff). This can be actually good for security provided that
> the choice is informed. User that wants some GPU-insentive tasks will now
> probably choose Ubuntu (or dualboot) over Qubes. None of them are better
> choices than allowing to take some risks for some VMs.
>
> Before GUIVM is implemented, it probably does not make much sense to
> implement GPU virtualization, because it would make additional maintenance
> effort for ITL.
>
> GPU passthrough (that can be also used with some less secure approach of
> GPU virtualization) might be a reasonable addition for some people, but not
> as a general solution for all Qubes users, because external monitors often
> connected to the dedicated GPU*. Not mentioning laptops with just one GPU.
> (Those can be more common for Linux and Qubes users.)
>
> I foresee a GPUVM in VM settings (like today's NetVM in VM settings).
>
> Regards,
> Vít Šesták 'v6ak'
>
>
> *) I honestly don't know the reason for that. In the past, I had laptop
> with three graphical outputs (screen, VGA and HDMI). Since the old
> integrated GPU was able only two of them, it makes sense that one of the
> outputs goes through the dedicated cards. The last time I checked, it
> however looks like this should be no longer a problem. Today's Intel CPUs
> seem to often support three displays (quickly verified on Intel ARK on few
> random CPUs), while today's laptops tend to have just two outputs (internal
> and HDMI).
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/qubes-users/l2oqYEWpY-A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/qubes-users/3a20b39b-7ee8-43ca-9cfc-1d5e2ed26f18%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJEMUN9qXq71yxmUjSbTNutjWQV7ywDzYMjZcO6OqUrtc12qiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

2018-01-20 Thread Lorenzo Lamas
On Wednesday, January 17, 2018 at 10:29:18 PM UTC+1, Ilpo Järvinen wrote:
> On Wed, 17 Jan 2018, Lorenzo Lamas wrote:
> 
> > On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote:
> > > ## Qubes 3.2
> > > 
> > > For Qubes 3.2, we plan to release an update that will make almost all
> > > VMs run in a fully-virtualized mode. Specifically, we plan to backport
> > > PVH support from Qubes 4.0 and enable it for all VMs without PCI
> > > devices. After this update, all VMs that previously ran in PV mode (and
> > > that do not have PCI devices) will subsequently run in PVH mode, with
> > > the exception of stub domains. Any HVMs will continue to run in HVM
> > > mode.
> > 
> > Is this the shim-based approach from XSA-254?
> 
> No, it won't be a shim-based approach (see also the Marek's mail in this 
> thread).
> 
> > Then it should be made clear that the VM's will be more vulnerable to 
> > Meltdown: 
> 
> Even if shims would be used, that "more" claim is false as Meltdown 
> against the host hypervisor from PVs that are currently used in R3.2 
> expose both host and also the guest through the host hypervisor (its 
> memory). With shims only the guest is still vulnerable, this time through 
> the intermediate xen instance running in the HVM/PVH encapsulating the PV 
> guest. Clearly it's "less" vulnerable rather than "more".
> 
> Qubes has been trying to migrate away from PVs altogether (rather than 
> e.g., placing PVs into those shims) due to PV vulnerabilities in general. 
> In fact, even before these HW vulnerabilities were discovered, the process 
> towards PVH was ongoing which is why R4.0 rcs as is are much better 
> protected already. These vulnerabilities only accelerated this process.
> There will be, unfortunately, be one limitation to this migration still 
> due to PCI passthrough: VMs with PCI devices need to remain PV (or their 
> stubdoms in R4.0).
> 
> > "Note this shim-based approach prevents attacks on the host, but leaves
> > the guest vulnerable to Meltdown attacks by its own unprivileged
> > processes; this is true even if the guest OS has KPTI or similar
> > Meltdown mitigation."
> > https://xenbits.xen.org/xsa/xsa254/README.which-shim
> 
> Also, note that one of the fundamental assumption with Qubes security 
> model is that the VMs _will get compromised_ (regardless of HW exploits). 
> What Qubes aims to protect against is escalation from a compromised VM
> to host or to another VM.
> 
> 
> -- 
>  i.

Thank you for clarifying this.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f08a8a34-859b-4cbe-b8aa-aa9f54e15f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Another "Best Hardware" 4 VMs setup question.

2018-01-20 Thread taii...@gmx.com

On 01/20/2018 02:08 PM, Davidson wrote:



I just forgot. I noticed that some places (librem I think, and 
System76 
) 
are selling computers with ME (partially) disabled on their intel 
procs, does anyone know about either buying just procs or mobo/proc 
combos with (partially) disabled intel ME procs?



Purism is a scam, ME can't be disabled.
Please note their "coreboot" is simply a shim loader layer, the hardware 
init is done by the intel FSP binary blob moving the trust layer from 
the vendor+intel to just intel which I argue is not a real improvement 
to justify the high price of their devices.


https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
https://goblinrefuge.com/mediagoblin/u/onpon4/m/what-purism-s-road-to-fsf-ryf-endorsement-chart-should-look-like/

Google tried to get intel to free ME, if they can't do it then no one can.

System76, Purism etc are all using me_cleaner a tool which they didn't 
develop so you can buy pretty much any laptop and get the same results 
if ME is your only concern although considering the massive security 
problems with intel CPU's now I wouldn't buy one.


My laptop recommendation as always is a lenovo G505S, no ME/PSP and 
coreboot with open source cpu/ram init (blobs for video/power, but are 
removable due to no hardware code signing enforcement unlike intel or 
new amd stuff). It works with Qubes 4.0.


For a desktop/workstation I recommend the libre firmware available 
KCMA-D8/KGPE-D16 (coreboot with entirely open source hardware init) they 
also feature OpenBMC for libre remote management.


--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3fc73e8e-81f7-2bc6-8bb2-08dd0e1134e4%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Another "Best Hardware" 4 VMs setup question.

2018-01-20 Thread Davidson



On 01/20/2018 01:51 PM, Stumpy wrote:
I have been reading through the forum about the various 
recommendations for hardware. The general consensus seems to be "more 
mem and ssd drive". I am running 3.2, have 16gb mem, and a Samsung ssd 
drive and it still takes 10 sec (timed it) to put up a terminal in a 
new vm. While I can tolerate that I'm really wanting to explore 
options that can give me a faster start up for apps (and appvms). Its 
been awhile since I bought my CPU so I can't remember what it is 
beyond a i5, if the /proc/cpuinfo is right (its a bit confusing for me 
as I don't understand if its showing the nfo for the proc or a virtual 
proc?) then I have a Intel Core i5-4570 CPU @ 3.20GHz and it displays 
for processor 0 and processor 1 so I will go out on a limb and assume 
its a dual core?


Considering my current setup, and the fact that I wholly plan on 
upgrading to qubes v4 once its stable, and that I am willing to fork 
out for a new system (though with a pretty limited budget ~500) could 
anyone make suggestions on the most logical route to take? (hopefully 
not "grin and bear it").

Cheers

PS I have 30 VMs BUT don't usually run more than 10 at a time (due to 
mem i guess) but would probably run about 15 regularly if I could.


I just forgot. I noticed that some places (librem I think, and System76 
) 
are selling computers with ME (partially) disabled on their intel procs, 
does anyone know about either buying just procs or mobo/proc combos with 
(partially) disabled intel ME procs?


--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0969c612-8160-951d-099d-b336628f463c%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: [qubes-devel] Qubes Controller as the new Qubes-Manager

2018-01-20 Thread Davidson



On 01/06/2018 06:27 AM, 'Tom Zander' via qubes-users wrote:

On Saturday, 6 January 2018 00:11:43 GMT Franz wrote:

I would add some way to make some order in the
applVM list, so that a standard view may show only the most commonly used
VMs, while rarely used VMs are hidden and shown only clicking a button. To
do that, there should be a flag to differentiate the visibility of VMs.

I made a start with this based on my own usage; See the attached
screenshots.
Going from screenshot1 (showing all my qubes) to 5 by removing ones based
on;
* being templates for disposable VMs. (you likely never want to start them
after initial configuration).
* being a "network" VM.
* Being a template.
* Being halted.

Naturally you can combine those settings in any way you want to show the
subsection of qubes you use.
I expect that I''l end up using the settings as "snapshot4" shows it most of
the time.
  

This may be helpful also in a corporate environment when an administrator
can decide which VMs should be shown and which should be hidden.

This is a great idea, I recall that root added tags in 4.0. I have not tried
them yet, but it sounds like a good fit.

Thanks for the ideas!


Hey, thanks again for your work, much appreciated.

Another thought just occurred to me, a collapsible tree like option. I 
have like "work" VMs (one for libre office stuff, another for email, 
another for vid confer) and for general communications (one for IRC, 
another for Signal, another for personal email) and anon stuff (crypto 
wallets, email via tor, browser, etc), the list I have is really quite 
long and I find myself sorting/re-sorting naming etc. I use tree-style 
addon in firefox which has the fantastic option to let you stack tabs 
among other things, considering that and how I have my file manager 
setup to show a tree of the folders I have it would really be quite 
handy to organize VMs into a collapsible tree.

Just a thought :)

--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/088ebdd6-d9fa-6e94-e55b-2b0ecedea6d0%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Another "Best Hardware" 4 VMs setup question.

2018-01-20 Thread Stumpy
I have been reading through the forum about the various recommendations 
for hardware. The general consensus seems to be "more mem and ssd 
drive". I am running 3.2, have 16gb mem, and a Samsung ssd drive and it 
still takes 10 sec (timed it) to put up a terminal in a new vm. While I 
can tolerate that I'm really wanting to explore options that can give me 
a faster start up for apps (and appvms). Its been awhile since I bought 
my CPU so I can't remember what it is beyond a i5, if the /proc/cpuinfo 
is right (its a bit confusing for me as I don't understand if its 
showing the nfo for the proc or a virtual proc?) then I have a Intel 
Core i5-4570 CPU @ 3.20GHz and it displays for processor 0 and processor 
1 so I will go out on a limb and assume its a dual core?


Considering my current setup, and the fact that I wholly plan on 
upgrading to qubes v4 once its stable, and that I am willing to fork out 
for a new system (though with a pretty limited budget ~500) could anyone 
make suggestions on the most logical route to take? (hopefully not "grin 
and bear it").

Cheers

PS I have 30 VMs BUT don't usually run more than 10 at a time (due to 
mem i guess) but would probably run about 15 regularly if I could.


--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/083f00687d53c404ad2b2a5515974bac%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: XFCE Settings menu gone

2018-01-20 Thread beso
I have same problem.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/39a1d83f-11c6-433f-9c1e-20abbdbf7276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Using fedora-26-minimal sys-vms

2018-01-20 Thread '[799]' via qubes-users
Hello,

I want to use fedora-26-minimal based sys-vms and followed the documentation 
(https://www.qubes-os.org/doc/templates/fedora-minimal )

I have updated the default fedora-26-minimal template and installed all 
packages mentioned in the docs (Qubes 4.0 part of the above documentation link) 
plus all firmware packages.

What do I need to install to get the network manager icon working?

NetworkManager is installed in the template and I have verified in the sys-net 
VM that it is running:

systemctl status NetworkManager

Says: active (running)

I tried to start NetworkManager from command line, but got the message:

You must be root to run NetworkManager.

I then started a xterm from dom0 as the Root user:

qvm-start -u root sys-net NetworkManager but nothing happened. I also try to do 
this from a xterm session (qvm-start -u root sys-net xterm).

Any ideas how to get a sys-net which has a working network manager?

[799]

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/BbBUvPEuJO1mn1_nuijkn0vBxPn5xAorFclHFOsQUwXeKtaNWwMhl8VHFATTVmmwWbXI2Nd8SGeKn6YPoIJ7n5XvDKzRXgdfSCt4PGZkxU8%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] files /etc/yum.repos.d/fedora.repo and fedora-updates.repo ?

2018-01-20 Thread Chris Laprise

On 01/20/2018 10:41 AM, ThierryIT wrote:

Hi,

Let's try to be clear ...
I have installed few weeks  ago anti-evil-maid package + dependencies.
I have had several problem with it ...
When checking what packages are installed, I can see that they all have as common 
denominator "fc23" (as exemple: tboot 1:1.8.2-3.fc23)
I don't want to install any packages links to this templates version (23) but 
move to v26 ..
When checking fedora.repo and fedora-updates.repo they are both link to fc23.
How to  move properly  to fc26 ?

Thx



Those package versions are for dom0, not regular guest VMs. The dom0 VM 
will remain fc23 on Qubes 3.2 even when the guest VM templates are 
properly upgraded to fc26.



--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5fb0f133-40bb-6c3b-1824-c91fcc09ad0b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] files /etc/yum.repos.d/fedora.repo and fedora-updates.repo ?

2018-01-20 Thread ThierryIT
Hi,

Let's try to be clear ...
I have installed few weeks  ago anti-evil-maid package + dependencies.
I have had several problem with it ...
When checking what packages are installed, I can see that they all have as 
common denominator "fc23" (as exemple: tboot 1:1.8.2-3.fc23)
I don't want to install any packages links to this templates version (23) but 
move to v26 .. 
When checking fedora.repo and fedora-updates.repo they are both link to fc23.
How to  move properly  to fc26 ?

Thx

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9933ed02-e946-4241-ad98-dcf14422d68f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread Vít Šesták
When Qubes gets a separate GUIVM, the risks of GUI virtualization could become 
lower, because the GUIVM is expected to be more up-to-date (and thus have 
recent security updates for the drivers) than the current dom0.

The GUI virtualization should be optional (so user can choose the reasonable 
tradeoff). This can be actually good for security provided that the choice is 
informed. User that wants some GPU-insentive tasks will now probably choose 
Ubuntu (or dualboot) over Qubes. None of them are better choices than allowing 
to take some risks for some VMs.

Before GUIVM is implemented, it probably does not make much sense to implement 
GPU virtualization, because it would make additional maintenance effort for ITL.

GPU passthrough (that can be also used with some less secure approach of GPU 
virtualization) might be a reasonable addition for some people, but not as a 
general solution for all Qubes users, because external monitors often connected 
to the dedicated GPU*. Not mentioning laptops with just one GPU. (Those can be 
more common for Linux and Qubes users.)

I foresee a GPUVM in VM settings (like today's NetVM in VM settings).

Regards,
Vít Šesták 'v6ak'


*) I honestly don't know the reason for that. In the past, I had laptop with 
three graphical outputs (screen, VGA and HDMI). Since the old integrated GPU 
was able only two of them, it makes sense that one of the outputs goes through 
the dedicated cards. The last time I checked, it however looks like this should 
be no longer a problem. Today's Intel CPUs seem to often support three displays 
(quickly verified on Intel ARK on few random CPUs), while today's laptops tend 
to have just two outputs (internal and HDMI).

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3a20b39b-7ee8-43ca-9cfc-1d5e2ed26f18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread Foppe de Haan
On Saturday, January 20, 2018 at 2:53:38 PM UTC+1, Alex Dubois wrote:
> On Saturday, 20 January 2018 09:40:36 UTC, Foppe de Haan  wrote:
> > On Saturday, January 20, 2018 at 9:38:06 AM UTC+1, Alex Dubois wrote:
> > > On Thursday, 18 January 2018 22:56:10 UTC, Tom Zander  wrote:
> > > > On Sunday, 14 January 2018 08:12:24 CET r...@tuta.io wrote:
> > > > > Is qubes able to use the computing power of the gpu or is the type of 
> > > > > gpu
> > > > > installed a waste in this issue?
> > > > 
> > > > Relevant here is an email I wrote recently;
> > > > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > > 
> > > I'll reply in that thread about this to stay in topic.
> > > 
> > > But in few words: Not possible until GPU virtualization to have a 
> > > trustable solution.
> > > 
> > > > 
> > > > The context is a GSoC proposal proposal to modernize the painting 
> > > > pipeline of Qubes.
> > > > 
> > > > Today GL using software uses [llvmpipe] to compile and render GL inside 
> > > > of 
> > > > a Qube, completely in software and then push the 2d image to dom0.
> > > > This indeed wastes the GPU.
> > > > 
> > > > 
> > > > [llvmpipe]: 
> > > > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > > > 
> > > > -- 
> > > > Tom Zander
> > > > Blog: https://zander.github.io
> > > > Vlog: https://vimeo.com/channels/tomscryptochannel
> > 
> > Since I am unable to estimate the security aspects of any given approach, 
> > and you do, have you seen this approach? 
> > https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387
> 
> I am not member of the Qubes core team, I am an avid user/developer and 
> believer :) so my view is only mine...
> The project you mention is doing a great job (for a VMWare workstation type 
> set-up), however as far as I understood the copy is from/to the same GPU. 
> This is where I am NOT comfortable with. As explained the client VM would 
> issue processing requests to the GPU (and may abuse it).
> 
> However, using their work to copy from one GPU (assigned to ONE VM) to Dom0 
> GPU could be good. However you still have the problem with the BW on the bus 
> (luckily depending on your hardware build 2 different buses (your 2 cards are 
> on different PCIe lines). You will not get 144Hz but 60Hz is within reach. 
> Temptation to compress the stream will be there, the decompression code will 
> be in the attack surface.

Thanks for looking at it, and your thoughts. :)

To clarify: their idea indeed is to use two GPUs, since SR-IOV support simply 
isn't an option for regular users (due to artificial market segmentation), and 
according to them, any dom0 GPU that supports PCIe gen3 x4 can handle up to 
4k60 at least.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8d621fb6-33e9-4f19-b5e0-886bd5c759df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread Alex Dubois
On Saturday, 20 January 2018 09:40:36 UTC, Foppe de Haan  wrote:
> On Saturday, January 20, 2018 at 9:38:06 AM UTC+1, Alex Dubois wrote:
> > On Thursday, 18 January 2018 22:56:10 UTC, Tom Zander  wrote:
> > > On Sunday, 14 January 2018 08:12:24 CET r...@tuta.io wrote:
> > > > Is qubes able to use the computing power of the gpu or is the type of 
> > > > gpu
> > > > installed a waste in this issue?
> > > 
> > > Relevant here is an email I wrote recently;
> > > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > 
> > I'll reply in that thread about this to stay in topic.
> > 
> > But in few words: Not possible until GPU virtualization to have a trustable 
> > solution.
> > 
> > > 
> > > The context is a GSoC proposal proposal to modernize the painting 
> > > pipeline of Qubes.
> > > 
> > > Today GL using software uses [llvmpipe] to compile and render GL inside 
> > > of 
> > > a Qube, completely in software and then push the 2d image to dom0.
> > > This indeed wastes the GPU.
> > > 
> > > 
> > > [llvmpipe]: 
> > > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > > 
> > > -- 
> > > Tom Zander
> > > Blog: https://zander.github.io
> > > Vlog: https://vimeo.com/channels/tomscryptochannel
> 
> Since I am unable to estimate the security aspects of any given approach, and 
> you do, have you seen this approach? 
> https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387

I am not member of the Qubes core team, I am an avid user/developer and 
believer :) so my view is only mine...
The project you mention is doing a great job (for a VMWare workstation type 
set-up), however as far as I understood the copy is from/to the same GPU. This 
is where I am NOT comfortable with. As explained the client VM would issue 
processing requests to the GPU (and may abuse it).

However, using their work to copy from one GPU (assigned to ONE VM) to Dom0 GPU 
could be good. However you still have the problem with the BW on the bus 
(luckily depending on your hardware build 2 different buses (your 2 cards are 
on different PCIe lines). You will not get 144Hz but 60Hz is within reach. 
Temptation to compress the stream will be there, the decompression code will be 
in the attack surface.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/553b21c0-cc0c-47f6-b9e1-2ba03762164f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread 'Tom Zander' via qubes-users
On Saturday, 20 January 2018 10:40:36 CET Foppe de Haan wrote:
> Since I am unable to estimate the security aspects of any given approach,
> and you do, have you seen this approach?
> https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122
> 387

That looks exactly like the approach my (very naive) proposal was thinking 
of; but these guys actually seem to know their GL and went ahead
and did it :)

Their proof-of-concept showing that the result is *faster* (much less 
bandwidth) than the Qubes approach is very exciting.

Thanks for the link!
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1829903.i5khPQVWEZ%40mail.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Moving dom0 screenshots immediately to VMs

2018-01-20 Thread Alex Dubois
On Saturday, 20 January 2018 06:21:36 UTC, Jean-Philippe Ouellet  wrote:
> On Fri, Jan 19, 2018 at 3:55 AM,   wrote:
> > I've been working on a solution for this, but unfortunately there are too 
> > many factors that I'm not familiar with.
> >
> > My goal is to to able to:
> >
> > 1) Take a screenshot using the dom0 hotkey
> > 2) In the "Screenshot" dialogue, select a script from the "Open with:" 
> > option
> > 3) A text entry box that prompts me for the destination VM
> > 4) The screenshot is sent to the indicated VM
> >
> > I think this can be accomplished with
> >
> > .desktop application file
> > zenity
> > qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
> >
> > but I'm lost in the details.
> >
> > Current problems
> >
> > - I can't get dom0 to include my .desktop application files as "Open with:" 
> > options in the "Screenshot" dialogue
> > - I'm not sure what format the screenshot is in initially... will the 
> > .desktop application receive a bunch of bits? Or the path to a temporary 
> > file?
> > - I can figure out how to pipe the screenshot if it's a file, but I don't 
> > know how to handle a "bunch of bits" scenario
> >
> > Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
> > looks great, but the code is too complicated for me to review and I just 
> > need basic functionality anyway. 
> > https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh
> 
> This problem has already been solved, but upstreaming it was stalled
> for some policy reasons. See here:
> https://github.com/QubesOS/qubes-issues/issues/953
> 
> My implementation can be found here:
> https://github.com/jpouellet/qubes-screenshot-helper
> 
> Regards,
> Jean-Philippe

Ah great. I like this implementation. Reviewing the code it does not seem to 
introduce any risk and provide all the functionality required.

Could you explain briefly the steps to install (after the git pull).

May I also ask you for some help/pointer on a yubikey package I've done. I just 
need to do the packaging and it may save me some time if you were to give me 
few pointers...

Project is here... the doc state that it is packages, but it is not (yet)...
https://github.com/adubois/qubes-app-linux-yubikey

Please reply in that thread if you want:
https://groups.google.com/forum/#!topic/qubes-users/BkdTuXZZnwE

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7ee007f3-e478-469b-90f5-f3f140275fa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread Foppe de Haan
On Saturday, January 20, 2018 at 9:38:06 AM UTC+1, Alex Dubois wrote:
> On Thursday, 18 January 2018 22:56:10 UTC, Tom Zander  wrote:
> > On Sunday, 14 January 2018 08:12:24 CET r...@tuta.io wrote:
> > > Is qubes able to use the computing power of the gpu or is the type of gpu
> > > installed a waste in this issue?
> > 
> > Relevant here is an email I wrote recently;
> > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> 
> I'll reply in that thread about this to stay in topic.
> 
> But in few words: Not possible until GPU virtualization to have a trustable 
> solution.
> 
> > 
> > The context is a GSoC proposal proposal to modernize the painting 
> > pipeline of Qubes.
> > 
> > Today GL using software uses [llvmpipe] to compile and render GL inside of 
> > a Qube, completely in software and then push the 2d image to dom0.
> > This indeed wastes the GPU.
> > 
> > 
> > [llvmpipe]: 
> > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > 
> > -- 
> > Tom Zander
> > Blog: https://zander.github.io
> > Vlog: https://vimeo.com/channels/tomscryptochannel

Since I am unable to estimate the security aspects of any given approach, and 
you do, have you seen this approach? 
https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cdb0d122-d579-4e60-b8d2-db991efa10fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

2018-01-20 Thread Alex Dubois
On Thursday, 18 January 2018 22:56:10 UTC, Tom Zander  wrote:
> On Sunday, 14 January 2018 08:12:24 CET r...@tuta.io wrote:
> > Is qubes able to use the computing power of the gpu or is the type of gpu
> > installed a waste in this issue?
> 
> Relevant here is an email I wrote recently;
> https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ

I'll reply in that thread about this to stay in topic.

But in few words: Not possible until GPU virtualization to have a trustable 
solution.

> 
> The context is a GSoC proposal proposal to modernize the painting 
> pipeline of Qubes.
> 
> Today GL using software uses [llvmpipe] to compile and render GL inside of 
> a Qube, completely in software and then push the 2d image to dom0.
> This indeed wastes the GPU.
> 
> 
> [llvmpipe]: 
> https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bde05d64-6516-432a-8a2b-120ee64797cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.