Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread zachm1996 
On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote:
>
> On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek 
> Marczykowski-Górecki wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- 
>> Hash: SHA256 
>>
>> On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com wrote: 
>> > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com 
>> wrote: 
>> > > 
>> > > I preemptively submitted this PR to see what the Qubes team thinks. 
>> > > https://github.com/QubesOS/qubes-vmm-xen/pull/70 
>> > > 
>> > > I agree it probably should be fixed upstream, although I've seen the 
>> Qubes 
>> > > team make exceptions and apply their own changes. Upstream would 
>> probably 
>> > > take a huge amount of time to get merged and tested. I'm not a 
>> developer 
>> > > though so I'm sure you could explain the issue better than I. If you 
>> do 
>> > > mention it, CC me as well! I like the CLI argument idea, that's 
>> probably a 
>> > > much cleaner way of doing it and defaulting it to true. That way 
>> users 
>> > > could disable it if needed due to hardware screw-ups. 
>> > > 
>> > 
>> > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is 
>> > probably as good a place to start the (github) discussion I suppose. 
>> > 
>> > I expect Claudia is correct that it's really a Xen defect to address, 
>> > either with a flag to disable the check, or security/stability focused 
>> > checks only. 
>> > 
>> > Xen might point upwards again, of course, and tell AMD to fix their 
>> > microcode or manufacturer's their BIOS's... 
>> > 
>> > ...but if a disable flag could be added (--yes_i_know_what_im_doing 
>> caveat, 
>> > of course) that'd be a good short term workaround for the larger Qubes 
>> user 
>> > base that is less likely to be able to figure out how to get a build 
>> > working and rpm applied and keep up to date with upstream. 
>>
>> (continuing discussion from the above PR) 
>>
>> The patch as it is, is not acceptable, as it may introduce security 
>> and/or stability issues on some machines. Xen (and Linux too) assumes 
>> what CPU features is can use based on CPUID flags. If those changes 
>> during system runtime (including suspend/resume) some instructions or 
>> control registers may no longer be valid (->crash) or safe to use 
>> (->security issue). 
>>
>
> Appreciate you joining the discussion Marek, your input is really valued :)
>  
>
>>
>> If that's just about microcode updates, that's probably BIOS bug - if it 
>> applies microcode update on system startup, it should do the same on 
>> system resume too. Anyway it's worth trying updating linux-firmware 
>> package, which carries microcode updates for AMD. This should make Xen 
>> apply microcode updates too - before checking those flags. 
>> I've just uploaded updated version of the package to the current-testing 
>> repository (both R4.0 and R4.1). 
>>
>
> I totally understand the resistance to merge the PR and that the real 
> cause of the issue should be fixed in BIOS or OS CPU microcode.
>
> I will be testing that new linux-firmware package on R4.0 shortly and will 
> report back, thanks for uploading it. I've used my laptop on and off all 
> day with suspending it multiple times using the "hacky" patch. If the new 
> microcode works, it shouldn't write the log line saying it has missing 
> features. I still have the vmm-xen packages I built with the modified patch 
> installed.
>

I installed the new linux-firmware in dom0, rebooted and tested a 
suspend/resume. Sadly the Xen log says the bits changed still so I'm 
guessing this will have to be addressed by AMD and hardware manufacturers. 
Will have to put some thought into what to do next.
 

>  
>
>>
>> If that's about something else, then fixing it would require finding 
>> what exactly is changing (and preferably also why). And only then find 
>> how to mitigate this issue. If specific flags would turn out to be not 
>> related to security features or otherwise having unwanted effects, then 
>> ignoring those changes would be an option. But ignoring _only those 
>> flags verified to be safe to ignore_, not all of them. 
>>
>
> I hope it doesn't come to that but we'll see. I wouldn't really know what 
> else to do besides complain to Lenovo and hope they yell up at AMD to 
> investigate. I assume it's something weird between hardware manufacturers 
> and AMD.
>  
>
>>
>> - -- 
>> 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/THMrX1ywFAl4/abcACgkQ24/THMrX 
>> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq 
>> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F 
>> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh 
>> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM 
>>

Re: VS: [qubes-users] Re: 2 new Intel vulnerabilites

2020-02-09 Thread reggelo 

>
> I've got the same exact setup and same issues with suspend/resume :(
>
> Haven't found any solution so far, have you?
>

I have tried with 4.1 (Build4.1-20200131) 
 but the result is the same: 
suspend/resume not working :(
With Debian (Bullseye) works! But after i install the xen, same suspend 
issue appear again...
Related lines from dmesg:
'
[4.957422] kfd kfd: Allocated 3969056 bytes on gart
[4.957512] kfd kfd: error getting iommu info. is the iommu enabled?
[4.957514] kfd kfd: Error initializing iommuv2
[4.961211] kfd kfd: device 1002:15d8 NOT added due to errors
'
@Michael Andersson: Could you please tell us which configuration works to 
you?



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c8e237d5-084d-45af-9749-5bb3a55d7132%40googlegroups.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread zachm1996 
On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek 
Marczykowski-Górecki wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com  
> wrote: 
> > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote: 
> > > 
> > > I preemptively submitted this PR to see what the Qubes team thinks. 
> > > https://github.com/QubesOS/qubes-vmm-xen/pull/70 
> > > 
> > > I agree it probably should be fixed upstream, although I've seen the 
> Qubes 
> > > team make exceptions and apply their own changes. Upstream would 
> probably 
> > > take a huge amount of time to get merged and tested. I'm not a 
> developer 
> > > though so I'm sure you could explain the issue better than I. If you 
> do 
> > > mention it, CC me as well! I like the CLI argument idea, that's 
> probably a 
> > > much cleaner way of doing it and defaulting it to true. That way users 
> > > could disable it if needed due to hardware screw-ups. 
> > > 
> > 
> > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is 
> > probably as good a place to start the (github) discussion I suppose. 
> > 
> > I expect Claudia is correct that it's really a Xen defect to address, 
> > either with a flag to disable the check, or security/stability focused 
> > checks only. 
> > 
> > Xen might point upwards again, of course, and tell AMD to fix their 
> > microcode or manufacturer's their BIOS's... 
> > 
> > ...but if a disable flag could be added (--yes_i_know_what_im_doing 
> caveat, 
> > of course) that'd be a good short term workaround for the larger Qubes 
> user 
> > base that is less likely to be able to figure out how to get a build 
> > working and rpm applied and keep up to date with upstream. 
>
> (continuing discussion from the above PR) 
>
> The patch as it is, is not acceptable, as it may introduce security 
> and/or stability issues on some machines. Xen (and Linux too) assumes 
> what CPU features is can use based on CPUID flags. If those changes 
> during system runtime (including suspend/resume) some instructions or 
> control registers may no longer be valid (->crash) or safe to use 
> (->security issue). 
>

Appreciate you joining the discussion Marek, your input is really valued :)
 

>
> If that's just about microcode updates, that's probably BIOS bug - if it 
> applies microcode update on system startup, it should do the same on 
> system resume too. Anyway it's worth trying updating linux-firmware 
> package, which carries microcode updates for AMD. This should make Xen 
> apply microcode updates too - before checking those flags. 
> I've just uploaded updated version of the package to the current-testing 
> repository (both R4.0 and R4.1). 
>

