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

[Reg Tiangha]

On 01/24/2018 07:51 AM, Ed wrote:
> On 01/24/2018 04:29 AM, Andrew David Wong wrote:
> 
>> ## Qubes 3.2
>>
>> Previously, we had planned to release an update for Qubes 3.2 that would
>> have made almost all VMs run in PVH mode by backporting support for this
>> mode from Qubes 4.0. 
> 
> Out of curiosity, is this still going to happen?  I would love to see
> this if possible, not only helping mitigate Meltdown without the
> performance penalty (I believe), but also would give a nice general
> security boost to 3.2
> 
> Thanks,
> Ed
> 

The thing is, if Qubes intends on sticking with Xen 4.6 on Qubes R3.2,
then the promise of 1 year extended support after R4.0 is officially
released may be hard to meet since Xen will discontinue security support
 in Oct 2018 (Source:
https://wiki.xenproject.org/wiki/Xen_Project_Release_Features ). That
means there could be a 3-4+ month period where the Qubes devs would need
to manually backport from newer versions of Xen any security fixes found
in Xen during that time frame (in essence, the Qubes project would need
to take over maintenance of the Xen 4.6 branch for that time period).
That could increase the support/maintenance burden for the Qubes devs by
a lot, depending on how complex the security issues are (worse case
would be another thing like Meltdown/Spectre happening again during that
time frame after official Xen support ends).

Xen 4.8 will be supported with security fixes by Xen until Dec 2019, so
assuming that Qubes R4.0 comes out this calendar year, then there'd
still be time left over to honor that 1 year extended support promise,
at least when it comes to any Xen fixes. So backporting Xen 4.8 to Qubes
R3.2 might actually be the better move in the long term, if the devs
really intend to honor that 1 year extended support promise. But that's
just my opinion.

-- 
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/p4alsi%245q0%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes4.0 rc3 install error

[Reg Tiangha]

On 12/04/2017 02:39 PM, Shashank wrote:
> Thank you very much for the wonderful explanation of how it works. Would all 
> the files in /boot be deleted Incase I did a factory install on my machine? 
> i,e go back to factory settings. Or would I have to do the way you mentioned, 
> by mounting /boot somehow, which I am a bit skeptical about how to do it. 
> 
> Thanks 
> 

If by "factory install" you mean reinstalling Windows, then maybe? I'm
not sure.

As for mounting /boot externally, you can do it with any Linux Live CD
(ex. Ubuntu). In fact, if you're lucky, some of the more modern ones
might even populate the file explorer with the various partitions on
your hard drive and you can use that instead to point and mount the
/boot partition.

Otherwise, you'll need to do it through the command line. There's lots
of examples on Google and YouTube; here's one using CentOS 6:

http://docs.intuitivetechnology.com/article/92-how-to-mount-linux-filesystem-from-a-live-cd-and-copy-a-backup

But it's essentially the same procedure no matter what distro's LiveCD
you use.

Good luck!

-- 
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/p04gbh%248rl%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes4.0 rc3 install error

[Reg Tiangha]

On 12/04/2017 02:16 PM, Reg Tiangha wrote:
> On 12/04/2017 01:48 PM, Shashank wrote:
>> Oh no probably i didn’t mention it in my initial post, sorry about that. I 
>> am actually dual booting on my system and set a partition of 80 gb on my 
>> hard drive. 
>>
>> And I am getting the error that 
>>
>> At least 3 mb disk space required on /boot/efi
>>
>> Thank you very much. 
>>
> 
> You said that you were previously running R3.2 on this machine, correct?
> 
> The problem is that whenever you upgrade or remove a Qubes kernel, the
> uninstallation script does *not* remove the corresponding initramfs.img
> file from /boot/efi/EFI/qubes/ so if you install and remove a bunch of
> kernels, then over time, that directory gets cluttered up with old files
> and thus you eventually run out of space on /boot.
> 
> The answer would be to somehow mount /boot (probably using another OS)
> and delete all the initramfs.img files in the /boot/efi/EFI/qubes/ that
> no longer apply (which might be all of them or everything in that
> directory, if you're attempting a clean install) and then retry the R4
> installation again.
> 
> In fact, all Qubes users who upgrade kernels will get bitten by this
> eventually (if they haven't already). If you've ever ran df -h in dom0
> and wondered why /boot seemed to be slowly filling up over time, this is
> why. Not sure if it's a flaw in the qubes-kernel uninstallation script
> or something else. I've just gotten into the habit of manually deleting
> old img files in that directory whenever the system uninstalls a kernel.
> 


Edit:  Sorry, I meant vmlinuz files, not initramfs img files. Then
again, my systems use Legacy Boot rather than EFI; I'm not sure if they
get properly deleted automatically on a proper EFI system.

-- 
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/p04e9m%24t0d%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 11/25/2017 05:51 AM, Foppe de Haan wrote:
> On Friday, November 24, 2017 at 6:00:37 PM UTC+1, Foppe de Haan wrote:
>> On Friday, November 24, 2017 at 3:25:40 PM UTC+1, Frédéric Pierret (fepitre) 
>> wrote:
>>> Le vendredi 24 novembre 2017 15:22:20 UTC+1, Foppe de Haan a écrit :
 On Thursday, November 23, 2017 at 9:30:30 PM UTC+1, Frédéric Pierret 
 (fepitre) wrote:
> Le mercredi 22 novembre 2017 18:31:29 UTC+1, Foppe de Haan a écrit :
>> Now that 4.14's reached stable, does anyone plan to test it soon (or 
>> have an idea when they'll have time to do so)? Since 4.13 wasn't stable 
>> 'by default' in qubes, I would assume 4.14 won't be either, but although 
>> I'll certainly give it a go, I'm fairly sure I am not the best person to 
>> try to figure out what's wrong when I run into trouble. :)
>
> Ok so I'm trying kernel-4.14.1 since this morning and it seems to be more 
> stable than 4.13. I have not experienced any random crash which normally 
> would have occurred at least once in a day with kernel-4.13. You can try 
> it if you want: 
> https://github.com/fepitre/qubes-linux-kernel/tree/devel-4.14

 Great. :) Which fedora version did you use to build it, though? When I try 
 using 25 or 26, it errors while whining about u2mfn. I've checked the 
 thread in the bug tracker, but it doesn't really
>>>
>>> I'm using a Fedora 26 (on a Debian server with Xen, not Qubes) with a 
>>> DIST_DOM0 as Fedora 23. If you want, I can upload the kernel files on 
>>> sourceforge.
>>
>> it may have something to do with the fact that 'dkms status u2mfn' doesn't 
>> return anything, as that results in 'cp -r /usr/src/u2mfn-$u2mfn_ver 
>> /home/user/qubes-linux-kernel/u2mfn' erroring out.
> 
> So when it tries to run this script prior to building the kernel: 
> https://github.com/QubesOS/qubes-linux-utils/blob/master/kernel-modules/qubes-prepare-vm-kernel
>  , it fails, because 'dkms status u2mfn' yields an empty string when run in a 
> (fc26) VM.
> 

I finally had time to play around with this and I hit the same issue in
my FC 26 build template (dkms status u2mfn yields an empty string). I
don't know how my machine got into this state in the first place (I
suspect it was an issue upgrading from FC25 to FC26), but it's easily
fixable.

Two things to do:

First, verify the version of u2mfn in /usr/src of your build template by
running:

ls /usr/src

There *should* be only one version, but in my case I had two (if anyone
else out there is in the same boat, read on).

Second, we need to tell dkms of u2mfn's existence. 3.2.5 is the latest
version of u2mfn, so I'm going to assume this is the one we're going to
be working with. To fix the empty string issue, simply re-register the
module with dkms by running:

sudo dkms add -m u2mfn -v 3.2.5

And that should fix it. You can verify it by running:

dkms status u2mfn

and it should no longer return an empty string.

Now, if you have an older version of u2mfn in there (in my case, it was
3.2.4 which was the FC25 version), you'll need to remove it.

Run:

sudo rpm -e qubes-kernel-vm-support

and it'll spit out the full package names of the two versions of the
package on your system.

To remove the older one (I'll assume it's 3.2.4), you would run rpm -e
with the full package name (ex. sudo rpm -e
qubes-kernel-vm-support-3.2.4-1.fc25 or something like that).

BUT it will probably not work because that version of the module isn't
registered with dkms either. So you'll need to do the same thing as with
3.2.5 above:

sudo dkms add -m u2mfn -v 3.2.4

And then you can re-run the rpm -e command again and this time, it
should work and your system should be back to its expected state.

Note that for anyone on R3.2, you *won't* be able to compile kernel 4.14
on an FC26 template because it will link to FC26's openssl-1.1.0 and
FC23 only has openssl-1.0.2 and thus it won't install in dom0. You'll
either need to compile that kernel on an FC25 template or older (which
sucks, since FC25 is EOL on Dec. 12), *or* figure out how to upgrade
openssl in R3.2 dom0 to version 1.1.0 (possible, but not trivial).

-- 
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/p04aq7%24ck%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Turn off quiet boot?

[Reg Tiangha]

On 2017-10-11 5:42 PM, Ron Hunter-Duvar wrote:
> Does anyone know how to turn off QubesOs' quiet boot (splash screen
> instead of kernel messages)?
> 
> I like to see the messages during boot (and shutdown). More than once
> I've caught a lurking problem (although it scrolls by fast, those red "[
> FAILED ]" messages really stand out).
> 
> I've removed the "quiet" keyword from the "kernel=" lines in
> /boot/efi/EFI/qubes/xen.cfg, but that only gives me the first page or
> so, and still brings up the splash screen. Pressing Esc gets me back to
> the messages, but I'd like to have it stay there.
> 
> This is with EFI booting. No grub (don't even have a grub.cfg file in
> /boot).
> 
> Thanks,
> 
> Ron
> 

I'm not sure how to turn it off, but you can toggle it on demand by
pressing F2.

-- 
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/ormn8r%2455k%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 dnsmasq update?

[Reg Tiangha]

On 2017-10-07 1:19 PM, Ron Hunter-Duvar wrote:

> Well, I did all this, and confirmed that the sys-* servicevms are all
> using Fedora 25, but it still has dnsmasq version 2.76. According to
> US-CERT, 2.78 is needed to get the vulnerability fixes. Which concerns
> me, given the length of time that the exploit code has been public.
> Surprises me too, since Debian had it out in a matter of hours.
> 
> However, it's not running in any of these, nor in dom0. Should I just
> uninstall it?
> 
> Thanks,
> Ron
> 

It's weird, but it seems like every distro *but* Fedora has released an
updated version or version with a backported fix. Even Red Hat
Enterprise has done it. I don't know what the hold up is, but it'll be a
package with a backported fix and currently it's set to be 2.76.4 (or
greater if more bugs are found).

https://bodhi.fedoraproject.org/updates/FEDORA-2017-515264ae24

-- 
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/orcae3%24jon%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 2017-10-01 10:21 AM, Frédéric Pierret (fepitre) wrote:

