Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[ThierryIT]

Not familiar with this ... Will need procediure to follow.


Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > No, I am still under R3.2
> > 
> > Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > > >
> > > >
> > > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > >
> > > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > >>
> > > >>> Nobody ?
> > > >>>
> > > >>>
> > > >>>
> > > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
> > > >>>
> > > >>>
> > >  Hi,
> > > 
> > > 
> > > 
> > >  I am going to install a new sys-usb.
> > >  I have before to install all what I need to the template (fedora-26)
> > >   first. When following your procedure:
> > > 
> > > 
> > >  ykpers has been installed but: I cannot do the same for
> > >  qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > 
> > >  no match for argument
> > > 
> > >  ideas ?
> > > >>
> > > >> Not quite sure what you are trying to do here. What procedure? What
> > > >> command are you entering?
> > > 
> > > Are you trying this on Qubes 4.0? Those Yubikey packages might not be in
> > > the Qubes repo yet.
> 
> Hi,
> 
> I have not maintained this for some time. So long that I can't remember if 
> the packages had been created/tested, I don't think they have.
> 
> Best is you follow the steps to build it on a new temporary VM, don't be 
> afraid it should not be too hard:
> - Execute the yum command in "Build dependancies"
> - Also install pam-devel
> - Follow the steps in preparing the build and build
> - Deploy the code in Dom0 and the USB VM.
> 
> I am about to upgrade to Qubes 4.0 rc4 (when released) so won't probably be 
> able to help until this is done.
> 
> Any help from someone who is used to packaging under Fedora would be nice.
> 
> Alex

-- 
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/79a97c8e-5626-4ab0-9625-764dabaf45ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Just installed AEM(Anti-Evil-Made)...see an error:(

[Tim W]

On Sunday, January 14, 2018 at 11:06:56 AM UTC-5, vel...@tutamail.com wrote:
> Managed to find what was causing the error and how to remove the error:
> 
> https://askubuntu.com/questions/778875/tpm-error-6-when-booting-thinkpad
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1413409
> 
> In my BIOS I went to Security -> Security Chip -> Security Chip set to 
> "Active"
> 
> However this brings up additional BIOS setting questions...
> 
> Any body have any thoughts on the best configuration for my default BIOS for 
> a Lenovo? Specifically related to the "Security Chip" settings?
> 
> Clear Security Chip?
> Intel TXT Feature?
> 
> I am not sure I am comfortable yet with changing my BIOS to Coreboot but love 
> the idea:)
> 
> My threat vector is more from a well funded malicious hacker(vs Intel or a 
> Government). Just trying to harden my PC the best I can...
> 
> Any thoughts or advice would be greatly appreciated.
> 
> Thanks,
> V

I have a t440p, what model do you have and processor version of tpm?  As you 
mention coreboot support I assume older model.

-- 
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/55173539-cbd6-4478-9153-061a42ef6490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Simon Gaiser]

Marek Marczykowski-Górecki:
[...]
> I don't see anything else related to this device. So until Simon gets
> permissive mode sorted out, it look like you have to use that usb
> ethernet.

FYI: https://github.com/QubesOS/qubes-core-admin/pull/184

-- 
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/ec1f044a-7910-1966-0e2a-d3b9b20503d3%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[mossy-nw]

Marek Marczykowski-Górecki:
> On Thu, Jan 18, 2018 at 07:21:14PM +, mossy-nw wrote:
>> OK thanks, Marek.  I'll try to help get that backup bug reproduced
>> then... should I file a permissive mode bug report based on this
>> discussion, or do you feel like all of the relevant folks are looped in
>> on this thread already?
> Even if relevant people are aware of it, a github issue would be useful
> for tracking purpose (for example to easily check what package version
> contains a fix).
>
Great -- please see issue #3476 
 -- I linked this thread 
there and pasted what I see as most
relevant comments from you all here, feel free to crticize/clarify.

thx,

-m0ssy

-- 
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/61cea59a-0a30-b63b-5c66-f0a170bfc35c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] GPU?

['Tom Zander' via qubes-users]

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

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

[qubes-users] Re: GPU?

[Vít Šesták]

On Thursday, January 18, 2018 at 10:00:19 PM UTC+1, Alex Dubois wrote:
> You can use GPU computing in Dom0 with the assumption that:
> - You trust the software you plan on using
>- 3D design software such as Blender
>- GPU compute such as CUDA libs, Tensorflow, Keras, etc..
> - You only create assets/code and export them out of Dom0

You right, one can, but:

* At least, this goes against the nature of Qubes.
* You don't have any Internet connection there.
* Creating only (and not importing anything) is a very important (and often 
unrealistic) assumption. So, you should not open any file you download. If 
there is some vulnerability in such software (well, Blender: 
https://developer.blender.org/T52924), you are actually potentially more 
affected than with traditional OS like Ubuntu: In Qubes, dom0 sometimes gets 
out of date (like Q3.2 being based on EOLed F23), so you don't receive any 
security update for software like Blender. That's not because ITL does not care 
about security, that's because Blender is not a a security-critical component 
like Xen or Linux kernel are. That's the cost of using Qubes in a way it was 
never intended.

> If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen 
> to do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however:
> - It is far from trivial and only limited setups are known to work

Right.

> - The security of it is not as robust (I can't remember where I read that, I 
> think it was in the GPU Pass-through page of the Xen wiki)

I guess one of potential reasons: Some people have succeeded only without 
stubdom, i.e., with QEMU running in dom0.

V6

-- 
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/41aa2710-cfbf-4b9a-a432-d4666a0d5346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: GPU?

[Alex Dubois]

On Thursday, 18 January 2018 21:00:19 UTC, Alex Dubois  wrote:
> On Sunday, 14 January 2018 07:12:24 UTC, ro...@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?
> 
> You can use GPU computing in Dom0 with the assumption that:
> - You trust the software you plan on using
>- 3D design software such as Blender
>- GPU compute such as CUDA libs, Tensorflow, Keras, etc..
> - You only create assets/code and export them out of Dom0
> 
> If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen 
> to do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however:
> - It is far from trivial and only limited setups are known to work
> - The security of it is not as robust (I can't remember where I read that, I 
> think it was in the GPU Pass-through page of the Xen wiki)
> 
> I have tried with limited success few years back (only one boot and was never 
> able to get it back after)...

Sorry forgot to mention that GPU pass-through also require another monitor (or 
switch input...).
It may also be much easier to only use it as a Compute GPU (you keep the UI via 
Qubes-Dom0)

-- 
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/039bb36d-c45a-44bc-8479-0db627db2cc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: GPU?

[Alex Dubois]

On Sunday, 14 January 2018 07:12:24 UTC, ro...@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?

You can use GPU computing in Dom0 with the assumption that:
- You trust the software you plan on using
   - 3D design software such as Blender
   - GPU compute such as CUDA libs, Tensorflow, Keras, etc..
- You only create assets/code and export them out of Dom0

If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen to 
do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however:
- It is far from trivial and only limited setups are known to work
- The security of it is not as robust (I can't remember where I read that, I 
think it was in the GPU Pass-through page of the Xen wiki)

I have tried with limited success few years back (only one boot and was never 
able to get it back after)...

-- 
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/a9604c45-de67-4a9c-94cd-6b85735f6159%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Please help with 8th Generation Intel i5

[donoban]

On 01/18/2018 11:15 AM, Krišjānis Gross wrote:> I did navigate to /tmp
and looked at some logs. Unfortunately I do not know what to look for
there. Took some screen shots (attached). Does that ring any bells?

I think the problem is:

(EE) VESA(0): V_BIOS address 0xaa7a0 out of range

I've searched a little but I didn't find anything useful. I hope someone
could help you on this.

> 
> A side question- how can I copy the logs in /tmp to a flash drive or 
> something in order to post those here? 
> 
> Which Linux distribution should I try to run in order to do a reasonable 
> comparison?
> 

Ideally same as dom0, fedora-24?? I would try to guess what kernel
version starts to work fine with it and compare with built-in the qubes iso.

-- 
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/69cc9ad1-7a91-c734-db6a-2fe509cb088c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Created new fedora-26 dvm, how to delete old dvm

[cooloutac]

On Thursday, January 18, 2018 at 3:34:54 PM UTC-5, donoban wrote:
> On 01/18/2018 09:27 PM, '[799]' via qubes-users wrote:
> > Hello,
> > 
> > After migrating my templates to Fedora 26, I have also created a new
> > disposable VM, based on a Fedora 26 template.
> > 
> > I have set the new DVM to start, from all other AppVMs, as such the DVM
> > should not be referenced to in any other app vm.
> > I tried to remove the default DVM, but it didn't work.
> > What do I need to do, to get rid of the old (Fedora 25 based) DVM which
> > comes with the default Qubes 4rc3 isntallation ?
> > 
> 
> 
> At least in Qubes 3.2 you can try with 'qvm-ls' for finding it and
> 'qvm-remove vm-name' for delete it.
> 
> I think something like 'qvm-remove fedora-25-dvm' should work.
> 
> But I don't know if it's different on Qubes 4.

https://www.qubes-os.org/doc/remove-vm-manually/

-- 
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/85a81b81-4100-40f4-b2ef-0efe922e3d73%40googlegroups.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)

[cooloutac]

On Thursday, January 18, 2018 at 12:20:49 PM UTC-5, David Hobach wrote:
> On 01/18/2018 04:04 PM, cooloutac wrote:
> > SO it doesn't look like 4th or 5th generation boards are going to get a 
> > bios patch.  IS the bios patch nescessary?
> 
> Meltdown can be patched on Kernel and/or Hypervisor level with a 
> performance loss by doing in the Kernel what should be done by the CPU. 
> It also seems that Qubes 4 isn't affected in certain virtualisation 
> modes, see the QSB & XSA.
> 
> It might be possible to patch Spectre 1 & 2 in limited ways as well, but 
> there are only ideas out yet, see 
> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
> 
> So the Microcode patches would be the proper way to do it and even there 
> it seems to be hard if I recall the Spectre paper correctly, but the 
> Open Source community attempts to implement (partial) mitigations anyway.
> 
> > Or Should we just assume our desktop pc's are about as secure as android 
> > phones now?   Are they no good after a year or two?  I joke that real 
> > security costs alot of money because when firmware gets compromised nothing 
> > you can do but replace the pc.But if you have to buy a new mobo and pc 
> > every year or two to stay up to date that is a sad future for most people.

OHH  so thats why people say there is a performance loss,  in other words if 
your vendor doesn't patch the bios?  because I got a huge increase in 
performance with my board that got patched.  So i'm having a hard time 
believing all the hype about it.

And so yes I'm reading that the Qubes team is working to make some changes even 
to 3.2,  which is great news.  But I wasn't sure if they are able to address 
all the problems.

I guess a performance loss because lack of vendor support, is better then no 
mitigations at all.   If this is even the case,  I'm still skeptical.

-- 
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/30159d48-6ecf-4b30-a4a2-60bec7f545ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Sporadic Inter-VM Routing Issues with Qubes Updates Proxy

[wordswithnemo]