I totally understand the resistance to merge the PR and that the real cause 
of the issue should be fixed in BIOS or OS CPU microcode.

I will be testing that new linux-firmware package on R4.0 shortly and will 
report back, thanks for uploading it. I've used my laptop on and off all 
day with suspending it multiple times using the "hacky" patch. If the new 
microcode works, it shouldn't write the log line saying it has missing 
features. I still have the vmm-xen packages I built with the modified patch 
installed.
 

>
> If that's about something else, then fixing it would require finding 
> what exactly is changing (and preferably also why). And only then find 
> how to mitigate this issue. If specific flags would turn out to be not 
> related to security features or otherwise having unwanted effects, then 
> ignoring those changes would be an option. But ignoring _only those 
> flags verified to be safe to ignore_, not all of them. 
>

I hope it doesn't come to that but we'll see. I wouldn't really know what 
else to do besides complain to Lenovo and hope they yell up at AMD to 
investigate. I assume it's something weird between hardware manufacturers 
and AMD.
 

>
> - -- 
> 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/THMrX1ywFAl4/abcACgkQ24/THMrX 
> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq 
> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F 
> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh 
> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM 
> 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz 
> iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg== 
> =h62J 
> -END PGP SIGNATURE- 
>

P.S. the bits do change for me as stated in the Xen log when I resume from 
a suspend. Here is what mine says.

(XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b)


-- 
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

Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

2020-02-09 Thread 'awokd' via qubes-users 
Sven Semmler:
> Hi,
> 
> I created a sys-firewall based on debian-10-minimal:
> 
> * qvm-clone debian-10-minimal deb-10-sys-firewall
> * qvm-create --template deb-10-sys-firewall --label blue dvm-sys-firewall
> * qvm-prefs dvm-sys-firewall template_for_dispvms True
> * qvm-create --class DispVM --template dvm-sys-firewall --lable blue 
> sys-firewall
> * qvm-prefs sys-firewall provides_network True
> * qvm-prefs sys-firewall netvm sys-net
> 
> Then in deb-10-sys-firewall (template):
> 
> * sudo apt-get install qubes-core-agent-networking 
> qubes-core-agent-dom0-updates 
> * attempting to install iproute tells me that this package no longer exists 
> and I shall try iproute2
> * iproute2 does exist and was already installed
> 
> Then in dvm-sys-firewall (template for disposable):
> 
> * added "iptables -I FORWARD 2 -s 10.137.0.21 -d 10.137.0.25 -j ACCEPT" to 
> /rw/config/qubes-firewall-user-script
> 
> Then shut everything down and started sys-firewall.
> 
> Result: 
> 
> * network connectivity working
> * the above mentioned iptables rule is working (.21 can connect to .25)
> * qubes-qube-manager gives me this error when I try to edit the firewall 
> rules of any qube connected to sys-firewall: "Networking qube does not 
> support 'qubes-firewall' - firewall restrictions will not be applied."
> * however it does not give me this error when I try to edit other qubes 
> connected to sys-whonix
> 
> Any ideas?
> 
> /Sven
> 
Maybe it doesn't like the "disposable" part? Try it with a regular AppVM
based on that same minimal template.


-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0e3469a9-8219-3b3c-c071-bad91494dba6%40danwin1210.me.

Re: [qubes-users] Tips for configuring Qubes firewall?

2020-02-09 Thread 'awokd' via qubes-users 
fiftyfourthparal...@gmail.com:
> I'm new to Qubes and I've nearly finished setting up my machine for it's 
> first network connection (purged all Fedora, enabled AppArmor, disabled 
> passwordless root, etc.)
> 
> Firewalls are an enigma to me but I know they're super important, so I just 
> wanted to ask: Is there anything you think I should know before connecting? 
> 
>- Is it fine to just stick with the installation default? 

Probably!

>- Are there any firewall structures (e.g. more than one) that confer 
>improved security? 

I have a hard time thinking of a scenario where multiple sys-firewalls
would protect from a compromise while a single would not. Doesn't mean
there isn't one.

>- Any rules you'd say are highly recommended for the security and 
>privacy enthusiast?
> 
> All I'm looking to do is surf the internet using tor and/or vpn, and maybe 
> torrenting. High tolerance for annoyance. No plans for other apps yet.

If you have a reliable guard/bridge that is also a directory server you
can set a rule for sys-whonix so it can only communicate to its IP &
port. You can also disable IPv6 on it and Whonix workstations
(qvm-features sys-whonix ipv6 '').

> Feel free to add in any other security tips someone like me might find 
> essential
> 
> Thanks in advance!
> 


-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c955dd1a-d159-1b5a-2c01-d19a1d9257c3%40danwin1210.me.

Re: [qubes-users] Can't update or install anything in dom0 last two days

2020-02-09 Thread 'awokd' via qubes-users 
0...@tuta.io:
> Hi.
> 
> 
> This repos unreachable:
> 
> baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/25/Everything/x86_64/os/
> baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/25/x86_64
> 
> 
> Can you recommended any another good dom0 trusted fedora repos?
> 
> Has Anyone has network troubles on Qubes 4.0.3?
> I use two diferent laptops.

Those aren't the default repos set in Qubes. Check in dom0's
/etc/yum.repos.d. Use the "metalink=" ones, not the "#baseurl="s.


-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5c8d615f-445a-e679-3272-427b57f3ef70%40danwin1210.me.

Re: [qubes-users] Is Qubes Split GPG safe?

2020-02-09 Thread 'awokd' via qubes-users 
Claudio Chinicz:
> All the idea behind this is to keep your keys in a safe place (VM without 
> network), isolated from your application VM.
> 
> I've installed the work-gpg (keys vault) and created a mail VM with 
> Thunderbird and Enigmail.
> 
> While Enigmail cannot create new keys on the vault (I have to manually import 
> them), it allows me to download/copy the contents of my keys (private).
> 
> So, if my mail VM is compromised my keys may be stolen/used regardless of my 
> keys being kept in a vault!
> 
> So, what's the purpose of split gpg?
> 
> Thanks for any feedback.
> 
In a way, it's security by obscurity- some code looking for keys won't
know to request through split-gpg. It prompts every time it accesses
your keys with split-gpg, with the theory being the user will recognize
an unauthorized request and deny it. In practice, it's difficult to
determine authorized vs. unauthorized with Thunderbird because it
requests access every time a signed email arrives.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9784b2c6-5b1b-1005-dbda-a6ee3d1b%40danwin1210.me.

Re: [qubes-users] How to install software in an AppVM without loosing persistence?

2020-02-09 Thread unman 
On Sun, Feb 09, 2020 at 05:16:09PM +0100, dhorf-hfref.4a288...@hashmail.org 
wrote:
> On Sun, Feb 09, 2020 at 12:49:39PM -, 'Monsieur DuPont' via qubes-users 
> wrote:
> > That looks like a good solution, unfortunately I couldn't find any easy way 
> > to
> > do it online (I have no experience in Linux terminal kung fu). So any help
> > with that regards would be deeply appreciated, especially since the other
> 
> that depends a lot on what you are trying to install.