> 
> Hi, just a small update of current kernel branches status:
> 
> From our last commits with Reg, the last version of kernel 4.12.14 is 
> available and also I created the branch for devel-4.13 (currently version 
> 4.13.4).
> 
> From my side, I had kernel panic in VM with latest version 4.12.14 when 
> merging all the options in CONFIG file from stable-4.9 due to 
> vlv2_plat_configure_clock related to CONFIG_INTEL_ATOMISP (see 
> https://github.com/fepitre/qubes-linux-kernel/commit/3edc1d714539aba669c6c710a09b8022ff8fcaa2).
>  This problem was known for several distros with Xen PV DomU (e.g. 
> https://bugs.archlinux.org/task/55447 and 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711298). So not setting 
> this driver solved my problem (even for kernel-4.13+).
> 
> Best,
> 

Perfect! I was trying to figure out why 4.13.4 was panicking when used
in a VM too (dom0 seemed to work fine) but didn't have enough time to
really dig deep into the kernel options and didn't actually try to boot
4.12.14 either; I just assumed it worked (the last one I tried was
4.12.13). I'm glad you figured it out! Hopefully, there won't be anymore
weirdness when 4.14 (the next LTS kernel) comes out.

-- 
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/oqs1ma%24ppv%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Hardened VM templates in Qubes

[Reg Tiangha]

On 2017-09-25 6:42 AM,
dhfgebenskzkwkwnd...@gmail.com wrote:
> Hello, please tell me if there are guides to hardening VM templates? 
> Coldhak.ca is dead, is there anything else or use KSPP manually?
> 
> Thanks.
> 

Most of the KSPP options have been enabled in the most recent versions
of the 4.9 kernel in the Qubes repository, at least for the ones that
exist in that branch of the kernel. Obviously, more options have been
introduced in newer branches so you'd have to compile those kernel
versions on your own if you wanted them.

-- 
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/oqdn27%24v2l%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: New potential way of disabling ME

[Reg Tiangha]

On 2017-08-28 11:36 PM, loke...@gmail.com
wrote:
> Apparently ME has a HAP mode that can be enabled, which disables most of the 
> ME functionality.
> 
> http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
> 

Yep. They're already looking into incorporating it into me_cleaner too.

https://github.com/corna/me_cleaner/issues/53


-- 
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/oo3crf%24945%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qubes-devel Google Group Web Interface: Banned Content Warning

[Reg Tiangha]

FYI, trying to view the qubes-devel Google Group on a web browser
currently displays this message:

Banned Content Warning
The group that you are attempting to view (qubes-devel) has been
identified as containing spam, malware or other malicious content.
Content in this group is now limited to view-only mode for those with
access.
Group owners can request an appeal after they have taken steps to clean
up potentially offensive content in the forum. For more information
about content policies on Google Groups, please see our Help Centre
article on abuse and our Terms of Service.

If you click on "Continue to the group," it shows no messages.

-- 
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/oo2u05%24khl%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 Building an up to date dom0 3.18 Kernel

[Reg Tiangha]

On 2017-08-27 9:10 AM, 'Vincent Adultman' via qubes-users wrote:
> 
> Thanks for your time in replying Reg, something that interests me is the
> necessity of building in a FC23 VM. Would you agree there's a
> possibility of security issues whilst building as FC23 is EOL? (when
> fetching or verifying), not sure how Qubes builder gets around this,
> having tried in an up to date FC25 VM, it fails building the rpms
> despite dracut being up to date
> 
> -- 

I'm not sure. Potentially if a security flaw has been found in glibc
that wasn't fixed, then maybe it would have an effect, but I don't know.
Fetching and verifying should be fine, unless there've been flaws found
in gpg that haven't been fixed either (which I don't think there have
been recently).

About the dracut thing, some people have said that they had to
explicitly enable the fedora-updates repository in the FC25 VM. I
haven't checked myself since I primarily run Debian VMs, but it might be
worthwhile double-checking to see if that repository is actually enabled
in the VM, and if not, to enable it and see if there's a newer version
of dracut available.

You could also try copying over the various .spec files (and maybe
Makefiles as a last resort if that still doesn't work) from the
stable-4.9 branch as those were updated with fixes for compile issues in
later Fedoras that may not have made it back to the stable-3.18 branch.

-- 
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/onur8f%24pns%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch

[Reg Tiangha]

On 2017-08-25 8:35 AM, nicholas roveda wrote:
> Thanks for all the details.
> 
> I've tested on the R4.0 rc1, so fc25, I'll try it soon on the R3.2 (fc23 and 
> fc24), so we can crosscheck the script.
> 
> I saw both dom0 and vm rpms are generated, but is it better to generate 
> different rpms for them with config-host and config-vm?
> 

Having the build script spit out separate rpms (or ideally, use
config-host for the kernel.rpm and config-guest for the
kernel-qubes-vm.rpm) would be ideal (but then figuring out how to handle
kernel-devel.rpms for both might be a challenge), but I really just
intended for that grsec branch to be a proof-of-concept using existing
Qubes build infrastructure. I wasn't intending on extending things (and
to be honest, I don't have the time), but if someone else wanted to take
it on, they're certainly welcome to!

-- 
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/onpd6u%2425a%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch

[Reg Tiangha]

On 2017-08-24 9:23 AM, Sandy Harris wrote:
> At some point, these patches may become unnecessary & perhaps some of
> them already are. There is ongoing work aimed at getting related
> patches into the mainline Linux kernel.
> 
> Wiki: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
> Mailing list: http://www.openwall.com/lists/kernel-hardening/
> 
> It is possible that in the long term helping with that work would be a
> better use of time than the porting effort. On the other hand it seems
> likely that the port is a good idea for now.
> 

Just an FYI, but most of the KSPP recommended kernel options that aren't
enabled by default (that exist in the 4.9 branch; not all of them do
since others debut in 4.10+) are enabled in the 4.9 Qubes kernel that's
already been pushed out. It isn't much, but it's better than nothing and
if it's already included in there for free, then why not use it?

Also, later kernel versions (4.11+) have already included some of the
work from the Linux Hardened project, and if people are compiling newer
kernels, people can include the patches that haven't yet made it into
upstream from here in their own builds if they like:

https://github.com/copperhead/linux-hardened/releases

I used to keep track of that in my devel-4.11-hard branch, but when
newer kernel versions are released, the Linux Hardened project abandons
the old branch in favor of the newer branch and stops releasing patches
for it, even though the older version will be supported for another two
releases. So I just stopped doing it since the last 4.11 version doesn't
work with the last 4.11 hardened patch set, nor the first 4.12 patch
set, and it isn't worth it to migrate the new stuff since 4.11 is EOL
anyway, which is why my branch of that isn't as up-to-date as it could
or should be.

Instead, people can decide for themselves if they want to include them
in their kernel builds or not; it's easy to add your own patches with
the Qubes kernel build system (just add the path to the patch to the
series.conf file).

-- 
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/ono3s0%249hk%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch

[Reg Tiangha]

On 2017-08-24 4:27 PM, nicholas roveda wrote:
> I think Reg has done a great job and the porting its a must go path to force 
> the developers to throw away all the differences that slow down or prevent 
> the develop of a secure system.
> 

To be fair, I don't forward port anything; it's @minipli on GitHub
(https://github.com/minipli/linux-unofficial_grsec/releases) that does
the hard work. All I do is make it easy to use the existing Qubes kernel
build scripts to include and package it, which was the original intent
once the old coldkernel project became more mature, but unfortunately
ended when the grsec project stopped releasing patches to the public
with 4.9.24 (I do make one change to minipli's patches though, and
that's to remove his custom uname patch because a) something like
4.9.45.unofficial-grsec.qubes.pvops is ridiculously long and b) it
actually breaks the Qubes build scripts because it results in a version
mismatch and thus halts the compile).

But really, that branch is just a proof-of-concept; it really does
require the user to customize the kernel config and/or user space to
work properly, although it should work for the most part out-of-the-box.
I'm not sure yet if it can be completely trusted so I don't actually
recommend that people use it per se; for example, the grsec guy included
a binary firmware blob in the original grsec patches that was only
recently discovered. @minipli has taken it out of future patches, but
since the original patch set was never audited, who knows what else
might be in there? But for the people who've heavily invested in the old
coldkernel or in PAX in their VMs, at least this is a way they can
continue using it while still having a somewhat up-to-date kernel.

I'll double check that build script soon; it works on my machine, but
maybe what I have in my build VM isn't sync'ed with what I have on my
public account for the grsec branch. But I also only build on an FC23
VM; are people using something different (like FC24 or 25) to build on?
Because that might be it too.

-- 
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/ono35q%2459o%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Network Manager: 'Device not ready' after suspend.

[Reg Tiangha]

On 2017-08-23 3:08 PM, Andrew Morgan wrote:
> I tried that kernel on sys-net with no change yes, but dom0's kernel has
> not changed.
> 
> Would it perhaps be an issue with xen's PCI passthrough functionality?
> Could it be left in a broken state after a suspend and thus sys-net is
> not able to have proper access to the network device?
> 
> Thanks for helping with testing and debugging.
> 
> Andrew Morgan
> 


Have you guys tried blacklisting your wireless driver modules as per
these instructions here:

https://www.qubes-os.org/doc/wireless-troubleshooting/#automatically-reloading-drivers-on-suspendresume

The people who have been experiencing the same issues say that this
workaround works.

-- 
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/onlfpa%24jsj%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unofficial forward-ported grsec 4.9 Qubes kernel branch

[Reg Tiangha]

On 2017-08-23 9:01 AM, nicholas roveda wrote:
> I'm trying to build your port, but I,ve actually had to to some changes to 
> `kernel.spec` because the script exits with an error at line 136: 
> `%_sourcedir/check-for-config-changes .config.orig .config`.
> 

Actually, if you mean that 'make rpms' fails by default, that's
intentional. It's because there isn't a 'config' file in the main repo
directory like there is in the other kernel branches.

The grsecurity kernel options include separate settings for 'host' and
'guest' depending on where the kernel is to be used. So for dom0, you
would configure a 'host' grsec kernel, and for a vm you'd configure a
'guest' grsec kernel.

With that in mind, there are two config files in the repo, config-guest
and config-host, with the only difference between the two is that single
option for host vs guest. It's not intuitive, but what you need to do is
copy one of those to be the main 'config' file for the repo before
running 'make rpms'

That said, I can't exactly tell *what* effect using one or the other has
on the kernel. No other kernel options change, so I don't know what it
does behind the scenes. Furthermore, running either kernel the other way
(ex. using a kernel configured to be a host kernel as a vm kernel
instead) seems to work fine. So at the end of the day, I suppose it
doesn't matter what configuration you use...?

The way I do it for my machine is I compile two kernels, using the
config-host file for my dom0 kernel, and the config-guest file for my
VMs. You can do this by installing the kernel rpm with the host
configuration, and the kernel-qubes-vm rpm with the guest configuration.
Or you can also change the rel number on the second compile to something
different and you can install both sets of packages at the same time
(although you may need to run rpm -ivh --force). "Many paths up a mountain."

So try reverting the check-for-config-changes script back to the way it
was and copying one of the kernel config files already included in the
repo to be the main 'config' file and run 'make rpms' and it should work
fine.

If you want to customize the config file, delete the 'config' file, run
'make rpms' and wait for the patching to complete (the process will also
stop when it can't find a 'config' file). Then copy the config file you
want to customize to the kernel-4.9.XX/linux-4.9.XX directory and name
it .config and then run 'make menuconfig' to go through the interface.
When done, copy back the new .config file to the root directory,
renaming it back to 'config' and then run 'make rpms'

Hope that helps!

-- 
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/onlceu%24cdv%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 3.2 Building an up to date dom0 3.18 Kernel

[Reg Tiangha]

On 2017-08-21 4:59 AM, 'Vincent Adultman' via qubes-users wrote:
> As previously detailed ad nauseum, none of the Qubes dom0 4.4 or 4.9
> version Kernels will boot on my laptop (HP Elitebook 2540p). This means
> I'm stuck on the ancient 3.18.17-8.
> 
> I'm comfortable(ish - have built a Xenial template) using Qubes builder
> and I notice Reg Tiangha has a repo with updated 3.18 kernel at
> https://github.com/rtiangha/qubes-linux-kernel/ I notice Reg also
> submits patches which are merged into the official qubes-linux-kernel
> repo after review by Marek.
> 
> 1. Is there any chance of getting the updated 3.18 kernel merged into
> the official repos so anyone (read me) with truculent hardware can
> remain on this, even if it means building the package ourselves? (this
> is actually what I was envisaging maybe happening when previously
> inquiring whether it was possible to buy a support case from ITL)
> 
> 2. If not (not worth the effort of Marek to review?) given the existence
> of https://github.com/rtiangha/qubes-linux-kernel
> <https://github.com/rtiangha/qubes-linux-kernel/> what are the
> suggestions to an 'ordinary' end user who wants to build a 3.18 kernel
> from there? Specifically, I'd be extending my trust from the Qubes
> developers to Reg, who apart from clearly being active in the Qubes
> community, I know nothing about. Are there sensible actions that can /
> should be taken with git to verify the kernel code? No insult to Reg
> here intended whatsoever :)
> 

If you don't trust me, you can easily do it yourself. Just clone the
master qubes-linux-kernel repo from the QubesOS account, change the
number in the 'version' file to the latest number (as of now, it's
3.18.66 but you can verify that at kernel.org) and that'll update what's
already there.

But some Xen security patches released since the last 3.18 version will
be missing and you'll probably want to add those. Easiest way to do that
is to go here:

https://xenbits.xen.org/xsa/

and grab any patches from there that have to do with the Kernel since
the last time a 3.18 release was pushed out and add them to your tree
(you can look at how Marek has applied them in the 4.9 branch; basically
you add the path to the patch into the series.conf file). Hint: It's XSA
157 (though not all five of them) and XSA 216.

Finally, for bonus points, if you want a slightly harder kernel, you can
implement some of the KSPP recommended settings listed here (but not all
of them exist in 3.18 so you'll need to search first):

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

and the Linux Hardened project here:

https://github.com/copperhead/linux-hardened/wiki/Upstream-progress-tracking

Those are basically the only changes I've made; in the 4.9+ kernel
configs, other changes have been for newer driver support that didn't
exist in older versions. Good luck!

-- 
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/onenp1%24gpi%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] Re: Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 06/29/2017 04:59 AM,
0spinbo...@gmail.com wrote:
> fyi: this kernel built as-is will cause kernel panics on (some, common) Ryzen 
> motherboards. Issue is described here among other places: 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1671360
> This happens as soon as config_pinctrl_amd is set to 'm' in the build config. 
> Un-setting it should evade the issue (as I've not yet seen a proper fix for 
> it).
>

I've now disabled it in my branch. But reading through the thread, they
say it's been fixed but I can't figure out what part in their changelog
addresses it. Did they merely disable the kernel option as well, or was
there an actual patch? Latest 4.9 version is now 4.9.35 and there
doesn't seem to be anything obvious in the .34 and .35 changlogs that I
can see that addresses it either. But then again, maybe I don't know
what I'm looking for.


-- 
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/oj3mrb%24gv%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 06/27/2017 04:50 PM,
0spinbo...@gmail.com wrote:
> It seems building works fine on fc23. Wonder what changed between 6/17 and 
> today that fc25 no longer compiles kernels, though.
>
> Wasn't using any patches from the hardening project. 

I just spun up a FC25 BuildVM and *no* kernels (I even tried 4.4 and
4.9) compile any more on that machine (but they do with the same config
on FC23).

There was a change to the kernel.spec file a few weeks ago to work
around a buggy dracut on FC25 for R4.0 and I think that's what's causing
it (the script seems to die in that code chunk) and maybe reverting it
to the old version might help, but I won't have time to look at this
again for another couple of days. I've noticed that Marek has continued
to do work on that file since the last time it was synchronized so maybe
if I sync up with that version, it might work again.

For now though, things seem to work fine with an FC23 build VM, so I'd
suggest sticking with that for now.


-- 
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/oivcfg%242cp%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 2017-06-27 1:53 PM, Reg Tiangha wrote:
> On 2017-06-27 1:37 PM,
> 0spinbo...@gmail.com wrote:
> 
>> Thanks. Was already up to date, though, and all gzip-related options were 
>> enabled (as before). Only change was a new package req 
>> (elfutils-libelf-devel).
>> As for new info, I have frustratingly little to offer:
>> -
>>  mkdir -p 
>> /home/user/rpmbuild/BUILDROOT/kernel-4.11.7-18.pvops.qubes.x86_64//var/lib/qubes/vm-kernels/4.11.7-18
>> + 
>> PATH=/sbin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/user/.local/bin:/home/user/bin
>> + dracut --nomdadmconf --nolvmconf --kmoddir 
>> /home/user/rpmbuild/BUILDROOT/kernel-4.11.7-18.pvops.qubes.x86_64/lib/modules/4.11.7-18.pvops.qubes.x86_64
>>  --modules 'kernel-modules qubes-vm-simple' --conf /dev/null --confdir 
>> /var/empty -d 'xenblk xen-blkfront cdrom ext4 jbd2 crc16 dm_snapshot' 
>> /home/user/rpmbuild/BUILDROOT/kernel-4.11.7-18.pvops.qubes.x86_64//var/lib/qubes/vm-kernels/4.11.7-18/initramfs
>>  4.11.7-18.pvops.qubes.x86_64
>> Kernel version 4.11.7-18.pvops.qubes.x86_64 has no module directory 
>> /lib/modules/4.11.7-18.pvops.qubes.x86_64
>> ldconfig: need absolute file name for configuration file when using -r
>> dracut: ldconfig might need uid=0 (root) for chroot()
>> ++ lsinitrd 
>> /home/user/rpmbuild/BUILDROOT/kernel-4.11.7-18.pvops.qubes.x86_64//var/lib/qubes/vm-kernels/4.11.7-18/initramfs
>>  usr/lib/modules/4.11.7-18.pvops.qubes.x86_64/modules.dep
>> + modules_dep=
>> + '[' -z '' ']'
>> ++ mktemp -d
>> + tmpdir=/tmp/tmp.0U02gQXJIH
>> + zcat 
>> /home/user/rpmbuild/BUILDROOT/kernel-4.11.7-18.pvops.qubes.x86_64//var/lib/qubes/vm-kernels/4.11.7-18/initramfs
>> + cpio -imd -D /tmp/tmp.0U02gQXJIH
>>
>> gzip: 
>> /home/user/rpmbuild/BUILDROOT/kernel-4.11.7-18.pvops.qubes.x86_64//var/lib/qubes/vm-kernels/4.11.7-18/initramfs:
>>  not in gzip format
>> cpio: premature end of archive
>> + exit 1
>> error: Bad exit status from /var/tmp/rpm-tmp.MAZxNe (%install)
>> 
>> (If there is a way to get more (relevant) information, you'll have to tell 
>> me where to (start) look(ing), sorry.)
>>
> 
> 
> Curious:  What is your build environment for this kernel? I only ever
> use/test FC23 because that's what my dom0 runs, but there have been
> issues when the compile environment is different (ex. FC25).
> 
> I've only ever gotten gzip errors if I completely remove gzip support
> from my config options, but I've only seen it appear at boot and not at
> compile time.
> 

Also, are you using the 4.11 patches from the Hardened Kernel project? I
remember rpm generation failing one time (can't remember the exact error
message) with one version of their patches (it patched in properly and
successfully compiled, but just died when it came to generating the
rpms), which eventually got fixed in a later revision. If you're using
them but haven't updated it recently, their latest version is 4.11.7.a:

https://github.com/copperhead/linux-hardened/releases

I also have a branch that tracks just that, which is essentially the
same as my devel-4.11 branch but just adds in and updates the
linux-hardened patches as those get released, mainly for convenience:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11-hard



-- 
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/oiufvf%24g9q%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Screen brightness

[Reg Tiangha]

On 06/26/2017 04:25 PM, Unman wrote:
> On Mon, Jun 19, 2017 at 06:20:14PM -0700, Bob wrote:
>> Is there any way to turn down screen brightness, either via terminal or 
>> system settings? The closest thing I can find is System Tools -- Power 
>> Manager --Display. That gives options regarding adjusting brightness after 
>> inactivity, but I am wondering if it's possible to set the default 
>> brightness?
>>
>> Thanks.
>>
> A quick search ("fedora change brightness") throws up a number of
> solutions if you cant do this with  monitor or Function keys -
> suggestions include installing xbacklight and booting with various
> acpi_backlight options. I would try those first.
> I don't think there's anything Qubes specific here - you need to find a
> solution that works with Fedora and (if you need to install software)
> install it in dom0, since that provides the graphics.
> To install software in dom0 you use the 'qubes-dom0-update' command,
> which needs to be run as root. This will download the software in the
> updateVM and then transfer it in to dom0 - this is necessary because
> dom0 has no networking.
>
If you're using XFCE and you have the Power Management tray icon in your
Notification Tray, you can also right-click on it and it'll bring up a
screen brightness slider that you can adjust, if your machine supports
it (for example, it doesn't appear on my desktop but it does on my
notebook).



-- 
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/oiu883%24ufs%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 06/27/2017 08:09 AM, Epitre wrote:
> Le mardi 27 juin 2017 12:40:00 UTC+2, 0spin...@gmail.com a écrit :
>> Anyone have an idea why, since 4.11.7, I am always getting a "initramfs not 
>> in gzip format" error?
> Hi, same problem for me with 4.11.7. I also tried to select only AMD family 
> (my type of processor) and it results the same.
>

I just tried 4.11.7 for myself on my machine, and it works fine in both
dom0 and in VMs.

So, if you're using my development branch, make sure to run 'git pull'
to ensure everything is synced up (for example, if you haven't done it
in a while, then you may not have the XSA 216 security patches applied
to your kernel that were released last week):

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11

Otherwise, make sure your config file has these options set (use 'make
menuconfig' and search for them to ensure they're set correctly):

CONFIG_HAVE_KERNEL_GZIP=y

CONFIG_RD_GZIP=y

CONFIG_DECOMPRESS_GZIP=y


If that still doesn't work, then more information is needed. But for
now, try the above and see if that works.



-- 
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/oiu84e%24ufs%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 2017-06-22 12:22 PM, motech man wrote:
> OK, sounds straightforward, I'll give it a shot.
> 
> As to the 4.11 offer, will that work for a kaby-lake system? Sound far older 
> than the 4.4 kernel in the current 3.2 Qubes ISO. Unless you mistyped the 
> version I suspect it would not work well.
>
Nope, didn't mistype anything. You can see the various
officially-supported-by-upstream kernels and what versions they're at by
visiting https://kernel.org. 4.11.6 is the latest in the 4.11 branch.

> Are there any specific options or patches in that 4.11 code that
relate to suspend issues?

No idea. But Kaby Lake is a relatively new platform and it usually takes
a few major kernel releases before hardware support in the kernel
catches up. So maybe it'll fix things for you, or maybe it won't (but
might later on). Video card support should be better, though, since the
Intel video driver is newer.




-- 
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/oih25r%246bg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 2017-06-22 11:49 AM, motech man wrote:
> I just used the qubes-dom9-update cli cmd. Still not sure how to change 
> kernel config to tailor to my hardware. I have compiled any a Linux kernel 
> but not sure the proper "qubes" way to do it. I'm just a newb after all ;-/

It's not hard. If you're familiar with compiling a normal kernel, all
you need to do is to grab Qubes kernel source here:

https://github.com/QubesOS/qubes-linux-kernel/tree/stable-4.9

Run 'make get-sources && make verify-sources' to download the vanilla
kernel source.

Take the config file from the Qubes kernel root directory and run 'make
menuconfig' on that (extract the kernel source with tar Jxf, copy that
config file to .config in the kernel source directory, run 'make
menuconfig') and customize it to your liking. When you're done, copy
that updated .config file to replace the old config file in the root
Qubes kernel directory.

Then run 'make rpms' to compile the whole thing. Outputted rpms will be
in the rpms/x86_64 directory.

Finally, copy them to dom0 and install them using rpm -ivh --force.

If you're feeling adventurous, I've got a 4.11 branch on my GitHub
account, if you want to see if that'll fix your suspend issues.

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11

I've been running it on my desktop since its release and it seems to
work fine.

-- 
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/oih0t1%24lof%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Ubuntu Xenial Update Dependency Breakages

[Reg Tiangha]

On 06/21/2017 06:23 AM, Unman wrote:
> I'm assuming that you have added Qubes repositories to apt sources, and
> specified Debian, although you are running Xenial. Qubes doesn't provide
> repositories for Ubuntu packages, (as yet).

I've been thinking about this. I assume part of the reason for this is
that there's limited capacity on the Qubes development end to either
maintain or manage an Ubuntu update repository on Qubes infrastructure,
and while I think there was talk about having some sort of hosted
Community repository in the past, I'm sure that's been deferred so that
efforts can be focused on getting R4.0 out the door.

But there are so many third-party Ubuntu PPAs hosted on Launchpad. Would
it be possible for either the Qubes project or a group from the
community to build and host Qubes update packages on that platform,
independently from the Qubes project if need be, so that everyone in the
Qubes community who runs Ubuntu templates can benefit? Granted, I don't
know what the criteria is to get projects hosted over there, and Qubes
packages would only really benefit those running Ubuntu on Qubes and not
a normal Ubuntu user (so maybe that would disqualify it?), but it would
be nice if some kind of repository could be set up to host the
Qubes-specific packages that get updated whenever there are updates for
mainline Qubes for community-supported templates like Ubuntu and
Archlinux (and maybe others like CentOS and Trisquel in the future).

What I've been doing is keeping an eye on the qubesbot on Github and
whenever something gets pushed out, to take note of it and compile my
own versions, but it's a pain to push out to all my VMs. I think I'm
leaning towards setting up my own local repository to push updates to so
that I can use that in my VMs rather than manually installing those
packages myself, but it's something I don't have experience in (yet).

-- 
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/oidphb%24bg1%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Any release schedule for Qubes 4.0

[Reg Tiangha]

On 2017-06-20 9:06 AM, Swâmi Petaramesh wrote:
> Hi there,
> 
> I've been googling here and there, and couldn't find any release
> schedule for the upcoming qubes 4.0...
> 
> Any clue anybody ?
> 
> ॐ
> 

They haven't released one yet and it will be done when it's done.

Personally, I'd rather have them leave it in the oven until it's fully
baked, rather than to rush it out and then patch heavily later. If it
isn't ready yet, then it isn't ready. People can help speed things up
however, by volunteering to help find/fix bugs or helping with software
development by taking on one of the many "Help Wanted" tasks here:

https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22=%E2%9C%93

Or contributing in other ways as specified here:

https://www.qubes-os.org/doc/contributing/

-- 
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/oibes4%2418l%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [UP] Qubes and USB Ethernet adapter

[Reg Tiangha]

On 2017-06-19 10:12 AM, Swâmi Petaramesh wrote:
> Hi,
> 
> Does anybody here have an idea about this ?
> 
> Le 16/06/2017 à 08:28, Swâmi Petaramesh a écrit :
>> Hi,
>>
>> I have a new Asus laptop which comes with no integrated Ethernet, but an
>> USB Gigabit Ethernet adapter.
>>
>> I wonder if this will be compatible with Qubes' Net VM, or if I will
>> need to allocate the complete USB controller to the net VM - which would
>> be extremely annoying to me...
>>
>> Any clue appreciated.
>>
>> Kind regards.
> 
> ॐ
> 


Some people have it working with USB wifi network adapters, so I don't
see why it wouldn't work with an Ethernet one. It would depend on driver
and/or firmware support being installed in the NetVM first, though,
although if you have access to another machine with network access and a
USB flash drive, you could manually copy over any missing drivers or
firmware. But I don't know if other people got it working using a USB VM
and doing pass-through for just that device, or if they had to allocate
the entire USB controller to the Net VM.

-- 
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/oi8vua%24o0u%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: support of encrypted Linux- and Windows-VMs?

[Reg Tiangha]

On 2017-06-19 9:41 AM,
josefh.ma...@hushmail.com wrote:
> Hello List
> 
> 
> Does Qubes support encrypted Linux- and Windows-VMs?
> 
> 

As in Linux VMs encrypted with something like LUKS and Windows with
Bitlocker? I don't see why not. Certainly if those VMs are set up as
HVMs, although I'm not sure how it would work when it comes to unlocking
if they were set up as PV vms. I've never tried it myself.

-- 
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/oi8v0r%24n8r%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: certified laptop delivery to Russia

[Reg Tiangha]

On 2017-06-19 12:56 AM, taii...@gmx.com wrote:
> I don't care how much cash they give to the devs purism is a scam plain
> and simple, don't buy from them.
> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem_laptop_purism_doesnt_believe_in/
> 

Your news is old. The latest hardware revisions of the 13 and 15 inch
models will ship with coreboot:

https://phoronix.com/scan.php?page=news_item=Librem-13-v2-More-Coreboot

Although to be fair, I'm not sure what'll happen with the older models
and if it's easy to flash it yourself.

They'll still rely on the Intel ME (like all modern Intel laptops) but
it looks like ME Cleaner works on these models too. For now, that's the
best that anyone can hope for.

https://puri.sm/coreboot/

That said, I still think they're overpriced for what you get. I'm on the
fence on whether or not it's worth the premium to have something with
coreboot and a neutered ME pre-installed so I don't have to disassemble
the thing myself in order to flash the chips. Certainly not with the
exchange rates the way they are right now.

-- 
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/oi7umc%24uce%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Is there a mechanism that stops qube os from starting if the drive is unplugged?

[Reg Tiangha]

On 2017-06-18 6:49 PM, carr...@gmail.com
wrote:
> I ask because I plan to hot swap my qube os drive out with my windows drive. 
> When I swap back in the qube os drive it does not boot. I installed anti-evil 
> maid and encrypted the drive but no tpm. 
> 

By "hot swap," do you mean actually yanking out the hard drive while
everything is turned on and then plugging in the other hard drive,
again, while everything is still turned on? Because that's the
traditional meaning of the term. If so, unless you've got specialized
hardware that properly cuts power off to the drive before you pull it
(and even then, I don't think Windows supports being plugged
into/plugged out of a running system anyways), I think you might have
some bigger problems at the moment.

-- 
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/oi7arn%24kpg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 06/15/2017 03:02 PM, Reg Tiangha wrote:
> On 06/15/2017 02:51 PM, Zrubi wrote:
>> Do we already have any git issues about 4.9 and its currently known
>> problems?
>>
> Nothing centralized that tracks all 4.9 issues/regressions that I'm
> aware of, outside of this message thread. Some tickets have been opened
> up as needed for specific issues (for example, full-range slub_debug
> being enabled exposing a kernel bug that breaks SSL connections) though.
>
> Sometimes comments or feedback are posted under the relevant kernel
> update ticket whenever a new one is pushed out:
>
> https://github.com/QubesOS/updates-status/issues
>
> One thing to test would be a variety of different 4.9 releases; while
> I'm still leaning towards an X or interaction with newer X issue, it
> could also be a regression that was introduced upstream. And it would be
> nice to know if this issue is happening on video cards that *aren't*
> Intel. Really, the only kernel config option that changed between 4.4
> and 4.9 for Intel cards is that preliminary hardware support option
> being changed to enabled by default. If disabling that doesn't fix it,
> there there are either bigger issues at play in the kernel *or* the
> issue is somewhere else.
>
> Also, a greater list of specific KDE apps to test would be helpful if
> you could provide that.
>
>
Finally, another idea: I believe it was Vik who said that on newer Intel
video cards, the i915 driver actually *wasn't* being used in 4.4 because
it did not support newer cards, and a generic video driver was being
automatically used instead. So maybe that i915 support for newer
hardware exists in 4.9 and is actually being used, but is buggy on
Haswell or newer which is why it only appears now.

That said, again, I've been running 4.9 on Sandy Bridge for months and
the issue didn't show up until I started using Debian 9 templates, so
I'm not completely convinced yet that it's 4.9 alone that is the issue.
It could be a combination of things, or Qubes video code interacting
with newer X alongside the i915 driver included in the 4.9 kernel.

Which is why it would really be useful if someone with an AMD or Nvidia
video card could try the same set up and see if this rendering issue
appears or not. If it doesn't, then it'd help rule out if this is a
general problem, or just a problem that appears with Intel video cards.

Another thing you could test is running that app suite on a Fedora 23
template (and even Debian 8 if those apps exist there) to see if the
problem appears. If it does not, then it's more evidence that newer
versions of X might be part of the 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 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/ohut6b%242b7%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 06/15/2017 01:53 PM, Zrubi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 06/15/2017 06:34 PM, Reg Tiangha wrote:
>
>> Curious:  For those apps that exhibit that behavior, are they
>> running on Debian 9 or Fedora 25 templates?
> Nope.
> Fedora 24 mainly, and Debian 8
> The later is only for sys-net, so all my taskbar icons coming from a
> F24 based template.
>
Thanks. I don't really use Fedora, but I'll set up a test VM once my
laptop is finished converting this Debian 8 template to 9. Can you list
some apps that this happens with so I can test across a variety of
templates? I'm still leaning towards an X issue, but maybe it's always
been there since Fedora 24, even under kernel 4.9. But I would assume if
that was the case, then more people would have spoken up by now.
>> Since it works fine in Debian 8 (I haven't tested much with any 
>> Fedoras), I'm wondering if it's less a kernel issue and more of an
>> issue with newer X or how Qubes integrates with newer X (but I
>> guess if it works properly on 4.4, it may be a combination of the
>> three; don't know how to fix it though).
> Maybe it is a know issue, but:
> online netvm change on a disposable VM is also broken on the latest
> 4.9 VM kernel. (Qubes Manager shows it is changed, but not working in
> practice)
>
I've *never* ever had this work for me (although it might have worked
once in R3.0 or something old like that); I've always had to shut down
the Disp VM first, alter the dvm template, and then start up a new one
in order to change NetVMs.

>> I can't play around with this until later today, but in the
>> meantime, what graphics hardware are you running, Zrubi? And which
>> version of 4.4 are you running where things work fine? And finally
>> if you can, if it's an Intel card, can you try booting with this
>> kernel option to see if it makes a difference?
>>
>> i915.preliminary_hw_support=0
> I believe this setting will not affect this chipset. But will try if I
> have a chance. (This is my only Qubes Laptop atm and using it for
> production)
>
> HW details:
>
> Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
> Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09)
> Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00
>
> SW versions:
> Qubes 3.2
> xen: 4.6.5
> kernel: 4.4.62-12
>
It might; if you could try it in both dom0 and vm (and maybe different
combinations if you have the time), that'd be useful to help rule things
out. It's toggled on by default to work around this:

https://www.phoronix.com/scan.php?page=news_item=intel-skl-prelim-support

but maybe it's no longer an issue with 4.9.



-- 
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/ohup4h%243bu%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 06/15/2017 10:34 AM, Reg Tiangha wrote:
> On 06/15/2017 05:40 AM, Zrubi wrote:
>> My Lenovo T450 working fine with kernel 4.4
>> Jut tried the latest 4.9.31 and has some interesting graphic related
>> issues:
>>
>> Under KDE, the application icons in the taskbar are messed up. Means
>> broken application images are displayed. Broken means some kind of
>> transition between the last visited desktop icons and the current one.
>> The problem disappear (probably refreshing to a valid icon) by the
>> time. But messing up again if I switch virtual desktops. Which I do
>> very often.
>>
>> A refresh is surely occures if I switch out to a CLI terminal and
>> back. But the result is just temporary, as if I switching virtual
>> desktops the icons are getting messed up again and again.
>>
>> Switched back to kernel 4.4 solved these problems, so it is less
>> likely a hardware bug.
>>
> Curious:  For those apps that exhibit that behavior, are they running on
> Debian 9 or Fedora 25 templates?
>
> I'll be honest, I primarily run Debian templates and in anticipation of
> the official release of Debian 9 this week, I've been slowly migrating
> my Debian 8 templates to Debian 9, and I've started to notice that
> behaviour as well. It does *not* happen under Debian 8 on kernel 4.9.
> And I've been running 4.9 kernels in dom0 since December. I *have* been
> running Debian 9 as my sys-net for months, though, and the
> NetworkManager applet seems fine. I haven't tested extensively, but for
> me, the IBus (for keyboard langauge switching) icon has a black overlay,
> and when I play music through Rhythmbox on Debian 9, the pop up message
> that displays when a new song is played is a little corrupted (but that
> never happened on the same kernel on Debian 8).
>
> Since it works fine in Debian 8 (I haven't tested much with any
> Fedoras), I'm wondering if it's less a kernel issue and more of an issue
> with newer X or how Qubes integrates with newer X (but I guess if it
> works properly on 4.4, it may be a combination of the three; don't know
> how to fix it though).
>
> Intel Sandy Bridge is my system; haven't tested on other hardware.
>
>
And to follow up, I just installed 4.9.32 and haven't noticed it as
much, but I've only put in 10 minutes of testing so I can't say for sure
if it was a regression in 4.9.31.

I can't play around with this until later today, but in the meantime,
what graphics hardware are you running, Zrubi? And which version of 4.4
are you running where things work fine? And finally if you can, if it's
an Intel card, can you try booting with this kernel option to see if it
makes a difference?

i915.preliminary_hw_support=0



-- 
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/ohueub%24d3r%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 06/15/2017 05:40 AM, Zrubi wrote:
> My Lenovo T450 working fine with kernel 4.4
> Jut tried the latest 4.9.31 and has some interesting graphic related
> issues:
>
> Under KDE, the application icons in the taskbar are messed up. Means
> broken application images are displayed. Broken means some kind of
> transition between the last visited desktop icons and the current one.
> The problem disappear (probably refreshing to a valid icon) by the
> time. But messing up again if I switch virtual desktops. Which I do
> very often.
>
> A refresh is surely occures if I switch out to a CLI terminal and
> back. But the result is just temporary, as if I switching virtual
> desktops the icons are getting messed up again and again.
>
> Switched back to kernel 4.4 solved these problems, so it is less
> likely a hardware bug.
>
Curious:  For those apps that exhibit that behavior, are they running on
Debian 9 or Fedora 25 templates?

I'll be honest, I primarily run Debian templates and in anticipation of
the official release of Debian 9 this week, I've been slowly migrating
my Debian 8 templates to Debian 9, and I've started to notice that
behaviour as well. It does *not* happen under Debian 8 on kernel 4.9.
And I've been running 4.9 kernels in dom0 since December. I *have* been
running Debian 9 as my sys-net for months, though, and the
NetworkManager applet seems fine. I haven't tested extensively, but for
me, the IBus (for keyboard langauge switching) icon has a black overlay,
and when I play music through Rhythmbox on Debian 9, the pop up message
that displays when a new song is played is a little corrupted (but that
never happened on the same kernel on Debian 8).

Since it works fine in Debian 8 (I haven't tested much with any
Fedoras), I'm wondering if it's less a kernel issue and more of an issue
with newer X or how Qubes integrates with newer X (but I guess if it
works properly on 4.4, it may be a combination of the three; don't know
how to fix it though).

Intel Sandy Bridge is my system; haven't tested on other hardware.


-- 
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/ohuctn%24vei%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Weird SSL issues

[Reg Tiangha]

On 06/07/2017 08:43 AM, Bernhard wrote:
>> Hello Qubes community!
>>
>> I have a weird issue with SSL (HTTPS) access. 
>>
>> Here is my setup: Debian 9 minimal sys-net - Fedora 24 minimal sys-firewall. 
>> Any app-vm running Fedora 24 or Debian 9 (have not tested any other) have 
>> issues connecting to https sites with Chrome, Chromium or Firefox-esr. 
>> Sometimes it works, sometimes not...
>>
>> I have tested on numerous wired and wireless network with the same result..
>>
>> Please help me figure this out!
>>
>> Dominique
>>
> Hello, I sometimes have SSL issues that all from the fact that the time
> in the appvm are wrong (sometimes even in the future) - although dom0 is
> accurately set up. If you have a cure to that (especially for debian) I
> am interested ... maybe you experience the same problem? Bernhard
>
Are you running kernel 4.9.29 from current-testing? There's a workaround
in this thread here:

https://github.com/QubesOS/qubes-issues/issues/2840#issuecomment-305938895

And it should be fixed in the next kernel release.


-- 
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/oh9geh%24bt2%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Lenovo s230u "Twist"

[Reg Tiangha]

On 06/03/2017 10:35 AM, Reg Tiangha wrote:
> On 06/03/2017 03:35 AM,
> wordswithn...@gmail.com wrote:
>> Upgrading to kernel 4.9.29-17 (from the testing repo) fixed the mouse and 
>> keyboard issues!
>>
>> It has apparently caused my Intel PCIe WiFi card to crash when returning 
>> from suspend, requiring a reboot of sys-net.
>
> That'll be addressed in the next kernel release, but there are a couple
> of other issues that have come up in deep testing that are being worked
> through right now. Tracking here:
>
> https://github.com/QubesOS/qubes-issues/issues/2844
>
> But if it's really bothersome, you can work around it right now by
> blacklisting the wifi power module by following the instructions here:
>
> https://www.qubes-os.org/doc/wireless-troubleshooting/#automatically-reloading-drivers-on-suspendresume
>
> Either should work. The bottom line is that Intel's wifi power saving
> functionality that was introduced after 4.4 is buggy for certain cards,
> so users of other distros have resorted to blacklisting the module, and
> some other major distros like Fedora and Ubuntu have even resorted to
> compiling the option out of their default kernels until it all gets
> resolved some day.
>
>
Sorry, did the wrong CTRL-SHIFT copy/paste thing there. The kernel bugs
with the 4.9.29 kernel are being tracked here:

https://github.com/QubesOS/updates-status/issues/55


-- 
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/oguooe%24bbl%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Lenovo s230u "Twist"

[Reg Tiangha]

On 06/03/2017 03:35 AM,
wordswithn...@gmail.com wrote:
> Upgrading to kernel 4.9.29-17 (from the testing repo) fixed the mouse and 
> keyboard issues!
>
> It has apparently caused my Intel PCIe WiFi card to crash when returning from 
> suspend, requiring a reboot of sys-net.


That'll be addressed in the next kernel release, but there are a couple
of other issues that have come up in deep testing that are being worked
through right now. Tracking here:

https://github.com/QubesOS/qubes-issues/issues/2844

But if it's really bothersome, you can work around it right now by
blacklisting the wifi power module by following the instructions here:

https://www.qubes-os.org/doc/wireless-troubleshooting/#automatically-reloading-drivers-on-suspendresume

Either should work. The bottom line is that Intel's wifi power saving
functionality that was introduced after 4.4 is buggy for certain cards,
so users of other distros have resorted to blacklisting the module, and
some other major distros like Fedora and Ubuntu have even resorted to
compiling the option out of their default kernels until it all gets
resolved some day.


-- 
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/oguofi%24bbl%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 06/01/2017 06:55 AM, Pablo Di Noto wrote:
> Oh, yeah... I have started experiencing quite annoying internet connectivity 
> issues, very, very difficulty to troubleshot. Symptoms are:
>
> - Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never 
> reaching some of the content.
> - SSH sessions can hang while exchanging keys, and if the recover can last 
> for hours.
> - Pinging sys-net from sys-firewall sometimes stops responding, but that does 
> not happen consistently with the higher level issues (browsing from any VM 
> can be impossible, and still ping works) 
>
> After 4 days of troubleshooting (switching browser versions, browser brands, 
> changing templates, replacing openwrt+mwan3 home router with direct 
> connections from ISP demarc to the machine, using different ISPs, doing all 
> the same on a brand new R3.2 + "--enablerepo=qubes*testing", creating new 
> sys-net+sys-firewall based on different templates, and so on...) y have just 
> found that taking a failing setup and setting the kernels of all involved VMs 
> to 4.4.67-12 makes the problem disappear.


For anyone encountering SSL issues with the 4.9.29 kernel, could you add
slub_debug=- to your VM's kernelopts and restart the VM to see if that
helps and report back? The issue may have been identified, but it could
use more feedback.


View your current kernel options:

qvm-prefs -l  kernelopts

Set new kernel options:

qvm-prefs -s  kernelopts "slub_debug=- (and anything else that
was output above)"


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 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/ogst8d%24cb8%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 2017-06-01 6:55 AM, Pablo Di Noto wrote:
> Hello,
> 
>> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
> 
> Using it on a Lenovo X250 (i3-5010U), and other desktops.
> 
> Experiencing consistently the "no wifi after resume" which was working fine 
> with 4.4.x