On Monday, January 15, 2018 at 12:39:41 PM UTC-5, Kiwi17 wrote:
> Hi, I was hoping someone may be able to help make heads or tails of this 
> frustrating issue I'm having.
> 
> 
> 
> Background
> 
> I use a VPN configured as-per the Qubes recommended config for VPNs 
> (https://www.qubes-os.org/doc/vpn/). 
> 
> I have used this configuration with the following VM hierarchy for some 
> months without a problem: sys-net -> sys-firewall -> vpn -> vpn-firewall -> * 
> 
> [where "vpn-firewall" runs the qubes-yum-proxy service (verified TCP listener 
> is showing up in netstat on  0.0.0.0:8082)]
> 
> 
> 
> Problem
> 
> Recently I have encountered a problem where whenever I go to update a 
> TemplateVM, or dom0 - any VM that is configured to use the qubes update proxy 
> - the dnf update times out. The following is the output of "sudo dnf -vvv 
> --refresh update" on a Fedora 26 TemplateVM:
> 
> 
> 
> Cannot download 
> 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26=x86_64':
>  Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for 
> https://mirrors.fedoraproject.org/metalink?repo=updates-released-f26=x86_64
>  [Connection timed out after 30003 milliseconds].
> 
> Error: Failed to synchronize cache for repo 'updates'
> 
> 
> 
> If we watch netstat during this attempted update, we see that a SYN is sent 
> to the correct update proxy address of 10.137.255.254:8082, but no SYN-ACK is 
> received:
> 
> tcp    0    1 10.137.5.14:57914   10.137.255.254:8082 SYN_SENT 
> 
> 
> 
> Leaving this running, no TCP connection is ever established with the 
> qubes-updates-proxy service at "vpn-firewall". Similarly, watching for 
> inbound connections on "vpn-firewall" yields no results for an incoming 
> connection from the TemplateVM. During this time, all  AppVMs continue to 
> have full network connectivity via the vpn-firewall gateway.
> 
> 
> 
> Now here's the weird bit... The problem is sporadic. Sometimes I can reboot 
> my host machine and the updates proxy is broken, other times it works fine.
> 
> 
> 
>  To my untrained eye, this appears to be a routing issue internal to Xen. 
> Does anyone have some advice on how I can investigate further?
> 
> 
> 
> Many thanks in advance,
> 
> Alex
> 
> 
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.

Some thoughts that may or may not be useful:

- qubes-updates-proxy should always be running on the firewall that is closest 
to the vpn. So if you are doing something like

sys-net->sys-firewall->sys-vpn->sys-firewall-vpn->sys-firewall-work

then qubes-updates-proxy should be running on your sys-firewall-vpn.

- Check that you've enabled the qubes-updates-proxy service on the 
sys-firewall-vpn Settings in Qubes VM Manager

- Check that the service is running on sys-firewall-vpn

sudo service qubes-updates-proxy status

If you're running your firewall with restricted memory then in my experience 
tinyproxy *sometimes* fails to start. This minimal memory requirement seems to 
be higher for Fedora 26 than 25.

- Check your dnf settings "cat /etc/dnf/dnf.conf" on your TemplateVM to confirm 
that it's set up to use the proxy. There should be a line at the bottom similar 
to

proxy=10.137.255.254

- Try to update the TemplateVM without using the proxy

-- 
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/cc86159b-eff4-41e1-87e8-58523a8db625%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Created new fedora-26 dvm, how to delete old dvm

[donoban]

On 01/18/2018 09:27 PM, '[799]' via qubes-users wrote:
> Hello,
> 
> After migrating my templates to Fedora 26, I have also created a new
> disposable VM, based on a Fedora 26 template.
> 
> I have set the new DVM to start, from all other AppVMs, as such the DVM
> should not be referenced to in any other app vm.
> I tried to remove the default DVM, but it didn't work.
> What do I need to do, to get rid of the old (Fedora 25 based) DVM which
> comes with the default Qubes 4rc3 isntallation ?
> 


At least in Qubes 3.2 you can try with 'qvm-ls' for finding it and
'qvm-remove vm-name' for delete it.

I think something like 'qvm-remove fedora-25-dvm' should work.

But I don't know if it's different on Qubes 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/2cb91f28-b139-f8e4-79f9-515c9007ce85%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Created new fedora-26 dvm, how to delete old dvm

['[799]' via qubes-users]

Hello,

After migrating my templates to Fedora 26, I have also created a new disposable 
VM, based on a Fedora 26 template.

I have set the new DVM to start, from all other AppVMs, as such the DVM should 
not be referenced to in any other app vm.
I tried to remove the default DVM, but it didn't work.
What do I need to do, to get rid of the old (Fedora 25 based) DVM which comes 
with the default Qubes 4rc3 isntallation ?

[799]

my procedure to create a new Fedora 26 DVM:

---8# Create a new Disposable App-VM "my-dvm" which is based on a custom 
template t-fedora-26
qvm-create --template t-fedora-26 --label red --property 
template_for_dispvms=True --class=AppVM my-dvm

# TEST: Start an application in this dvm
qvm-run --dispvm=my-dvm xterm

# Fix menu entry from Domain: my-dvm to Disposable: my-dvm
# https://groups.google.com/forum/#!msg/qubes-users/gfBfqTNzUIg/sbPp-pyiCAAJ
# https://github.com/QubesOS/qubes-issues/issues/1339#issuecomment-338813581
qvm-features vmname appmenus-dispvm 1
qvm-sync-appmenus --regenerate-only my-dvm

# Change the Disp-VM from an AppVM (here: my-untrusted)
qvm-prefs --set my-untrusted default_dispvm my-dvm

# Try to start something from this AppVM in a disposable VM
qvm-run --auto my-untrusted 'qvm-open-in-dvm https:/google.de'
# This should start a new dispvm which is based on your dvm-App

---8

Gesendet von ProtonMail mobile

-- 
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/HshR1Yx4N8HrY_ywCzx0n-Yydoi5s14S7B28ExPTOYTQvi7BkmpwQYLJsAt9pw5Sb3C4wtZhbDvN5SnlIKJqrp6uFsitl-8REAeN9rUdaHA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Marek Marczykowski-Górecki]

On Thu, Jan 18, 2018 at 07:21:14PM +, mossy-nw wrote:
> OK thanks, Marek.  I'll try to help get that backup bug reproduced
> then... should I file a permissive mode bug report based on this
> discussion, or do you feel like all of the relevant folks are looped in
> on this thread already?

Even if relevant people are aware of it, a github issue would be useful
for tracking purpose (for example to easily check what package version
contains a fix).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-- 
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/20180118192838.GD2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

['awokd' via qubes-users]

On Thu, January 18, 2018 6:00 pm, Nik H wrote:

> Reasoning: The entire point of HW virtualization is to have very fast and
> seamless context switching so that if I have 10 different VMs running,
> the processor does not lose performance from that. So you keep caches,
> and you keep speculatively executing what you believe to be the correct
> branch of an if statement. HW virtualization vs. software seems to have
> been implemented mainly to improve performance, and not to improve
> security/isolation.
>
> I found various snippets of information hinting at this as well, but
> again, I'd be happy to be wrong! But, if I am right, then qubes isolation
> is compromised.

This is the feeling I got too wrt Spectre, but it's hard to find facts on
it. Maybe if we could look at what the virtualization opcodes are doing at
a microcode level...

