Re: [qubes-users] High End Compatible Qubes Laptop

[taii...@gmx.com]

On 12/17/2017 11:37 AM, hirenpatel...@gmail.com wrote:


What is the best laptop I can get (less than $4k) which will work with Qubes 3 
& 4?

Define best? What do you want to do?

I would get a Lenovo G505S, it is owner controlled (no ME/PSP) and 
supports coreboot with open source silicon init.

It has more than enough speed to run normal laptop tasks.

--
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/c7efd04a-ff88-78d7-6c2d-21b815e5c8eb%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?

[Michael Siepmann]

 On 12/17/2017 08:33 AM, Chris Laprise wrote:
> On 12/17/2017 09:45 AM, Michael Siepmann wrote:
>
>> Recently the "LINK IS UP" notification has been staying visible until I
>> manually close it.  At first it wasn't doing that. Are you seeing that
>> too? Could a recent update have caused this?
>
> Yes, I'm seeing it again on fedora-26 but not debian-9. This has been
> an off-and-on issue with notify-send over the years.
>
I tried changing the template for my sys-vpn to debian-9 but the VPN
service didn't work. However, when I switched it back to fedora-25 (I'm
not using 26 yet) the persistent notification issue was fixed! (When the
issue was happening, btw, it was only with the "up" notifications, not
the "down" ones.)

-- 
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/2a50762d-53d4-dcd1-84bf-8786c9042e47%40TechDesignPsych.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] DMA attacks are possible not only via USB?!

[Chris Laprise]

On 12/17/2017 03:23 PM, 'Chris' via qubes-users wrote:

It seems as if Qubes OS is useless in protecting against hardware 
access. Even with TPM, I am not sure how realistic it is. Will AEM be 
triggered when changing USB controllers or adding hostile USB devices to 
the one whilelisted controller that manages the AEM device? If not, what 
is the point of AEM? How is AEM any better than simply putting the 
bootloader on a separate disk? Okay, it gives a bit better piece of mind 
that really MY bootloader was used, but that is about it, right? It 
won't help against someone adding compromised devices to a PCI-E slot or 
USB?!


Any links or help here? Btw, its really hard to find any useful 
information via Google about most topics regarding Qubes OS. Is Qubes OS 
somehow downranked intentionally?


Welcome to Qubes, circa 2012. :)

If you dig into old listgroup posts, you'll see this topic covered over 
and over again. Much of the discussion is based-on or references 
Joanna's (@rootkovska) blog posts:


https://blog.invisiblethings.org/index.html

TL;dr - AEM protects you only within a margin where an attacker (e.g. 
Evil Maid) isn't terribly skilled and has only a brief window of time to 
attack. Beyond that, we are *still* talking about physical access here.


Another data point is the HCL. If you look for entries by "Qubes core 
developers" you should notice all of those systems are Laptops! Qubes is 
rather laptop-centric because they are more integrated and more 
difficult to subvert in a piecemeal fashion. IIRC Joanna has recommended 
PC laptops as preferable because of keyboards that are not only 
integrated, but also PS/2 (non-USB).


Add to that a sprinkling of discussion about making motherboards more 
tamper-evident.


So there is a certain level of pragmatism when it comes to physical 
security. The fact that Qubes was released for PC hardware should not be 
taken as a sign that the Qubes community regards current PC architecture 
as having very good security. Qubes tries to make the best out of a bad 
situation, and even the core devs want better-designed hardware.


Finally, there is the notion that if someone is resourceful enough to 
trick your TPM, then "you probably have bigger problems than PC security 
anyway". Its sort of an infosec cop-out, but there's some truth to it.


--

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/d31014d4-94a5-222f-7489-c98e274a05f5%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Ethernet port in an USB-C dock - failure to attach to sys-net

[Kristian Elof Sørensen]

> what does lsusb in sys-usb show? What's the listed device class?

[user@sys-usb ~]$ lsusb -s 003:013 -v