There's a 4.9.29 in current-testing now, try that and see if that works
better. Otherwise, blacklist your module like Patrik Hagara suggested in
his follow up.

The reason why I *think* this is happening is that somewhere in between
4.4 and 4.9, Intel introduced some power management functionality for
wifi cards, but it's buggy. Users of other distros blacklist those
modules to work around it, and other distros like Fedora and Ubuntu have
now resorted to not enabling that option in their kernels. So I took it
out of this one. So try 4.9.29 if you haven't installed it already and
see if that works, although it'll probably not affect wifi cards from
other manufacturers that are having the same issue since it's an
Intel-only option.


>> 4) General feedback on the 4.9 kernel.
> 
> Oh, yeah... I have started experiencing quite annoying internet connectivity 
> issues, very, very difficulty to troubleshot. Symptoms are:
> 
> - Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never 
> reaching some of the content.
> - SSH sessions can hang while exchanging keys, and if the recover can last 
> for hours.
> - Pinging sys-net from sys-firewall sometimes stops responding, but that does 
> not happen consistently with the higher level issues (browsing from any VM 
> can be impossible, and still ping works) 
> 
> After 4 days of troubleshooting (switching browser versions, browser brands, 
> changing templates, replacing openwrt+mwan3 home router with direct 
> connections from ISP demarc to the machine, using different ISPs, doing all 
> the same on a brand new R3.2 + "--enablerepo=qubes*testing", creating new 
> sys-net+sys-firewall based on different templates, and so on...) y have just 
> found that taking a failing setup and setting the kernels of all involved VMs 
> to 4.4.67-12 makes the problem disappear.