-- 
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/ce9c9392f0cd7a73fc766ebfecc47906.squirrel%40tt3j2x4k5ycaa5zt.onion.
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)

[Nik H]

On Jan 16, 2018, at 2:56 AM, Vít Šesták 
 wrote:
> 
> * If an application does not mitigate Spectre and attacker finds useful entry 
> point, attacker can read memory of the application (but nothing more).
> * If VM kernel does not mitigate Spectre and attacker finds useful entry 
> point, attacker can probably read memory of whole VM (but other VMs are not 
> affected).
> * If Xen does not mitigate Spectre and attacker finds useful entry point, 
> attacker can probably read memory of whole system.

Can you explain why you think that Spectre can't escape the container (VM)? It 
seems that is the main issue, Spectre escapes the container.

I read the whitepaper and what Spectre is doing is, it's accessing memory it 
should not have access to, and then uses a few simple tricks to extract the 
data it should not have access to. This happens on a processor level so any 
bounds checks that are outside the CPU core will not prevent that. 

Given the nature of the attack, I do not think that hardware virtualization 
would stop this attack. Reasoning: If HW Virtualization was doing privilege 
checks on memory access in speculatively executed code, it would severely 
impact or completely remove the performance gains from speculative execution. I 
would be *very* happy to be wrong about that so if you have info to the 
contrary, please let me know.

Here's how spectre works (conceptual - the existing sample implementations are 
just that, examples):

- Trick the CPU into doing something it shouldn't to, like in our case access 
another VM's memory.
- This memory access happens in a speculative execution, which is built for 
speed and doesn't have time to check whether or not I actually have the right 
to access this memory. 
- Speculative execution continues, and I load some of my own data into the 
processor, but which data depends on the value of the byte I read in the 
previous step.
- The CPU realizes I didn't have access, and reverts register states
- The CPU does not, however, remove my data from the cache
- I can then use cache timing to figure out *what part* of my own data was 
cached
- Once I know what part of my data was cached, I know the value of the byte 
that I read illegally.

If Hardware virtualization were to protect against this attack, it would need 
to either have bounds checks inside the processor core, or flush caches 
whenever different VMs run, all of which would severely impact performance. So 
I don't think they do it.

Reasoning: The entire point of HW virtualization is to have very fast and 
seamless context switching so that if I have 10 different VMs running, the 
processor does not lose performance from that. So you keep caches, and you keep 
speculatively executing what you believe to be the correct branch of an if 
statement. HW virtualization vs. software seems to have been implemented mainly 
to improve performance, and not to improve security/isolation. 

I found various snippets of information hinting at this as well, but again, I'd 
be happy to be wrong! But, if I am right, then qubes isolation is compromised.

Sorry this got a bit long.


-- 
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/A0271FCD-6100-4839-BEF1-1A46540EE9B5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 04:50:02PM +, mossy-nw wrote:
> 
> 
> Marek Marczykowski-Górecki:
> > On Thu, Jan 18, 2018 at 01:05:46AM +, mossy-nw wrote:
> >> Marek Marczykowski-Górecki:
> >>> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:
>  Dear Qubes community,
> >>>
>  Has anyone using Qubes R4.0 been able to resolve any issues (e.g. with
>  wifi) by setting PCI permissive mode? (as described in:)
> >>>
>  https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-issues
> >>>
>  I successfully used this in Qubes R3.2 to get wifi working for dell xps
>  13 9350 (bcm4350) but am having no luck using this method in R4.0_rc3.
> >>>
>  This situation seems identical (driver errors that persist but
>  nonetheless wifi works using permissive mode) resolved by in a previous
>  (R3.2) qubes-users thread by miaoski --
>  https://groups.google.com/forum/#!msg/qubes-users/m4GzpfOVBiQ/bf5XCEc-DQAJ
> >>>
>  I'm hesitant to give up and go back to R3.2 on this machine, so I don't
>  have access to the R3.2 dom0 dmesg output for PCI spermissive mode, but
>  I recall before setting permissive mode dmesg suggested doing so.  This
>  is not the case in R4.0_rc3 however.
> >>>
>  Some dmesg output, if this gives anyone any ideas:
> >>>
>  [dom0 ~] lspci | grep -i network
>  3a:00.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
>  Network Adapter (rev 08)
> >>>
>  Before setting permissive mode:
>  [dom0 ~]$ sudo dmesg | grep
>  [7.222306] pci :3a:00.0: [14e4:43a3] type 00 class 0x028000
>  [7.222348] pci :3a:00.0: reg 0x10: [mem 0xdc40-0xdc407fff 
>  64bit]
>  [7.222379] pci :3a:00.0: reg 0x18: [mem 0xdc00-0xdc3f 
>  64bit]
>  [7.222618] pci :3a:00.0: supports D1 D2
>  [7.222619] pci :3a:00.0: PME# supported from D0 D1 D2 D3hot 
>  D3cold
>  [7.222766] pci :3a:00.0: System wakeup disabled by ACPI
>  [8.053279] pciback :3a:00.0: seizing device
>  [   68.211970] xen_pciback: vpci: :3a:00.0: assign to virtual slot 0
>  [   68.212362] pciback :3a:00.0: registering for 4
>  [   68.217475] pciback :3a:00.0: enabling device ( -> 0002)
> >>>
> >>> Did you get anything after that message? Permissive mode helps mostly
> >>> with cases reported in dom0 dmesg with message like this:
> >>>
> >>> pciback :03:00.0: Driver tried to write to a read-only
> >>> configuration space field at offset 0x110, size 4. This may be 
> >>> harmless,
> >>> but if you have problems with your device:
> >>> 1) see permissive attribute in sysfs
> >>> 2) report problems to the xen-devel mailing list along with details of
> >>> your device obtained from lspci.
> >>>
> >>> Interesting would be to see messages in sys-net about that device
> >>> driver.
> >>> You may also try updated kernel for VM, there is
> >>> kernel-qubes-vm-4.14.13-1 package in current-testing repository:
> >>> https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories
> >>>
> >>>
> > 
> >> Thanks, Marek--I will try the updated kernel (though sys-net has the
> >> appropriate driver binary file, and this was working under R3.2 for many
> >> months i.e. with older kernels).  Here are relevant messages from sys-net:
> > 
> >> [user@sys-net ~]$ lspci -k
> >> 00:05.0 Network controller: Broadcom Limited BCM4350 802.11ac Wireless
> >> Network Adapter (rev 08)
> >>Subsystem: Dell Device 0023
> >>Kernel modules: brcmfmac
> > 
> >> [user@sys-net ~]$ sudo dmesg | grep brcmfmac
> >> [1.703756] usbcore: registered new interface driver brcmfmac
> >> [1.970170] brcmfmac: brcmf_chip_recognition: SB chip is not supported
> >> [1.970185] brcmfmac: brcmf_pcie_probe: failed 14e4:43a3
> > 
> > Do you see other relevant kernel messages about that time (not necessary
> > containing brcmfmac)?
> > 
> > I assume this is after enabling permissive mode, right?
> > Simon, is setting permissive mode in dom0 enough? Or maybe qemu in
> > stubdomain perform some additional filtering?
> > 
> 
> Sounds like you all are way ahead of me on this thread now (great!)--but
> yes, this is after permissive mode enabled.  I want to add upon first
> booting single clicking the dock icon for sys-net reads "device not
> managed" but after sleeping and waking there is no longer any entry at all.
> 
> I don't feel confident to judge for sure what's relevant, but here are
> some things that might be.
> 
> [1.979068] FUJITSU Extended Socket Network Device Driver - version
> 1.1 - Copyright (c) 2015 FUJITSU LIMITED
> [1.980511] piix4_smbus :00:01.3: SMBus Host Controller not enabled!
> [1.981868] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [1.982959] ehci-pci: EHCI PCI platform driver
> [1.998059] uhci_hcd: USB Universal Host Controller 