Yes, it does.
In Fedora you can install using `dnf --installroot`  option
I dont think there is a similar option in Debian.
If you have a tar file, you can untar it where you will (e.g Tor
Browser)
If you have sources, you can very often compile and install wherever you
want, and the README will help you to do that.

> 
> 
> > solution (of cloning a TemplateVM and installing stuff in it) didn't work 
> > for
> 
> or you just install it in the template, without any cloning.
> that should work for anyone who is not part of the "computers are more
> secure without a compiler installed" cult.

There are many reasons for cloning templates, and security and
compartmentalization are two of them.
I dont know any cultists such as you describe. I do know security
professionals who maintain distinct templates for different qubes, on
the reasonable ground of reducing attack surface where possible. I prefer
to follow them.

unman

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209165613.GA8405%40thirdeyesecurity.org.

Re: [qubes-users] How to install software in an AppVM without loosing persistence?

2020-02-09 Thread 'Monsieur DuPont' via qubes-users 
 Depending on what the software is, and how it is installed, you may also
be able to install to one of the persistent directories under /rw - /home/user
(obviously) or under /usr/local  

  

That looks like a good solution, unfortunately I couldn't find any easy way to
do it online (I have no experience in Linux terminal kung fu). So any help
with that regards would be deeply appreciated, especially since the other
solution (of cloning a TemplateVM and installing stuff in it) didn't work for
me for some reason :(  

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/158125257859.8132.14324487181550564431%40startmail.com.

Re: [qubes-users] No Internet through sys-net and sys-firewall in qubes 4.0

2020-02-09 Thread 'awokd' via qubes-users 
Taehwan Kim:

> In sys-net

> 4: vif16.0:  mtu 1500 qdisc noop state DOWN group 
> default qlen 32 <-- I think this is sys-firewall connected to sys-net
> 
> in sys-firewall
> ip addr | grep -i cast
> 
> 2: eth0:  mtu 1500 qdisc mq state UP group 
> default qlen 1000
> 3: vif18.0:  mtu 1500 qdisc noop state DOWN group 
> default qlen 32

Yes, that vif interface should be UP on both. Check sudo journalctl in
sys-net to see if any related errors are logged. Might try creating a
new sys-net from scratch to see if that helps (make a new AppVM with
"provides network" checked, set to HVM, attach your NIC(s)).

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8bb14a93-5f59-3f51-770f-c1e9829c4bed%40danwin1210.me.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread brendan . hoar 
On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote:
>
>
> Has anyone tried utilizing the xen command line options to mask bits in 
> the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? 
>
> The man page below says that "Settings applied here take effect globally, 
> including for Xen and all guests." This *might* mean it is applied *before* 
> the resume from sleep CPU bit checks (but I'm not promising anything, as I 
> have not traced through the source). And also "*Warning: This option is 
> not fully effective on Family 15h processors or later.*"
>

Just noticed that the warning applies only to 1.2.34, which is AMD-only, 
apparently. Unclear to me if the other items 1.2.35 and higher, which is 
for "x86" apply only to intel or to all x86 architecture.
 
B

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4e3833ec-12e9-4f12-a128-52d449ec336d%40googlegroups.com.

[qubes-users] Re: Upgrade to 16 GB RAM for an X230

2020-02-09 Thread ggg397 
I have posted on the other sites.   Perhaps the best answer I will get is 
when I contact Crucial itself, during the week.  I also wanted to ask info 
from those who are doing the same thing.  

Any comment about which device you used to put Core Boot onto laptop?  I 
see of the programming devices which I have to wait for it to come from 
China.

One of the sources for changing the wireless adapters is also from China.

I see some offers to sell batteries which have more cells.  Not sure if 
these batteries will fit.  Anyone have experiences with this.   

Shame I did not have the money to buy the core I7 from the beginning, I 
know those things can be replaced in some desktop MOBO's.  Can it be done 
with this laptop?  

Any other suggestions of fixes, upgrades, or tests to make?


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a27c928c-69b5-4165-9278-d1e97bb6ed3d%40googlegroups.com.

Re: [qubes-users] Where are the VM NICs?

2020-02-09 Thread 'awokd' via qubes-users 
Ulrich Windl:
> I have a question on the networks used for VM communication:
> I'm using Xen PVMs, and then I see the virtual NICs a VM has in xentop (for 
> example).
> However in Qubes OS the number of NICs is zero. So where are those NICS and 
> virtual LANs configured? I also could not find a bridge device.
> Maybe the FAQ could be updated regarding that...
> 
> Regards,
> Ulrich
> 
They are configured in scripts ran on startup. Check ip link in sys-net
for example, and you'll see a vif. Sys-firewall will have a couple. I
don't know why they don't appear in xl top in dom0. Qubes doesn't have a
bridge device by default.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/374b1bc6-3f58-baf2-c9f5-12a21c60a2f5%40danwin1210.me.

Re: [qubes-users] Is Qubes Split GPG safe?

2020-02-09 Thread Claudio Chinicz 
‎Thanks, I now better understand the concepts.

On Sunday, 9 February 2020 15:41:39 UTC+2, awokd wrote:
>
> Claudio Chinicz: 
> > All the idea behind this is to keep your keys in a safe place (VM 
> without network), isolated from your application VM. 
> > 
> > I've installed the work-gpg (keys vault) and created a mail VM with 
> Thunderbird and Enigmail. 
> > 
> > While Enigmail cannot create new keys on the vault (I have to manually 
> import them), it allows me to download/copy the contents of my keys 
> (private). 
> > 
> > So, if my mail VM is compromised my keys may be stolen/used regardless 
> of my keys being kept in a vault! 
> > 
> > So, what's the purpose of split gpg? 
> > 
> > Thanks for any feedback. 
> > 
> In a way, it's security by obscurity- some code looking for keys won't 
> know to request through split-gpg. It prompts every time it accesses 
> your keys with split-gpg, with the theory being the user will recognize 
> an unauthorized request and deny it. In practice, it's difficult to 
> determine authorized vs. unauthorized with Thunderbird because it 
> requests access every time a signed email arrives. 
>
> -- 
> - don't top post 
> Mailing list etiquette: 
> - trim quoted reply to only relevant portions 
> - when possible, copy and paste text instead of screenshots 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/83c9d18c-0720-47d5-be07-89337013828b%40googlegroups.com.

Re: [qubes-users] Is Qubes Split GPG safe?

2020-02-09 Thread Claudio Chinicz 
Hi, thanks. It is now much clearer the inner workings of split gpg.

On Sunday, 9 February 2020 15:49:45 UTC+2, qubes...@riseup.net wrote:
>
> Claudio Chinicz wrote: 
> > All the idea behind this is to keep your keys in a safe place (VM 
> > without network), isolated from your application VM. 
> > 
> > I've installed the work-gpg (keys vault) and created a mail VM with 
> > Thunderbird and Enigmail. 
> > 
> > While Enigmail cannot create new keys on the vault (I have to 
> > manually import them), it allows me to download/copy the contents of 
> > my keys (private). 
> > 
> > So, if my mail VM is compromised my keys may be stolen/used 
> > regardless of my keys being kept in a vault! 
> > 
> > So, what's the purpose of split gpg? 
>
> The private keys should never touch the online VM running thunderbird. 
> The keys should be generated on the offline VM and the only way to 
> perform operations that require the private key must be via the 
> split GPG setup. 
>
> If you generated the key on the online VM it is probably best to 
> start with a new one if you would like to get the benefit of the split GPG 
> setup of Qubes. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/486e2167-59c2-4160-8f0e-ce3ed0c1ce7f%40googlegroups.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread Brendan Hoar 
On Sun, Feb 9, 2020 at 9:15 AM Claudia  wrote:

> From linuxreviews.org:
> "There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. [...] RDRAND support is
> indicated by CPUID Fn0001_ECX[30]. This bit can be reset by clearing
> MSR C001_1004[62]. Any software that checks for RDRAND support using CPUID,
> including the kernel, will believe that RDRAND is not supported. "
>
> According to the page below, RDRAND is bit 30 in ECX, not 31. And that
> still doesn't explain the 27th bit turning on after resume.
> 27: OSXSAVE (turns ON)
> 30: RDRAND (unchanged)
> 31: Not used, always 0 (turns ON)
>
> https://www.felixcloutier.com/x86/cpuid#fig-3-7
>
> So it doesn't sound like the same problem at all, but all my search
> queries seem to lead back to the RDRAND issue. I'm hoping someone with more
> expertise in this area can make some better sense of this.


Hmm bit 27 can be influenced by software. Might be an issue where the value
was saved for reference before the OS/hypervisor modified it?
OSXSAVE A value of 1 indicates that the OS has set CR4.OSXSAVE[bit 18] to
enable XSETBV/XGETBV instructions to access XCR0 and to support processor
extended state management using XSAVE/XRSTOR

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOajFedfNAM-wo2k7bD4oSWAOrfWfp3J%2BO4pnVHR7nXg3%2BKOCg%40mail.gmail.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread Claudia 
> marmarek:
> This is a very bad idea to "fix" it. Those missing/changed CPUID bits later 
> on will cause issues.
> And given most of the microcode updates recently are about speculative 
> execution, missing those
> features will make the host vulnerable to those issues again. There are 
> multiple ways it can
> manifest - from crashes when Xen uses (now not present) CPU feature, to 
> silent failures when Xen
> tries to use some feature and assume it protects the system, while it does 
> not in practice.
> 
> For this particular case (microcode included in BIOS newer than in OS), I see 
> two options: make
> BIOS (coreboot, right?) apply microcode update on resume too, or include 
> newer microcode in OS.

I want to make one thing clear: I am **not** suggesting this check be removed 
altogether. I am suggesting adding an **optional**, even undocumented, override 
parameter which defaults to the **current behavior** which is to panic. 

I've found the patch to be quite stable so far. Unpatched is guaranteed to 
cause a crash (xen
panic) at resume; patched so far has not caused any noticeable stability issues 
for the four of us
using it, afaik. Just saying.

Also, not everyone has the option of coreboot. And we're not even completely 
certain this a
post-resume microcode update issue, either.

> lunarthegray:
> @marmarek the "fix" is a hack for sure but it's currently the only way to get 
> some AMD Ryzen
> laptops to work with Qubes. I built Qubes R4.1 the other day and with kernel 
> 5.4 and Xen 4.13 the
> issue remains.Laptop users often suspend and are on the go as I am. There was 
> some discussion on
> the qubes-users mailing list about other solutions. I'm no firmware/Xen 
> expert though. Would
> pinning dom0 to 1 vCPU prevent the issue of missing or changed CPU bits?I'm 
> not exactly sure what
> the fix would be with standard BIOS, as I'm not brave enough to flash 
> coreboot on my very new
> ThinkPad. Should I start trying to get in contact with Lenovo? I'm assuming 
> AMD needs to release a
> microcode patch as it's not really an issue with Xen itself.

At least in my case, CPU pinning did not fix this issue. The bits still change 
and (would) cause a
Xen panic as before. Pinning dom0 to CPU0 merely fixed a separate post-resume 
issue with my SATA
controller. In that thread, I link to the original Xen archives thread about 
pinning which had
nothing to do with Ryzen.

February 9, 2020 2:09 AM, "Marek Marczykowski-Górecki" 
 wrote:
> (continuing discussion from the above PR)
> 
> The patch as it is, is not acceptable, as it may introduce security
> and/or stability issues on some machines. Xen (and Linux too) assumes
> what CPU features is can use based on CPUID flags. If those changes
> during system runtime (including suspend/resume) some instructions or
> control registers may no longer be valid (->crash) or safe to use
> (->security issue).

Like I said, it's been very stable for me so far. I've only had one bad resume 
in the months I've been using it, suspending at least once a day. Security 
issues on the other hand are indeed unknown at this point.

Also worth noting that this is Xen-specific. Afaik, the Linux kernel doesn't 
check for these changes. So everyone using plain old Ubuntu or whatever would 
be subject to the same stability and security implications caused by this patch.

> If that's just about microcode updates, that's probably BIOS bug - if it
> applies microcode update on system startup, it should do the same on

Weird that it's happening equally on various vendor BIOSes as well as coreboot, 
the only thing they have in common is Ryzen 2xxx-3xxx chips. It doesn't sound 
to me like a **BIOS** bug, per se, unless all these vendors and the Coreboot 
developers wrote the same bug independently. More likely an AMD bug, imo.

> system resume too. Anyway it's worth trying updating linux-firmware
> package, which carries microcode updates for AMD. This should make Xen
> apply microcode updates too - before checking those flags.
> I've just uploaded updated version of the package to the current-testing
> repository (both R4.0 and R4.1).

Thanks for the tip. I'll try it when I have a chance. 
`--enablerepo=qubes-dom0-current-testing kernel-latest linux-firmware` I'm 
guessing?

> If that's about something else, then fixing it would require finding
> what exactly is changing (and preferably also why). And only then find
> how to mitigate this issue. If specific flags would turn out to be not
> related to security features or otherwise having unwanted effects, then
> ignoring those changes would be an option. But ignoring _only those
> flags verified to be safe to ignore_, not all of them.

See my other reply about that.

But I would like to mention, there are already all kinds of options and 
parameters throughout the Xen, Qubes, and Linux codebases that come with 
stability/security implications. This isn't Apple iOS. You can easily shoot 
yourself in the foot. That's the nature

Re: [qubes-users] How to add swap space

2020-02-09 Thread dhorf-hfref . 4a288f10 
On Sun, Feb 09, 2020 at 02:13:53PM +, 'awokd' via qubes-users wrote:
> https://github.com/Qubes-Community/Contents/blob/master/docs/misc/iaq.adoc#how-can-i-provision-a-vm-with-a-largernon-standard-swap-and-tmp

for "up to 10GB" and on a modern qubes with lvm-pool there is also ...
just start the the vm, no dom0 actions required:

vm$ sudo mkswap /dev/xvdc3
vm$ sudo swapon /dev/xvdc3
vm$ sudo mount -o remount,size=10g /tmp


the "50G" thing is harder, but can still be done "almost the same way". 
again, start the vm, but one step in dom0 and two extra steps in the vm:

dom0$ qvm-volume resize vm:volatile 50GiB
vm$ sudo swapoff -a
vm$ sudo blkdiscard /dev/xvdc
vm$ sudo mkswap /dev/xvdc
vm$ sudo swapon /dev/xvdc
vm$ sudo mount -o remount,size=50g /tmp