Honestly, I have been encountering SSH issues with GitHub recently, but
I've been running 4.9/4.10 and 4.11 kernels on my two machines for
months now, and it's only started happening in the last couple of weeks.
Since it clears up if I wait for a bit (and it's intermittent), I'm not
confident it's a kernel issue unless a regression was introduced
upstream recently. Are your SSH issues just with GitHub, or are they
with other sites as well?

I haven't really noticed the web browsing issues either, so more info or
reports would be useful. Off the top of my head, I can't see how the
kernel would affect that, although I haven't looked into it in depth too
much yet. But my gut tells me that could be a different issue not
related to the kernel.

-- 
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/ogp71v%24j8b%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: debian 8 grsec vs thunderbird

[Reg Tiangha]

On 2017-05-31 1:04 PM, haaber wrote:
>> and if grsec is killing processes you actually want to run, you can look
>> at the logs, see what protection is being triggered, and can use
>> paxctl/paxctld to disable it just for that executable or library.
> 
> I tried, but I dd not learn anything useful. Here, for example, is a
> sniplet of my syslog (sorry for broken long lines)
> 
> May 21 22:21:15 localhost kernel: [  717.509203] PAX: execution attempt
>in: , 715894beb000-715894e5b000 715894beb000
> May 21 22:21:15 localhost kernel: [  717.509216] PAX: terminating task:
>/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java(java):5500, uid/euid:
>0/0, PC: 715894beb060, SP: 71589f156488
> May 21 22:21:15 localhost kernel: [  717.509222] PAX: bytes at PC:
>85 f6 0f 84 11 00 00 00 0f ae f0 0f ae 3f 48 83 c7 40 ff ce
> May 21 22:21:15 localhost kernel: [  717.509239] PAX: bytes at SP-8:
>71589f1564c0 71589daf685b 71589f156530 71589f156530
>71589f1564c0 71589de1a558 71589f156a40 71589f156a40
>71589f156a20 71589dee2f37 71589f156b40
> 
> how do you read off the protection that was being triggered in this ??
> Bernhard
> 


Usually dmesg gives some hints, but most of the time it's the memory
protection, so that's a good first thing to try. You can also google the
executable and grsecurity and see what comes up since you're probably
not the only one to encounter the issue.

In this case, Java is well known to be incompatible with the full set of
PAX protections. You could try disabling just the memory protections to
see if that helps:

sudo paxctl -cm /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

and/or if it doesn't, then disable a bunch more:

sudo paxctl -cpemrxs /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

Java, WINE, and other things that emulate other things usually don't
play nice with grsecurity and so you'll need to figure out which
binaries or libraries grsec/pax is killing and modify their protection
permissions to get them to run.

-- 
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/ogn4pf%24tle%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: debian 8 grsec vs thunderbird

[Reg Tiangha]

On 2017-05-31 12:34 PM, haaber wrote:
> Thank you very much Reg! That solves miraculously the problem. I was
> playing with -E instead and it did not help me. At least I learned some
> minimal experience with  paxctl that way :))   Bernhard

Lower case letters disable the specific protection and upper case
letters enable them. So the 'm' disabled memory protections, and the 'E'
would have enabled the emulation of trampolines.

You can learn what all the options are by looking at paxctl's man page:

man paxctl

and if grsec is killing processes you actually want to run, you can look
at the logs, see what protection is being triggered, and can use
paxctl/paxctld to disable it just for that executable or library.

-- 
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/ogn3j8%24c0j%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: debian 8 grsec vs thunderbird

[Reg Tiangha]

On 05/31/2017 04:59 AM, haaber wrote:
> Some update : the same happens with 4.9.20.grsec. The reason seems
> visible in ulimit -a:
>
> core file size  (blocks, -c)   0
>
> whereas thunderbird requests 4096 (whatsoever unit). Remains to
> understand /etc/security/limits.conf
>
> Bernhard

systemd actually ignores /etc/security/limits.conf, although anything
launched by a gnome-terminal (and maybe some other things as well) does
respect that file.

systemd looks at /etc/systemd/user.conf and /etc/systemd/system.conf
instead so if you're changing variables in limits.conf, you could try
setting them there as well.

Or you can disable the memory protections on Thunderbird; that's what
coldkernel actually did by default if you used their paxctld
configuration, but it only had a listing for Icedove and not for
Thunderbird.

You could add a listing under /etc/paxctld.conf for Thunderbird:

/usr/lib/thunderbird/thunderbirdm

and/or manually convert the executable with paxctl if you have it installed:

sudo paxctl -cm /usr/lib/thunderbird/thunderbird


-- 
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/ogmqg5%247ro%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Booting USB Quebes across multiple machines?

[Reg Tiangha]

On 05/29/2017 06:59 AM, Dave C wrote:
> * I have a laptop which boots incredibly slowly.  There is a roughly 2 minute 
> delay in the boot process.  I suspect it is waiting for PS/2, but the machine 
> has none. Although I'm not sure, and not sure how to troubleshoot.


If you weren't aware, you can press F2 during boot up to see the text
version of the boot sequence; maybe that might give you some hints as
well. I have an old-style hard drive rather than an SSD in my laptop,
and as it gets more and more fragmented over time with trimming VMs and
what not, the boot sequence has slowed down. Most of the time goes to
booting up sys-net, sys-usb and sys-firewall before getting to the log
in screen. That's about 2-3 minutes on its own.


-- 
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/oghfv9%241hg%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maccchanger, debian9 template, Screensave

[Reg Tiangha]

On 05/28/2017 02:20 PM, Finsh wrote:
> thanks, ive already made a fed25 template(not tested so far) I followed the 
> instructiosn on the documentation site, what are the differences to your 
> methode?
>

If your fedora-25 template already works properly, then there's no
difference. I copy/pasted mine from the Qubes website and changed it to
work going from fc24 to fc25 instead of fc23 to fc24.


-- 
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/ogfbu3%246sr%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maccchanger, debian9 template, Screensave

[Reg Tiangha]