Re: [qubes-users] How to play videos in qubes? says needs codec H.264, Mpeg-4 something

[Steve Coleman]

On 01/18/2018 11:12 AM, jerr...@disroot.org wrote:

i installed kmplayer, still says need some additional codecs, refers me to the 
software program, finds gsstreamer multimedia codecs - H.264 , when i click 
install on this plugin it says enable third-party software source? gsstreamer 
multiemedia codecs -H.264 provided by fedora. this software source must be 
enabled to continue installation, and has an option enable and install

how do i enable it?


1) you can use the "dnf --enablerepo [reponame]" argument to temporarily 
enable a specific repo during the install command, but that may not get 
you any updates later since that is one time only command.


2) You can also edit the repo file 
/etc/yum.repos.d/rpmfusion-[non]free[*].repo and change the  "enabled=0" 
to "enabled=1" for the appropriate url you want. Once you do this you 
will be given the updates if the "*-update" repo is left enabled. You 
will have to be more careful in the future not to install other things 
that you may not want to trust in the future.


The repo's files in fedora are found here:
[~]$ ls -1 /etc/yum.repos.d/rpmfusion-*free*.repo
/etc/yum.repos.d/rpmfusion-free.repo
/etc/yum.repos.d/rpmfusion-free-updates.repo
/etc/yum.repos.d/rpmfusion-free-updates-testing.repo
/etc/yum.repos.d/rpmfusion-nonfree.repo
/etc/yum.repos.d/rpmfusion-nonfree-updates-testing.repo
/etc/yum.repos.d/rpmfusion-nonfree-updates.repo

After doing the above edits you can do:
"sudo dnf search gstreamer[1]-plugins-[good|bad|ugly|*] "
and get a list of plugins in each category. These categories generally 
refer to licensing or patent encumbered code issues.


Unfortunately the string "h.264" isn't found in the description 
anywhere, and I don't remember which one it was in. You may find your 
answer here:

https://gstreamer.freedesktop.org/documentation/plugins.html





January 17, 2018 6:55 PM, "Steve Coleman"  wrote:


Use DNF to look for ffmpeg, and install that, if it is not already. Likely it 
is not installed.

After that, if it still does not play, then start by telling us what app you 
are using to play the
video. There are usually plugins that connect an app to the otherwise 
encumbered/licensed/patented
algorithms, which is the bane of free and open software. The plugin 
architecture allows a
separation of the encumbered parts from that of the software application core.

On 01/16/2018 11:50 AM, jerr...@disroot.org wrote:


i can't install this codec from fedora 26 from software add ons.. also > i've 
tried doing yum
search h.264, there's nothing that seems like this > codec..
-- > 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/0fceeb06479346b8c2dbdf67ea572f59%40disroot.org
 >
.
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/7fc3ad35-56d5-5027-7f68-f0784baf47c0%40jhuapl.edu.
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/238d1e22-245f-bf76-ac92-5cdfbb5b232a%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Alt-Tab not passed through

['[799]' via qubes-users]

Gesendet von ProtonMail mobile

-- 
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/Nl7cAH9ddI5FqNGUN-o4Rg3ug-seBZDJTmAvHv4Ycm413VhtoGd4pRBX2usaMoILBuXD6c8IVTI-AlGoQo_s_-2QXl35nRkheQJ9BKfFnR4%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Lenovo X250, Intel Core i7-5600U, 16GB Ram, 512GB SSD

[juanjimenezbazzino]

Hi Peter! 
Awesome to find someone else with an x250 trying qubes. 
Im having the same issue trying to install v3.2 but without success. 
Could you post a step-by-step of booting until the install splash screen?



On Wednesday, September 14, 2016 at 9:48:40 AM UTC-3, Peter Völkl wrote:
> Woks very well.
> 
> Installation steps from UEFI Troubleshooting required: https://www.qube
> s-os.org/doc/uefi-troubleshooting/
> Notebooks Hardware Settings to "UEFI only" without BIOS Compatibility
> also required.

-- 
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/ec38d254-5c06-49c6-8a2b-0f8920d7d5a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

AW: Re: [qubes-users] How to play videos in qubes? says needs codec H.264, Mpeg-4 something

['[799]' via qubes-users]

 Tim W wrote:
>> [799] wrote
>> I have a complete How-to which you can just
>> follow per copy & paste to get a multimedia
>> AppVM which is based on Debian-8 and can
>> be used to listen to Spotify, watch DVD and
>> use Amazon Prime or Spotify.
>> If you are interested I can send you the
>> installation script.