Bus 003 Device 013: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit
Ethernet
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass  255 Vendor Specific Class
  bDeviceSubClass   255 Vendor Specific Subclass
  bDeviceProtocol 0 
  bMaxPacketSize0 9
  idVendor   0x0b95 ASIX Electronics Corp.
  idProduct  0x1790 AX88179 Gigabit Ethernet
  bcdDevice1.00
  iManufacturer   1 
  iProduct2 
  iSerial 3 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   57
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol  0 
  iInterface  4 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  11
bMaxBurst   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst   3
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  15

-- 
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/1513542636.996.7.camel%40elof.dk.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] DMA attacks are possible not only via USB?!

['Chris' via qubes-users]

Hi,

I am wondering a bit what this USB & NetVM shielding are really buying me. I am 
switching from a laptop to a desktop, so it may remain unattended for quite a 
while and thus could be exposed to hardware access... The hardware access will 
be mild, meaning I could imagine someone to compromise a bootloader or install 
a malicious device.

Now say that install an internal USB controller to which I connect an SD-Card 
reader, which in turn uses Anti-Evil-Maid to boot the machine. This controller 
needs to be whitelisted. But since it is internal and will only provide one 
slot for the card reader, the machine will not boot properly without this 
setup. Still, someone could compromise this setup.

So lets say I had a PCI-Express card reader, which seems to not be available 
for desktops... Wouldn't this pose the same problem? PCI-Express also has DMA 
access. How does Qubes know that a particular PCI-Express device can be safely 
attached to Dom0 (like a SD card reader on a laptop, which is usually 
PCI-Express)? If the PCI-Express device is compromised, wouldn't it compromise 
Dom0?

Anyway I am trying to wrap my head around what I can and can not protect 
against.

It seems as if Qubes OS is useless in protecting against hardware access. Even 
with TPM, I am not sure how realistic it is. Will AEM be triggered when 
changing USB controllers or adding hostile USB devices to the one whilelisted 
controller that manages the AEM device? If not, what is the point of AEM? How 
is AEM any better than simply putting the bootloader on a separate disk? Okay, 
it gives a bit better piece of mind that really MY bootloader was used, but 
that is about it, right? It won't help against someone adding compromised 
devices to a PCI-E slot or USB?!

Any links or help here? Btw, its really hard to find any useful information via 
Google about most topics regarding Qubes OS. Is Qubes OS somehow downranked 
intentionally?

Cheers
Chris

-- 
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/suUnD0yJpvEF22zlFlIRDF10NkbqtaPsbbmZwiQz0lErvA9-HmGLGX49d_s7GjytL7x3hy84XNR33F_Ip6P3pOzaNtWFHqAkfuw9FM1qX-E%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Ethernet port in an USB-C dock - failure to attach to sys-net

[Yethal]