the swapoff+blkdiscard is only about 90% reliable in my exp, if anything
fires a blockdevice-hotplug event in between those it will auto-swapon
the old device again. just repeat swapoff+blkdiscard if the mkswap
errors out about "in use". 

both ways do not require any cleanup in the vm or in dom0.

you can check if you are on "modern qubes with lvm-pool" by checking
whether you have a /dev/xvdc3 inside the appvm. 
or more importantly, that you do NOT have a xvdc2 (which indicates
file-pool reverse-cow is in in use).




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209155801.GP8973%40priv-mua.

Re: [qubes-users] Is Qubes Split GPG safe?

2020-02-09 Thread qubes-lists 
Claudio Chinicz wrote:
> All the idea behind this is to keep your keys in a safe place (VM
> without network), isolated from your application VM.
> 
> I've installed the work-gpg (keys vault) and created a mail VM with
> Thunderbird and Enigmail.
> 
> While Enigmail cannot create new keys on the vault (I have to
> manually import them), it allows me to download/copy the contents of
> my keys (private).
> 
> So, if my mail VM is compromised my keys may be stolen/used
> regardless of my keys being kept in a vault!
> 
> So, what's the purpose of split gpg?

The private keys should never touch the online VM running thunderbird.
The keys should be generated on the offline VM and the only way to
perform operations that require the private key must be via the 
split GPG setup.

If you generated the key on the online VM it is probably best to
start with a new one if you would like to get the benefit of the split GPG
setup of Qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1be27134-6fa7-75eb-69e8-2e2047734116%40riseup.net.

Re: [qubes-users] Installation with VT-d disabled; need to redo?

2020-02-09 Thread 'awokd' via qubes-users 
Ulrich Windl:
> Hi!
> 
> I'm new to Qubes OS and to this list: I installed QUbesOS on an 64GB USB 
> stick. That took almost 3 hours! (I filed some issues at github, too)
> My problem was that I could not find the VT-d setting in the BIOS (see also 
> https://superuser.com/questions/367290/how-to-enable-hardware-virtualization-on-asus-motherboard/1152970#1152970),
>  and I was not sure whether my PC has it.
> So I continued the installation despite of the warning.
> It _seemed_ that the installation worked without an error, but there were 
> periodic messages in the installer's journal that didn't look quite right.
> Now basically the installed system works (now with Vt-d enabled), but I 
> wonder whether the installation (which seems to launch VMs temporarily) 
> suceeded normally, or whether it's better to re-do the installation (thinking 
> of another three hours...).
> 
> Regards,
> Ulrich
> 
If the installer had problems due to VT-d not being enabled, it
typically results in failing to create sys-net or sys-firewall. If your
network is working, you didn't encounter this so I wouldn't bother
reinstalling.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bcb1996a-de8a-b74b-8d02-cbb67a73bc9c%40danwin1210.me.

Re: [qubes-users] Is Qubes Split GPG safe?

2020-02-09 Thread unman 
On Sun, Feb 09, 2020 at 01:49:00PM +, qubes-li...@riseup.net wrote:
> Claudio Chinicz wrote:
> > All the idea behind this is to keep your keys in a safe place (VM
> > without network), isolated from your application VM.
> > 
> > I've installed the work-gpg (keys vault) and created a mail VM with
> > Thunderbird and Enigmail.
> > 
> > While Enigmail cannot create new keys on the vault (I have to
> > manually import them), it allows me to download/copy the contents of
> > my keys (private).
> > 
> > So, if my mail VM is compromised my keys may be stolen/used
> > regardless of my keys being kept in a vault!
> > 
> > So, what's the purpose of split gpg?
> 
> The private keys should never touch the online VM running thunderbird.
> The keys should be generated on the offline VM and the only way to
> perform operations that require the private key must be via the 
> split GPG setup.
> 
> If you generated the key on the online VM it is probably best to
> start with a new one if you would like to get the benefit of the split GPG
> setup of Qubes.
> 

I think you are missing the point.
What Claudio is reporting is a bug - you are right that the private keys
should never touch the onlineVM.  You cant manually export them using
the qubes-split-gpg-wrapper, for example.
But if you use Enigmail with the split-gpg-wrapper, the private key ends
up in the onlineVM, and is therefore open to compromise.
This cant be right.

unman




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209143143.GA7765%40thirdeyesecurity.org.

Re: [qubes-users] Re: Upgrade to 16 GB RAM for an X230

2020-02-09 Thread unman 
On Sun, Feb 09, 2020 at 06:51:38AM -0800, ggg...@gmail.com wrote:
> I have posted on the other sites.   Perhaps the best answer I will get is 
> when I contact Crucial itself, during the week.  I also wanted to ask info 
> from those who are doing the same thing.  
> 
> Any comment about which device you used to put Core Boot onto laptop?  I 
> see of the programming devices which I have to wait for it to come from 
> China.
> 
> One of the sources for changing the wireless adapters is also from China.


Almost all devices you buy will be made in China even if they are not
shipped from there.
Cheap kits are available with CH341A and SOIC clip.
I've read about people worrying about voltage- never had this issue with
any programmer.
If you want to do more than one off, a decent clip (Pomona) is a must.

>
> I see some offers to sell batteries which have more cells.  Not sure if
> these batteries will fit.  Anyone have experiences with this.

9 cell batteries will fit the x230 - you want a 44++ or equivalent.
Many of the 9 cells you buy will need an EC patch. I always apply this
*before* corebooting. Don't know if that is needed. 
https://github.com/hamishcoleman/thinkpad-ec is the source

> 
> Shame I did not have the money to buy the core I7 from the beginning, I 
> know those things can be replaced in some desktop MOBO's.  Can it be done 
> with this laptop?  
> 

No

> Any other suggestions of fixes, upgrades, or tests to make?

Replace Intel wifi with Atheros. 
Consider upgrade to IPS if you can (although many people don't see difference in
ordinary use)

unman

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209153745.GA8115%40thirdeyesecurity.org.

Re: [qubes-users] Is Qubes Split GPG safe?

2020-02-09 Thread unman 
On Sun, Feb 09, 2020 at 02:31:43PM +, unman wrote:
> On Sun, Feb 09, 2020 at 01:49:00PM +, qubes-li...@riseup.net wrote:
> > Claudio Chinicz wrote:
> > > All the idea behind this is to keep your keys in a safe place (VM
> > > without network), isolated from your application VM.
> > > 
> > > I've installed the work-gpg (keys vault) and created a mail VM with
> > > Thunderbird and Enigmail.
> > > 
> > > While Enigmail cannot create new keys on the vault (I have to
> > > manually import them), it allows me to download/copy the contents of
> > > my keys (private).
> > > 
> > > So, if my mail VM is compromised my keys may be stolen/used
> > > regardless of my keys being kept in a vault!
> > > 
> > > So, what's the purpose of split gpg?
> > 
> > The private keys should never touch the online VM running thunderbird.
> > The keys should be generated on the offline VM and the only way to
> > perform operations that require the private key must be via the 
> > split GPG setup.
> > 
> > If you generated the key on the online VM it is probably best to
> > start with a new one if you would like to get the benefit of the split GPG
> > setup of Qubes.
> > 
> 
> I think you are missing the point.
> What Claudio is reporting is a bug - you are right that the private keys
> should never touch the onlineVM.  You cant manually export them using
> the qubes-split-gpg-wrapper, for example.
> But if you use Enigmail with the split-gpg-wrapper, the private key ends
> up in the onlineVM, and is therefore open to compromise.
> This cant be right.
> 
> unman
> 