> why not post up the how to as I think many
> would find it beneficial with so many new
> users.

Actually I started to write a how-to for Qubes, but I found it hard to 
understand how to add new content to the Qubes site using GITHUB.
I've read the Qubes Docu Howto located here:
https://www.qubes-os.org/doc/doc-guidelines/
I was able to add a new page but it seems that it takes a long time until a 
push request make it back to the Qubes Doc repository, which feels kind a 
frustrating, as such I decided to create my own how-to repository.

[799]

Here is my procedure how to create a multimedia AppVM based on a Debian 
template.

# Firewall needs to be open to access Internet and DNS as we need to install 
additional packages on the multimedia-template VM.

# Based on the default Qubes OS Debian-8 template

# Clone template
qvm-clone debian-8 my-debian-8

# Setup networking for the new template as we need to download some files
qvm-prefs -s my-debian-8 netvm my-sys-firewall

# Launch new template
qvm-start my-debian-8

# Edit Firewall Rules in the VM
# [X] Allow network access except...
# [X] Allow DNS queries

# Launch Terminal in the newly started VM template
qvm-run my-debian-8 gnome-terminal

# Become root
su -

### Installation Spotify
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 
BBEBDCB318AD50EC6865090613B00F1FD2C19886
# TODO where to find the GPG Fingerprint for Spotify??
# Public-Key: 
http://keyserver.ubuntu.com/pks/lookup?op=vindex=0xD2C19886=on
# Fingerprint: BBEB DCB3 18AD 50EC 6865 0906 13B0 0F1F D2C1 9886
echo deb http://repository.spotify.com stable non-free | tee 
/etc/apt/sources.list.d/spotify.list
apt-get update
apt-get install -y spotify-client
# Create a spotify desktop-entry
cp -p /usr/share/spotify/spotify.desktop /usr/share/applications/
cp /usr/share/spotify/icons/spotify-linux-16.png 
/usr/share/icons/hicolor/16x16/apps/spotify.png

### Installation VLC
# Add Repository for libdvdcss
# http://www.videolan.org/developers/libdvdcss.html
# TODO where to find the GPG Fingerprint for VLC??
# Public-Key: 
http://keyserver.ubuntu.com/pks/lookup?op=vindex=0xB84288D9=on
# Fingerprint: 8F08 45FE 77B1 6294 429A 7934 6BCA 5E4D B842 88D9
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 
8F0845FE77B16294429A79346BCA5E4DB84288D9
echo "deb http://download.videolan.org/pub/debian/stable/ /" >> 
/etc/apt/sources.list
echo "deb-src http://download.videolan.org/pub/debian/stable/ /" >> 
/etc/apt/sources.list
apt-get update
apt-get install -y libdvdcss2
apt-get install -y vlc

### Installation Google Chrome
# Howto verify the debian repository?
# https://www.google.com/linuxrepositories/
wget -c 
https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
# better option instead of using wget?
# Try to install Google Chrome
dpkg -i google-chrome-stable_current_amd64.deb
# Install dependencies for Google Chrome (if not installation will fail)
# This will install: fonts-liberation libappindicator1 libdbusmenu-glib4 
libdbusmenu-gtk4 libindicator7 libxss1
apt-get -f upgrade
# Install Google Chrome
dpkg -i google-chrome-stable_current_amd64.deb
rm google-chrome-stable_current_amd64.deb

# Shutdown template
qvm-shutdown my-debian-8

# Create a new App-VM from this new Debian 8 template
qvm-create --template=my-debian-8 --label=orange --mem=512 --vcpus=2 multimedia
qvm-prefs -s multimedia netvm sys-firewall