W dniu niedziela, 17 grudnia 2017 21:08:38 UTC+1 użytkownik Kristian Elof 
Sørensen napisał:
> > You shouldn't have to do that, sys-usb is a NetVM by default.
> > 
> 
> Interesting.
> 
> the sys-usb is indeed listes as "Type: NetVM"
> 
> However the ethernet device does not show up when running ifconfig or the 
> "Network Connections" gui program.
> 
> When plugging in the USB-C dock, I see this:
> 
> [user@sys-usb ~]$ sudo dmesg -w
> ...
> [22271.385720] usb 3-1.2.4: new SuperSpeed USB device number 9 using xhci_hcd
> [22271.404341] usb 3-1.2.4: New USB device found, idVendor=0b95, 
> idProduct=1790
> [22271.404371] usb 3-1.2.4: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [22271.404389] usb 3-1.2.4: Product: AX88179
> [22271.404401] usb 3-1.2.4: Manufacturer: ASIX Elec. Corp.
> [22271.404412] usb 3-1.2.4: SerialNumber: 01
> [22271.739817] ax88179_178a 3-1.2.4:1.0 eth0: register 'ax88179_178a' at 
> usb-:00:00.0-1.2.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 
> 60:45:cb:bd:16:c8
> [22271.803545] ax88179_178a 3-1.2.4:1.0 enp0s0f0u1u2u4: renamed from eth0
> 
> [user@sys-usb ~]$ /sbin/ifconfig 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1  (Local Loopback)
> RX packets 36  bytes 2016 (1.9 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 36  bytes 2016 (1.9 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> No other network device than "lo" is listed? I would have expected either 
> eth0 or enp0s0f0u1u2u4 ?
> 
>   Kristian

what does lsusb in sys-usb show? What's the listed device class?

-- 
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/3221aaef-c9bf-463e-854e-4f33c83b67b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Ethernet port in an USB-C dock - failure to attach to sys-net

[Kristian Elof Sørensen]

> You shouldn't have to do that, sys-usb is a NetVM by default.
> 

Interesting.

the sys-usb is indeed listes as "Type: NetVM"

However the ethernet device does not show up when running ifconfig or the 
"Network Connections" gui program.

When plugging in the USB-C dock, I see this:

[user@sys-usb ~]$ sudo dmesg -w
...
[22271.385720] usb 3-1.2.4: new SuperSpeed USB device number 9 using xhci_hcd
[22271.404341] usb 3-1.2.4: New USB device found, idVendor=0b95, idProduct=1790
[22271.404371] usb 3-1.2.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[22271.404389] usb 3-1.2.4: Product: AX88179
[22271.404401] usb 3-1.2.4: Manufacturer: ASIX Elec. Corp.
[22271.404412] usb 3-1.2.4: SerialNumber: 01
[22271.739817] ax88179_178a 3-1.2.4:1.0 eth0: register 'ax88179_178a' at 
usb-:00:00.0-1.2.4, ASIX AX88179 USB 3.0 Gigabit Ethernet, 60:45:cb:bd:16:c8
[22271.803545] ax88179_178a 3-1.2.4:1.0 enp0s0f0u1u2u4: renamed from eth0

[user@sys-usb ~]$ /sbin/ifconfig 
lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 36  bytes 2016 (1.9 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 36  bytes 2016 (1.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

No other network device than "lo" is listed? I would have expected either eth0 
or enp0s0f0u1u2u4 ?

Kristian

-- 
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/1513541309.996.6.camel%40elof.dk.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Ethernet port in an USB-C dock - failure to attach to sys-net

[Yethal]

W dniu niedziela, 17 grudnia 2017 20:04:33 UTC+1 użytkownik Kristian Elof 
Sørensen napisał:
> Hello
> 
> I'm trying to make a Gigabit Ethernet port in an USB-C dock available to 
> sys-net
> 
> How come this does not work? My mistake or hardware not fully supported by 
> kernel/qubes?
> 
> Qubes 3.2
> Linux kernel 4.9.56-21
> Asus SimPro Dock https://www.asus.com/Docks/ASUS-SimPro-Dock/specifications/
> 
> [user@sys-usb ~]$ lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 005: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit 
> Ethernet
> 
> 
> [username@dom0 ~]$ qvm-usb 
> sys-usb:3-1.2.4   0b95:1790 ASIX_Elec._Corp._AX88179_01
> sys-usb:2-1.3 1fc9:500d NXP_SIMPRODOCK_PD_2.100_098e0695
> sys-usb:2-1.2.3   0bda:4040 Generic_USB_Audio_201405280001
> sys-usb:2-8   8087:0a2b 8087_0a2b
> 
> [username@dom0 ~]$ qvm-usb -a sys-net sys-usb:3-1.2.4
> ERROR: Device attach failed: /usr/lib/qubes/usb-import: line 37: [: sta: 
> integer expression expected/usr/lib/qubes/usb-import: line 51: printf: write 
> error: Invalid argument

You shouldn't have to do that, sys-usb is a NetVM by default.

-- 
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/bab475bf-a449-4994-8e09-7089eac2a875%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora 26 VLC/mplayer fullscreen problem

[donoban]

Hi,

since Fedora 25 reached his EOL I have upgraded to Fedora 26 and I am 
having a problem with VLC.


When I go to fullscreen mode the video gets the full area of the window 
but the size of the window is unchanged . If I maximize it, it doesn't 
get the whole screen. It doesn't get the top panel like an standard 
maximize of another window.


Wondering if it could be a Fedora or VLC problem instead Qubes related I 
tested mplayer too getting the same behavior.


I have allow_fullscreen = true for all VM's, also this VM doesn't have 
this problem with debian or fedora 25 templates.


Any idea?


--
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/d5471f25-1cbb-656f-3484-b81a69a63efd%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [3.2] HCL report for Inspiron 15-5578 (AKA 15z Touch)

[Vít Šesták]

Even though the MoBo officially supports up to 16 GiB of RAM, I've tried 32 GiB 
of RAM without any apparent issues.

There was one 16 GiB module and one free slot, so I have bought exactly the 
same model (Hynix HMA82GS6AFR8N-UH) and it just works. There is official 
(dis)assembly guide. The hardest part of the installation was disconnecting the 
battery from MoBo, because the connector is very stiff.

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

-- 
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/7385077b-2947-4986-8a09-a93ff3063402%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] High End Compatible Qubes Laptop

[hirenpatelxyc]

What is the best laptop I can get (less than $4k) which will work with Qubes 3 
& 4?

 

-- 
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/7e0af4e8-e041-4ca8-a79e-b1b19c1a1dee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?

[Chris Laprise]

On 12/17/2017 09:45 AM, Michael Siepmann wrote:


Recently the "LINK IS UP" notification has been staying visible until I
manually close it.  At first it wasn't doing that. Are you seeing that
too? Could a recent update have caused this?


Yes, I'm seeing it again on fedora-26 but not debian-9. This has been an 
off-and-on issue with notify-send over the years.




--

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/846125c2-ec07-301b-bb23-40dbb88b444c%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: VPN Disconnects when Qubes goes to sleep (and does not reconnect when coming out of sleep)?

[Michael Siepmann]

On 12/03/2017 10:00 PM, Chris Laprise wrote:
> On 12/03/2017 10:30 PM, Michael Siepmann wrote:
>>   On 12/02/2017 11:14 PM, Chris Laprise wrote:
>>> Looking at openvpn entries in 'journalctl' can give you a better idea.
>>> I've seen instances where openvpn versions starting with 2.4 have this
>>> bad reaction to disconnection (which is what sleep/wake is in this
>>> case); with openvpn 2.3 you could count on it to keep
>>> going/re-connecting. But there may also be an issue with the way
>>> Qubes/Xen are handling the virtual interfaces between VMs; the
>>> symptoms remind me of basic networking problems many of us have
>>> experienced with prior Qubes releases, where only VM restarts would
>>> re-build inter-VM links correctly.
>>>
>>> But if there isn't a basic networking problem, moving to a
>>> service-based config will be more robust and should keep openvpn
>>> running. One way to do this is to have your rc.local script start
>>> openvpn with systemd-run (and the right options), but I've already
>>> created a project that uses a full systemd config to manage VPN
>>> processes...
>>>
>>> https://github.com/tasket/Qubes-vpn-support
>>>
>>> Setup is much easier than the vpn doc, though it currently only works
>>> with Qubes 3.2 which I'm guessing you're using. The usual 'systemctl
>>> start/stop/status' commands give you control over the
>>> qubes-vpn-handler.service that manages openvpn.
>>>
>> Thank you! So far this seems to be working fine, automatically
>> reconnecting after resume. Any chance of getting this approach mentioned
>> on https://www.qubes-os.org/doc/vpn ?
>
> Great! I think it could be linked in the revised doc once the Qubes
> R4.0 issues are worked out.
>

Recently the "LINK IS UP" notification has been staying visible until I
manually close it.  At first it wasn't doing that. Are you seeing that
too? Could a recent update have caused 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/a5af6b2d-3e0f-8bc7-d3a9-9b5c9a9a70cf%40TechDesignPsych.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)

['Tom Zander' via qubes-users]

On Saturday, 16 December 2017 03:25:46 CET Yuraeitha wrote:
> Initially, this is all the reasons I can think of for wanting V-GPU.
...
> - Extending a single Qubes machine around the house or company, using
> multiple of screens, keyboards/mouses or other thinkable means.

This sounds inherently unsafe.
Not sure what your usecase is, but there has to be a better way than 
allowing a multitude of foreign, not-directly-connected hardware from 
accessing various very security sensitive channels.

...
> - Cryptocoin miners who wish to utilize a single machine
> for all round purposes. 

To build a proper crypto-mining rig based on GPUs, you would not run an OS 
on the machine. It literally drains money out of your system to use it on 
the same hardware as you main desktop.
If you install 8 GPUs on a mainboard, you have to realize that the mainboard 
ends up costing a fraction of the total.
Reusing it for non-mining purposes (while mining) just doesn't make any 
sense. Both from an economics as well as a security point of view.

-- 
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/8533554.PhlilUoQuC%40cherry.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Atheros AR928X & Q4.0rc3 Passthrough

['awokd' via qubes-users]

On Sun, December 17, 2017 11:44 am, Holger Levsen wrote:
> On Sat, Dec 16, 2017 at 02:21:30PM -, 'awokd' via qubes-users wrote:
>
>> Getting crashes on domU boot with an assigned Atheros wireless PCIe
>> card under Qubes 4.0rc3 with both PV and HVM. Any suggestions how to
>> accomplish it? Some of the posts/threads I find go back to 2010 but I'm
>> still stumped.
> [...]
>

> I cannot really help you, but for me it's good to see someone else has
> this problem with an Atheros AR928X card as well. I was testing it on Qubes
> 3.2 with coreboot and wasnt 100% sure this was due to Qubes/Xen,
> or coreboot or hardware… still need to try that hw with pure Debian to rule
> out that it's a hw problem.

Thanks for taking a look! It works with no problems under pure Debian on
the same machine. If I swap drives I can also test it on a plain Xen
4.8.2/Fedora 26 setup but since Qubes tweaks Xen I'm not sure a success or
failure there would provide any useful information...

-- 
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/30a43b93d673899ce919fcffc73bf3ba.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Atheros AR928X & Q4.0rc3 Passthrough

[Holger Levsen]

On Sat, Dec 16, 2017 at 02:21:30PM -, 'awokd' via qubes-users wrote:
> Getting crashes on domU boot with an assigned Atheros wireless PCIe card
> under Qubes 4.0rc3 with both PV and HVM. Any suggestions how to accomplish
> it? Some of the posts/threads I find go back to 2010 but I'm still
> stumped.
[...] 
> I've tried several things such as adding permissive and no-strict-reset
> flags when attaching the device, bunch of ath9k kernel options, etc. Only
> thing that resulted in any change whatsoever was when I blacklisted the
> ath9k module entirely, then I could boot.
> Not sure where to go next. Figure out how to edit Xen quirks? Comment out
> everything that looks like a write and recompile the driver? Throw it away
> and buy something else? (I'd prefer to get this working somehow.)

I cannot really help you, but for me it's good to see someone else has
this problem with an Atheros AR928X card as well. I was testing it on
Qubes 3.2 with coreboot and wasnt 100% sure this was due to Qubes/Xen,
or coreboot or hardware… still need to try that hw with pure Debian to
rule out that it's a hw problem. 

-- 
cheers,
Holger

-- 
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/20171217114404.yu5yxoc4jal6ye5b%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)

['Tom Zander' via qubes-users]

On Sunday, 17 December 2017 11:59:26 CET Yuraeitha wrote:
> f, but from what I understand, complex software is hard to make secure,
> compared to well-made hardware minimizing use of software. If Qubes
> hypothetically were to adopt these, would the hardware approach be more
> secure here?

The question isn't really about software vs hardware.
The overall design and concept is what is more important.
The actual approach of how to do this makes or breaks the security mode. 
>From that approach follows what parts are required to be in hardware (to 
still be fast and secure).

I claim no expertise in the domain you address in this thread, so apologies 
for the generic answer.
-- 
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/1828191.tAHdXYOLUq%40cherry.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)

[Yuraeitha]

On Saturday, December 16, 2017 at 4:47:24 PM UTC+1, awokd wrote:
> On Sat, December 16, 2017 2:25 am, Yuraeitha wrote:
> > Aight, so the idea of this thread, is to get an overview of where we
> > stand, that is, how far are we away from archiving GPU Passthrough on
> > Qubes.
> 
> If you look at how the "competition" is approaching it, you need GPU
> hardware capable of virtualization such as Nvidia Grid, Radeon Sky(?),
> Intel GVT-g and hypervisor support.
> 
> https://www.nvidia.com/object/grid-technology.html
> https://www.amd.com/en-us/innovations/software-technologies/sky
> https://01.org/igvt-g
> https://code.vmware.com/article-detail/-/asset_publisher/8n011DnrSCHt/content/vsga-datasheet
> https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-configuring-graphics.pdf
> 
> Not something I've ever played with, but it seems kind of like IOMMU to
> me. You could write a software layer to provide slow virtualized GPUs, or
> use hardware for faster ones.
> 
> Of these, it seems like Intel's approach is the most open source friendly.
> XenGT has working code. No idea how hard it would be to integrate with
> Qubes, though.
> 

That's a very interesting perspective, to bring in the market movements and 
other open source developments into the discussion as well, possibly detecting 
spots that might work together with Qubes. The competition also seems to be 
getting more fierce as virtual augmentation and reality becomes bigger? That's 
a very good idea for topic discussion too, I agree. It's interesting questions 
you set in motion, like for example to ponder over how far these developments 
can be be put together with Qubes with our current or emerging means of 
tomorrow.

Between software or hardware controlled IOMMU graphics, maybe the question for 
Qubes is which one of them is more secure though? I'm not a code developer my 
self, but from what I understand, complex software is hard to make secure, 
compared to well-made hardware minimizing use of software. If Qubes 
hypothetically were to adopt these, would the hardware approach be more secure 
here? Or maybe one can even use software controlled IOMMU in a less secure 
Stub-domain, for less important things as well? Kind of like a Qubes opt-in 
feature? I wonder how feasible this would be though, but it sounds really 
attractive to have user-choices like these.

I haven't read through all the links and their interconnected topics yet, but 
plan to do that over the next couple of days as I have more time. The ones I 
read were quite interesting to read already.

> > I must be tired, I initially wrote 'qubestions' instead of 'questions'
> > here... aight, so possible questions for the discussion.
> 
> I like it! Let's rename the FAQ to Frequently Asked Qubestions.

huehue, mistakes when tired (or even when high) can lead to some interesting 
places sometimes :-)

-- 
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/534e830a-cbed-4d37-99f8-9c9d47383d77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: External display and mouse issue on 4.0rc3

[Yuraeitha]

On Saturday, December 16, 2017 at 2:57:15 PM UTC+1, Kushal Das wrote:
> Hi,
> 
> I am using 4.0rc3 updated from testing on T470 (and a few of friends
> in different models) having an issue of using mouse on any external
> display. We can click on the top menubar of any application, but can
> not use the mouse else where in the application (in any application).
> If we move a terminal there, we can type or move between tabs using
> Keyboard. But, can not use the mouse.
> 
> Wondering if anyone else saw the similar issue?
> 
> Kushal
> -- 
> Staff, Freedom of the Press Foundation
> CPython Core Developer
> Director, Python Software Foundation
> https://kushaldas.in

I suspect everything works after a full Qubes system restart? or is it 
permanently not working even after a restart? I have similar issues, but it's 
usually only happening to me when I leave my Qubes running for too long 
connected to a HDMI TV, or if the HDMI TV goes sleep mode on its own while 
Qubes is running, or if Qubes itself goes suspend/hibernate.

Everything is dodgy after returning from suspend/hibernate. Recently after 
newer updates (using current-testing updates here) it was enough to just 
restart the VM's though.

Sounds familiar, perhaps? or is your issue something else completely?

-- 
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/1904768c-bc11-4be6-a748-4e24cf902c6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.