I've raised issue.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209153911.GB8115%40thirdeyesecurity.org.

Re: [qubes-users] How to install software in an AppVM without loosing persistence?

2020-02-09 Thread dhorf-hfref . 4a288f10 
On Sun, Feb 09, 2020 at 12:49:39PM -, 'Monsieur DuPont' via qubes-users 
wrote:
> That looks like a good solution, unfortunately I couldn't find any easy way to
> do it online (I have no experience in Linux terminal kung fu). So any help
> with that regards would be deeply appreciated, especially since the other

that depends a lot on what you are trying to install.


> solution (of cloning a TemplateVM and installing stuff in it) didn't work for

or you just install it in the template, without any cloning.
that should work for anyone who is not part of the "computers are more
secure without a compiler installed" cult.



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209161609.GQ8973%40priv-mua.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread brendan . hoar 
On Sunday, February 9, 2020 at 3:19:34 PM UTC, Claudia wrote:
>
> > marmarek:
> > This is a very bad idea to "fix" it. Those missing/changed CPUID bits 
> later on will cause issues.
> > And given most of the microcode updates recently are about speculative 
> execution, missing those
> > features will make the host vulnerable to those issues again. There are 
> multiple ways it can
> > manifest - from crashes when Xen uses (now not present) CPU feature, to 
> silent failures when Xen
> > tries to use some feature and assume it protects the system, while it 
> does not in practice.
> > 
> > For this particular case (microcode included in BIOS newer than in OS), 
> I see two options: make
> > BIOS (coreboot, right?) apply microcode update on resume too, or include 
> newer microcode in OS.
>
> I want to make one thing clear: I am **not** suggesting this check be 
> removed altogether. I am suggesting adding an **optional**, even 
> undocumented, override parameter which defaults to the **current behavior** 
> which is to panic. 
>
> I've found the patch to be quite stable so far. Unpatched is guaranteed to 
> cause a crash (xen
> panic) at resume; patched so far has not caused any noticeable stability 
> issues for the four of us
> using it, afaik. Just saying.
>
>
Has anyone tried utilizing the xen command line options to mask bits in the 
cpuid, in particular section 1.2.35 cpuid_mask_ecx)? 

The man page below says that "Settings applied here take effect globally, 
including for Xen and all guests." This *might* mean it is applied *before* 
the resume from sleep CPU bit checks (but I'm not promising anything, as I 
have not traced through the source). And also "*Warning: This option is not 
fully effective on Family 15h processors or later.*"

https://xenbits.xen.org/docs/4.13-testing/misc/xen-command-line.html

Excerpted:

```
1.2.34 cpuid_mask_cpu 

= fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b

Applicability: AMD

If none of the other *cpuid_mask_** options are given, Xen has a set of 
pre-configured masks to make the current processor appear to be 
family/revision specified.

See below for general information on masking.

*Warning: This option is not fully effective on Family 15h processors or 
later.*
1.2.35 cpuid_mask_ecx 1.2.36 cpuid_mask_edx 1.2.37 cpuid_mask_ext_ecx 1.2.38 
cpuid_mask_ext_edx 1.2.39 cpuid_mask_l7s0_eax 1.2.40 cpuid_mask_l7s0_ebx 
1.2.41 cpuid_mask_thermal_ecx 1.2.42 cpuid_mask_xsave_eax 

= 

Applicability: x86. Default: ~0 (all bits set)

The availability of these options are model specific. Some processors don't 
support any of them, and no processor supports all of them. Xen will ignore 
options on processors which are lacking support.

These options can be used to alter the features visible via the CPUID 
instruction. Settings applied here take effect globally, including for Xen 
and all guests.

Note: Since Xen 4.7, it is no longer necessary to mask a host to create 
migration safety in heterogeneous scenarios. All necessary CPUID settings 
should be provided in the VM configuration file. Furthermore, it is 
recommended not to use this option, as doing so causes an unnecessary 
reduction of features at Xen's disposal to manage guests.
```

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/808b8f43-2501-4419-a710-f9cd2bb65235%40googlegroups.com.

[qubes-users] lid close = system dead.

2020-02-09 Thread haaber 

Hi experience (as well) problems since that last dom0 update. Journalctl
mentions

dom0 systemd-sleep: suspending system ...
dom0 kernel: PM : suspend entry (deep)
-- reboot --

which suggests that lid-open does not awake the system. Did someone
already find a solution to that? It did work perfectly until last
dom0-update

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/22d38b64-ed70-4d75-09ca-695f64ba33ba%40web.de.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread Claudia 
February 9, 2020 9:52 AM, zachm1...@gmail.com wrote:

> On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote:
> 
>> On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek 
>> Marczykowski-Górecki wrote:
>>> If that's about something else, then fixing it would require finding
>>> what exactly is changing (and preferably also why). And only then find
>>> how to mitigate this issue. If specific flags would turn out to be not
>>> related to security features or otherwise having unwanted effects, then
>>> ignoring those changes would be an option. But ignoring _only those
>>> flags verified to be safe to ignore_, not all of them.
>> 
>> I hope it doesn't come to that but we'll see. I wouldn't really know what 
>> else to do besides
>> complain to Lenovo and hope they yell up at AMD to investigate. I assume 
>> it's something weird
>> between hardware manufacturers and AMD.
>> 
>>> - --
>>> 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/THMrX1ywFAl4/abcACgkQ24/THMrX
>>> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq
>>> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F
>>> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh
>>> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM
>>> 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz
>>> iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg==
>>> =h62J
>>> -END PGP SIGNATURE-
>> 
>> P.S. the bits do change for me as stated in the Xen log when I resume from a 
>> suspend. Here is what
>> mine says.
>> 
>> (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b)
> 

Thanks for sharing that. Just as I expected, bits 31 and 27, xor 0x8800. 
That makes three of us now.

I finally did some digging. I'm wondering if it has to do with the RDRAND issue 
which has been well known since at least May 7, 2019 to affect Fam15h. This 
stands to reason, as I immediately updated to the May 19 BIOS update when I 
bought this machine. awokd had suggested this update, specifically an AGESA 
update contained within, might have been the cause of an unrelated problem.

https://www.phoronix.com/scan.php?page=news_item=AMD-CPUs-RdRand-Suspend
https://linuxreviews.org/AMD_finally_submits_kernel_patch_for_broken_RDRAND_on_older_AMD_APUs
https://www.mail-archive.com/qubes-users@googlegroups.com/msg31568.html - User 
awokd's note about AGESA update
https://www.mail-archive.com/qubes-users@googlegroups.com/msg31689.html - User 
Qubes123's investigation into CPUID bits