# Add Google Chrome, VLC and Spotify to the AppVM Menu via "add/remove app 
shortcuts"

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

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 04:44:54PM -, awokd wrote:
> On Thu, January 18, 2018 4:16 pm, "Marek Marczykowski-Górecki" wrote:
> 
> 
> > Not exactly...
> >
> >
> > 1. qvm-start sends a request to qubesd, using Admin API
> > 2. qubesd starts required netvm (recursively), if needed
> > 3. qubesd request qmemman to allocate needed memory for new VM
> > (according to VM's 'memory' property)
> > 4. qubesd calls into appropriate storage pool driver to prepare for VM
> > startup (create copy-on-write layers etc)
> > 5. qubesd gathers needed VM
> > properties etc and builds libvirt VM configuration (XML format, can be
> > seen using `virsh dumpxml`)
> > 6. qubesd calls into libvirt to start the VM
> > (but in paused mode)
> > 7. libvirt setup the VM using libxl, this include starting stubdomain if
> > needed
> > 8. qubesd start auxiliary processes, including:
> > - qrexec-daemon
> > - qubesdb-daemon (and fill its content)
> > 9. libvirt unpause the VM
> > 10. qvm-start-gui process (running separately from qubesd, as part of
> > dom0 user GUI session) starts gui daemon
> 
> Thank you, sir. No wonder I was having trouble following the control flow.

For the record, most of the above is in "start" method:
https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-vm/qubesvm.html#qubes.vm.qubesvm.QubesVM.start
(there is "source" link at the right side)

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgz6YACgkQ24/THMrX
1ywAeQgAiNAlBk75F0ezCZHOgPed8Rd3qc8/pP7zRTYeWUOUCiDxSky+FSompw/k
1JS/ROgisCcma+16W2EPmGPDkxUjkJJcL+OJj/jZGZolxnFKoY3Atbu42qEckAlG
br11XSXtdVuV3IPR3nHQhdCn5BltwAgw0QE80ziekvb+9Fh+bIdzH8S9qyk/sVbf
WML6a/Gn81Nh4dWyktLL5V0onZmpn0wbRWhyXFGi9HUOJUgnl7WImLgjGD+3YBch
iCVwULNxewDA0Nkfq2UARnsODjP23M/9CNplUAq1oPumtQYIcsc4wGGDcZH/xXo4
aAhtZskNopUgBeCvBWGr7sywGSs1LA==
=G7vM
-END PGP SIGNATURE-

-- 
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/20180118164734.GB2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

['awokd' via qubes-users]

On Thu, January 18, 2018 4:16 pm, "Marek Marczykowski-Górecki" wrote:


> Not exactly...
>
>
> 1. qvm-start sends a request to qubesd, using Admin API
> 2. qubesd starts required netvm (recursively), if needed
> 3. qubesd request qmemman to allocate needed memory for new VM
> (according to VM's 'memory' property)
> 4. qubesd calls into appropriate storage pool driver to prepare for VM
> startup (create copy-on-write layers etc)
> 5. qubesd gathers needed VM
> properties etc and builds libvirt VM configuration (XML format, can be
> seen using `virsh dumpxml`)
> 6. qubesd calls into libvirt to start the VM
> (but in paused mode)
> 7. libvirt setup the VM using libxl, this include starting stubdomain if
> needed
> 8. qubesd start auxiliary processes, including:
> - qrexec-daemon
> - qubesdb-daemon (and fill its content)
> 9. libvirt unpause the VM
> 10. qvm-start-gui process (running separately from qubesd, as part of
> dom0 user GUI session) starts gui daemon

Thank you, sir. No wonder I was having trouble following the control flow.

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

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 03:42:43PM -, awokd wrote:
> On Thu, January 18, 2018 3:06 pm, Simon Gaiser wrote:
> > awokd:
> >
> >> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
> >>
> >>
> >>>
> >>> According to logs provided by mossy-nw permissive mode is correctly
> >>> enabled in xen-pciback in dom0 for this device. The question here is
> >>> what else is needed for HVM (using qemu in stubdomain).
> >>
> >> My dom0 log shows that too, but the guest-dm/debug log showed the PCI
> >> device always getting added with permissive=false. Maybe that's what you
> >>  are saying, qemu isn't passing the value along?
> >
> > Yes that's the problem. The guide sets permissive mode in pciback and
> > not via libxl. So the stubdomain never learns about it. Will take a look
> > today.
> 
> Was trying to beat you to it but got lost in all the layers! Does anyone
> know of a flowchart somewhere of what happens when you enter "qvm-start
> vm" in 4.0? I gathered:
> 
> qvm-start
> qubesadmin -> QubesDB
> salt
> libxl calls Xen code-> stubdomain with qemu
> qemu uses libxl calling Xen code to start vm

Not exactly...

1. qvm-start sends a request to qubesd, using Admin API
2. qubesd starts required netvm (recursively), if needed
3. qubesd request qmemman to allocate needed memory for new VM
   (according to VM's 'memory' property)
4. qubesd calls into appropriate storage pool driver to prepare for VM
   startup (create copy-on-write layers etc)
5. qubesd gathers needed VM properties etc and builds libvirt VM
   configuration (XML format, can be seen using `virsh dumpxml`)
6. qubesd calls into libvirt to start the VM (but in paused mode)
7. libvirt setup the VM using libxl, this include starting stubdomain if
   needed
8. qubesd start auxiliary processes, including:
   - qrexec-daemon
   - qubesdb-daemon (and fill its content)
9. libvirt unpause the VM
10. qvm-start-gui process (running separately from qubesd, as part of
   dom0 user GUI session) starts gui daemon

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgyFIACgkQ24/THMrX
1yyEEwf+K1bF8s/zig+WmCFKfVrF+G9kFTC0l4FWejwbNBd3pslgz2ED6fu9S3S/
j/5OpEj40DF404FT7i1c9R6J0+hWvrIcuizZUJ3sY0Ip1na12sivxInhesLsOzMk
Qn/tz5Tob1HuowJEZG5CwBo/WkVZvkDmzn9hBFDg3hOoRPBg/kdFNJduQM+/zYGq
0SPfG9dUDKlDsi41hV4/ciZJiMRwOJIhaPj8nioyBUxrZSrhy8V1Z4/q8sCXxPu3
h8akFQxqyb27D7FjCgZALiISR0Er5pm3vsVhaNamEMV98A16BbmjHJAAbtTFGMUL
aFqppX3FK0v/g+RogLvyoBPxHYKkkA==
=eXzz
-END PGP SIGNATURE-

-- 
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/20180118161618.GZ2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Simon Gaiser]

Marek Marczykowski-Górecki:> On Thu, Jan 18, 2018 at 03:06:00PM +, Simon 
Gaiser wrote:
>> awokd:
>>> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
>>>

 According to logs provided by mossy-nw permissive mode is correctly
 enabled in xen-pciback in dom0 for this device. The question here is what
 else is needed for HVM (using qemu in stubdomain).
>>>
>>> My dom0 log shows that too, but the guest-dm/debug log showed the PCI
>>> device always getting added with permissive=false. Maybe that's what you
>>> are saying, qemu isn't passing the value along?
> 
>> Yes that's the problem. The guide sets permissive mode in pciback and
>> not via libxl. So the stubdomain never learns about it. Will take a look
>> today.
> 
> If that's the case, it looks we need another option for PCI device, like
> this:
> 
> qvm-pci attach sys-net dom0:xx_yy.zz -o permissive=True

Yes, exactly. And if I didn't miss something we first need to teach
libvirt about the permissive option.

-- 
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/a4a1f49c-4568-405c-ba05-6755da75abf2%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 03:06:00PM +, Simon Gaiser wrote:
> awokd:
> > On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
> > 
> >>
> >> According to logs provided by mossy-nw permissive mode is correctly
> >> enabled in xen-pciback in dom0 for this device. The question here is what
> >> else is needed for HVM (using qemu in stubdomain).
> > 
> > My dom0 log shows that too, but the guest-dm/debug log showed the PCI
> > device always getting added with permissive=false. Maybe that's what you
> > are saying, qemu isn't passing the value along?
> 
> Yes that's the problem. The guide sets permissive mode in pciback and
> not via libxl. So the stubdomain never learns about it. Will take a look
> today.

If that's the case, it looks we need another option for PCI device, like
this:

qvm-pci attach sys-net dom0:xx_yy.zz -o permissive=True

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgvHYACgkQ24/THMrX
1ywg3Qf/c/gV4AycMBti0O65ZP8s2tROvOBH8JkAZlNkO988GeQrPc4/O6fW4wR8
sfLLPzfylFTqcYm/gX8/UmNY01b/v167zUf2SLdqvCEqt08hykJ+fVII0tLuPz6c
fxvCyjrF3Q4zRdUaT3irL20TYoVPYZrbJwvtVk0gtHdmSMcmQIVQ4gU3isf3hYu9
RdRJ58Qulom9fmAlTu1LeQWdnzFLFW7ryIMtM7xaYC1RawLlEuxeIUjOCHxZP0Uw
zfexZkFyHHFTpGSE0tJT47jhK8JiHOIj+YEFASeaNu9DTTsGPTZxmnDD0aAh0FvT
OFXRpDPqIh31xQlnoHI7fGokETOTDg==
=tSUs
-END PGP SIGNATURE-

-- 
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/20180118152542.GY2653%40mail-itl.
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)

['awokd' via qubes-users]

On Thu, January 18, 2018 3:04 pm, cooloutac wrote:
> But if you have to buy a new
> mobo and pc every year or two to stay up to date that is a sad future for
> most people.

Most people, but not the Intel board members and stockholders!


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

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Simon Gaiser]