On 05/28/2017 02:00 PM, Reg Tiangha wrote:
> On 05/28/2017 01:14 PM, Finsh wrote:
>> oh ok, thanks.well, that is very unfortunate.so i will have to use the 
>> debian-9 template for sys-net.
>
> Well, that's not exactly true. You could take that fedora-24 (or
> fedora-24-minimal) template, clone it, and then upgrade the clone to
> Fedora 25.
>
> [user@dom0 ~]$ qvm-clone fedora-24 fedora-25
> [user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
> [user@dom0 ~]$ qvm-run -a fedora-25 gnome-terminal
> [user@dom0 ~]$ qvm-block -A fedora-25
> dom0:/var/tmp/template-upgrade-cache.img
> [user@fedora-25 ~]$ sudo mkfs.ext4 /dev/xvdi
> [user@fedora-25 ~]$ sudo mount /dev/xvdi /mnt/removable
> [user@fedora-25 ~]$ sudo dnf clean all
> [user@fedora-25 ~]$ sudo dnf --releasever=25
> --setopt=cachedir=/mnt/removable distro-sync
>
> (Shut down TemplateVM by any normal means.)
>
> [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
> [user@dom0 ~]$ qvm-trim-template fedora-25
>
>
> Assuming Network Manager is already installed in that fedora-24
> template, it should get upgraded to version 1.4.0 after the whole
> template gets upgraded to Fedora 25. Be warned that there maybe be some
> graphical bugs still present with some applications due to the switch to
> Wayland, which is why I think there's no official Qubes Fedora 25
> template even though there's already an official FC25 Qubes repository.
> But for something as sys-net, it should work fine; I had that running on
> my laptop for a while before I switched my sys-net to Debian 9.
>
>

Ugh. Word-wrap screwed up the commands. Let me try again:

In dom0:

[user@dom0 ~]$ qvm-clone fedora-24 fedora-25
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-run -a fedora-25 gnome-terminal
[user@dom0 ~]$ qvm-block -A fedora-25 
dom0:/var/tmp/template-upgrade-cache.img (all one line)

Then open a terminal on the fedora-25 template and run:

[user@fedora-25 ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-25 ~]$ sudo mount /dev/xvdi /mnt/removable
[user@fedora-25 ~]$ sudo dnf clean all
[user@fedora-25 ~]$ sudo dnf --releasever=25 
--setopt=cachedir=/mnt/removable distro-sync (all one line)

Shut down TemplateVM by any normal means. Then in dom0:

[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-trim-template fedora-25



-- 
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/ogfaej%243qd%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maccchanger, debian9 template, Screensave

[Reg Tiangha]

On 05/28/2017 01:14 PM, Finsh wrote:
> oh ok, thanks.well, that is very unfortunate.so i will have to use the 
> debian-9 template for sys-net.


Well, that's not exactly true. You could take that fedora-24 (or
fedora-24-minimal) template, clone it, and then upgrade the clone to
Fedora 25.

[user@dom0 ~]$ qvm-clone fedora-24 fedora-25
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-run -a fedora-25 gnome-terminal
[user@dom0 ~]$ qvm-block -A fedora-25
dom0:/var/tmp/template-upgrade-cache.img
[user@fedora-25 ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-25 ~]$ sudo mount /dev/xvdi /mnt/removable
[user@fedora-25 ~]$ sudo dnf clean all
[user@fedora-25 ~]$ sudo dnf --releasever=25
--setopt=cachedir=/mnt/removable distro-sync

(Shut down TemplateVM by any normal means.)

[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ qvm-trim-template fedora-25


Assuming Network Manager is already installed in that fedora-24
template, it should get upgraded to version 1.4.0 after the whole
template gets upgraded to Fedora 25. Be warned that there maybe be some
graphical bugs still present with some applications due to the switch to
Wayland, which is why I think there's no official Qubes Fedora 25
template even though there's already an official FC25 Qubes repository.
But for something as sys-net, it should work fine; I had that running on
my laptop for a while before I switched my sys-net to Debian 9.


-- 
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/ogfa8h%243qd%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maccchanger, debian9 template, Screensave

[Reg Tiangha]

On 05/28/2017 12:19 PM, Finsh wrote:
> thanks, that makes sense. can anybody explain to me how to update the 
> Networkmanager in Fedora-24? 
>
>  dnf --showduplicates list NetworkManager only shows older versions...
>
>
> greetings.
>

Again, the version of Network Manager that properly randomizes MAC
addresses doesn't appear until Fedora 25.

If you really want to get it on Fedora 24, you'll need to compile it
yourself. But depending on what libraries are included in Fedora 24, it
might not be possible without upgrading the libraries too (it may or may
not be the case, but that is certainly the case with Debian 8).


-- 
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/ogf6gt%244g9%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maccchanger, debian9 template, Screensave

[Reg Tiangha]

On 05/28/2017 10:43 AM, Finsh wrote:
> Wy is the Macchanger method in the documentaion the way you should use to 
> change  the maccadress?
> It looks a lot easyer to me just to update Networkmanager in fedora and use 
> this Methode?


Because the version of NetworkManager that supports randomizing the MAC
address properly doesn't appear until Fedora 25. So the other method is
the only way to do it on older Fedora templates (and on Debian 8 as well).


-- 
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/ogf0d5%24vtk%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows 7 Install

[Reg Tiangha]

On 05/25/2017 11:36 AM, James Chi wrote:
> Here is where I am:
>
> 1.  I attached usb drive to sys-usb
> 2.  Went to sys-usb: Files, Other Locations, then into the USB drive
> 3.  Copied windows 7 iso file to other AppVM (ie, win7 VMName)
> 4.  Found windows 7 iso in win7 VM using search.  I then moved the iso to the 
> Downloads folder.
> 5.  Used this command in Don0 Terminal: qvm-start win7 
> --cdrom=win7:/Downloads/win7.iso
> 6.  The terminal returned: "This VM does not support attaching drives."  
> (FYI, I also tried to run the iso from sys-usb VM but I received the same 
> message for I tried to move it and try as well)
>
> What am I doing wrong?


Your command is wrong. You're trying to start the win7 VM while telling
it the iso is also in the win7 vm, which probably won't work.

Move back that iso to sys-usb (into the Downloads folder, if you want).
The command you would then run would look like this (I'm assuming the vm
you're trying to install to is the win7 one):

qvm-start win7 --cdrom=sys-usb:/home/user/Downloads/win7.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/og787k%24ghj%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 05/24/2017 12:37 PM, cyrinux wrote:
> Hi,
>
> I have a T450s, and it works well, just this:
>
> Seems to have a problem for me, i often miss wireless after suspend.
> I need to stop firewall and wlan vm to reload iwlwifi driver.
> No easy to unload iwlwifi, faster to stop and start.
> I don't remember i have this problem before.
>
> No other problems.
>
> Thx

Thanks for the feedback. There should be a work-around in the next
kernel release, so keep an eye out for a 4.9.29 or higher to appear in
one of the Qubes repositories and try that one when it comes out. I
*think* the kernel workaround will work, but it could use some testing
when it's out.

In the meantime, you can also work around it locally by blacklisting the
iwlwifi power management module. In your sys-net, edit
/rw/config/suspend-module-blacklist and add:

iwlmvm iwlwifi

and then reboot the vm. According to other people, that should make the
wifi stuff work again too.


-- 
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/og4k7b%24g15%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Unofficial forward-ported grsec 4.9 Qubes kernel branch

[Reg Tiangha]

Just because the baton was dropped doesn't mean that others weren't
willing to pick it up.

There are a few groups now that are forward porting the last grsecurity
release (4.9.24) to work with newer kernels in the 4.9 branch. This is
the one that the Hardened Kernel Community Project links to:

https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec

And the Dapper Linux project is trying to forward-port the patches to
4.11 (but it still doesn't compile properly; trust me, I've tried):

https://github.com/dapperlinux/dapper-secure-kernel-patchset


I've taken their work and created a test 4.9 Qubes grsec kernel branch
merging their patches with the Qubes/Xen patches here (the only one that
wouldn't merge was the mcelog patch so I commented it out; I'm too newb
to figure out how to adjust it to account for the changes that the grsec
patches make), if people wanted to play around with it:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.9-grsec


Some Notes:

- The resulting kernel-qubes-vm package as a VM kernel works *exactly*
the same as a coldkernel. So if you were running coldkernel in your VMs
before, you can save yourself a lot of time using this instead because
instead of installing a grsec kernel on each VM, all you have to do now
is install it once in dom0 and only point the VMs you want to use it.

- I haven't played with it too much yet, but the standard dom0 kernel
package boots, but you'll need to run paxctl to soften the protections
on various binaries and libraries for it to work 100% (paxctl -cm
/usr/bin/pulseaudio is definitely one of them), and maybe do some other
things as well. The problem is, Fedora doesn't have pax-tools in its
repository (I think; Debian definitely does), so you'll have to compile
those utilities yourself. The Dapper Linux project has a branch and
compile instructions on GitHub, but it's up to you to figure out how to
use them (there's lots of documentation on the web; the Arch and Gentoo
Linux grsecurity wikis are probably a good place to start):

https://github.com/dapperlinux/pax-tools


There's probably a risk in continuing to use a stale patch set as time
goes by, but if you're the type that believes a stale grsecurity patch
set is still better than the stock kernel configuration, there are
groups out there trying to keep it alive for as long as possible.


As for getting as many of those grsec patches merged upstream as
possible, that's where the Hardened Kernel Community Project comes in
and they're primarily concentrating on 4.11 for now. Their work is here:

https://github.com/thestinger/linux-hardened/


And I've created a 4.11 branch that merges in those patches (it's what
I'm currently running in dom0 on my personal machines at the moment, and
it seems to work fine) here:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11-hard


If you just want a stock 4.11 experience, I've also created a branch
without the hardened stuff here:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.11


So for those who are bored with the stock kernels and want to try
something new (or need better hardware support than what 4.9 has), there
are a few more choices now.


-- 
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/og4hqk%2410t%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: error starting VM : invalid argument: network device with mac 00:16:00:00:00:00 already exists when starting sys-whonix

[Reg Tiangha]

On 05/23/2017 10:01 PM, Reg Tiangha wrote:
> On 05/23/2017 09:57 PM, Reg Tiangha wrote:
>> On 05/23/2017 08:10 PM, yreb-lm wrote:
>>> error starting VM : invalid argument: network device with mac
>>> 00:16:00:00:00:00 already exists when starting sys-whonix
>>>
>>> I was getting this in sys-net also, but I removed one of the   network
>>> controllers, and it seems to have stopped
>>>
>>> in sys-net  I have an  ethernet controller :intel   and  a  network
>>> controller: realtek   ; neither of these  has the mac  address being
>>> complained about  by sys-whonix
>>>
>>> and I dont see any other VMs  using a network controller, including
>>> sys-whonix,  has no devices  in the settings
>>>
>>>
>>> the system has dual ethernet ports and wifi , i'm guessing that is why
>>> I had 2 ethernet controllers,
>>>
>>> this all seemed to work flawlessy, until  my  botched   Fedora 23 to
>>> Fedora 24 upgrade
>>>
>>> sigh
>>>
>> Maybe it's time to delete sys-net and create a new one from scratch.
>>
>> And as for your Fedora 24 issues, it's sounding like your
>> /etc/yum.repos.d/qubes-r3.repo file is mis-configured. You should
>> manually verify/edit them to read something like
>>
>> baseurl = http://yum.qubes-os.org/r3.2/current/vm/fc24
>>
>> rather than rely on the sed method in the instructions.
>>
>> Or if your templates are totally trashed to the point where they're not
>> worth salvaging, just download a Fedora 24 template directly:
>>
>> sudo qubes-dom0-update --enablerepo=qubes-dom0-templates-itl
>> qubes-template-fedora-24
>>
>> And restart setting up those templates from scratch.
>>
>>
> Actually, I think I screwed up the command. To install a Fedora 24
> template, just type:
>
> sudo qubes-dom0-update qubes-template-fedora-24 (or
> qubes-template-fedora-24-minimal)
>
> The templates-itl repository is already enabled by default.
>
>
Actually, upon further reflection, if you still want to upgrade your
Fedora 23 template to 24, you'll need to verify *all* of the
/etc/yum.repo.d/fedora*.repo files have '$releasever' replaced with
'fc24' instead in addition to the qubes repo file. But honestly, just
download a fresh Fedora 24 template. Life will probably be a lot easier.
You *could* then manually update that to Fedora 25 by replacing every
instance of $releasever in all the repo files to fc25, but at this
point, maybe that'd be a bad idea for 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 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/og357c%24p4i%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: error starting VM : invalid argument: network device with mac 00:16:00:00:00:00 already exists when starting sys-whonix

[Reg Tiangha]

On 05/23/2017 09:57 PM, Reg Tiangha wrote:
> On 05/23/2017 08:10 PM, yreb-lm wrote:
>> error starting VM : invalid argument: network device with mac
>> 00:16:00:00:00:00 already exists when starting sys-whonix
>>
>> I was getting this in sys-net also, but I removed one of the   network
>> controllers, and it seems to have stopped
>>
>> in sys-net  I have an  ethernet controller :intel   and  a  network
>> controller: realtek   ; neither of these  has the mac  address being
>> complained about  by sys-whonix
>>
>> and I dont see any other VMs  using a network controller, including
>> sys-whonix,  has no devices  in the settings
>>
>>
>> the system has dual ethernet ports and wifi , i'm guessing that is why
>> I had 2 ethernet controllers,
>>
>> this all seemed to work flawlessy, until  my  botched   Fedora 23 to
>> Fedora 24 upgrade
>>
>> sigh
>>
> Maybe it's time to delete sys-net and create a new one from scratch.
>
> And as for your Fedora 24 issues, it's sounding like your
> /etc/yum.repos.d/qubes-r3.repo file is mis-configured. You should
> manually verify/edit them to read something like
>
> baseurl = http://yum.qubes-os.org/r3.2/current/vm/fc24
>
> rather than rely on the sed method in the instructions.
>
> Or if your templates are totally trashed to the point where they're not
> worth salvaging, just download a Fedora 24 template directly:
>
> sudo qubes-dom0-update --enablerepo=qubes-dom0-templates-itl
> qubes-template-fedora-24
>
> And restart setting up those templates from scratch.
>
>
Actually, I think I screwed up the command. To install a Fedora 24
template, just type:

sudo qubes-dom0-update qubes-template-fedora-24 (or
qubes-template-fedora-24-minimal)

The templates-itl repository is already enabled by default.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/og30j8%24qmk%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: error starting VM : invalid argument: network device with mac 00:16:00:00:00:00 already exists when starting sys-whonix

[Reg Tiangha]

On 05/23/2017 08:10 PM, yreb-lm wrote:
> error starting VM : invalid argument: network device with mac
> 00:16:00:00:00:00 already exists when starting sys-whonix
>
> I was getting this in sys-net also, but I removed one of the   network
> controllers, and it seems to have stopped
>
> in sys-net  I have an  ethernet controller :intel   and  a  network
> controller: realtek   ; neither of these  has the mac  address being
> complained about  by sys-whonix
>
> and I dont see any other VMs  using a network controller, including
> sys-whonix,  has no devices  in the settings
>
>
> the system has dual ethernet ports and wifi , i'm guessing that is why
> I had 2 ethernet controllers,
>
> this all seemed to work flawlessy, until  my  botched   Fedora 23 to
> Fedora 24 upgrade
>
> sigh
>
Maybe it's time to delete sys-net and create a new one from scratch.

And as for your Fedora 24 issues, it's sounding like your
/etc/yum.repos.d/qubes-r3.repo file is mis-configured. You should
manually verify/edit them to read something like

baseurl = http://yum.qubes-os.org/r3.2/current/vm/fc24

rather than rely on the sed method in the instructions.

Or if your templates are totally trashed to the point where they're not
worth salvaging, just download a Fedora 24 template directly:

sudo qubes-dom0-update --enablerepo=qubes-dom0-templates-itl
qubes-template-fedora-24

And restart setting up those templates from scratch.


-- 
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/og30bh%24qmk%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Help regarding installing CUBES

[Reg Tiangha]

On 05/23/2017 01:34 PM, Martin Bak wrote:
> On Tuesday, May 23, 2017 at 5:25:35 PM UTC+2, Reg Tiangha wrote:
>> On 05/23/2017 04:06 AM, Martin Bak wrote:
>>> I have a Dell XPS 9350 i7 U6500 laptop... I have bought a Sandisk Extreme 
>>> SDHC UHS-II PRO 32GB SD card (300MB/sec) and i have used Rufus to write the 
>>> CUBES OS ISO file to the SD card (in DD mode)...
>>>
>>> When i boot CUBES OS - the menu shows...but after i choose install/test and 
>>> install...it loads the first 3 lines - all with an added status of "OK"... 
>>> but afterwards... the screen is just black and stays black...and nothing 
>>> happens...
>>>
>>> So - im stucked :-( and don't know how to make it work?
>>>
>>> I really hope some of you guys can help me to solve this issue :-)
>>>
>>> Best regards,
>>> Martin
>>>
>> A long shot, but try to get into the advanced options of the bootloader
>> of the installer to edit the kernel options and add nomodeset and see if
>> that helps.
> Can you please elaborate exactly how to do this and what text/code to add?
>

I can't remember off the top of my head, but when the bootloader to the
installer pops up, you either hit e to edit it or there's a menu option
at the bottom of the screen.

But reading through your thread, it probably won't work; it's mostly
meant for video card issues, especially with Intel cards. Yours sounds
like an EFI issue, which nomodeset wouldn't do anything to fix. I've
seen others report the same sorts of issues, and I haven't seen a fix
for it yet, outside of an updated installer and/or kernel being included
in a new 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/og231v%24k5a%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 05/23/2017 01:16 PM, Foppe de Haan wrote:
> On Tuesday, May 23, 2017 at 6:40:47 PM UTC+2, Reg Tiangha wrote:
>> On 05/23/2017 10:37 AM, Foppe de Haan wrote:
>>> It failed to load that module on my PC. (That is, modprobe gave a 'not 
>>> found' error, and keyboard didn't work.)
>> Would you be willing to compile the version found here and help test to
>> see if it also occurs with this version of the tree:
>>
>> https://github.com/rtiangha/qubes-linux-kernel/tree/stable-4.9
>>
>> It's updated to 4.9.29 but I could use a sanity check for this issue
>> before I start digging deeper.
> That one works here
>
Thanks! I'll assume things are good then, at least when it comes to this.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/og22bm%24t8k%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 05/23/2017 10:37 AM, Foppe de Haan wrote:
> It failed to load that module on my PC. (That is, modprobe gave a 'not found' 
> error, and keyboard didn't work.)

Would you be willing to compile the version found here and help test to
see if it also occurs with this version of the tree:

https://github.com/rtiangha/qubes-linux-kernel/tree/stable-4.9

It's updated to 4.9.29 but I could use a sanity check for this issue
before I start digging deeper.


-- 
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/og1olq%245nn%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 05/23/2017 09:59 AM, Foppe de Haan wrote:
> mouse+kb connected through sys-usb, yes. I have a ps/2 keyboard for 
> 'emergencies', but since it's shit, I prefer not to use it. :)
> Anyway, have rebuilt my own kernel with the option Marek mentioned enabled, 
> and now it's working as intended.


That's good to know. So the 4.9.28 that's in current-testing then, does
that work properly too, or does it fail to load the uinput module?
Looking at the kernel .config file in the tree, CONFIG_UINPUT=m so that
module should be present. And module loading is enabled too, so there
shouldn't be any obvious reason why uinput wouldn't load. But there
might be some corner cases that I hadn't considered in my testing, so it
would be nice to iron those out if they're present before the 4.9 branch
gets pushed out to the masses.


-- 
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/og1mu7%24c2e%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Help regarding installing CUBES

[Reg Tiangha]

On 05/23/2017 04:06 AM, Martin Bak wrote:
> I have a Dell XPS 9350 i7 U6500 laptop... I have bought a Sandisk Extreme 
> SDHC UHS-II PRO 32GB SD card (300MB/sec) and i have used Rufus to write the 
> CUBES OS ISO file to the SD card (in DD mode)...
>
> When i boot CUBES OS - the menu shows...but after i choose install/test and 
> install...it loads the first 3 lines - all with an added status of "OK"... 
> but afterwards... the screen is just black and stays black...and nothing 
> happens...
>
> So - im stucked :-( and don't know how to make it work?
>
> I really hope some of you guys can help me to solve this issue :-)
>
> Best regards,
> Martin
>

A long shot, but try to get into the advanced options of the bootloader
of the installer to edit the kernel options and add nomodeset and see if
that helps.


-- 
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/og1k8r%241ku%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Request for feedback: 4.9 Kernel

[Reg Tiangha]

On 05/23/2017 04:41 AM, Foppe de Haan wrote:
> Done and did run into something somewhat important (usb keyboard/mouse 
> pass-through no longer functioning properly). I have the same issue with my 
> own kernel/vm-kernel builds, not yet figured out what's causing this.
>

Do you use a sys-usb and have your keyboard/mouse piped in through that,
or do you use the USB devices connected directly to dom0?

I have a sys-usb with a USB mouse on both my desktop and laptop, and it
works as expected. But I use a PS/2 keyboard on the desktop and whatever
the laptop uses for its keyboard and haven't tested much with a USB
keyboard. But I would assume that if the USB mouse works, the keyboard
will too. That said, I haven't tested at all with a USB set up that uses
dom0 directly, so maybe that's the difference?


-- 
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/og1j9h%24aa1%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to close the CVE-2015-0565 security gap for any RAM-type?

[Reg Tiangha]

On 05/21/2017 02:34 PM, xet7 wrote:
> Can anvil kernel module protections for rowhammer be added to Qubes?
>
> https://news.ycombinator.com/item?id=12822490
>
So I've skimmed through the whitepaper (https://iss.oy.ne.ro/ANVIL.pdf)
and because it says that it uses hardware performance counters to detect
rowhammer attacks, and while it probably works properly on a bare-metal
system, I can't tell if this is something that can only be used in dom0
or if it can actually be used in VMs as well (or if it'll work properly
at all in a Xen-based system).

But let's assume for a moment that it would work properly in Qubes. With
the Qubes security model, what are the most likely places to get hit by
a rowhammer attack that might benefit from something like Anvil? I would
assume sys-net is a prime candidate. Maybe even sys-firewall? But what
is the likelihood or in what circumstances would an AppVM behind a
sys-firewall be subjected to a rowhammer assault? Is this the sort of
thing an attacker would need remote access to in order to exploit? Or is
it something that can run on its own autonomously?

Clearly, I don't know much about how rowhammer would be used in a
real-world attack scenario, LOL.


-- 
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/oftiqa%243qk%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wifi not reconnecting after sleep

[Reg Tiangha]

On 05/21/2017 11:31 AM, Reg Tiangha wrote:
> Actually, I think I may have found another way to address this in the
> kernel (basically, disabling power management in the Intel wifi driver,
> since the general consensus is that it's still buggy and everyone on
> other distros with this problem have addressed it by blacklisting the
> module like in the link above).
>
> It'll be in my 4.9.29 pull request (still waiting for a bit more
> feedback on the 4.9 kernel in general in case there are other things I
> might be able to address, but if there's nothing else, I'll probably
> send that PR later today after I finish testing a few other things), but
> if you need an immediate fix, try the tip above or place
>
> iwlmvm iwlwifi
>
> in /rw/config/suspend-module-blacklist in your sys-net VM.
>
>
Well, I've just submitted the pull request. For those with Intel wifi
cards not coming up correctly after suspend/sleep, be on the lookout for
kernel 4.9.29 or higher some time in the future and see if that works
around the issue without having to blacklist any modules.


-- 
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/oftfve%24tgb%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wifi not reconnecting after sleep

[Reg Tiangha]

On 05/21/2017 07:19 AM, Reg Tiangha wrote:
> On 05/21/2017 07:00 AM, Reg Tiangha wrote:
>> On 05/21/2017 05:39 AM, Dominique St-Pierre Boucher wrote:
>>> Same Kernel!!! 4.9.28-16.pvops.qubes.x86_64
>>>
>>> Dominique
>> There is one thing I can think of trying that may help, but it would
>> require testing. Do you feel comfortable in compiling your own kernel?
>> If so, I can add the *possible* fix to one of my testing branches.
>> Otherwise, you'll have to wait until 4.9.29 makes it into a repository,
>> but I don't know how long that will take.
>>
>> Let me know.
>>
>>
> Or maybe you could try this and fix it yourself right away:
>
> https://elementaryos.stackexchange.com/questions/4623/no-wi-fi-after-sleep
>
> If it works, that'd be the better solution.
>
>
Actually, I think I may have found another way to address this in the
kernel (basically, disabling power management in the Intel wifi driver,
since the general consensus is that it's still buggy and everyone on
other distros with this problem have addressed it by blacklisting the
module like in the link above).

It'll be in my 4.9.29 pull request (still waiting for a bit more
feedback on the 4.9 kernel in general in case there are other things I
might be able to address, but if there's nothing else, I'll probably
send that PR later today after I finish testing a few other things), but
if you need an immediate fix, try the tip above or place

iwlmvm iwlwifi

in /rw/config/suspend-module-blacklist in your sys-net VM.


-- 
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/ofsisr%24blt%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

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

[Reg Tiangha]

On 05/20/2017 12:48 PM, Vít Šesták wrote:
> Few Qubes-unrelated notes:
>
> * It does not have numpad, even the Fn does not allow pressing numbers on 
> numpad. You have to rely on number row (or external keyboard).

Question:  Does this work on stock Fedora 25? I'm looking at the Qubes
kernel config and there are some numpad related drivers that are
disabled by default.

If it does work on Fedora 25 and you have the capability to jump back to
it, a list of running modules via lsmod might be useful. Otherwise, if
it does work, I could try to track down a copy of the stock FC25 kernel
config and see where the differences might be. Else, the difference
would lie somewhere in userland.


-- 
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/ofs7vm%24qdk%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wifi not reconnecting after sleep

[Reg Tiangha]

On 05/21/2017 07:00 AM, Reg Tiangha wrote:
> On 05/21/2017 05:39 AM, Dominique St-Pierre Boucher wrote:
>> Same Kernel!!! 4.9.28-16.pvops.qubes.x86_64
>>
>> Dominique
> There is one thing I can think of trying that may help, but it would
> require testing. Do you feel comfortable in compiling your own kernel?
> If so, I can add the *possible* fix to one of my testing branches.
> Otherwise, you'll have to wait until 4.9.29 makes it into a repository,
> but I don't know how long that will take.
>
> Let me know.
>
>

Or maybe you could try this and fix it yourself right away:

https://elementaryos.stackexchange.com/questions/4623/no-wi-fi-after-sleep

If it works, that'd be the better solution.


-- 
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/ofs459%246pd%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wireless Adapter Issues

[Reg Tiangha]

On 05/21/2017 06:30 AM,
steven.a.wal...@gmail.com wrote:
> Qubes is not detecting my network adapter. It is a panda wireless pau05. The 
> system is detecting it via lsusb, but it is not loading it into the system. 
> Does anyone know how I can fix this and get it running.


Do you have a sys-usb VM? In my head, either you make sys-net your USB
VM as well, or if your sys-usb is separate from sys-net, you use qvm-usb
-a to attach the Panda device to sys-net:

https://www.qubes-os.org/doc/usb/#attaching-a-single-usb-device-to-a-qube-usb-passthrough

Either that, or you attach the entire USB controller that your Panda
device is connected to to sys-net:

https://www.qubes-os.org/doc/assigning-devices/#finding-the-right-usb-controller

But I don't have much experience with USB network devices.

The module for the driver for that card is called rt2800usb and it is
enabled in both the 4.4 and 4.9 kernels. You can verify that it's loaded
by running lsmod.


-- 
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/ofs3ep%24t4j%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wifi not reconnecting after sleep

[Reg Tiangha]

On 05/21/2017 05:39 AM, Dominique St-Pierre Boucher wrote:
> Same Kernel!!! 4.9.28-16.pvops.qubes.x86_64
>
> Dominique

There is one thing I can think of trying that may help, but it would
require testing. Do you feel comfortable in compiling your own kernel?
If so, I can add the *possible* fix to one of my testing branches.
Otherwise, you'll have to wait until 4.9.29 makes it into a repository,
but I don't know how long that will take.

Let me know.


-- 
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/ofs312%24d21%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Suitability for an application testing scenario

[Reg Tiangha]

On 05/21/2017 02:22 AM, Vít Šesták wrote:
> Getting rid of seamless mode: HVM is one approach, loopback VNC or Xvfb is 
> another one.
>
> On pausing VMs: Actually, even if you just suspend and resume the whole 
> system, all VMs get unpaused.
>
> Xen actually has some restore capability, at least for PVs and maybe also for 
> HVMs. This one is actually used in today's DVM implementation (as of 3.2), 
> but it will AFAIK be handled differently in Qubes 4. The problem is it is 
> hard to make it working properly with template-based VMs without additional 
> restrictions and without counterintuitive impact on performance (like 
> hibernated VMs affecting TemplateVM performance). See 
> https://github.com/QubesOS/qubes-issues/issues/832#issuecomment-289100070 .
>
> So, if you want hibernation, you can use a standalone VM. Such VM can handle 
> everything on its own without involving Qubes (provided that the OS supports 
> hibernation). I am not sure if hibernation will work well with standalone PV, 
> but with standalone HVM, I see no reason why it should not work.
>
> Regards,
> Vít Šesták 'v6ak'
>

I'm curious:  Would hibernation work correctly if the VM were paused
first? I don't use suspend or hibernation myself, so I don't know the
answer to that.

Of course, in the current Qubes kernel configuration, Hibernation
support isn't even enabled in the kernel, so I suppose it's currently a
moot point.


-- 
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/ofrk1g%24oq6%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Suitability for an application testing scenario

[Reg Tiangha]

On 05/21/2017 12:02 AM, David Seaward wrote:
> Hi,
>
> Previously I've used type II VMs like VirtualBox for application
> testing: install application on the base OS, test features (including
> GUI features, shell integration and system integration), discard
> changes. Additional steps might include: pause/resume the VM, save
> different states of the VM.
>
> Are Qubes OS VMs suitable for the same purpose? Specifically, is it
> possible to switch from a dom0 view to a VM-only view, rather than VM
> windows appearing in dom0?
>
> Regards,
> David
>
> P.S. If this is possible, Qubes OS also seems like a more flexible
> alternative to dual-booting?
>

If you want to interact with the complete desktop environment for a
particular distro, you can install it in Qubes as a standalone HVM. Then
the environment would work just like a regular VirtualBox VM without the
Seamless Mode (so you could interact with stuff like its Application Menu).

You can use Qubes Manager to pause the VM, but it doesn't seem to stay
paused after a reboot (when the PC comes back up, the VM is essentially
powered off) so I'm not sure if that's totally useful or not. As far as
I know, Qubes/Xen doesn't have the concept of snapshots so restoring to
different states isn't possible. If I'm wrong, then I'm sure someone
will correct me.



-- 
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/ofrb06%24puh%243%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Desktop shell choices & integration on dom0

[Reg Tiangha]

On 05/20/2017 11:58 PM, Reg Tiangha wrote:
> On 05/20/2017 11:51 PM, David Seaward wrote:
>> Hi,
>>
>> Is it possible to change the desktop shell for dom0, for example from
>> XFCE to GNOME?
>>
>> Additionally, I'm used to getting some degree of application/shell
>> integration: notifications, tray icons, widgets (e.g. a controller for
>> the music app). Do VM apps integrate with the dom0 shell?
>>
>> Regards,
>> David
>>
> If you mean the terminal program, you could probably just install it:
>
> sudo qubes-dom0-update gnome-terminal
>
>
> As for AppVM notifications, if you're asking if tray icons appear in the
> notification bar or if app pop up messages appear, they usually do work.
> I don't know about desktop widgets, though; I'm thinking no.
>
>
Actually, if you're talking about changing the desktop environment (XFCE
to Gnome), then the answer is no. There was talk about porting it to
Gnome when they were thinking of switching from KDE, but I think that's
been put on the back burner now since XFCE works well enough. Although
if someone wanted to jump in and help out with the porting effort as a
developer, I'm sure they'd welcome patches.



-- 
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/ofraha%24puh%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Desktop shell choices & integration on dom0

[Reg Tiangha]

On 05/20/2017 11:51 PM, David Seaward wrote:
> Hi,
>
> Is it possible to change the desktop shell for dom0, for example from
> XFCE to GNOME?
>
> Additionally, I'm used to getting some degree of application/shell
> integration: notifications, tray icons, widgets (e.g. a controller for
> the music app). Do VM apps integrate with the dom0 shell?
>
> Regards,
> David
>

If you mean the terminal program, you could probably just install it:

sudo qubes-dom0-update gnome-terminal


As for AppVM notifications, if you're asking if tray icons appear in the
notification bar or if app pop up messages appear, they usually do work.
I don't know about desktop widgets, though; I'm thinking no.


-- 
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/ofraa1%24puh%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Why should I clone a template?

[Reg Tiangha]

On 05/20/2017 06:43 PM, Todd Lasman wrote:
> The dogma, as I understand it, is that it's safer to clone a template,
> make changes to the clone, then base your AppVM's off of that cloned
> template.
>
> - From the Qubes website:
> "It is highly recommended to clone the original template, and make any
> changes in the clone instead of the original template. The following
> command clones the template. Replace your-new-clone with your desired
> name..."
>
> My question is, why? It seems to me that if you ever needed the
> original template back, you could just download it again from the
> repository. Am I missing something?
>
> Todd


Not really. It's more of a convenience thing and/or advice for those who
have limited bandwidth or data caps on their internet connection. If you
don't mind re-downloading the original template (which might be 1GB+)
plus maybe hundreds of MBs worth of updates afterwards, then it's up to
you. Otherwise, it's more bandwidth efficient to keep the stock
templates up-to-date and clone them if you need to make more specialized
templates later on.


-- 
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/ofqo9i%249m2%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wifi not reconnecting after sleep

[Reg Tiangha]

On 05/20/2017 04:53 PM, Reg Tiangha wrote:
> On 05/20/2017 08:23 AM, Dominique St-Pierre Boucher wrote:
>> Hello Qubes users
>>
>> Everything was working fine until updates were installed a couples of week 
>> back. I was unable to get wifi access back after a sleep. My sys-net vm use 
>> a minimal debian stretch template and I never had a sleep issue before.
>>
>> I have included part of the syslog after the sleep. I you need more info, I 
>> still have the full syslog.
>>
>> Anyone have seen this before?
> What version of the kernel are you running?
>
> To find out, open up a terminal in dom0 and type in
>
> uname -r
>
>
And do it in sys-net as well, in case you're running different kernels
between the two for whatever 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 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/ofqhhl%241es%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Wifi not reconnecting after sleep

[Reg Tiangha]

On 05/20/2017 08:23 AM, Dominique St-Pierre Boucher wrote:
> Hello Qubes users
>
> Everything was working fine until updates were installed a couples of week 
> back. I was unable to get wifi access back after a sleep. My sys-net vm use a 
> minimal debian stretch template and I never had a sleep issue before.
>
> I have included part of the syslog after the sleep. I you need more info, I 
> still have the full syslog.
>
> Anyone have seen this before?

What version of the kernel are you running?

To find out, open up a terminal in dom0 and type in

uname -r


-- 
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/ofqhce%241es%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

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

[Reg Tiangha]

On 05/20/2017 01:51 PM, Vít Šesták wrote:
>> I am wondering if Haswell and newer is more tightly
>> bound to the Intel ME to the point where those machines actually need
>> the driver enabled to work correctly. I don't think that's the case, but
>> a sanity check would be useful.
> It it just about testing if everything works well, or should I try to look at 
> something specific?
>
> Regards,
> Vít Šesták 'v6ak'

Mostly right now, I'm concerned about regressions in hardware support;
the hardware I have access to test on is limited (Sandy Bridge,
Westmere, and a Core 2 Quad Q6600) so while things work fine for me
(I've actually moved on to 4.11 in dom0 now since the Hardened Kernel
Community Project is working hard to port grsecurity features to that
tree and have made patches available), I don't know if this kernel will
work fine for others as is.

In regards to the ME, in addition to Intel hardware support working
properly, I suppose I'm curious if the machine will run longer than 30
minutes without the ME driver (although maybe that's just a Windows
thing; I don't know).


-- 
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/ofq6vm%24p9i%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Request for feedback: 4.9 Kernel

[Reg Tiangha]

People may not have noticed, but there is now a 4.9 kernel in
current-testing (4.9.28 to be specific).

If the release schedule holds, then that should be migrated to stable
soon, however, before that happens, some feedback on that kernel would
be useful before it gets pushed to the majority of users.

Specifically, it'd be nice to know if:

1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.

2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.

3) If newer Intel platforms (i.e. Haswell or newer) works with this
kernel (I took out the Intel ME driver and the newest machine I have
access to is a Sandy Bridge machine; I have no issues, but I wonder if
Haswell or newer is tied more strongly to the Intel ME such that it
actually needs that driver in order t work properly). If there are Intel
hardware issues with this kernel, then I'll re-enable the driver in my
next Pull Request.

4) General feedback on the 4.9 kernel.