>From linuxreviews.org:
"There have been reports of RDRAND issues after resuming from suspend on some 
AMD family 15h and family 16h systems. [...] RDRAND support is indicated by 
CPUID Fn0001_ECX[30]. This bit can be reset by clearing MSR C001_1004[62]. 
Any software that checks for RDRAND support using CPUID, including the kernel, 
will believe that RDRAND is not supported. "

According to the page below, RDRAND is bit 30 in ECX, not 31. And that still 
doesn't explain the 27th bit turning on after resume. 
27: OSXSAVE (turns ON)
30: RDRAND (unchanged)
31: Not used, always 0 (turns ON)

https://www.felixcloutier.com/x86/cpuid#fig-3-7

So it doesn't sound like the same problem at all, but all my search queries 
seem to lead back to the RDRAND issue. I'm hoping someone with more expertise 
in this area can make some better sense of 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86dfd10b83e568a734521dfd61f5af90%40disroot.org.

Re: [qubes-users] How to add swap space

2020-02-09 Thread 'awokd' via qubes-users 
billol...@gmail.com:
> 
> I need to add swap space to a VM, but it's not clear to me how to do it.  
> If this were "normal" linux, I'd just add a swap file, but I don't know if 
> I need can do that in dom0, and if that translates to available swap space 
> in my VMs.  The last time I played with memory things in dom0, I brought 
> the system down, so I'm a little hesitant to just go in and do it.
> 
> So... say I want to add a 50G swap file.  Can I just dd the space and make 
> the swap file like normal in dom0?  Do I have to create another real swap 
> partition?
> 
> Thanks!
> 
> billo
> 
https://github.com/Qubes-Community/Contents/blob/master/docs/misc/iaq.adoc#how-can-i-provision-a-vm-with-a-largernon-standard-swap-and-tmp

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5d737938-11b5-f1ab-f73c-33777b0bd62f%40danwin1210.me.

Re: [qubes-users] Tips for configuring Qubes firewall?

2020-02-09 Thread fiftyfourthparallel 
Thanks for taking the time to reply!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/94db01dd-8170-4c22-b1c1-7682ad94a8cc%40googlegroups.com.

Re: [qubes-users] create custom image result in problems with python-blivet sources

2020-02-09 Thread user74293 
Hello.

thanks for your hints, but i need a little more help.
The actual versions in fc31 are:
- python3-blivet-3.1.5-2.fc31.noarch.rpm
- python3-blivet-3.1.7-1.fc31.noarch.rpm

If i look for a matching storaged-project/blivet version then i don't find the 
file blivet-xxx-tests.tar.gz.
The only version with the test-archive is 3.2.0. This version would be 
available in fc rawhide.
And do i need the existing patches or some others?

I'm now not sure how i can solve this situation. 
This is the first time for me to use the qubes-builder, can someone help me?

Thanks


> Hello,
> Do a 'make get-sources' in blivet repo. The pull of sources is done once 
> during the global get sources. Here the problem is that we use SRPM from 
> fedora repositories but they are not keeping all the versions. In 
> consequence, we currently need to sync with Fedora update.
>
> Best,
> Frédéric
>
> Le 8 février 2020 14:35:10 GMT+01:00, user74...@disroot.org a écrit :
>> Hello,
>> i'm trying to create a custom qubes image to install a fedora 31 dom0
>> using https://www.qubes-os.org/doc/qubes-builder/ 
>> (mailto:qubes-users+nore...@googlegroups.com)to see how it will run on
>> my hardware.
>> Already the step 'make get-sources' show the following problem up:
>> --> Downloading additional sources for blivet...
>> Cannot find source RPM: python-blivet-3.1.6-1.fc31.src.rpm
>> make[1]: *** [Makefile:21: blivet-3.1.6.tar.gz.UNTRUSTED] Error 1
>> make: *** [Makefile:205: blivet.get-sources-extra] Error 2
>>
>> I've tried to solve this with a newer version 3.1.7, but then there are
>> the test-src's... missing while building.
>> Please give me some hints to solve my problem .
>> Thanks
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "qubes-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to qubes-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/qubes-users/649a6a486daecf809d99c69427baeff5%40disroot.org.
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
> brièveté.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7aa490025ae98df3453c2444ee5fa629%40disroot.org.

Antw: [EXT] Re: [qubes-users] Q: is Qubes OS a "portable" installation?

2020-02-09 Thread Ulrich Windl 
>>> unman  schrieb am 08.02.2020 um 02:10 in 
>>> Nachricht
<21911_1581124220_5e3e0a7c_21911_3958_1_20200208011020.ga...@thirdeyesecurity.or
 
>:
> On Fri, Feb 07, 2020 at 11:06:40PM +0100, Ulrich Windl wrote:
>> Hi!
>> 
>> Being new to Qubes OS on an USB stick, I wonder whether the installation is 
> "portable", meaning whether I can put the stick into different computers. Or 
> is specific hardware-configuration saved during installation (like passing 
> the NIC to the network VM) or at first boot?
>> 
>> Of course I'd like it to be portable ;-)
>> 
>> Regards,
>> Ulrich
>> 
> 
> Hi Ulrich.
> It's portable indeed, provided you can boot from USB (precludes recent
> Dell ), and system has VT-d etc enabled, and system supports whatever of
> UEFI/Legacy you chose at install. 

Thanks,

great to know. If it's not in the docs, it should be added IMHO.

Ulrich


> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/20200208011020.GA631%40thirdeye 
> security.org.




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5E41059D02A100036F74%40gwsmtp.uni-regensburg.de.

[qubes-users] VLC gets black when maximized

2020-02-09 Thread Guerlan 
My VLC gets all black when maximized and the video wont start playing 
again, I have to close it. I'm trying on debian9. Did someone have this 
problem?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5b68ea3c-4e6d-4c76-89a4-757fb941d900%40googlegroups.com.

Re: [qubes-users] sys-firewall based on debian-10-minimal not recognized

2020-02-09 Thread Sven Semmler 
On Sun, Feb 09, 2020 at 01:46:12PM +, 'awokd' via qubes-users wrote:
> Maybe it doesn't like the "disposable" part? Try it with a regular AppVM
> based on that same minimal template.

I did: makes no difference. Also I've been running debian-based and
fedora-based disposable sys-firewall for years. It has most likely to do
with the -minimal template and me being oblivious to what the Qubes
Manger looks for. 

After verifying that the firewall does indeed work and does what it's
supposed to do I see this as a minor annoyance. I saw some discussion on
github about how the Qubes Manager recognizes firewall functionality but
all those things I already checked - I think (see previous postings).

Could you point out to me please how I would verify that the qubes-firewall 
service is up and running?

/Sven

-- 
 public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200210064307.GA1559%40app-email-private.


signature.asc
Description: PGP signature

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread Claudia 
February 9, 2020 8:52 PM, "Marek Marczykowski-Górecki" 
 wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote:
>> On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote:
>>> 
>>> 
>>> Has anyone tried utilizing the xen command line options to mask bits in 
>>> the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? 
>>> 
>>> The man page below says that "Settings applied here take effect globally, 
>>> including for Xen and all guests." This *might* mean it is applied *before* 
>>> the resume from sleep CPU bit checks (but I'm not promising anything, as I 
>>> have not traced through the source). And also "*Warning: This option is 
>>> not fully effective on Family 15h processors or later.*"
>>> 
>> 
>> Just noticed that the warning applies only to 1.2.34, which is AMD-only, 
>> apparently. Unclear to me if the other items 1.2.35 and higher, which is 
>> for "x86" apply only to intel or to all x86 architecture.
> 
> I may be missing it in this thread, but have anybody tried Qubes 4.1
> builds (with Xen 4.13) on such system? Does it have the same issue?