awokd:
> On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:
> 
>>
>> According to logs provided by mossy-nw permissive mode is correctly
>> enabled in xen-pciback in dom0 for this device. The question here is what
>> else is needed for HVM (using qemu in stubdomain).
> 
> My dom0 log shows that too, but the guest-dm/debug log showed the PCI
> device always getting added with permissive=false. Maybe that's what you
> are saying, qemu isn't passing the value along?

Yes that's the problem. The guide sets permissive mode in pciback and
not via libxl. So the stubdomain never learns about it. Will take a look
today.

-- 
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/b33c3a7f-4857-4507-c8a2-961a0bbdbd8b%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

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

[cooloutac]

SO it doesn't look like 4th or 5th generation boards are going to get a bios 
patch.  IS the bios patch nescessary?

Or Should we just assume our desktop pc's are about as secure as android phones 
now?   Are they no good after a year or two?  I joke that real security costs 
alot of money because when firmware gets compromised nothing you can do but 
replace the pc.But if you have to buy a new mobo and pc every year or two 
to stay up to date that is a sad future for most people.  

-- 
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/dfa0ab2f-a7fd-4911-a820-e7a3e92b2e8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

['awokd' via qubes-users]

On Thu, January 18, 2018 2:26 pm, "Marek Marczykowski-Górecki" wrote:

>
> According to logs provided by mossy-nw permissive mode is correctly
> enabled in xen-pciback in dom0 for this device. The question here is what
> else is needed for HVM (using qemu in stubdomain).

My dom0 log shows that too, but the guest-dm/debug log showed the PCI
device always getting added with permissive=false. Maybe that's what you
are saying, qemu isn't passing the value along?

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

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jan 18, 2018 at 02:12:26PM -, awokd wrote:
> On Thu, January 18, 2018 1:17 am, Marek Marczykowski-Górecki wrote:
> > On Thu, Jan 18, 2018 at 01:05:46AM +, mossy-nw wrote:
> >>> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:
> 
>  Has anyone using Qubes R4.0 been able to resolve any issues (e.g.
>  with wifi) by setting PCI permissive mode? (as described in:)
> >>>
>  https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-iss
>  ues
> 
> > I assume this is after enabling permissive mode, right?
> > Simon, is setting permissive mode in dom0 enough? Or maybe qemu in
> > stubdomain perform some additional filtering?
> 
> Per device permissive mode is broken in 4.0. I was trying to figure out
> where exactly while troubleshooting my Atheros card. I found where the
> init script in the stubdomain reads the device values from xenstore, but I
> couldn't find anywhere that actually added per device permissive entries
> to xenstore (whereas I did find where msitranslate and power_mgmt got
> set).
> 
> For my troubleshooting, I set the init script to default to
> permissive=true which results in every device being added as permissive
> but it didn't help my Atheros case anyways.

According to logs provided by mossy-nw permissive mode is correctly
enabled in xen-pciback in dom0 for this device. The question here is
what else is needed for HVM (using qemu in stubdomain).

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpgrokACgkQ24/THMrX
1yx8tQf9GA3s9nLdFQjLeQ6SRcsQGUVd/BSUkz/n+ssrcJHOm3xmcbi7bxE5/Pyd
iubkwqZwxCkNOLD1SAVVGEXmcPCh1mLvxCNhms2s16J0YQSBYTYEEgytgc3Maf6N
SZ80cCSnj4wM/OOc3xG7dbjq7cB827OyE4l3wxTzjnCKubRK6BKLMrJp9S/mG0O6
q45Hr1q75kRwZwRg77DAwq7wkVt9CSk8+S9tltlA6Cj0zK6wnw+4Enp21QHCgEim
z78RvpHZEjQefQAxIX9omIR1QsDvWj4uLSdQTisJZUseOU23rSqxtNU1MNisjKNn
88zC1Z4pJP6MX8SmfRlFR6RdkWi3lg==
=Nn3O
-END PGP SIGNATURE-

-- 
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/20180118142617.GW2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] PCI passthrough working in Qubes R4.0?

['awokd' via qubes-users]

On Thu, January 18, 2018 1:17 am, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 18, 2018 at 01:05:46AM +, mossy-nw wrote:
>>> On Wed, Jan 17, 2018 at 11:54:23PM +, mossy-nw wrote:

 Has anyone using Qubes R4.0 been able to resolve any issues (e.g.
 with wifi) by setting PCI permissive mode? (as described in:)
>>>
 https://www.qubes-os.org/doc/assigning-devices/#pci-passthrough-iss
 ues

> I assume this is after enabling permissive mode, right?
> Simon, is setting permissive mode in dom0 enough? Or maybe qemu in
> stubdomain perform some additional filtering?

Per device permissive mode is broken in 4.0. I was trying to figure out
where exactly while troubleshooting my Atheros card. I found where the
init script in the stubdomain reads the device values from xenstore, but I
couldn't find anywhere that actually added per device permissive entries
to xenstore (whereas I did find where msitranslate and power_mgmt got
set).

For my troubleshooting, I set the init script to default to
permissive=true which results in every device being added as permissive
but it didn't help my Atheros case anyways.


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