4.9.29 was just released today, so before I send in a Pull Request, let
me know how 4.9.28 performs and if changes to the kernel config may need
to be made.


-- 
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/ofq67a%24n56%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

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

[Reg Tiangha]

On 05/20/2017 12:48 PM, Vít Šesták wrote:
> Hello,
> I am sending the HCL report.
>
> I am not sure what model number to use, because the commonly used 15-5578 
> refers to various configuration. But when I use TN-5578-N2-711S, it seems to 
> refer to very specific piece of hardware (with different CPUs, HDDs/SSDs 
> etc.), the number may also include they key labels (Czech and Slovak in this 
> case), which is too specific for HCL. This one has 16GiB RAM, 512GiB SSD and 
> i7-7500U CPU.
>
> The hardware is quite a new for Qubes 3.2. For this reason, I had to use a 
> newer kernel. With the original one, I had issues with suspend (always froze) 
> and GPU support. With the new one (probably the same you can install from 
> unstable), it is much better. See 
> https://groups.google.com/forum/#!searchin/qubes-users/5578|sort:relevance/qubes-users/v6_B7FHnNUE/NR-yv6OHBQAJ
>  for more details. I hope this will require no tuning with Qubes 4.0.


There's a 4.9.28 kernel in dom0 current-testing now, perhaps that might
give you better hardware support?

https://ftp.qubes-os.org/repo/yum/r3.2/current-testing/dom0/fc23/rpm/kernel-4.9.28-16.pvops.qubes.x86_64.rpm

If you can give me the output of sensors-detect and lspci in dom0, I can
double check to see if there are drivers for that hardware in the 4.9
tree and then see if they're enabled in the 4.9 kernel .config. The 4.9
kernel config when it comes to hardware support is mostly just a
forward-ported 4.4 kernel config with a few additional tweaks for
security (mainly taken from the Kernel Self Protection Project's
recommended settings).

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

And I'd also be interested in general feedback for the 4.9 kernel; one
of the changes I made was to remove the Intel ME driver from it. The
latest machine I have access to is a Sandy Bridge machine, and while I
have no issues, I am wondering if Haswell and newer is more tightly
bound to the Intel ME to the point where those machines actually need
the driver enabled to work correctly. I don't think that's the case, but
a sanity check would be useful.


-- 
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/ofq3oh%24gro%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Swap space and reducing memory usage?

[Reg Tiangha]

On 05/20/2017 10:51 AM, Gaiko Kyofusho wrote:
> I have a 16gb mem system which can't be upgraded any further to my
> knwoledge. I had thought this would be enough but I am running into
> memory errors more often than I would like. I admittedly open maybe
> 7-12 appvms so the obvious answer to my prob might be open less appvms
> but for my workflow that would be inconvient. I do not remember
> setting up a swap space during setup but I think it was set up
> automatically though in the dom0 system monitor plugin the swap space
> monitor never seems to move (stays at zero). 
>
> My questions are two fold I guess:
>
>  1. Are there any recomended ways for reducing memory usage?
>  2. How can I tell if swap is being used?
>  3. If swap is not being used how can I enable it?
>
I only have 8 GB of RAM and it can handle about 7-12 VMs, depending on
what I'm doing. But I tweaked my VM memory settings; leaving it to the
defaults makes it hard to run more than 4-5 VMs at the same time since
new ones won't start up because of a lack of RAM.

The first thing you can do is reduce the max amount of memory the AppVMs
use. By default, they're set to use between 400-4000 MB of RAM, but if
you look at your actual VM RAM usage in a terminal window by using the
top or free commands, you may find that your actual usage is a lot less
and can reduce that upper limit to something like 2000 MB or less. That
includes your service VMs like your firewall; you can probably reduce
the upper limit on sys-firewall to 300-400 MB rather than the 4000 MB
it's set to by default.

Or if you don't go crazy with various iptables firewall rules, you can
run the qubes-mirage-firewall from here as a replacement to sys-firewall:

https://github.com/talex5/qubes-mirage-firewall

I have mine running with only 32MB of RAM and things work fine (there's
a hack you may need to do to get DispVMs to connect to the internet
properly though, but regular VMs work fine with it).

Next thing to look at is the RAM allocated to dom0. By default, the
upper limit is 4096 MB but I reduced mine to 2048 MB and haven't
encountered any noticeable issues. In order to change it though, you
have to edit your GRUB config files and then reboot.

Edit /etc/default/grub in dom0 and change the dom0_mem=min and
dom0_mem=max values to match your needs. I set mine to 1024 and 2048
respectively, but you might be able to go even lower (say 512 and 1536
or something like that). Then, you'd need to regenerate
/boot/grub2/grub.cfg to get it to work permanently. I don't remember the
command off the top of my head, but you alternatively, you can edit that
file directly making the changes to all references of dom0 max and min
memory like you did with the previous file, save it, and it'll still
work once you reboot.

If you make those changes, that should help. There's no magic bullet as
to what to set those max memory settings to since it really depends on
how you use your VMs, so you may have to do a bit of profiling first to
figure out what your optimal max RAM values are for each case.


-- 
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/ofpt90%24njc%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel AMT Vulnerability CVE-2017-5689

[Reg Tiangha]