I also had the same problem with unpatched Xen 4.13, it was on the fc31-based 
R4.1 build right before christmas. The check was introduced in 4.8.3.3 and 
probably hasn't changed. For what it's worth, R4.1 and R4.0 both resume fine 
when booted without Xen. See 
https://www.mail-archive.com/qubes-users@googlegroups.com/msg31518.html

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/874173b083a3c9426f120f68814a9bf7%40disroot.org.

[qubes-users] Confidential email from orpheu

2020-02-09 Thread orpheu via qubes-users 
Hello,You have just received a confidential email via Tutanota (https://tutanota.com). Tutanota encrypts emails automatically end-to-end, including all attachments. You can reach your encrypted mailbox and also reply with an encrypted email with the following link:Show encrypted emailOr paste this link into your browser:https://mail.tutanota.com/#mail/M-ftvrh2eXP6sGVrwtFXu6miMiszmQThis email was automatically generated for sending the link. The link stays valid until you receive a new confidential email from me.Kind regards,orpheu



-- 
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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/M-ftvuq2%40tuta.io.

Re: [qubes-users] Re: Upgrade to 16 GB RAM for an X230

2020-02-09 Thread tetrahedra via qubes-users 

On Sun, Feb 09, 2020 at 03:37:45PM +, unman wrote:

Any other suggestions of fixes, upgrades, or tests to make?


Replace Intel wifi with Atheros.


What's the benefit of the Atheros chip over Intel?

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200210031057.GA1045%40danwin1210.me.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread zachm1996 
On Sunday, February 9, 2020 at 2:52:57 PM UTC-6, Marek Marczykowski-Górecki 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Sun, Feb 09, 2020 at 09:28:13AM -0800, brend...@gmail.com  
> wrote: 
> > On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com 
> wrote: 
> > > 
> > > 
> > > Has anyone tried utilizing the xen command line options to mask bits 
> in 
> > > the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? 
> > > 
> > > The man page below says that "Settings applied here take effect 
> globally, 
> > > including for Xen and all guests." This *might* mean it is applied 
> *before* 
> > > the resume from sleep CPU bit checks (but I'm not promising anything, 
> as I 
> > > have not traced through the source). And also "*Warning: This option 
> is 
> > > not fully effective on Family 15h processors or later.*" 
> > > 
> > 
> > Just noticed that the warning applies only to 1.2.34, which is AMD-only, 
> > apparently. Unclear to me if the other items 1.2.35 and higher, which is 
> > for "x86" apply only to intel or to all x86 architecture. 
>
> I may be missing it in this thread, but have anybody tried Qubes 4.1 
> builds (with Xen 4.13) on such system? Does it have the same issue? 
>
>
I have, yes. A few days ago I built an ISO using R4.1 and tested it. The 
same issue happens with a fresh R4.1 install and Xen 4.13 + 5.4 kernel.
 

> - -- 
> 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/THMrX1ywFAl5AcSAACgkQ24/THMrX 
> 1yzQ/ggAmQOFWyP0GNVs5dMuSzKx6mo7myoJ0tlJaKdpNPKZZnYjaLAqhUPig5YG 
> rd5iv26TjVq/bl8uiRE0/qwV0/sjqgmLTqPIQanzxsB5Cnok3OZyswghGJY/UY8Y 
> j5ADzpzRtCC7WhQkvhtPSwcC3c72rgmjfQg2IjKfYU6qyv+0aJ2HuJQj/kA49cG6 
> kzwGRIJJlxVfCsnlXSwmHa17PyiolvYqpQFhCN8EIM3KYFcjrBK+kP7nqdNXuQ8R 
> atZqH66h8wxp/BvGO9xGZPmWV6uhrC+JIKfdlaspKO4fWFxXuBwxGgS+favkn5wT 
> vBJcU6wxj2Qwk6MvJV17BMV1dwqntg== 
> =HtGL 
> -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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cd0084c5-b049-4357-8b8c-06f9cec3eb18%40googlegroups.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread 'awokd' via qubes-users 
Claudia:
>> marmarek:

>> For this particular case (microcode included in BIOS newer than in OS), I 
>> see two options: make
>> BIOS (coreboot, right?) apply microcode update on resume too, or include 
>> newer microcode in OS.
> 
> I want to make one thing clear: I am **not** suggesting this check be removed 
> altogether. I am suggesting adding an **optional**, even undocumented, 
> override parameter which defaults to the **current behavior** which is to 
> panic. 
> 
> I've found the patch to be quite stable so far. Unpatched is guaranteed to 
> cause a crash (xen
> panic) at resume; patched so far has not caused any noticeable stability 
> issues for the four of us
> using it, afaik. Just saying.
> 
> Also, not everyone has the option of coreboot. And we're not even completely 
> certain this a
> post-resume microcode update issue, either.

FWIW, my corebooted AMD has the same issue and resolution. Of course,
much of the source code came from AMD so it could be something common to
most/all. I wonder if there's a fix that could be made at that level.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a4dc0396-7404-821e-529f-f63110c0e560%40danwin1210.me.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

2020-02-09 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote:
> On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote:
> >
> >
> > Has anyone tried utilizing the xen command line options to mask bits in 
> > the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? 
> >
> > The man page below says that "Settings applied here take effect globally, 
> > including for Xen and all guests." This *might* mean it is applied *before* 
> > the resume from sleep CPU bit checks (but I'm not promising anything, as I 
> > have not traced through the source). And also "*Warning: This option is 
> > not fully effective on Family 15h processors or later.*"
> >
> 
> Just noticed that the warning applies only to 1.2.34, which is AMD-only, 
> apparently. Unclear to me if the other items 1.2.35 and higher, which is 
> for "x86" apply only to intel or to all x86 architecture.

I may be missing it in this thread, but have anybody tried Qubes 4.1
builds (with Xen 4.13) on such system? Does it have the same issue?

- -- 
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/THMrX1ywFAl5AcSAACgkQ24/THMrX
1yzQ/ggAmQOFWyP0GNVs5dMuSzKx6mo7myoJ0tlJaKdpNPKZZnYjaLAqhUPig5YG
rd5iv26TjVq/bl8uiRE0/qwV0/sjqgmLTqPIQanzxsB5Cnok3OZyswghGJY/UY8Y
j5ADzpzRtCC7WhQkvhtPSwcC3c72rgmjfQg2IjKfYU6qyv+0aJ2HuJQj/kA49cG6
kzwGRIJJlxVfCsnlXSwmHa17PyiolvYqpQFhCN8EIM3KYFcjrBK+kP7nqdNXuQ8R
atZqH66h8wxp/BvGO9xGZPmWV6uhrC+JIKfdlaspKO4fWFxXuBwxGgS+favkn5wT
vBJcU6wxj2Qwk6MvJV17BMV1dwqntg==
=HtGL
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200209205248.GD29736%40mail-itl.