On 2017-05-11 10:57 AM, Dimitri wrote:
> The 'Intel Management Engine' is something like God on your CPU. 
> Unfortunately its creators were quite human. This manifests in imperfections, 
> also known as bugs. CVE-2017-5689 is one of those 
> (https://www.ssh.com/vulnerability/intel-amt/). Successfully exploiting a bug 
> in the ME will make an attacker very happy as this could get him complete 
> control over the unlucky machine. If the bug additionally is exploitable 
> remotely we have  heaven  on earth. At least for attackers. For all others 
> this smells like hell.
> 
> This is probably not too surprising for Qubes people. The ME has been known 
> to be a security problem before.
> 
> I have no insight in the named vulnerability nor in the technicalities of the 
> ME. So I'm wondering how this affects Qubes.
> - Can it be exploited from remote if the right (or wrong) network/wireless 
> card is used? Yes, NICs are attached to sys-net, but does that really help in 
> this case?
> - Can it be exploited locally from a VM?
> - One way to fix this particular problem is to update the firmware. (If 
> you're lucky enough to get an update for your computer). Is there an other 
> way? Maybe isolating the ME from all PCI devices? My guess is: No. Please 
> show me that I'm wrong...
> 
> Another point that makes me wonder but might be out of topic for this group:
> Intel released the vulnerability. Why? Because it has been leaked. I'm  sure  
> Intel did not know anything about this before. You?
> 
> Thanks for sharing thoughts!
> 


My understanding is that the ME intercepts packets before it gets to the
OS layer, so attaching a built-in Intel NIC to sys-net has absolutely no
effect on mitigating stuff coming in that way because the OS wouldn't
even get to see the malicious packets so you couldn't use iptables to
filter them out. For this particular exploit, if you're unable to update
the ME firmware, either you have some kind of external hardware firewall
blocking traffic to and from the ports in question, or use something
like a USB NIC that isn't tied to the ME. But that wouldn't necessarily
guard against any other undisclosed exploits that might still be lurking
in the ME.

As for how an attacker can leverage this exploit on Qubes locally, I'm
not sure. I'm sure other people who are smarter than me have figured out
some possibilities, though.

As for the rest of your questions about they 'whys,' well, your guess is
as good as anyone else's.

-- 
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/of27hr%246b1%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [3.2] Issues with Intel® HD Graphics 620 after update of clean installation

[Reg Tiangha]

On 2017-05-04 10:17 PM, Vít Šesták wrote:
> I can try updating everything to current-testing, but I doubt it helps. 
> Specifically, the issue occurs even in lightdm and dom0 windows, so we can't 
> blame GUID which is not even running.
> 
> On premilinary HW support: It is actually there by default. I've tried to 
> remove it temporarily, but it did not change anything.
> 
> I also don't insist on HW acceleration, as it has proven to be unneeded 
> there. My issue seems to be conjunction of two issues, where solving any of 
> them solves my issue:
> 
> * Some generic GPU drivers are used instead of i915.
> * Rendering X11 output this way is slow.
> 
> I can also try installing X11 from F24 or F25 repositories. I know, this can 
> break it totally, but it might be worth trying. The idea is to try  recent 
> (?) kernel from Qubes with recent X11 from newer Fedora.
> 
> Regards,
> Vít Šesták 'v6ak'
> 

Well, maybe just update dom0 to current-testing then and as a sanity
check, one or two of your templates; maybe it really is qubes-gui-agent
that needs to be fixed as two new xserver dummy drivers were introduced
with the latest rounds of stable updates and the issues only showed up
in templates using X versions older than the one found in FC25. You'll
also get the latest version of Xen that's been patched to fix the latest
XSAs so it's probably worth doing.

But yeah, I can't figure out what else might have changed. Nothing
really changed with respect to the kernel config options between 4.4.15
and 4.4.55, and I'm doubtful the kernel code base changed that much too
so I'm really leaning towards something on the Qubes platform end.

-- 
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/oegveh%24k63%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [3.2] Issues with Intel® HD Graphics 620 after update of clean installation

[Reg Tiangha]

On 2017-05-04 3:28 PM, Vít Šesták wrote:
> Well, found that. I can edit /boot/efi/EFI/qubes/xen.cfg. It does not look 
> like there is something like Grub menu, though.
> 
> * Downgrade to the previous kernel version fixes the issue, but in a quite 
> different way I thought: All symptoms (missing /dev/dri, error messages in 
> Xorg.0.log) except lags remain. So, it seems that the no Qubes kernel 
> supports HD620, but the old one doesn't suck at nonaccelerated video.
> * Upgrade to the new kernel does not change anything. Maybe it is slightly 
> less laggy, maybe not.
> 
> Staying with older kernel might be a temporary workaround, but only if it 
> does not open any relevant vulnerability (dom0 has a pretty small attack 
> surface, so it might be the case) and if it is likely that this issue will be 
> somehow fixed in 4.0.
> 
> By the way, how is hardware support determined? I know that dom0 for Q3.2 is 
> based on Fedora 23, but it has a kernel compiled by ITL. I am unsure which 
> one of those facts have bigger influence on HW compatibility. If the 
> compatibility is derived from F23, it is rather clear that KabyLakes will not 
> be supported well there.
> 
> Regards,
> Vít Šesták 'v6ak'
> 
> Regards,
> Vít Šesták 'v6ak'
> 

The only things I can think of are these:

- Upgrade everything to current-testing. There is an updated
qubes-gui-agent package that might help with window performance issues.
- On the newer kernel, set this option in the boot menu next to all of
the other kernel options:  i915.preliminary_hw_support=1

You might be encountering something similar to this:

https://www.phoronix.com/scan.php?page=news_item=intel-skl-prelim-support

-- 
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/oeggve%24lqp%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [3.2] Issues with Intel® HD Graphics 620 after update of clean installation

[Reg Tiangha]

On 2017-05-04 11:16 AM, Vít Šesták wrote:

> My other idea was to boot Qubes with the old kernel. But I don't know how to 
> do it with UEFI boot. With Legacy boot, there is a Grub menu where I can 
> choose an old kernel, edit kernel cmdline etc. With UEFI boot, I can see 
> nothing like it. Just when I press F12 in early boot stage, I can select what 
> to boot, but I can select just Qubes here, without any options.
> 
> What to do now?
> 
> Configuration:
> 
> * Dell Inspiron 15Z Touch 5578
> * Intel i7-7500U CPU
> * No dedicated GPU (I hoped to have less issues when I have just the 
> integrated one…)
> * UEFI boot.
> 
> Regards,
> Vít Šesták 'v6ak'
> 

Wish I could help. I don't know how to alter the UEFI boot menu, but
maybe try installing the 4.4.62 kernel in current-testing and see if
that fixes your issue? It could be a bug in the 4.4.55 kernel that was
pushed onto your system.

Either that, or rather than trying to change kernels at the bootloader
level, while you're logged in, figure out where the UEFI bootloader
keeps its config file and edit it (back it up first, though) to try and
boot the older kernel.

-- 
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/oefsg6%2497n%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Slimming Down the dom0 Kernel

[Reg Tiangha]

On 05/02/2017 02:27 PM, cooloutac wrote:
> I never even looked a a cryptography section man tyvm!  yes would be very 
> awesome to know which ones to disable. very interesting. and what hardware 
> etc of course,  and we can then just copy our config over when building the 
> next one.  I think that is always the part that kills people but 20-40 mins 
> aint bad.  
>
> I wouldn't mind compiling a kernel myself with good instructions.  I'm just 
> weary because I have tried in debian template and can't get the gui.  It goes 
> green and then to yellow on boot, can connect from terminal to it. I probably 
> didn't do it the Qubes way properly.  I think because of a missing module 
> Marmarek said once so I tried to modprobe it not sure which one or how.  
>
> But ya if some expert can make a guide to compile kernel that would be 
> awesome.
>
> and thats right doh we do it all in a vm on Qubes!

Exactly! All of this research to find a generic, slimmed down kernel
configuration (for dom0 and/or maybe for VMs too) that can run on a
variety of Qubes machines would only need to be done once. Once done, it
could just be reused for every kernel update in that branch, and would
only need to be revisited whenever there's a major kernel update to
figure out which new features to integrate or reject. And ditto for a
personal kernel too that's tailored only to your hardware. That's how I
do it for my machines.

It's worthwhile doing, regardless, if only to save on disk space and
maybe RAM (I still can't believe I cut my personal kernel down to 1/4
the size of the stock kernel). I am interested in the Cryptography
stuff, though, because by default, *all* of the ciphers are enabled, and
I wonder if it's possible if an attacker could somehow downgrade the
encryption cipher in a VM or dom0 used by various operations to make
things easier to exploit, in which case, you could mitigate some of that
at the kernel level by taking out the weaker ciphers or those that Qubes
doesn't explicitly use. I don't know if that's a valid attack vector,
but if I thought of it, maybe someone smarter than me has too, and also
knows how to pull it off.


-- 
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/oeaqjg%24l1a%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Slimming Down the dom0 Kernel

[Reg Tiangha]

On 05/02/2017 01:40 PM, cooloutac wrote:
> you lost me SCSI subsystem, you mean like firmware drivers?  and 
> cryptopgraphy system?  no idea.  but sounds very interesting, I appreciate 
> your time.
>
> Also if I install all that stuff in my system. Shouldn't I then make sure to 
> uninstall it all, or at least disable all those compilers I installed for 
> security reasons?  We might need a guide on how to do that too.

In the kernel options menu, there are various sections that you can configure. 
Things like Processor Type & Features, Device Drivers, Networking Support, 
Cryptography, etc. The SCSI stuff lives in the Device Drivers section (along 
with other things like PCI and USB support), while the Cryptography section 
lists all of the ciphers that the kernel supports. You could probably slim down 
the Cryptography section by taking out either ciphers that may be dangerous to 
continue using because they've been proven to be ineffective, or at the very 
least, take out ciphers that QubesOS doesn't use in dom0. Problem is, I just 
don't know what Qubes uses.

As for installing stuff to compile a kernel, that's why you do the kernel 
compilation in a Template VM, ideally one that matches the distro that's being 
used in dom0. That way, all the dependencies are installed in there and all you 
need to do is copy out the generated rpms into dom0 from the TemplateVM and 
just install those.


-- 
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/74c269f7-d209-d971-5883-2823712a2997%40reginaldtiangha.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/02/2017 01:36 PM, cooloutac wrote:
> What do you mean by pocket router?  Is this like a cheap little router to 
> dongle off your pc?  it seems interesting because I definitely can't trust my 
> home router at all...
>

I mean something like this:

https://www.asus.com/ca-en/Networking/WL330gE/

It's the model I have, but it's old and no longer supported by Asus.
There used to be OpenWRT support for it, but no longer because of the
low RAM size. There is a newer model:

https://www.asus.com/ca-en/Networking/WL330NUL/

but I don't know much about it or if it's supported by open-source
firmware. But maybe devices like these could help guard against similar
exploits to the one being discussed in this thread, assuming the router
firmware can be protected too. But then again, who knows what other
holes the ME stuff may have? Something like this could be as futile as
trying to plug one hole of many in a sponge.


-- 
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/oeao2j%2417m%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Slimming Down the dom0 Kernel

[Reg Tiangha]

On 05/02/2017 12:41 PM, cooloutac wrote:
> I too would have trouble compiling kernel for fedora too.I only know how 
> to do it with debian using make-kpkg which is much easier.
>
The Qubes kernel build scripts actually make it very easy; assuming you
have all the software dependencies installed, you just need to run 'make
rpms.' The tricky part is the qubes-kernel-vm-support package has yet to
make it down to fc23 stable yet, so there's still some manual
configuration that needs to be done to get 4.9+ to compile on that
template. Hopefully, that'll fix itself within a week or whenever the
next batch of current-testing stuff migrates over to stable and things
will just work out-of-the-box. Of course, you can grab it yourself by
temporarily enabling the current-testing repo on an fc23 build template.

But my hope is to have that nicely-formatted kernel compile write-up
done by the end of this week; I'm not sure how much free time I'll have
past this week leading into July to work on this stuff so my hope is
that more people will feel empowered to compile their own kernels and to
share their results to see if everyone can find more kernel config
options that can be trimmed out while still having the kernel work on a
variety of hardware. For me, each compile-install-test cycle takes about
20-40 minutes on the laptop I use to test (longer if I actually compile
the kernel on it; my desktop is way faster), so there's diminishing
returns on my end in regards to time spent in trying to finesse more
options to disable by testing them out one-at-a-time. But if everyone
were to do a little bit on their own and compare their results, then
maybe things would move a bit faster. Personally, I'd like to know how
much of the SCSI subsystem or deprecated ciphers in the Cryptography
system could be cut out and still have things work, but again, I don't
have much more free time to work on this stuff.


-- 
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/oeakv5%24b9b%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/02/2017 11:37 AM, David Hobach wrote:
>
>
> On 05/02/2017 07:25 AM, Vít Šesták wrote:
>> * I wonder what does “exploitable locally” mean. If physical access
>> is required, I am not sure what would attacker gain (AEM bypass at
>> most, I guess). If it allows unprivileged user to elevate privileges,
>> this might be interesting for Qubes, depending on the attack vector:
>> If it requires attack over network interface, then sys-net can
>> perform it.
>
> @remotely:
> sys-net probably does not protect you here as Intel AMT (ME) runs even
> on top of the OS (Xen/Qubes). So it just captures all Intel management
> traffic directly in cooperation with your Intel chipset ethernet card
> and forwards it to the ME chipset - it never goes the regular way [3];
> admittedly, it depends on Intel's implementation of VT-d. I guess they
> ignored Vt-d for ME though... ah yes, they likely did: "ME’s desire
> for accessing the host memory cannot be constrained in any way, on the
> other hand, not even by VT-d." [1]
>
> @locally: Not sure whether sys-net helps with AMT enabled. After all
> an attacker might be able to route packets to your sys-net VM (-->
> =remotely)?
> The local forwarding service from [2] is probably not enabled in your
> sys-net though, so that's a plus.
>
> Maybe we'll see a QSB sooner or later... Just my 5 cents.
>
> [1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
> [2]
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075
> [3] https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/
>

Local access issues aside for a moment, it sounds like if you can
externally block the affected network ports, then you can also mitigate
this that way. That could be done on the router level, but may not stop
someone on the same subnet as you from getting at your machine that way
(nor if your router is compromised).

Someone here suggested an Ethernet condom, and I actually think there
might be some merit to it. Maybe this is where those pocket routers
(ideally with upgradable open-source firmware) with both wifi and
ethernet ports can come in. A private, external firewall that connects
to the network, rather than your machine doing so directly, with rules
to block those ME management ports and other high-risk ports just for
your machine. It's sad that we may be at that point, however, where we
need to seriously consider external hardware blockers for all sorts of
ports like USB, HDMI, etc, just to protect our devices.


-- 
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/oeakct%243sv%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Slimming Down the dom0 Kernel

[Reg Tiangha]

On 05/02/2017 12:57 AM, Eva Star wrote:
> All of this sounds very good. But most of us not so advanced unix
> users to compile kernel and install it. Maybe, somebody (as I) can
> try, but there is no readme on your repository how to do this and
> install it :)
>
> p.s. Maybe you forget about table(wacom) on you description and remove
> it? Currently, usb-vm does not support tablets. (Not a big problem)
>
The reason why that repository has no readme is because the Qubes master
repository has no readme. You do make a good point though:  All Qubes
packages should have some kind of write up on how to compile them. You
can kind of infer how to do it by reading through the Makefiles, but
still, it'd definitely be easier for anyone wanting to jump in to simply
test them, if not develop for them, if easier instructions were
available on how to compile them and what the software dependencies for
that repository are.

I did post some compile instructions in this thread here:

https://groups.google.com/d/msg/qubes-users/yBeUJPwKwHM/CFLgGsyKBAAJ

However, writing up a finalized and nicely formatted version for the
Qubes website is next on my TO-DO list.

As for things like Wacom tablets, I didn't mention it in my message in
this thread, but it, along with all other input devices supported in the
kernel, is still enabled in the current set of kernel options for this
version of the dom0 kernel. But if you were compiling this for yourself
and you don't use such devices, that's another category of kernel config
options that you could disable.

I've done some further refinement on my personal kernel, and it only
takes up around 50MB of disk space, down from about 200MB with the stock
kernel. And I still think it could be reduced even more. So the one
currently found in the repository definitely can still be cut down as
well, and there are probably some obscure kernel options that aren't
applicable to a dom0 kernel that I've missed.

You could probably go even further with a VM kernel. I simply no longer
have the time to test right now (and probably won't for a few months),
but some light testing on my end shows you can remove things such as
S/ATA support and native GPU drivers, simply because those aren't
normally needed in a VM environment (at long as you're not doing GPU
passthrough, although I don't know if that works with the open source
graphics drivers to begin with). A stripped down VM kernel would also
make for an interesting research project too.


-- 
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/oe9ijp%242ae%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/01/2017 11:25 PM, Vít Šesták wrote:
> Some notes:
>
> * Applying the patch probably requires BIOS update (and MoBo vendor releasing 
> the update), I guess.
> * I wonder what is the technical distinction between home and SMB/Enterprise. 
> Is it vPro?
> * I am not sure how can I check the version. There are some ME/AMT-related 
> Linux tools, but I have found rather tools for remote management than tools 
> for accessing AMT on local machine.
> * I wonder what does “exploitable locally” mean. If physical access is 
> required, I am not sure what would attacker gain (AEM bypass at most, I 
> guess). If it allows unprivileged user to elevate privileges, this might be 
> interesting for Qubes, depending on the attack vector: If it requires attack 
> over network interface, then sys-net can perform it. If it involves ME 
> software for the OS (maybe for accessing the MEI PCI device), we should be 
> adequately isolated on Qubes. I hope that Qubes adds some protection in any 
> case and it is not exploitable from other VMs than sys-net.
> * There seems to be some MEI PCI device (see lspci | grep -i mei) in dom0 and 
> /dev/mei0. I am not sure how all the parts (network stack, MEI PCI device, 
> MEI software for OS and management while offline) are connected together.. I 
> am also unsure if having it in dom0 is good (i.e., it prevents passing 
> malicious inputs to it) or bad (i.e., it adds attack surface). The safest 
> approach seems to be attaching it to /dev/null with IOMMU (VT-d) isolation. 
> Just crerating an autostarted (and maybe also autoshutdown) 
> network-disconnected dummy VM with all ME-related PCI devices should do the 
> trick. The VM would be trusted not to pass any malicious input to MEI, but it 
> would not be trusted for anything else (so that it could absorb attack from 
> MEI). I am unsure if this adds some actual protection or if it is totally 
> hopeless.
>
> Regards,
> Vít Šesták 'v6ak'
>

Not necessarily. Intel does provide flashing utilities along with the ME
firmware updates, but it's up to your OEM to release them to you. Or for
you to procure them from somewhere else.

As for checking versions, it's all tied to the firmware and not the
utilities. You can probably tell which one you have through your BIOS
menu; it should display it. Some other tips here:

http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html#msg10193


-- 
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/oe98oh%24t1a%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/01/2017 02:48 PM, 'Lolint' via qubes-users wrote:
> Confirmation by Shintel:
> https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide%20-%20Rev%201.1.pdf
>
> -- 
> 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/tSXLoJvyyEDdBtL6zdZ4leYPp6Ar5jEpbkx4pO2jFfQlzozE5zfWdPjQ6-aCESh9zDb0pq_C9lBV5LIf_gwds80eRVcRcs2Jvu_AfNjXnG0%3D%40protonmail.com
> .
> For more options, visit https://groups.google.com/d/optout.


Well, they say that "this vulnerability does not exist on Intel-based
consumer PCs" and just in their small business versions, but who knows
if that's really the case?

That said, the firmware on most consumer platforms is about 1.5MB while
the small business stuff is 5MB so maybe this particular exploit only
exists somewhere in that extra 3.5MB worth of crap. But again, who knows?

The actual advisory lists which firmware versions are affected. For
those who want to attempt to flash their ME chip to patch against this,
any official "fixed" firmware's last four digits will start with a '3.'

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075=en-fr


-- 
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/oe88vl%24htk%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/01/2017 12:19 PM, Reg Tiangha wrote:
> On 05/01/2017 12:04 PM, cooloutac wrote:
>> On Monday, May 1, 2017 at 1:26:52 PM UTC-4, Vít Šesták wrote:
>>> AFAIU, if https://ark.intel.com/ shows “Intel® vPro™ Technology: no”, then 
>>> the particular CPU is safe. But I am not 100% confident in vPro and related 
>>> technologies, so I might be wrong. Can someone confirm/deny this claim?
>>>
>>> Regards,
>>> Vít Šesták 'v6ak'
>> I think its more about the management engine on the intel chipsets.  They 
>> say every board after 2008 is affected, even if you don't have amt it can be 
>> exploited locally? does that mean from the host os or with physical access 
>> to the board?Sounds scary regardless.
>>
>> And so we have to hope we get a bios patch or something?  Is someone going 
>> to keep tabs on what boards are getting patched so we can go buy them? lol.
>>
>> Its funny but after the recent dom0 update I told my family we have to buy 
>> new pc hardware and they think I'm completely nuts.  And ironically, or 
>> maybe not, my bank card was just hacked over the weekend.  I'm praying it 
>> was got from the only online vendor I ever used it once at a month or two 
>> ago, or the processing company and not my system.  But it sure is a crazy 
>> coincidence...
>>
>> I wonder are boards that check for bios updates themselves even safe, Can 
>> someone intercept with malicious update? 
>>
> It's up to you whether or not you trust this archive or not, but there
> is an archive of various ME firmware being kept here:
>
> http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html
>
> and a more comprehensive archive here:
>
> http://www.win-raid.com/t832f39-Intel-Engine-Firmware-Repositories.html
>
> You might be able to update your Intel ME firmware using one of the
> files found there. But you'd probably want to wait until a firmware with
> at least an April 2017 release date or newer is available; not all of
> them have one yet (certainly not for any of the machines that I run).
>
>

Also, rather than doing a dump of your ME firmware and then running
Intel ME Cleaner on it, I think you can download one of the full
firmware images from the second link that's applicable for your machine,
run Intel ME Cleaner on it, and then flash that using an external
programmer. That said, I don't have the external hardware to do it, so I
haven't done it myself, nor do I know if that would actually work.  All
Intel ME Cleaner tutorials that I've seen do it by dumping the ME
firmware from the chip first.



-- 
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/oe7uej%24b4a%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/01/2017 12:04 PM, cooloutac wrote:
> On Monday, May 1, 2017 at 1:26:52 PM UTC-4, Vít Šesták wrote:
>> AFAIU, if https://ark.intel.com/ shows “Intel® vPro™ Technology: no”, then 
>> the particular CPU is safe. But I am not 100% confident in vPro and related 
>> technologies, so I might be wrong. Can someone confirm/deny this claim?
>>
>> Regards,
>> Vít Šesták 'v6ak'
> I think its more about the management engine on the intel chipsets.  They say 
> every board after 2008 is affected, even if you don't have amt it can be 
> exploited locally? does that mean from the host os or with physical access to 
> the board?Sounds scary regardless.
>
> And so we have to hope we get a bios patch or something?  Is someone going to 
> keep tabs on what boards are getting patched so we can go buy them? lol.
>
> Its funny but after the recent dom0 update I told my family we have to buy 
> new pc hardware and they think I'm completely nuts.  And ironically, or maybe 
> not, my bank card was just hacked over the weekend.  I'm praying it was got 
> from the only online vendor I ever used it once at a month or two ago, or the 
> processing company and not my system.  But it sure is a crazy coincidence...
>
> I wonder are boards that check for bios updates themselves even safe, Can 
> someone intercept with malicious update? 
>

It's up to you whether or not you trust this archive or not, but there
is an archive of various ME firmware being kept here:

http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html

and a more comprehensive archive here:

http://www.win-raid.com/t832f39-Intel-Engine-Firmware-Repositories.html

You might be able to update your Intel ME firmware using one of the
files found there. But you'd probably want to wait until a firmware with
at least an April 2017 release date or newer is available; not all of
them have one yet (certainly not for any of the machines that I run).


-- 
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/oe7u8b%24s5m%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/01/2017 11:14 AM, Reg Tiangha wrote:
> On 05/01/2017 10:38 AM, Jean-Philippe Ouellet wrote:
>> *Sigh*... Yep. We were right to be concerned (of course). And now we
>> have something other than our tin foil hats to point at too:
>>
>> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>>
>> I want my RISC-V laptop already!
>>
> I don't know if it helps things, but I recently disabled the
> CONFIG_INTEL_MEI, CONFIG_INTEL_MEI_ME, and CONFIG_INTEL_MEI_TXE kernel
> options in my kernel branches as soon as I was made aware of their
> existence. My hope is that the ME hardware can't be exploited using
> those methods if they don't exist in the kernel in the first place; that
> someone would have to find another way. But again, I have no idea if
> that's useful or not. For what it's worth, my systems still boot and run
> properly, but the newest machine I have access to is of the Sandy Bridge
> era; I have no idea if newer machines actually need those options baked
> into the kernel in order to run. Can anyone advise?
>
> https://github.com/rtiangha/qubes-linux-kernel
>
> Also, if anyone has any other ideas on kernel options to disable for
> various security concerns (ME related or not), let me know. For the
> moment, I've implemented almost all of the KSPP's recommended settings
> that are applicable to a certain kernel branch, except for the ones
> about loadable modules since I don't know how it affect u2mfn or any
> other user-compiled kernel modules a Qubes user may want to install. I
> haven't encountered any issues on my machines (or at least, any that
> I've noticed), but those could use more testing as well:
>
> https://github.com/rtiangha/qubes-linux-kernel
>
>
>
Ugh, forgot to hit CTRL-SHIFT-V, ha!

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project



-- 
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/oe7qfr%24dro%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Intel ME exploitable

[Reg Tiangha]

On 05/01/2017 10:38 AM, Jean-Philippe Ouellet wrote:
> *Sigh*... Yep. We were right to be concerned (of course). And now we
> have something other than our tin foil hats to point at too:
>
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>
> I want my RISC-V laptop already!
>

I don't know if it helps things, but I recently disabled the
CONFIG_INTEL_MEI, CONFIG_INTEL_MEI_ME, and CONFIG_INTEL_MEI_TXE kernel
options in my kernel branches as soon as I was made aware of their
existence. My hope is that the ME hardware can't be exploited using
those methods if they don't exist in the kernel in the first place; that
someone would have to find another way. But again, I have no idea if
that's useful or not. For what it's worth, my systems still boot and run
properly, but the newest machine I have access to is of the Sandy Bridge
era; I have no idea if newer machines actually need those options baked
into the kernel in order to run. Can anyone advise?

https://github.com/rtiangha/qubes-linux-kernel

Also, if anyone has any other ideas on kernel options to disable for
various security concerns (ME related or not), let me know. For the
moment, I've implemented almost all of the KSPP's recommended settings
that are applicable to a certain kernel branch, except for the ones
about loadable modules since I don't know how it affect u2mfn or any
other user-compiled kernel modules a Qubes user may want to install. I
haven't encountered any issues on my machines (or at least, any that
I've noticed), but those could use more testing as well:

https://github.com/rtiangha/qubes-linux-kernel



-- 
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/oe7qck%24dro%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Slimming Down the dom0 Kernel

[Reg Tiangha]

OK, so I think I've taken this personal project of mine to see how much
I could trim down the dom0 kernel as far as I can on my own (or rather,
I've found a set of settings that work for the hardware I own, but I'm
not sure how it'll perform on other people's hardware) so I'm ready to
share the results of my work.

This is what I've managed to slim down/disable and still have a working
dom0:

- Disabled the vast majority of options under "Networking Support"
including Bluetooth (I had to leave TCP/IP support enabled as libvirt
needs it to create sockets; because of that, I left SYN cookie and
Security Marking enabled in case it uses it, but if it doesn't, those
two options could also be disabled and things would still work).
- All hardware networking driver support (including Wireless); dom0
shouldn't have access to the network because it's all done through a
NetVM; hence that driver support no longer needs to be in dom0.
- Various hardware drivers (Legacy stuff like PCMCIA, ISDN, Floppy
Disks, plus Dallas 1-wire support (was on the fence on that one), stuff
regarding fibre channel support and other things that Qubes would be
unlikely to run on, although it's theoretically possible that it could be).
- Slimmed down on some of the Security options, taking out Apparmor (it
never worked in Fedora dom0 anyways) and SELinux support (if you really
use it in dom0, you could compile it back in yourself).
- Implemented most of the KSPP's recommended options here:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

All-in-all, around 3,000 various kernel options were disabled, although
you could theoretically take that further by stripping out support for
hardware you don't use, and I'd love to do the same sorts of things to
some of the other sections like Cryptographic Support.

That said, the hardware support was something I struggled with. The
Networking stuff was easy; that's all handled by a NetVM so it could all
go. And if you have a USBVM, then it's easy:  Disable all USB hardware
support except keyboard, mouse and touchscreen. However, for the moment,
there's no guarantee that every Qubes OS user runs a sys-usb VM (for
various reasons, many probably valid) so I left all of that support in.
On my personal kernel, however, I did disable all of that and leave it
to a sys-usb VM to sort out, but my USB hardware needs are minimal;
yours may not be. And ditto if you use the PCI pass-through functionality.

And there's also a near-infinite variety of hardware configurations out
there that Qubes could theoretically run on too, some of them really
obscure, so it was difficult for me to figure out what to cut and what
to keep/add in.

So this is where the Qubes community can help. I've posted my slim
kernel branch, based on 4.9 here:

https://github.com/rtiangha/qubes-linux-kernel/tree/devel-4.9-slim

And a somewhat stock 4.9 kernel branch here:

https://github.com/rtiangha/qubes-linux-kernel/tree/stable-4.9

And I'd like people to try both and offer some feedback on it. Is there
stuff that used to work on the full 4.9 kernel or older kernels that
doesn't work with the slim version? If so, let me know what it is and
I'll add that support back in.

Do people run Qubes on obscure hardware or unique/different hardware
combinations that no longer works on the slim kernel (ex. does anyone
really use ATA over Ethernet?)?  Or something related to PCI
pass-through that no longer works?  If so, again, let me know so I can
figure out what hardware support to re-enable.

And of course, you can go much further if you're willing to customize
your own kernel, either taking out support for hardware you don't
have/will never use, or adding in anything that's missing yourself. If
you choose to go that route, please share your results.

I don't have access to detailed stats or how RAM usage is affected, but
anecdotally, a kernel with the stock configuration took up around 200MB
of disk space, and my personal slim kernel takes up about 95MB. I assume
there's a RAM savings as well, but I've never measured, nor have I
measured how performance is impacted (although maybe that's where
something like the Phoronix Test Suite could come in once things settle
down a bit more).

To test, all you need to install is the kernel package that gets
generated once you've compiled it and reboot into it. You could also
install the kernel-qubes-vm version and use that in a VM; I haven't
tested it thoroughly but there may be a RAM savings. I'd recommend using
it in a non-networked VM though; it'll still connect to the Internet
thanks to TCP/IP support still being included, however, I stripped out
stuff like Netfilter/Iptables support, so I don't know how that impacts
security.

So that's about it. I'm not sure when I'll have more free time again to
work on this in depth so there may or may not be more detailed work on
this project coming from my end for a few months (limited volunteer
hours to spend and all that), but maybe together we can 

[qubes-users] Re: Graphics Problem after updating Dom0

[Reg Tiangha]

On 2017-04-30 9:31 AM, Mystic Buyer wrote:
> On Sunday, April 30, 2017 at 4:34:25 AM UTC-4, foo4 wrote:
>> Mystic Buyer:
>>> Hi guys
>>>
>>> I hope someone will be able to help me out on this. So I just installed 
>>> Qubes 3.2 on my Dell xps 15 9560. Things worked perfectly until I updated 
>>> dom0. After the dom0 software was updated (like I read on some posts to 
>>> Fedora 24, not sure though). The graphics seems to have broken completely.
>>>
>>> *Touchpad does not work correctly after the login screen. Responds in 
>>> glitches. 
>>>
>>> *The screen has slowed down. Everything typed responds very late. And dom0 
>>> says "ClockVM failed to start. Exiting." Not sure what that is
>>>
>>> *The windows seem to respond like curtains falling from bottom down.
>>>
>>> If someone can tell me what is wrong and if some solutions that can be 
>>> applied. 
>>>
>>> Thanks.
>>>
>> Honestly, I think there is no solution, must wait for the devs to fix
>> it, and/or install on a different system, on my 2nd system skylake the
>> dom0 update didn't cause the same problem as it did on kabylake .
>>
>> Sure wish Linux had some kind of restore point or something as a
>> fallback :)
> 
> Yes I did observe that when I installed qubes on acer aspire, configuration 
> not as good as xps 15. 
> 
> Except the touchpad doesn't work. But everything else works perfectly fine 
> even after the dom0 update no problems at all.
> 
> I updated my dom0 on xps 15 to unstable repo as mentioned in some other posts 
> and it did solve the problems, everything after the update to unstable repo 
> on xps 15 is working fine.
> 

One thing to try (assuming that it's an Intel video card in your machine
and not an Nvidia one, but I don't know if it'll help) is to enter into
the Advanced Options menu when GRUB starts up (I don't know how it works
with UEFI) and under the 'module' line, add
i915.preliminary_hw_support=1 right after 'quiet' and then try to boot
with that option. Let me know if it does and I'll make it a default
setting in the 4.4 kernel in my next Pull Request.

As for VM graphics issues, there are some packages in current-testing
for all the various templates that may help with the slowness (mainly to
do with qubes-gui-agent); if you have the ability, see if installing
them helps with your issues. It did seem to help with mine.

Not sure what's happening with the touchpad driver; from what I can
tell, nothing has changed in regards to the kernel options between
4.4.55 and the previous one when it comes to touchpads. There *is* an
updated dom0 kernel in current-testing (4.4.62) that you could try to
install to see if that fixes things.

If you have the ability to compile your own kernel, you could try
compiling a 4.9 or 4.10 version using the instructions here (if you're
compiling on an fc23 template, you'll need to grab the
qubes-kernel-vm-support package from current-testing first since it
hasn't made its way to stable yet):


https://groups.google.com/d/msg/qubes-users/yBeUJPwKwHM/CFLgGsyKBAAJ

-- 
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/oe5nfc%24t0v%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 04/28/2017 11:56 PM, Foppe de Haan wrote:
> the update wasn't built for the fc23-vm: 
> https://github.com/QubesOS/updates-status/issues/17
>
That's really weird, since it came out for dom0, which is essentially
fc23. And it looks like the fc24 and 25 versions never transferred over
from current-testing either.


-- 
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/oe1a4b%24bjq%242%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 04/28/2017 11:20 PM, gho...@gmail.com
wrote:
>> I don't know why it wouldn't work for you, unless you're running a
>> version of Qubes older than R3.2 or using an unsupported Fedora template.
>>
>> As a last resort, you can replace your /usr/src/u2mfn-3.2.3/u2mfn.c file
>> with this one here:
>>
>> https://raw.githubusercontent.com/QubesOS/qubes-linux-utils/master/kernel-modules/u2mfn/u2mfn.c
>>
>> and compiling should work.
> It works now. Thanks for your help.
>
> I started from scratch with a new clone of the fedora 23 template that was 
> installed with R3.2. I replaced the u2mfn.c file with the one you linked to.
>
Hmm, looks like you're right. Only 3.2.3 is in all the Fedora repos
(23-25). Which is weird, because I could have sworn it was pushed out in
the latest round of stable updates. It does show up in the Debian repos,
though.

Well, the important thing was updating that u2mfn.c file to work with
kernels newer than 4.8. Glad to hear it still works.



-- 
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/oe19r0%24bjq%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 04/28/2017 10:25 PM, gho...@gmail.com
wrote:
>> You need to update the qubes-kernel-vm-support package in the Fedora VM
>> that you're trying to compile this in. A compatible version (3.2.4)
>> should has been pushed out to the stable repositories so running sudo
>> dnf upgrade should pull it in (unless you've never installed it in the
>> first place, in which case you should run sudo dnf install
>> qubes-kernel-vm-support instead). Once you've installed the package, try
>> compiling one of those kernels again and it should work.
> I have version 3.2.3 installed.  I also have the "current", 
> "current-testing", and "unstable" repositories enabled in qubes-r3.repo.  
>
> doing a search for qubes-kernel-vm-support only shows version 3.2.3.  Doing 
> upgrade says nothing to do. Doing a reinstall only installs version 3.2.3 Is 
> there somewhere else to get the version 3.2.4
>
> Thanks.
>
I don't know why it wouldn't work for you, unless you're running a
version of Qubes older than R3.2 or using an unsupported Fedora template.

As a last resort, you can replace your /usr/src/u2mfn-3.2.3/u2mfn.c file
with this one here:

https://raw.githubusercontent.com/QubesOS/qubes-linux-utils/master/kernel-modules/u2mfn/u2mfn.c

and compiling should work.


-- 
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/oe14qn%249e9%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HOWTO: Compiling Kernels for dom0

[Reg Tiangha]

On 04/28/2017 09:03 PM, gho...@gmail.com
wrote:
> Hello,
>
> I am following your instructions and trying to compile devel-4.10.  I am 
> getting the following error.  This error also occurs on stable-4.9. Any idea 
> how i can fix this.
>
> Thanks.
>
> /home/user/qubes-linux-kernel/u2mfn/u2mfn.c: In function 'u2mfn_ioctl':
> /home/user/qubes-linux-kernel/u2mfn/u2mfn.c:80:23: error: passing argument 5 
> of 'get_user_pages' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>(data, 1, 1, 0, _page, 0);
>^
> In file included from /home/user/qubes-linux-kernel/u2mfn/u2mfn.c:26:0:
> /home/user/qubes-linux-kernel/kernel-4.10.13/linux-4.10.13/include/linux/mm.h:1271:6:
>  note: expected 'struct vm_area_struct **' but argument is of type 'struct 
> page **'
>  long get_user_pages(unsigned long start, unsigned long nr_pages,
>   ^
> /home/user/qubes-linux-kernel/u2mfn/u2mfn.c:79:9: error: too many arguments 
> to function 'get_user_pages'
>ret = get_user_pages
>  ^
> In file included from /home/user/qubes-linux-kernel/u2mfn/u2mfn.c:26:0:
> /home/user/qubes-linux-kernel/kernel-4.10.13/linux-4.10.13/include/linux/mm.h:1271:6:
>  note: declared here
>  long get_user_pages(unsigned long start, unsigned long nr_pages,
>   ^
> cc1: some warnings being treated as errors
> /home/user/qubes-linux-kernel/kernel-4.10.13/linux-4.10.13/scripts/Makefile.build:300:
>  recipe for target '/home/user/qubes-linux-kernel/u2mfn/u2mfn.o' failed
> make[4]: *** [/home/user/qubes-linux-kernel/u2mfn/u2mfn.o] Error 1
> /home/user/qubes-linux-kernel/kernel-4.10.13/linux-4.10.13/Makefile:1490: 
> recipe for target '_module_/home/user/qubes-linux-kernel/u2mfn' failed
> make[3]: *** [_module_/home/user/qubes-linux-kernel/u2mfn] Error 2
> Makefile:150: recipe for target 'sub-make' failed
> make[2]: *** [sub-make] Error 2
> Makefile:24: recipe for target '__sub-make' failed
> make[1]: *** [__sub-make] Error 2
> make[1]: Leaving directory 
> '/home/user/qubes-linux-kernel/kernel-4.10.13/linux-obj'
> error: Bad exit status from /var/tmp/rpm-tmp.6UeD6a (%build)
>
>
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.6UeD6a (%build)
> Makefile:90: recipe for target 'rpms-dom0' failed
> make: *** [rpms-dom0] Error 1
>
You need to update the qubes-kernel-vm-support package in the Fedora VM
that you're trying to compile this in. A compatible version (3.2.4)
should has been pushed out to the stable repositories so running sudo
dnf upgrade should pull it in (unless you've never installed it in the
first place, in which case you should run sudo dnf install
qubes-kernel-vm-support instead). Once you've installed the package, try
compiling one of those kernels again and it should work.


-- 
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/oe131i%24au6%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.