Re: [qubes-users] Re: Fullscreen Multiple Monitors not possible?

2021-03-07 Thread Vít Šesták 'v6ak'
Well, in order to use the back from my first post, don't use the actual
fullscreen.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOgcfy9ZWW_sieWYrqHz1zE%2B5LchwxjxaDtREN-t0di7W9f2sg%40mail.gmail.com.


Re: [qubes-users] Re: Fullscreen Multiple Monitors not possible?

2021-03-07 Thread Vít Šesták 'v6ak'
I have forgotten to send the mail to qubes-users…

On Sun, Mar 7, 2021, 08:43 Prof. Dr. Michael Schefczyk  wrote:

> Dear Vít Šesták,
>
>
>
> Thank you very much! Indeed, fullscreen is possible with and without the
> allow_fullscreen setting. Unfortunately, there seems to be no way out of
> the problem that this does work only in a single monitor mode (literally
> full monitor instead of full screen).
>
>
>
> Regards,
>
>
>
> Michael Schefczyk
>
>
>
> *Von:* Vít Šesták <>
> *Gesendet:* Sonntag, 7. März 2021 08:38
> *An:* Prof. Dr. Michael Schefczyk
>
> *Betreff:* Re: [qubes-users] Re: Fullscreen Multiple Monitors not
> possible?
>
>
>
> Taskbar: that's why I wrote this:
>
>
>
> > If needed, make the window always-on-top by Alt+Space and selecting
> Always on Top.
>
>
>
> BTW, you can enter fullscreen in a similar way, even without
> allow_fullscreen. And you can probably configure shortcuts…
>
>
>
> Regards,
>
> Vít Šesták 'v6ak'
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOgcfy_YNP4h%3DoQXo%2BMxWDdUXefbutskbgG_kvUcxcOdezrvYA%40mail.gmail.com.


[qubes-users] Re: Fullscreen Multiple Monitors not possible?

2021-03-06 Thread Vít Šesták
I guess that the xfreerdp just creates a window that is large enough and 
positioned in a way that hides the window borders. However, Qubes OS AFAIK 
does not allow the positioning for security reasons. However, you can do 
this yourself. It depends on your desktop environment and configuration, 
there is rough howto for Xfce:

* Adjust the window position by alt+left-click and movement.
* Adjust the window size by alt+right-click and movement.
* If needed, make the window always-on-top by Alt+Space and selecting 
Always on Top.

I am pretty sure this can be automated by xdotool or something similar.

Regards,
Vit Sestak 'v6ak'

On Saturday, March 6, 2021 at 8:04:32 AM UTC+1 mic...@schefczyk.net wrote:

> Dear All,
>
> In QubesOS R4.0, I have two monitors connected to form a large screen made 
> up by two monitors side by side. I would like to achieve what does work in 
> Debian, for example, that is a fullscreen window covering the entire screen 
> (i. e., both monitors). This is particularly useful in rdp-seccions using 
> freerdp. It can be achieved using:
>
> xfreerdp /multimon
>
> This leads to a freerdp connection across multiple monitors at leaset in 
> Debian GNOME.
>
> In QubesOS R4.0 it does work in principle. A window as wide as the set of 
> monitors does get created. However, the fullscreen feature does not work. 
> As soon as one clicks fullscreen, the window gets confined to one of the 
> monitors. Of course, I did allow fullscreen as described here: 
> https://www.qubes-os.org/doc/full-screen-mode/ And of corse, everything 
> does work well with just one monitor connected. And yes, I do understand 
> the security concept of normally not covering the entire screen but showng 
> the window decorations including the VM color.
>
> Is there a way to overcome that limitation? If "fullscreen" can be made to 
> work across physical monitors in general, xfreerdp /multimon should work as 
> well.
>
> Thank you very much!
>
> Michael Schefczyk
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/af8c7604-ef3d-4b35-b264-f2773f76e4f2n%40googlegroups.com.


Re: [qubes-users] [HCL] ASRock B550 Phantom Gaming 4/ac

2021-03-06 Thread Vít Šesták
Very short advice: If you want to use Ryzen 5000 series and your BIOS 
version is P1.10 or lower, I suggest you to upgrade BIOS before installing 
Qubes OS and before configuring the BIOS.

## Short story

After some research, I decided to update BIOS. While ASRock advertises this 
MoBo to be comptabile with Ryzen 5000 series (see 
https://www.asrock.com/mb/AMD/B550%20Phantom%20Gaming%204ac/index.asp#Specification
 
), this seems to be a half-truth. According to their changelog at 
https://www.asrock.com/mb/AMD/B550%20Phantom%20Gaming%204ac/index.asp#BIOS 
, the BIOS 1.20 description contains "Support AMD Ryzen™ 5000 Series 
processors". So, with versions 1.00 and 1.10, you are probably out of luck.

What the BIOS change resolved:
* the rdrand issue with dnf
* the USB issues with my trackball.

One-time issues with the new BIOS version:
* When you flash the BIOS, it resets the settings, so you lose IOMMU etc. 
until you configure it again.
* It has probably changed the PCI identifiers, which has caused weird 
freezes when starting a VM with a PCI device assigned. Fortunatelly, in my 
temporary setup, no VM with any PCI device was configured to start on boot. 
If this was not my case, I would probably end up with non-bootable system 
and hard debugging...

Not resolved: suspend/resume issues. Symptoms remain the same, including , 
regardless the smt configuration.

Changed: /proc/cpuinfo - at least added rdrand.

## Long story about rdrand

(You probably don't need to read this to make this MoBo working, but you 
might be interested for any other reason.)

I've googled for the rdrand issue. Aside from many irelevant results (AMD's 
and Intel's issues with bad randomness or Google treating "Xen" in phrase 
with "AMD" as typo), I've learnt something:

1. The source that writes those errors is probably this: 
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc

2. Found the Intel's documentation of the _rdrand32_step instruction (well, 
intristic function) 
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_rdrand32_step
 
via https://doc.rust-lang.org/core/arch/x86_64/fn._rdrand32_step.html . So, 
the instruction can sometimes just fail without any apparent reason, and 
libstdc++ tries 100 times until it fails.

3. I've tried a code that tests _rdrand32_step (adjusted version of testing 
program from 
https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/
 
), see the attachment. It seems to always fail in both Dom0 and DomU.

4. Interesting finding: qubes-dom0-update works well, even though it runs 
dnf. I've tried to adjust the command to find the minimal difference that 
causes the command to fail/succeed:

$ sudo dnf update --installroot /
Error: random_device: rdrand failed
$ sudo dnf update --installroot /var/lib/qubes/dom0-updates 
Last metadata expiration check: 0:44:30 ago on Sat Mar  6 16:25:06 2021.
Dependencies resolved.
Nothing to do.
Complete!

5. Since this seems to be related to a CPU instruction which seems to be 
affected by microcode/BIOS, I've decided to update the BIOS. Which seems to 
have been the way to go, see above.

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


On Saturday, March 6, 2021 at 12:57:31 AM UTC+1 sv...@svensemmler.org wrote:

> On 3/5/21 5:48 PM, Vít Šesták wrote:
> > Well, I have to correct the claim about rdrand in Fedora 33: It does not
> > resolve the issue. The issue is a bit random, but it still appears.
>
> Hi Vít,
>
> just keep posting your findings to this thread, which is linked from 
> your HCL report. So others looking at your report will then find this 
> thread and see all the additional information you provide.
>
> I hope you'll be able to figure it out!
>
> Cheers,
> /Sven
>
> -- 
> public key: https://www.svensemmler.org/0x8F541FB6.asc
> fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aed35ee1-097d-4558-bd00-82b3af4a5fddn%40googlegroups.com.
// SPDX-License-Identifier: GPL-2.0
/*
 * Copyright (C) 2019 Jason A. Donenfeld . All Rights Reserved.
 *
 * Compile: `gcc -o test-rdrand -O3 -mrdrnd -std=gnu99 test-rdrand.c`
 */

#include 
#include 
#include 

int main(int argc, char *argv[])
{
	for (int j, i = 0; i < 20; ++i) {
		for (j = 0; j < 1; ++j) {
			uint32_t val = 0;
			if (__builtin_ia32_rdrand32_step()) {
printf("RDRAND() = 0x%08x\n", val);
break;
			}else{
printf("!");
			}
		}
		if (j == 1) {
			puts("RDRAND() = FAIL");
			return 1;
		}
	}
	return 0;
}


Re: [qubes-users] [HCL] ASRock B550 Phantom Gaming 4/ac

2021-03-05 Thread Vít Šesták
Well, I have to correct the claim about rdrand in Fedora 33: It does not 
resolve the issue. The issue is a bit random, but it still appears.

When searching, it looks like I was the only one with this issue on Qubes 
OS. OTOH, there is some indication that it is quite generic issue: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087

On Friday, March 5, 2021 at 11:13:59 PM UTC+1 sv...@svensemmler.org wrote:

> On 3/5/21 2:59 PM, Vít Šesták wrote:
> > I'm posting HCL report for my computer with this ASRock B550 Phantom
> > Gaming 4/ac and Ryzen 7 5800X.
>
> Hi Vít,
>
> thank you for your post. Your HCL report is now waiting as a pull 
> request to be merged in by the website maintainer.
>
> https://github.com/QubesOS/qubes-hcl/pull/49
>
> /Sven
>
> -- 
> public key: https://www.svensemmler.org/0x8F541FB6.asc
> fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4fb63fc7-32d7-4b49-9d2e-47db2add67ccn%40googlegroups.com.


[qubes-users] Re: [HCL] ASRock B550 Phantom Gaming 4/ac

2021-03-05 Thread Vít Šesták
I've resolved the sound issue:

1. I've experimented in a Debian qube with dequbesed pulseaudio (killall 
pulseaudio && sleep 1 && pulseaudio  --exit-idle-time=-1). After running 
`pacmd list-cards`, I read the output and ran pacmd set-card-profile 
 , which made it working.
2. After whole Qubes reboot (in order to reappear the sound card in dom0), 
I started seeing the card in pavucontrol.

So, the probably last major issue to resolve is the lack of sleep. All 
attempts end with something like this:

Mar 05 20:22:23 dom0 kernel: PM: suspend entry (deep)
-- Reboot --

So, this does not look like a GPU issue. It does not write any message 
after resume. (Well, even few messages before finishing suspend are 
missing, but they might be just not written to the log...)

Vít Šesták 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/051d0685-2697-435b-867c-ed2f864f53b7n%40googlegroups.com.


[qubes-users] [HCL] ASRock B550 Phantom Gaming 4/ac

2021-03-05 Thread Vít Šesták
Hello,
I'm posting HCL report for my computer with this ASRock B550 Phantom Gaming 
4/ac and Ryzen 7 5800X. I've few comments:

* You need to configure the MoBo, most notably to enable the IOMMU.
* The installer 4.0.4 boot shows blank screen after "Xen is relinquishing 
VGA console" or something similar. (I had a very small time to read it.) In 
the nutshell, the solution was 
https://www.qubes-os.org/doc/uefi-troubleshooting/#removing-noexitboot-and-mapbs
 
, but the Qubes 4.0.4 installer seems to have immutable filesystem, so I've 
adjusted the iso file by sed. Note that there are two occurrences of both 
strings, I have no idea why.

Suspend to RAM: Does not resume, no idea why. I have suspected it to be 
related to smt=off (see 
https://www.pcgamer.com/amd-is-analyzing-usb-disconnect-issue-in-500-series-motherboards/
 
), but it seems to behave the same even with smt=on. Using kernel 5.10 did 
not help.

Sound: The card does not seem to be recognized, so I can just use the 
DisplayPort sound output and no sound input :( Also, the sound output is 
not very good (voices are relatively quiet), but there can be multiple 
components to blame.

USB:
* Two controllers. Great.
* One of the controllers does not accept my trackball - it periodically 
reconnects in very short intervals and cannot be used. Note that this might 
be unrelated to Qubes OS: 
https://www.pcgamer.com/amd-is-analyzing-usb-disconnect-issue-in-500-series-motherboards/

LAN: not tested

Wi-Fi: works

TPM: The report shows no TPM. However, there is some TPM configuration in 
BIOS, and it is off by default. I could try to configure it and it might 
work.

Other issues: Cannot update the Fedora 32 template. I have found some other 
users with this issue in some other apps running on AMD CPU, but no 
solution. However, installing Fedora 33 helps. The error in Fedora 32:
$ sudo dnf update
Error: random_device: rdrand failed

Short reasoning why I decided for this MoBo: ECC support for a good price. 
ASrock's quality is reportedly comparable to ASUS, and those vendors are 
the only two who have ECC support on a non-server board. Also, the I've 
seen rather compatible ASrock MoBos in the Qubes HCL.

Regards,
Vit Sestak 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a5851277-ccf0-4cc9-9c00-f605935f7632n%40googlegroups.com.


Qubes-HCL-ASRock-B550_Phantom_Gaming_4_ac-20210305-211229.yml
Description: application/yaml


Re: [qubes-users] Re: High dom0 CPU usage by qubesd

2021-01-19 Thread Vít Šesták
Although my implementation is not fully complete, I have decided to share 
my progress: https://github.com/v6ak/qubes-i3status-dir

It is available under a WTFPL-like license.

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

On Monday, January 18, 2021 at 2:39:09 PM UTC+1 Vít Šesták wrote:

> BTW, I've started the reimplementation of qubes-i3status as a Python 
> wrapper around i3status. I am trying to be quite conservative – in the 
> default settings, there should be no visible difference except CPU load, 
> periodic freezes and bug fixes (battery status).
>
> * Some indicators (battery, load and time) are already present, they just 
> need some adjustments of the format in order to be a drop-in replacement.
> * Disk status was easy to implement. I just need to verify that it can 
> properly handle the change of default pool.
> * Running qubes: I need to study the events deeper…
> * NetVM status – currently, it is disabled and discouraged. I might decide 
> to reimplement this, but I am not 100% sure right now.
>
> Regards,
> Vít Šesták 'v6ak'
>
> On Friday, January 15, 2021 at 5:40:38 PM UTC+1 David Hobach wrote:
>
>> Hi Vit, 
>>
>> > * I have many VMs in my computer. 
>> > * I use i3 with qubes-i3status 
>> > * The script qubes-i3status calls command qvm-ls --no-spinner 
>> --raw-data 
>> > --fields NAME,FLAGS quite frequently. 
>> > * The command qvm-ls --no-spinner --raw-data --fields NAME,FLAGS seems 
>> to 
>> > cause high CPU load. Unfortunately, the process that shows the high CPU 
>> > usage is qubesd, not qvm-ls. 
>> > 
>> > What can be improved: 
>> > 
>> > a. Don't use qubes-i3status. Problem solved. 
>> > b. Optimize qvm-ls. Not sure how hard it is. 
>>
>> This issue is really old (back from at least 3.2) and caused by each 
>> qvm-ls line relating to one request to qubesd. Actually it was even worse 
>> with 3.2. 
>>
>> It should improve with 4.1 though, see [1]. 
>>
>> [1] https://github.com/QubesOS/qubes-issues/issues/3293 
>>
>> > c. Optimize qubes-i3status. I am not sure about the ideal way of doing 
>> > that, but clearly running qvm-ls --no-spinner --raw-data --fields 
>> > NAME,FLAGS just to compute the number of running qubes is far from 
>> optimal. 
>> > One could add --running. And maybe it could have been written without 
>> > flags. The script just ignores VMs with the first flag being “0” (maybe 
>> in 
>> > order to ignore dom0) and the second flag being “r” (probably not 
>> needed 
>> > with --running). 
>>
>> Filtering might work in the meantime, yes. 
>>
>> BR 
>> David 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b98004f9-01be-447c-9388-65944f948a14n%40googlegroups.com.


Re: [qubes-users] Re: High dom0 CPU usage by qubesd

2021-01-18 Thread Vít Šesták
BTW, I've started the reimplementation of qubes-i3status as a Python 
wrapper around i3status. I am trying to be quite conservative – in the 
default settings, there should be no visible difference except CPU load, 
periodic freezes and bug fixes (battery status).

* Some indicators (battery, load and time) are already present, they just 
need some adjustments of the format in order to be a drop-in replacement.
* Disk status was easy to implement. I just need to verify that it can 
properly handle the change of default pool.
* Running qubes: I need to study the events deeper…
* NetVM status – currently, it is disabled and discouraged. I might decide 
to reimplement this, but I am not 100% sure right now.

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

On Friday, January 15, 2021 at 5:40:38 PM UTC+1 David Hobach wrote:

> Hi Vit,
>
> > * I have many VMs in my computer.
> > * I use i3 with qubes-i3status
> > * The script qubes-i3status calls command qvm-ls --no-spinner --raw-data
> > --fields NAME,FLAGS quite frequently.
> > * The command qvm-ls --no-spinner --raw-data --fields NAME,FLAGS seems to
> > cause high CPU load. Unfortunately, the process that shows the high CPU
> > usage is qubesd, not qvm-ls.
> > 
> > What can be improved:
> > 
> > a. Don't use qubes-i3status. Problem solved.
> > b. Optimize qvm-ls. Not sure how hard it is.
>
> This issue is really old (back from at least 3.2) and caused by each 
> qvm-ls line relating to one request to qubesd. Actually it was even worse 
> with 3.2.
>
> It should improve with 4.1 though, see [1].
>
> [1] https://github.com/QubesOS/qubes-issues/issues/3293
>
> > c. Optimize qubes-i3status. I am not sure about the ideal way of doing
> > that, but clearly running qvm-ls --no-spinner --raw-data --fields
> > NAME,FLAGS just to compute the number of running qubes is far from 
> optimal.
> > One could add --running. And maybe it could have been written without
> > flags. The script just ignores VMs with the first flag being “0” (maybe 
> in
> > order to ignore dom0) and the second flag being “r” (probably not needed
> > with --running).
>
> Filtering might work in the meantime, yes.
>
> BR
> David
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/42dba1a7-e551-46fa-98e1-d8d59d5356f7n%40googlegroups.com.


Re: [qubes-users] Re: High dom0 CPU usage by qubesd

2021-01-14 Thread Vít Šesták
OK, reported, some optimization attempts included: 
https://groups.google.com/g/qubes-users/c/uTi3QHuhdy8

Also, I have some temptation to reimplement qubes-i3status as a Python 
wrapper around the original i3status. We would probably also resolve some 
other problems. For example, I had to fix reading of the battery status.

BTW, if you have ~25% CPU load, I guess you just have quad-core CPU (or 
maybe dual-core with hyperthreading).

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

On Wednesday, January 6, 2021 at 11:34:42 AM UTC+1 Jarrah wrote:

> This is some really nice tracing work. I'm sure it would be appreciated
> as an issue in the qubes-issues repository so it can be tracked properly.
>
> While I haven't gone to the same depth, I can confirm that `qubesd`
> jumps to ~25% CPU regularly on my (albeit much beefier) system with i3.
> This does correlate with qubes-i3status running on my system as well.
>
>
> As a temporary work around, you could modify the script
> (/usr/bin/qubes-i3status:123) to run every minute or longer. This would
> have the downside of the clock updating slower, but otherwise should not
> be a problem.
>
> Alternatively, if the number of running VMs doesn't interest you, you
> could comment out line 113 and modify 122 to suit this.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e3bcfe4b-2127-4d94-a3d0-07871ffbaf37n%40googlegroups.com.


[qubes-users] Re: How do you think about the clipboard inter-VMs

2021-01-08 Thread Vít Šesták
Well, it depends:

* When pasting to terminal, you should always think twice. (This BTW also 
holds for pasting a text copied from a webpage to a terminal – the webpage 
might let you copy something else that you can see…)
* When pasting to a text editor with highlighting, there is some risk of a 
vulnerability in the text editor.
* When pasting to a text editor with no highlighting etc., the risk is 
probably quite low.

Well, you could have an application that actively monitors clipboard and 
processes it in a vulnerable way. I don't think this is much likely, but it 
is possible in theory.

On OCR: I am not sure how could it help. Maybe it could limit the character 
set and let you review the copied text. Cool, but I believe this can be 
done in some much easier ways…

@stevenlc: Nation State Adversary has a good acronym…

Vít Šesták 'v6ak'

On Wednesday, January 6, 2021 at 5:04:13 AM UTC+1 pillule wrote:

>
> Hello,
>
> I wonder how do you manage your computing life with the problem of 
> the clipboard / file sharing.
>
> The documentation states :
> https://www.qubes-os.org/doc/copy-paste/
> “However, one should keep in mind that performing a copy and paste 
> operation from less trusted to more trusted qube is always 
> potentially insecure, since the data that we copy could exploit 
> some hypothetical bug in the target qube. For example, the 
> seemingly-innocent link that we copy from an untrusted qube could 
> turn out to be a large buffer of junk that, when pasted into the 
> target qube’s word processor, could exploit a hypothetical bug in 
> the undo buffer. This is a general problem and applies to any data 
> transfer from less trusted to more trusted qubes. It even applies 
> to copying files between physically separate (air-gapped) 
> machines. Therefore, you should always copy clipboard data only 
> from more trusted to less trusted qubes.”
>
> Also I remember a paper of Joanna Rutkowska assuming the same 
> principles.
>
>
> I guess most of us cheats theses rules sometimes ;
> if one deploys post-installation scripts in dom0,
> or takes notes in a vault and wants to copy in that URL,
> or maybe wants to take that snippet into that template ...
>
> I am curious to know how you think about it.
>
> I would like to let the least possible of my data in the VMs which 
> are exposed to the network. This, with the fact the ressources of 
> my computer are limited, unfortunally may leads to open breaches 
> in the comportamentalisation :
> Now I have a vault where I takes notes and needs to paste things 
> into it. I can't afford using a vault for each new context and it 
> will not solve the issue of the clipboard.
> Maybe I should just stick to the idea of one context equal one VM, 
> and refine what I think is pertinent to put on the word ‘context’.
>
> Otherwise, Is there really nothing one can do to enforce the 
> integrity of a piece of text ?
> Like using an OCR from dom0 to retranscript an screenshoot of a 
> less trusted VM (is that dumb or also somehow flawed or just so 
> loud nobody wants it) ?
>
> -- 
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f3d7cf35-2561-4a6d-a7a5-fefc1f0ce68cn%40googlegroups.com.


[qubes-users] Re: High dom0 CPU usage by qubesd

2021-01-06 Thread Vít Šesták
Hi,
I have some further info. I partially know cause and have a workaround.

There is my investigation. Some minor inaccuracies might be caused by 
retrospective writing:

1. I have tried to debug using strace. (Prerequisite: sudo 
qubes-dom0-install strace) After finding pid of qubesd, I ran:
sudo strace -s 256 -p PID_OF_QUBESD -o /tmp/qubesd.log

It looks like few seconds is enough to get a reasonable sample, see below.

2. I ran sort /tmp/qubesd.log | uniq -c | sort -n (one can also add “ -r | 
head -n 50”).

I have noticed an interesting line that repeats frequently:
sendto(270, "QubesNoSuchPropertyError\0", 25, 0, NULL, 0) = 25

3. Look closer:
$ grep --before=5 --after=5 QubesNoSuchPropertyError /tmp/qubesd.log 
The output contains many repeated occurrences of this, just with a 
different VM name. It seems to iterate over all the VMs (even those that 
are not running):
--
epoll_wait(3, [], , 0)= 0
getpid()= 
epoll_wait(3, [], , 0)= 0
epoll_wait(3, [], , 0)= 0
sendto(, "2\0", 2, 0, NULL, 0)   = 2
sendto(, "QubesNoSuchPropertyError\0", 25, 0, NULL, 0) = 25
sendto(, "\0", 1, 0, NULL, 0)= 1
sendto(, "Invalid property 'internal' of \0", 
38, 0, NULL, 0) = 38
shutdown(, SHUT_WR)  = 0
epoll_wait(3, [{EPOLLIN, {u32=, u64=}}], 18, 0) = 
1
close()  = 0

4. WTF, what would iterate over all the VMs? Maybe some script repeatedly 
runs qvm-ls? Let's ps aux | grep qvm-ls that! During increased CPU 
workload, I have identified:

qvm-ls --no-spinner --raw-data --fields NAME,FLAGS

5. During the current random CPU workload, I cannot reliably verify if it 
is the cause of the increased CPU usage, but at least I can verify if it is 
the cause of the error messages. So, I have tried the command while running 
this:

(sudo strace -s 256 -p PID_OF_QUBESD 2>&1) | grep 'Invalid property'

And yes, it seems to be the cause of the error messages and maybe also the 
source of increased CPU load.

6. Let's identify the script that runs the command: I ran htop, switched to 
tree mode (key t), waited for the qvm-ls (using watch + ps aux + grep) and 
typed “/qvm-ls”.

And the script to blame is – qubes-i3status

7. And yes, killing qubes-i3status has helped to decrease the CPU load. 
After doing that, I was able to confirm that qvm-ls --no-spinner --raw-data 
--fields NAME,FLAGS also causes the CPU load.


So, there are multiple causes combined:

* I have many VMs in my computer.
* I use i3 with qubes-i3status
* The script qubes-i3status calls command qvm-ls --no-spinner --raw-data 
--fields NAME,FLAGS quite frequently.
* The command qvm-ls --no-spinner --raw-data --fields NAME,FLAGS seems to 
cause high CPU load. Unfortunately, the process that shows the high CPU 
usage is qubesd, not qvm-ls.

What can be improved:

a. Don't use qubes-i3status. Problem solved.
b. Optimize qvm-ls. Not sure how hard it is.
c. Optimize qubes-i3status. I am not sure about the ideal way of doing 
that, but clearly running qvm-ls --no-spinner --raw-data --fields 
NAME,FLAGS just to compute the number of running qubes is far from optimal. 
One could add --running. And maybe it could have been written without 
flags. The script just ignores VMs with the first flag being “0” (maybe in 
order to ignore dom0) and the second flag being “r” (probably not needed 
with --running).

Regards,
Vít Šesták 'v6ak'
On Monday, January 4, 2021 at 11:51:23 PM UTC+1 Vít Šesták wrote:

> Hello,
> I have dual-core i7 7500U with disabled hyperthreading. In dom0, I often 
> have total CPU usage in tens of percents (often about 50 %, i.e., about 
> fully utilized single core). When I look at htop in dom0, it is clearly 
> caused by qubesd, which clearly uses the vast majority of CPU during these 
> peaks. Note that these peaks look rather random, I see no relation to any 
> activity. But they are quite frequent.
>
> When looking at the process tree, it has many child processes, probably 
> one for each domU qube. But they utilize near zero CPU.
>
> The column TIME+ confirms my CPU% observation in long term.
>
> I am not sure where to find any relevant log. Maybe journalctl, but I have 
> seen nothing suspicious there.
>
> Do you have any idea about the cause, solution or even a suggestion for 
> debugging?
>
> Regards,
> Vít Šesták 'v6ak'
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9ac8afbe-55ee-485c-a29b-b7c75b92ecden%40googlegroups.com.


[qubes-users] High dom0 CPU usage by qubesd

2021-01-04 Thread Vít Šesták
Hello,
I have dual-core i7 7500U with disabled hyperthreading. In dom0, I often 
have total CPU usage in tens of percents (often about 50 %, i.e., about 
fully utilized single core). When I look at htop in dom0, it is clearly 
caused by qubesd, which clearly uses the vast majority of CPU during these 
peaks. Note that these peaks look rather random, I see no relation to any 
activity. But they are quite frequent.

When looking at the process tree, it has many child processes, probably one 
for each domU qube. But they utilize near zero CPU.

The column TIME+ confirms my CPU% observation in long term.

I am not sure where to find any relevant log. Maybe journalctl, but I have 
seen nothing suspicious there.

Do you have any idea about the cause, solution or even a suggestion for 
debugging?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/60777876-a194-4685-86db-afc8fed89d6cn%40googlegroups.com.


[qubes-users] Using Zoom in Qubes

2020-05-10 Thread Vít Šesták
The problem with Zoom is probably that it opens a transparent overlay, likely 
because of annotations. However, Qubes OS does not support transparency. There 
is a workaround that hides the overlay:

xdotool selectwindow windowunmap

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bbb32f67-ebe2-44a6-ae0c-a42b16c6ea91%40googlegroups.com.


[qubes-users] Is a StandaloneVM equally secure as a AppVM that is created on it's own TemplateVM, and what is the difference between a StandaloneVM and a AppVM ?

2020-04-14 Thread Vít Šesták
In my opinion, the main reason for deciding between StandaloneVM and 
Template-based-VM is not security, it is management. With a Template-based-VM, 
you manage all or most of the apps in the template. If you have a single VM 
template for many Template-based-VMs, you just update the template and reboot 
the related VMs that are running. With standalone VMs, you need to update all 
of them separately.

Security concerns:

a. Malware might not survive reboot of Template-based-VM. This is however true 
just for some malware that is not adapted to Qubes OS, ale even this malware 
might survive VM reboot. AFAIR, this is explicitly a non-goal. There are many 
places to hook the malware after reboot – .bashrc, /usr/local/bin, browser 
extensions, …
b. When you have a StandaloneVM you don't run often, it might miss some 
updates, so you are more likely to run some software with known vulnerabilities 
after boot. This does not happen for Temlate-based-VM provided that you use 
some other VMs from the same template.
c. On the other hand, Template-based-VMs always require a reboot after 
updating. Without that, you can still run outdated software with some known 
vulnerabilities.

So, it depends on how you use it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/54e65034-0959-458f-bba7-56757a780a44%40googlegroups.com.


Re: [qubes-users] Re: [4.0] Intel Wi-Fi 6 AX200 adapter

2020-03-19 Thread Vít Šesták
Well, maybe it would be better to just compile some newer StubDom.

Also, I have realized that there is some similar discussion on Github: 
https://github.com/QubesOS/qubes-issues/issues/5615

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

On Thursday, March 19, 2020 at 10:42:00 PM UTC+1, Ilpo Järvinen wrote:
>
> On Thu, 19 Mar 2020, Vít Šesták wrote: 
>
> > Hello, 
> > I have some interesting updates. I have tried to: 
> > 
> > a. Boot Fedora 31 on the laptop (Live version from USB drive) – adapter 
> is 
> > detected and finds Wi-Fi networks. It just works. 
> > b. Boot Fedora 31 Live (from the same USB drive) in a HVM with attached 
> > Wi-Fi card. It had 2000MiB of RAM. It fails in the same way as my 
> previous 
> > attempts, not sure why. 
> > 
> > This looks like the AppVM is fine, but there is some glitch in the PCI 
> > handling. It might be related to Xen or to the DM, not sure. 
> > 
> > HVM: https://gist.github.com/v6ak/76f2c089c63b1fe184f3717d5bd5254e 
> > sys-net with Fedora 31: 
> > https://gist.github.com/v6ak/30ecc502d1ce7508953eb3d505564668 
> > 
> > I have also resolved the chicken-egg problem – I can connect to the 
> Internet 
> > via USB. This is not a permanent solution, but it was good enough for 
> > updating dom0. However, the update (+ subsequent reboot) has not changed 
> > anything. 
>
> One option would be compile a kernel with CONFIG_IWLWIFI_TRACING (or 
> something like that) and try to provide the trace log to iwlwifi devs. 
> ...It might not help though if it's not a HW/driver issue but xen/dm/pci 
> related thing. 
>
> -- 
>  i.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aa3c864a-fe45-4bc4-8614-860f28db8e4f%40googlegroups.com.


[qubes-users] Re: [4.0] Intel Wi-Fi 6 AX200 adapter

2020-03-19 Thread Vít Šesták
Hello,
I have some interesting updates. I have tried to:

a. Boot Fedora 31 on the laptop (Live version from USB drive) – adapter is 
detected and finds Wi-Fi networks. It just works.
b. Boot Fedora 31 Live (from the same USB drive) in a HVM with attached 
Wi-Fi card. It had 2000MiB of RAM. It fails in the same way as my previous 
attempts, not sure why.

This looks like the AppVM is fine, but there is some glitch in the PCI 
handling. It might be related to Xen or to the DM, not sure.

HVM: https://gist.github.com/v6ak/76f2c089c63b1fe184f3717d5bd5254e
sys-net with Fedora 31: 
https://gist.github.com/v6ak/30ecc502d1ce7508953eb3d505564668

I have also resolved the chicken-egg problem – I can connect to the 
Internet via USB. This is not a permanent solution, but it was good enough 
for updating dom0. However, the update (+ subsequent reboot) has not 
changed anything.

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

On Wednesday, March 18, 2020 at 8:46:31 PM UTC+1, Vít Šesták wrote:
>
> Hello,
> on a new laptop, I am trying to setup Qubes OS 4.0. I have installed the 
> latest point release (i.e., 4.0.3). I have bunch of issues, the most 
> important one is that I cannot connect to any network. I have made some 
> progress, but now, I am asking for some assistance.
>
> The command lspci shows the adapter as Intel Corporation Wi-Fi 6 AX200 
> (rev 1a).
>
> 1. Problem: Domain sys-net did not boot at all because of issues with 
> attaching ethernet PCI device.
> Workaround: I don't care much about ethernet, so I removed the PCI device. 
> Not optimal, but easy and good enough for now.
>
> 2. Domain sys-net does not even load iwlwifi kernel module.
> Cause: I have found that I need kernel 5.1 or 5.2 (depending on the 
> source).
> Solution: Use a backup of up-to-date Fedora 30 VM. Configure the mode to 
> HVM and the kernel to “(none)”. This will use up-to-date kernel from 
> Fedora, which is new-enough.
> Relevant link: 
> https://www.reddit.com/r/ManjaroLinux/comments/bx0skx/iwlwifi_driver_not_loading_for_intel_ax200_wifi/
> Relevant link: 
> https://www.intel.com/content/www/us/en/support/articles/05511/network-and-i-o/wireless-networking.html
>
> 3. Domain sys-net loads iwlwifi kernel module, but the Wi-Fi fails 
> immediately with “Microcode SW error detected. Restarting 0x200”. It 
> seems that Fedora automatically retries again and again and spams the log.
> This is the issue I am struggling with.
>
> What I have tried:
> * Use Fedora 31. I just cloned Fedora 30 on other laptop, created backup 
> and transferred to the other laptop. See 
> https://github.com/QubesOS/qubes-issues/issues/5289#issuecomment-582442319
> * Download ucode from 
> https://www.intel.com/content/www/us/en/support/articles/05511/network-and-i-o/wireless-networking.html
> * Replace /usr/lib/firmware/iwlwifi-cc-a0-48.ucode by 
> /usr/lib/firmware/iwlwifi-cc-a0-46.ucode if `sudo dmesg | grep 'firmware 
> version'` suggests that the 48 is being loaded. I did it in the TemplateVM, 
> rebooted sys-net and ensured that 46 is being loaded. According to the 
> https://www.intel.com/content/www/us/en/support/articles/05511/network-and-i-o/wireless-networking.html
>  
> , the version 46 is for AX200 and 48 is for AX201.
> No combination of those has helped, I am still getting the errors.
>
> Logs (Fedora 31, ucode from Intel):
> * Log sample (truncated, because it was too large, but it seems that 
> messages are repeating): 
> https://gist.github.com/v6ak/1cb7b172f63f8c20d7c4004f7996de39
> * Just unique messages (just proves there is nothing more interesting, 
> computed before the truncation): 
> https://gist.github.com/v6ak/f429774566cca097f51445ed93305136
>
> What I haven't tried:
> * Updating the dom0 – a bit chicken-egg problem, since I don't have 
> Internet connection on this laptop. I probably could transfer updates from 
> the other laptop, but I don't think this would make a difference.
> * Use Debian. Due to the kernel version, it does not seem to be worth 
> trying.
>
> Any ideas?
>
> Regards,
> Vít Šesták 'v6ak'
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/52e8577a-0756-4762-ae7e-bfc5b81125da%40googlegroups.com.


[qubes-users] [4.0] Intel Wi-Fi 6 AX200 adapter

2020-03-18 Thread Vít Šesták
Hello,
on a new laptop, I am trying to setup Qubes OS 4.0. I have installed the 
latest point release (i.e., 4.0.3). I have bunch of issues, the most 
important one is that I cannot connect to any network. I have made some 
progress, but now, I am asking for some assistance.

The command lspci shows the adapter as Intel Corporation Wi-Fi 6 AX200 (rev 
1a).

1. Problem: Domain sys-net did not boot at all because of issues with 
attaching ethernet PCI device.
Workaround: I don't care much about ethernet, so I removed the PCI device. 
Not optimal, but easy and good enough for now.

2. Domain sys-net does not even load iwlwifi kernel module.
Cause: I have found that I need kernel 5.1 or 5.2 (depending on the source).
Solution: Use a backup of up-to-date Fedora 30 VM. Configure the mode to 
HVM and the kernel to “(none)”. This will use up-to-date kernel from 
Fedora, which is new-enough.
Relevant link: 
https://www.reddit.com/r/ManjaroLinux/comments/bx0skx/iwlwifi_driver_not_loading_for_intel_ax200_wifi/
Relevant link: 
https://www.intel.com/content/www/us/en/support/articles/05511/network-and-i-o/wireless-networking.html

3. Domain sys-net loads iwlwifi kernel module, but the Wi-Fi fails 
immediately with “Microcode SW error detected. Restarting 0x200”. It 
seems that Fedora automatically retries again and again and spams the log.
This is the issue I am struggling with.

What I have tried:
* Use Fedora 31. I just cloned Fedora 30 on other laptop, created backup 
and transferred to the other laptop. See 
https://github.com/QubesOS/qubes-issues/issues/5289#issuecomment-582442319
* Download ucode from 
https://www.intel.com/content/www/us/en/support/articles/05511/network-and-i-o/wireless-networking.html
* Replace /usr/lib/firmware/iwlwifi-cc-a0-48.ucode by 
/usr/lib/firmware/iwlwifi-cc-a0-46.ucode if `sudo dmesg | grep 'firmware 
version'` suggests that the 48 is being loaded. I did it in the TemplateVM, 
rebooted sys-net and ensured that 46 is being loaded. According to the 
https://www.intel.com/content/www/us/en/support/articles/05511/network-and-i-o/wireless-networking.html
 
, the version 46 is for AX200 and 48 is for AX201.
No combination of those has helped, I am still getting the errors.

Logs (Fedora 31, ucode from Intel):
* Log sample (truncated, because it was too large, but it seems that 
messages are repeating): 
https://gist.github.com/v6ak/1cb7b172f63f8c20d7c4004f7996de39
* Just unique messages (just proves there is nothing more interesting, 
computed before the truncation): 
https://gist.github.com/v6ak/f429774566cca097f51445ed93305136

What I haven't tried:
* Updating the dom0 – a bit chicken-egg problem, since I don't have 
Internet connection on this laptop. I probably could transfer updates from 
the other laptop, but I don't think this would make a difference.
* Use Debian. Due to the kernel version, it does not seem to be worth 
trying.

Any ideas?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/58e60320-c1a0-4684-9a89-0e4b1a5b72bc%40googlegroups.com.


Re: [qubes-users] Re: Write-error on swap-device after having a full storage

2020-01-23 Thread Vít Šesták
Thank you! This has allowed me to mount the volume to a DVM, which has 
allowed me to fix the issue. Just running fsck in the DVM was enough to fix 
the issue.

Maybe I should create an issue (or find an existing one) for that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/084a8fe5-9fee-4273-ac7d-ebcd66d7eeaf%40googlegroups.com.


[qubes-users] Re: Write-error on swap-device after having a full storage

2020-01-22 Thread Vít Šesták
I have tried to debug it further. Unfortunately, I am unable to attach the 
VM's drive to a DVM:

$ qvm-block attach disp1163 dom0:mapper/qubes_dom0-vm--debian--10n--root
qvm-block: error: backend vm 'dom0' doesn't expose device 
'mapper/qubes_dom0-vm--debian--10n--root'

How can I do that?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e388d39-6ef4-4035-80be-23b7e9d1eab6%40googlegroups.com.


[qubes-users] Re: Write-error on swap-device after having a full storage

2020-01-22 Thread Vít Šesták
I have tried to debug it further. Unfortunately, I am unable to attach the 
VM's drive to a DVM:

$ qvm-block attach disp1163 dom0:mapper/qubes_dom0-vm--debian--10n--root
qvm-block: error: backend vm 'dom0' doesn't expose device 
'mapper/qubes_dom0-vm--debian--10n--root'

How can I do that?

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

On Wednesday, January 22, 2020 at 1:43:00 PM UTC+1, Vít Šesták wrote:
>
> Hello,
> I have done this:
>
> 1. Started a template VM update.
> 2. It seems to have run out of space during the update.
> 3. I extended the storage.
>
> Expected result: After extending the storage, it works again.
>
> Actual result: I can boot neither the VM nor the related Template-based 
> VMs. When I try to do so, it switches to emergency mode and I cannot do 
> anything with the VM. It shuts down quickly.
>
> Excerpt from the log:
>  
> https://gist.github.com/v6ak/6685d7b6b686076ff9486bd60d2950e0
>
> This is very strange. The swap file is created again and again on start, 
> isn't it? So, there cannot be no relict from the last run, can it?
>
> Other TemplateVMs work correctly.
>
> Regards,
> Vít Šesták 'v6ak'
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7eb29a3c-e40a-4e92-86ae-27f7294c7027%40googlegroups.com.


[qubes-users] Write-error on swap-device after having a full storage

2020-01-22 Thread Vít Šesták
Hello,
I have done this:

1. Started a template VM update.
2. It seems to have run out of space during the update.
3. I extended the storage.

Expected result: After extending the storage, it works again.

Actual result: I can boot neither the VM nor the related Template-based 
VMs. When I try to do so, it switches to emergency mode and I cannot do 
anything with the VM. It shuts down quickly.

Excerpt from the log:
 
https://gist.github.com/v6ak/6685d7b6b686076ff9486bd60d2950e0

This is very strange. The swap file is created again and again on start, 
isn't it? So, there cannot be no relict from the last run, can it?

Other TemplateVMs work correctly.

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

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


Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2020-01-03 Thread Vít Šesták
While comparing Qubes 4 to Fedora 25 might be tempting, it is not similar as it 
might seem. Qubes 4 is based on Fedora 25, but some parts including kernel are 
independent. So, seeing different kernel-related behavior in Fedora 25 and 
Qubes 4 is definitely not a surprise.

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

On January 3, 2020 6:53:24 PM GMT+01:00, Claudia  wrote:
>January 1, 2020 5:09 PM, "Claudia"  wrote:
>
>> However, I still have a long road ahead of me. I did several
>suspend/resume cycles, and each time I
>> had a different combination of problems, including the mouse
>sticking, the keyboard not working,
>> and finally input/output errors and segmentation faults in the
>terminal. But the Xen problem has
>> been identified nonetheless. I'll try kernel-latest and see if that
>changes anything.
>
>Installed kernel-latest from stable, 5.3.11-1.qubes.x86, and no
>difference as far as I can tell. It resumes fine the first time
>usually, but after the second or third cycle, I get a bunch of io
>errors, as though someone unplugged the SATA connector. I think this is
>actually the underlying cause of the other symptoms. This is with no
>VMs running. No swap.
>
>ata1.00: qc timeout (cmd 0xec)
>ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>ata1.00: limiting SATA link speed to 3.0 Gbps
>ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
>ata1.00: revalidation failed (errno=-5)
>ata1.00: disabled
>sd 0:0:0:0: [sda] Start/Stop Unit failed: Result:
>hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
>sd 0:0:0:0: [sda] tag#21 FAILED Result: hostbyte=DID_BAD_TARGET
>driverbyte=DRIVER_OK
>sd 0:0:0:0: [sda] tag#21 CDB: Write(10) 2a 00 3c 9f [...]
>blk_update_request: I/O error, dev sda, sector [...] op 0x1: (WRITE)
>flags 0x10 phys_seg 1 prio class 0
>BTRFS error (device dm-0): bdev /dev/mapper/luks-[...] errs: wr 1, rd
>0, flush 0, corrupt 0, gen0
>
>Note this different than the Fedora 25 resume behavior. In F25 with
>4.8.6, the screen doesn't power on, but the system seems responsive
>otherwise. For example ctrl-alt-delete reboots after 60 seconds as
>expected. (In Qubes, after resuming a second or third time and getting
>disk errors, when you try to shutdown it will just hang indefinitely.)
>But F25 was running from a USB drive so I wouldn't necessarily know if
>there were SATA errors in that case.
>
>I'll see if I can figure out how to apply the patch to the latest 4.1
>(F31-based) and try it from there. In the mean time, if anyone has any
>ideas please share.
>
>-- 
>You received this message because you are subscribed to a topic in the
>Google Groups "qubes-users" group.
>To unsubscribe from this topic, visit
>https://groups.google.com/d/topic/qubes-users/67LmZ8LsR9A/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to
>qubes-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/8b5cad4abcdce9da863ab033c86752d7%40disroot.org.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86C1ED2B-2651-459F-BF1C-D927C2A2EFA1%40v6ak.com.


Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2019-12-22 Thread Vít Šesták
Qubes123, that's an interesting finding. AFAIU, the CPUID check is rather a 
sanity check – it verifies that the microcode is loaded properly. I also, this 
should be no issue if Qubes provides a fresh microcode…

(And maybe it can cause crash if you suspend after BIOS update, provided that 
the BIOS contains a newer microcode.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/AE8C3618-A803-4AF8-A65B-B4252829A309%40v6ak.com.


Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2019-12-22 Thread Vít Šesták
As far as I know/understand:

* At start, all the PCI devices are assigned to dom0.
* When a qube with an attached PCI device starts, dom0 assigns the PCI device 
to the qube, so it is no longer attached to dom0. It never gets actually 
attached to dom0 automatically (until reboot). If it was, a malicious qube 
could for example flash a malicious firmware to a USB device and shut down in 
order to connect the malicious device to dom0.
* In order to have some additional protection, rd.qubes.hide_all_usb hides all 
USB devices. That is, the USB PCI device is attached to dom0, but Linux ignores 
it, maybe it blacklists related kernel modules.

The behavior you have observed suggests that both detached USB controller and 
ignored USB controller cause an issue. So, maybe the problem is not in the 
process of detaching a controller that is being used, but rather in not having 
the controller available.

Intel includes some USB controller in CPU and quick Googling suggests that so 
does AMD. Maybe there is some AMD-specific code in Linux kernel that expects 
the USB controller to be available for whatever weird reason. Yes, it sounds 
strange, but it is the least implausible explanation I was able to find.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/744c4e79-efef-475a-a3dd-41fd3ded10b3%40googlegroups.com.


[qubes-users] SystemTap in dom0 – kernel debug symbols

2019-10-29 Thread Vít Šesták
Hello,
I wanted to use systemtap (stap) in order to preprocess keyboard events. 
However, when I try to use a simple script, it fails:

$ sudo stap numpad.stp 
> semantic error: while resolving probe point: identifier 'module' at 
> numpad.stp:1:7
> source: probe module("evdev").function("evdev_events"){
>   ^
>
> semantic error: missing x86_64 kernel/module debuginfo [man 
> warning::debuginfo] under '/lib/modules/4.19.79-1.pvops.qubes.x86_64/build'
>
> Missing separate debuginfos, use: debuginfo-install 
> kernel-4.19.79-1.pvops.qubes.x86_64 
> Pass 2: analysis failed.  [man error::pass2]
>
>
The directory /lib/modules/4.19.79-1.pvops.qubes.x86_64/build exists and 
contains some files, but it probably does not contain debuginfo – it does 
not contain any file matching *debug*.

I have tried running debuginfo-install kernel-4.19.79-1.pvops.qubes.x86_64, 
but it uses DNF/YUM internally, so it cannot work.

Is there any way to get kernel debug symbols in dom0?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6c29c262-48c8-4b35-9ea7-755738e29004%40googlegroups.com.


[qubes-users] Re: Why is there no option to save VM state?

2019-10-29 Thread Vít Šesták
Actually, not saving state is not a security feature per se*. It is a 
consequence of template-based VM design.

The root filesystem of a template-based VM is cloned from the template on 
boot. This allows performing updates of many VMs at once by updating just 
one TemplateVM. There is however a filesystem for storing some state 
(typically mounted at /rw).

If it was a security feature, it would be quite weak. On typical OSes, the 
attacker has plenty of places where they can drop/hook a malware, for 
example .bashrc and /rw/config/rc.local.

If you want to store something in other directories than /home, /usr/local 
and similar, you can:

a. Extend the list of persisted directories: 
https://www.qubes-os.org/doc/bind-dirs/
b. Create a Standalone VM. This allows you full control of the VM, but it 
will take more space and you won't be able to update it just by updating 
its template.

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

*) Well, it can improve security by making administration easier. Without 
that, it would be easy to make some infrequently-used VM outdated. When you 
would start the VM after some time, you would risk various attacks sooner 
or lated.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4c9b2123-86a5-4c55-859d-f9c10708757c%40googlegroups.com.


Re: [qubes-users] Qubes does not recover from crashed X11 (related to shmoverride and GUID)

2019-08-25 Thread Vít Šesták
OK, I have created https://github.com/QubesOS/qubes-issues/issues/5273 .

There is not much new information in the issue. The main new information is 
that the recovery by renaming the shm.id.0 and restarting lightdm is just 
partial – all running VMs lose sound output (until rebooted) and some 
runnng VMs also hang indefinitely and cannot even respond to qvm-run -p 
vm-name ls.

V6

On Thursday, August 22, 2019 at 3:08:41 PM UTC+2, David Hobach wrote:
>
> On 8/21/19 11:59 PM, Vít Šesták wrote: 
> > Hello, 
> > sometimes, Intel driver makes my X11 crash (see X11-crash.log). It 
> happens 
> > usually when I rotate the screen, but also sometimes without any 
> apparent 
> > reason. I can usually replicate in a minute by rotating the screen like 
> > crazy. Note that this situation does not happen when I log out or kill 
> the 
> > X server. 
> > 
> > What's worse, Qubes OS does not recover properly. It displays login 
> prompt, 
> > but when I log in, all previously opened windows just flash and the GUID 
> > crashes. In the debug output, it complains about something related to 
> SHM, 
> > see guid.disp7824.log. Even newly started VM don't have a working GUID. 
> > 
> > Some debugging with strace has accidentally* pointed me to 
> > /var/run/qubes/shm.id.0 file. When I rename the file, the GUID seems to 
> be 
> > able to start it again. The shm.id.0 fle is recreated with a different 
> > number and it works again. 
> > 
> > I have found that the file is related to shmoverride documented at 
> > https://github.com/QubesOS/qubes-gui-daemon/tree/master/shmoverride . I 
> > however don't have much further idea about that. Well, it is some X11 
> > shared memory and it has some identifier. When the X11 crashes, maybe it 
> > gets corrupted or maybe just the old file is not removed. I don't think 
> > there is a corruption of the SHM, as some similar situation happened on 
> OOM 
> > kill. So maybe it is just about some final cleaning missing there. Do 
> you 
> > have some further idea? 
> > 
> > Regards, 
> > Vít Šesták 'v6ak' 
> > 
> > *) Well, I hit a kind of antiheisenbug. GUID does not work when I run it 
> > with strace (even before the X11 crash), because strace breaks SUID for 
> > obvious reason. As a result, it will fail when trying to access 
> > /var/run/qubes/shm.id.0. Nevertheless, this file seems to be relevant, 
> > although the discovery was rather random. 
>
> Hi Vit, 
>
> I'd recommend opening a respective Qubes issue on github as it looks 
> like a bug to me. 
>
> BR 
> David 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c04a619b-0362-4b0f-ba62-bded7b8512e7%40googlegroups.com.


[qubes-users] Qubes does not recover from crashed X11 (related to shmoverride and GUID)

2019-08-21 Thread Vít Šesták
Hello,
sometimes, Intel driver makes my X11 crash (see X11-crash.log). It happens 
usually when I rotate the screen, but also sometimes without any apparent 
reason. I can usually replicate in a minute by rotating the screen like 
crazy. Note that this situation does not happen when I log out or kill the 
X server.

What's worse, Qubes OS does not recover properly. It displays login prompt, 
but when I log in, all previously opened windows just flash and the GUID 
crashes. In the debug output, it complains about something related to SHM, 
see guid.disp7824.log. Even newly started VM don't have a working GUID.

Some debugging with strace has accidentally* pointed me to 
/var/run/qubes/shm.id.0 file. When I rename the file, the GUID seems to be 
able to start it again. The shm.id.0 fle is recreated with a different 
number and it works again.

I have found that the file is related to shmoverride documented at 
https://github.com/QubesOS/qubes-gui-daemon/tree/master/shmoverride . I 
however don't have much further idea about that. Well, it is some X11 
shared memory and it has some identifier. When the X11 crashes, maybe it 
gets corrupted or maybe just the old file is not removed. I don't think 
there is a corruption of the SHM, as some similar situation happened on OOM 
kill. So maybe it is just about some final cleaning missing there. Do you 
have some further idea?

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

*) Well, I hit a kind of antiheisenbug. GUID does not work when I run it 
with strace (even before the X11 crash), because strace breaks SUID for 
obvious reason. As a result, it will fail when trying to access 
/var/run/qubes/shm.id.0. Nevertheless, this file seems to be relevant, 
although the discovery was rather random.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d649df91-4e6c-4660-a84c-e439412b6eb6%40googlegroups.com.
Icon size: 128x128
ErrorHandler: BadValue (integer parameter out of range for operation)
 Major opcode: 130 (MIT-SHM)
 Minor opcode: 3 (X_ShmPutImage)
 Value:0x1e4
 Failed serial number:  110
 Current serial number: 111
[ 47101.381] (EE) Backtrace:
[ 47101.389] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x59ea19]
[ 47101.390] (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x50) [0x7ef51523961f]
[ 47101.391] (EE) 2: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0xc7e7) [0x7ef510c656c7]
[ 47101.391] (EE) 3: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0xce93) [0x7ef510c66463]
[ 47101.391] (EE) 4: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0xd172) [0x7ef510c669b2]
[ 47101.392] (EE) 5: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0xe5cf) [0x7ef510c692df]
[ 47101.392] (EE) 6: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x13e6e) [0x7ef510c743be]
[ 47101.392] (EE) 7: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x6b8a4) [0x7ef510d23674]
[ 47101.393] (EE) 8: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x6c0ec) [0x7ef510d246cc]
[ 47101.393] (EE) 9: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x6e16a) [0x7ef510d2811a]
[ 47101.394] (EE) 10: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x2cce4) [0x7ef510ca5844]
[ 47101.394] (EE) 11: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x61749) [0x7ef510d0f489]
[ 47101.394] (EE) 12: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x433ae) [0x7ef510cd2e7e]
[ 47101.395] (EE) 13: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x446d6) [0x7ef510cd5316]
[ 47101.395] (EE) 14: /usr/lib64/xorg/modules/drivers/intel_drv.so 
(_init+0x6362d) [0x7ef510d1336d]
[ 47101.395] (EE) 15: /usr/bin/X (BlockHandler+0x4e) [0x43ba3e]
[ 47101.396] (EE) 16: /usr/bin/X (WaitForSomething+0x141) [0x598441]
[ 47101.396] (EE) 17: /usr/bin/X (SendErrorToClient+0x13a) [0x436eaa]
[ 47101.396] (EE) 18: /usr/bin/X (InitFonts+0x428) [0x43b0b8]
[ 47101.399] (EE) 19: /lib64/libc.so.6 (__libc_start_main+0xf1) [0x7ef514e82431]
[ 47101.399] (EE) 20: /usr/bin/X (_start+0x2a) [0x424d5a]
[ 47101.399] (EE) 
[ 47101.399] (EE) Segmentation fault at address 0x8
[ 47101.399] (EE) 
Fatal server error:
[ 47101.399] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 47101.399] (EE) 
[ 47101.399] (EE) 
Please consult the Fedora Project support 
 at http://wiki.x.org
 for help. 
[ 47101.399] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[ 47101.399] (EE) 
[ 47101.399] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 47101.463] (EE) Server terminated with error (1). Closing log file.


[qubes-users] Messages in boot console

2019-07-21 Thread Vít Šesták
Hello,
Qubes OS used to allow me to show startup console by pressing escape.
After a recent upgrade, Qubes shows nothing there. Is it intentional? Can I 
reenable it?
Regards,
Vít Šesták 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2026e67f-376d-490a-9dce-e1934f5606f0%40googlegroups.com.


[qubes-users] Recommendation for on-screen keyboard

2019-06-22 Thread Vít Šesták
I am not sure about the level of support of virtual keyboards.

If you install the keyboard in dom0, it can either:

a. work as a stupid keyboard on screen – shown all the time unless you manually 
hide it and regardless the content under the keyboard
b. work as a smart keyboard on screen (shown if and only if there is a place to 
type in and regarding the application) like on Android. This would be limited 
for dom0 apps, as dom0 has no information about the text fields in AppVMs.

In AppVM, it could work well and smart, at least in theory. But it would be 
limited to the AppVM, for obvious reason.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9888d055-7062-4f48-ad63-a3cad07c4f14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] R4: Graphics issues: flashbacks and rendering freezes

2019-05-26 Thread Vít Šesták
Hello,
I have two rendering issues. Maybe they are related, maybe they aren't.


## 1. screen flashbacks

I don't remember when it started.

Some parts of screen have short random flashbacks, i.e. it shows the content 
shown some time ago. You can see a short video there:

https://drive.google.com/file/d/1ypHdDKiPpeE3SfwsdAwDzR3e-AyN932Q/view?usp=sharing

I am not moving the cursor, but it sometimes flashes the previous state.

This happens even on lockscreen (=> dom0-related). I remember I have 
screenshotted it (I can't find the screenshot, though), so it does not look 
like screen controller issue.

Usually, alt+tab; alt+tab (i.e., switching to another window and then back) 
helps, at least for some time.

## 2. screen rendering freezes

This one is likely related to the recent update. Screen rendering freezes 
completely (except mouse cursor) with kwin in some deterministic cases:

* Alt+tab.
* Screen rotated by 90° or -90°. (It is fine for 180°.)

With Xfwm, I see no such issue.

## Some info about my computer

CPU+GPU: Intel i7 7500U

$ cat /proc/cmdline
root=/dev/mapper/qubes_dom0-root rd.lvm.lv=qubes_dom0/root rd.lvm.lv=volatile 
i915.alpha_support=1 rhgb quiet rd.qubes.hide_all_usb 
plymouth.ignore-serial-consoles
$ uname -r
4.19.43-1.pvops.qubes.x86_64

Do you have any idea what to do with it?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/47e9caa3-5f7b-4698-a94e-8fc3b525ed5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Alt+Tab not redirected in AppVM

2019-04-09 Thread Vít Šesták
In some cases, Alt+Win+Tab is not handled by dom0 (at least with Kwin) and the 
remote VM handles it as Alt+Tab (AFAIR at least Windows and Unity).

-- 
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/d37aaff2-2482-420e-a038-16f8cbfce995%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] [4.0] Kernel panic in HVM

2019-03-18 Thread Vít Šesták
Thank you. The error message has told me that there was an attempt to kill the 
error process. I was not sure about the reason, but I have guessed that it is 
caused by low RAM (I had 400MiB, which is probably the default for some 
reason). Increasing the RAM has helped. Well, it had caused an issue with blank 
screen, since the console was redirected to hvc0, but booting with more RAM and 
without console=hvc0 has succeeded.

So, my issue is resolved, thank you for the assistance.

I wonder how was chosen the default RAM for HVMs. I believe that 400MiB is 
rarely enough nowadays.

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

On March 18, 2019 2:00:48 AM GMT+01:00, "Marek Marczykowski-Górecki" 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>On Sun, Mar 17, 2019 at 04:02:31PM -0700, Vít Šesták wrote:
>> Hello,
>> I have tried to boot Fedora 29 Silverblue in a HVM from the official
>ISO. I have noticed that there is some kernel panic before the HVM
>shuts down. The problem is that I cannot read it. Is there any way to
>read it, e.g., by disabling the automatic reboot somehow?
>
>Try pointing kernel at hvc0 console (console=hvc0 kernel arg), then you
>should get it in /var/log/xen/console/guest-VMNAME.log.
>
>- -- 
>Best Regards,
>Marek Marczykowski-Górecki
>Invisible Things Lab
>A: Because it messes up the order in which people normally read text.
>Q: Why is top-posting such a bad thing?
>-BEGIN PGP SIGNATURE-
>
>iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlyO7cAACgkQ24/THMrX
>1yxDRgf+MLv90YwLeNuw5fhZQb2Qh3krQaA6ogJaEmFxvpR/kLpElvNxhl3p8UCU
>Kgna/yQOnOBb2bHMFJTnUfH1pEdvr0zPk+OvY+DljeOt0hbhagLgmaIHBHGoqOng
>C1ugesrBAVkvoMHvF8i9ndllQXZNtILF//Brd/BVctGW+qe5sv8Q5VuetBo9TqVL
>8REEHmue/z4QQ+25NT5L4eFnmjfLS/9R1ayd9cMK+J1STwiJcuorjv9SDmd0p/O5
>WGNGXVIzw9WSUe5Psr0G5n9EVFA0VjPZqoITRrONTVeBq3K4aKL21uysjF4FJgIb
>USXg57YnD5tH/dVFdZh9Il7qUvE2lw==
>=a+tu
>-END PGP SIGNATURE-
>
>-- 
>You received this message because you are subscribed to a topic in the
>Google Groups "qubes-users" group.
>To unsubscribe from this topic, visit
>https://groups.google.com/d/topic/qubes-users/XdPXnRbbxPk/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to
>qubes-users+unsubscr...@googlegroups.com.
>To post to this group, send email to qubes-users@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/qubes-users/20190318010048.GB10743%40mail-itl.
>For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/A6FBD18D-ED42-4000-8852-95D74173B362%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] [4.0] Kernel panic in HVM

2019-03-17 Thread Vít Šesták
Hello,
I have tried to boot Fedora 29 Silverblue in a HVM from the official ISO. I 
have noticed that there is some kernel panic before the HVM shuts down. The 
problem is that I cannot read it. Is there any way to read it, e.g., by 
disabling the automatic reboot somehow?

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

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


Re: [qubes-users] Re: Android-x86 7.1-r2 with GAPPS installation guide

2019-02-26 Thread Vít Šesták
I was able to run PrimeOS live, but I had exactly the same issue with 
installation.

The explanation with /dev/xvdX sopunds plausible. Maybe it has a half support 
for Xen virtual devices – the kernel supports them (so they are not emulated 
like in Windows), but the installer has no idea about them…

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/026DBC86-D4A9-42D1-8CD5-AFBF8EE7BEB6%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: What is the state of automatic updates?

2019-02-24 Thread Vít Šesták
Why? I suggest having updates as automated as possible – for security reasons. 
It allows you to have all the latest security updates as soon as possible.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ccae666f-b60b-4e0c-aec4-2cfda3d78e43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Android-x86 7.1-r2 with GAPPS installation guide

2019-02-24 Thread Vít Šesták
Thank you for the work. I have few points:

* If we don't verify the commit/tag, I'd suggest downloading the source through 
HTTPS instead: https://scm.osdn.net/gitroot/android-x86/manifest.git
* You mention that we need a 30GB swap, but you don't mention the RAM you had 
assigned to the VM. What was the RAM? I would probably prefer using more RAM to 
swapping.
* Keeping with Android security updates will feel a bit like recompiling Gentoo 
every month…
* I have looked for GSIs (generic system images). Unfortunately, I haven't 
found any for x86.
* It should be easy to make a TemplateVM. Just use the private disk image 
(which is typically /rw) for /data.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5e1a604e-14cc-4971-99c2-72071cf7c146%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: QSB #46: APT update mechanism vulnerability

2019-02-14 Thread Vít Šesták
On February 14, 2019 6:18:47 PM GMT+01:00, "Marek Marczykowski-Górecki" wrote:
>On Thu, Feb 14, 2019 at 05:58:09PM +0100, Vít Šesták wrote:
>> When I update dom0 and then Debian/Whonix without restarting the Qube
>Manager or Update “widget”*, is it enough? Or I need to restart the
>updater app (or maybe whole Qubes)?
>
>No, you need to restart it - just close its main window. Unlike 3.2,
>there is no need for additional steps like right-clicking on Q->quit.
>Similarly, closing updater gui is enough, even if "updates available"
>icon/widget stays there (the updater gui is a separate process).

That sounds like something that informed users are able to do, but uninformed 
users might feel no reason for doing so. It is (obviously) up to you, but I 
suggest adding this information somewhere near downloads.

>> *) I don't like calling a „widget“ something that opens a real
>window. It reminds me Android widgets, so I rather imagine the
>something on desktop what is available only when all windows are
>minimized/closed/nonmaximized.
>
>I agree. But right now we have two similar functionalities and I try to
>name them differently. So, I call the new updater "widget", because
>it's
>started from a widget...

Maybe I use it differently than I am supposed to. Alt+F3, “qubes update”*, 
enter. I don't know any widget I can start it from.

>PS was dropping mailing list intentional?

Just accidental…

*) Well, I usually just type some prefix that makes the relevant item 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/0B42755A-8FF3-4E8A-9B91-441E46CF1B94%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: QSB #46: APT update mechanism vulnerability

2019-02-13 Thread Vít Šesták
Since Qubes 4.0.1 was released [1] before your message and before the DSA [2], 
I assume it is not a good idea to install Debian and Whonix from the 4.0.1 
installation media, is it?

If it is right, then I suggest adding a note on the download page [3] until 
4.0.2 release.

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

[1] https://www.qubes-os.org/news/2019/01/09/qubes-401/
[2] https://www.debian.org/security/2019/dsa-4371
[3] https://www.qubes-os.org/downloads/

-- 
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/a232d218-afb4-47c5-a3f2-bacd702731bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] OS rescue in Q4.0.1

2019-02-13 Thread Vít Šesták
Hello,
in Q3.2, there was an option to boot system rescue from the installation media. 
In Q4, there is no longer such option. However, as MarMarek has mentioned, we 
can use Ctrl+Shift+F2 and commands “killall -9 anaconda; anaconda --rescue”.* 
This really launches the rescue. I understand why this became harder and so 
far, it is OK.

When I run the rescue, it asks me for my password. Then, it usually fails after 
taking much time. Usually, I can see that the LVM has appeared there (so the 
LUKS is decrypted and the password was obviously correct). I can switch to 
another console and mount root from there. But I wonder why it does not work 
straightforwardly.

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


*) Have you tried Googling for “anaconda rescue”? ;)

-- 
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/19e38941-aec8-4adb-9802-b85ad376fb71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Keyboard backlight color based on active qube

2018-12-20 Thread Vít Šesták
So, you have found an ancient UNIX command to be useful for fuzzy testing: cat.

-- 
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/dc89750e-b053-4924-8615-21a8d46b8d10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-10-18 Thread Vít Šesták
Marmarek has identified the issue and fixed it: 
https://github.com/QubesOS/qubes-issues/issues/4351

So if you are patient, you can just wait until you see it in current 
repository. (There will be likely Gihtub comment.)

If you are eager, you can wait until it is in testing repository. (Again, we 
will probably see a Github comment.)

If you are supereager, you can compile it yourself 

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4438d31f-d9df-448c-b4cd-f62baafb27e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-02-11 Thread Vít Šesták
I am sorry for the monolog, but I have some further ideas and findings.

I see two promising options to make screensharing great again:

a. VM screensharing: It would share the screen of the current VM and nothing 
else. We need to get in-VM screenshots working for this. Or you can use a VNC 
loopback session with its drawbacks.
b. Full screensharing. This requires to pipe screen contents from dom0 to a 
specific domU. Maybe we need to stream it to some window that cover everything 
while being ignored by qubes-gui.

Technical findings:

When considering the most common VMs in Qubes, none of those two variants 
currently works well. When I try to screenshot the main X11 of a PV domU, I get 
a solid white image. This is true for any screenscrapping technique I have 
tried. I am not sure what is the reason of white screenshot, but I've traced it 
a bit:

* The color is not related to xsetroot call in /usr/bin/qubes-session (i.e., 
you can change it to some other color in a StandaloneVM and reboot it, but you 
will still get white screenshot).
* It is not related to xorg.conf and/or the dummyqbs driver. First, changing 
“dummyqbs” to “dummy” does not help. Second, when I copy 
/etc/X11/xorg-qubes.conf to /etc/X11/xorg.conf run a second X11 session (as :1) 
and screenshot it (e.g., env DISPLAY=:1 scrot out.png && feh out.png), the 
screenshot works. (Maybe you will want to run something there to see it, e.g., 
env DISPLAY=:1 xterm&.)
* It is not related to window manager. When i run a WM (Openbox) in standard 
Qubes session, it does not help. I believe it is also true vice versa.
* It seems to be related to qubes-gui process. When I kill it, screenshots (and 
thus screensharing) starts working. But obviously, you cannot interact with the 
GUI.

You can see it on a simple experiment. I've used two sessions of a DVM started 
by command qvm-run '$dispvm' bash. This creates some inconvenient Bash session 
(e.g., you cannot see prompts and error messages), but it is good enough to run 
few commands as follows:

sudo apt install scrot # Install screenshoting app. Adjust this if you are not 
on Debian.
xterm& # run some app that will be seen on screenshot
# sudo killall qubes-gui # Run this in one VM only in order to see differences.
ps aux | grep qubes-gui # See if it is killed
(rm -f out.png && scrot out.png && cat out.png | qvm-run '$dispvm' 'feh -') 
2>&1 # Look at the result. Since the VM might be incapable of showing some GUI, 
I start a new VM.

You might need to adjust the commands or your environment a bit (e.g., install 
feh if not installed), but it should be trivial and obvious.

I do not know why qubes-gui makes such difference. The source is at 
https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/gui-agent/vmside.c 
, but I still don't know why it behaves this way. There are two occurrences of 
“white” (case-insensitive), but I don't understand the code much. But I have 
found some interesting part: “/* pretend that GUI agent is window manager */”. 
So, it tries to look like some window manager. This is strange, as Openbox does 
not complain that some WM is already running when I run it within a Qubes 
session. But I don't understand X11 details much, which is probably the reason 
I don't understand the linked source code much.

No, I don't have a solution. I have few intermediate results that might be 
useful for someone to find something more.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/626cd5a7-97b0-497b-8d85-2eb7df9e9402%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-02-10 Thread Vít Šesták
Just another idea: Since the video approach is sooo slow, I've tried another 
approach. This one is suboptimal by design, but it is much faster than the 
recordMyDesktop variant. This one requires a VNC loopback session or other way 
of getting another session with its own background. (This is something that 
would be required for real screensharing anyway.) You can easily get it by apt 
install tigervnc-standalone-server tigervnc-viewer openbox (or similar command 
on non-Debian system), running vncpasswd (configure any password, you don't 
have to remember it), running tigervncserver and then running the viewer 
command mentioned it server's output.

There is my hack. It assumes that:
* /tmp/out.bmp is a symlink to /dev/stdout. The reason is the same as with the 
video approach.
* You have scrot installed in dom0.
* You have feh installed in the target VM.
* Your VNC loopback session has display :1. (You can change it.)
* You want to pipe it to disp3. (You can change it.)

The command to run in dom0:

while true; do (scrot /tmp/out.bmp | qvm-run disp3 -p 'env DISPLAY=:1 feh 
--bg-center --no-fehbg -'); done

It is suboptimal for many reasons:

* It forks several processes in both dom0 and domU for each screenshot.
* It opens a new RPC call for each frame. (Which causes previous unoptimality.)
* All screenshots are saved in /tmp (internal behavior of feh). This probably 
matters less when /tmp is tmpfs, but still.
* Works fully synchronously.

Actual performance on my laptop was about 2 FPS (measured by my eyes), which is 
not great, but it works much better than the video. For some purposes, 2FPs 
might be useable. Not sure why this is better than the video, maybe it is due 
to missing compression and decompression, maybe it is due to missing buffering.

How the performance can be improved:

1. Use a single pipe, don't open a new RPC call for each frame. (This might get 
tricky due to buffering. It might be important to verify that it works well 
even if the consumer is slower than producer.)
2. Use a single process as producer instead of looped scrot.
3. Use a single process as consumer instead of looped feh.

Another idea is to use half-duplex VNC, but this might be also tricky. The goal 
is not to allow to pass any input from the untrusted VM to VNC server in dom0, 
maybe except information about potential congestion (i.e., situation when 
consumer is slower than producer). I am not sure if VNC is designed for that, 
but Wireshark capture of session with -ViewOnly on client-side looks still a 
bit chatty. There are many Authentication Response messages for some time 
(WTF?) and many Fence messages (hmm, probably synchronization).

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4a8bff52-744b-4233-b87a-ddebe23a52c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-02-10 Thread Vít Šesták
I've implemented my approach of screensharing. It pipes content scrapped from 
dom0 to a VM. I don't call it a success, because the FPS is terribly low. But 
maybe someone can try to get it even further.

Recording:
* VLC and ffmpeg could be good choices (with probably many options for 
adjusting it for your needs), but they aren't available in Fedora unless you 
use some third-party repository, which is not what I wanted.
* recordMyDesktop works with some hacks and config, but its FPS is terribly low 
(at least when using --on-the-fly-encoding). It also does not have much 
encoding options. It would be probably ideal to use uncompressed video, because 
transfer is cheap and encoding/decoding is GPU/CPU-intensive. (Actually, GPU 
can at least theoretically help with encoding, as it happens in dom0. It can't 
help with video decoding.) I haven't tried to adjust video quality, because I 
am not sure about the effect on encoding performance.
* Not sure about other alternatives available in Fedora without additional 
repositories. I am not aware about any.
* Maybe we could try the software intended to pipe windows from domUs to dom0 
for the other way?

Playback:

* I use MPlayer, but any player capable of playing a pipe can do the job.
* If you want to use it in a VNC session, you will probably want to add 
something like “env DISPLAY=:1”. But now, it is too early.
* In my experiment, the domU part was Debian 9, but I don't think this matters 
much.

The script with comments: 
https://gist.github.com/v6ak/1678244cd71a0ebd019531d02a149c8f

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

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


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

2018-02-08 Thread Vít Šesták
On Thursday, February 1, 2018 at 10:31:14 AM UTC+1, Vít Šesták wrote:
> I have also seen one strange change (not sure about the timing, but it might 
> be related to the update) that might affect security of those who use some 
> pseudo-DVM for sys-usb. When I remove USB „mouse“* and attach it back, the 
> mouse is automatically allowed. Maybe the connection has not been closed. The 
> strange part is that this does not apply for USB keyboard, although the input 
> proxy works virtually the same.

Please ignore this part, the issues with touchpad/mice rather looks like a my 
fault.

V6

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9630075c-0ca7-4acb-a17e-7d19755b4e30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: [qubes-project] Hosting for OpenQA instance

2018-02-08 Thread Vít Šesták
Hello,
what's the current status?

If it has not been resolved, I'd like to ask if you require the hardware to 
have VT-d. This is a requirement for Q4, but maybe this is not a requirement 
when it runs under KVM with virtualized hardware. (Not sure.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/366e1e1e-37b2-40e5-b56c-84c5ae6f628c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] reboot sys-net

2018-02-02 Thread Vít Šesták
I remember some issues with reattaching in the past, but recently, the 
qvm-shutdown --wait --force sys-net && qvm-start sys-net seems to be working. 
It can fail in some cases like when you have a paused VM (a feature that seems 
to cause various issues in 3.2) and it does nto work id the sys-net is shut 
dows from the VM itself.

You can do the same for both sys-net and sys-firewall at once. The qvm-shutdown 
command accepts multiple VM names. For qvm-start, you can just request start of 
sys-firewall, because the sys-net VM is started automatically in such case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ef9188b0-4402-45c8-85f6-1527a7e8b972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-02-01 Thread Vít Šesták


On February 1, 2018 6:42:08 PM GMT+01:00, Dave C <qu...@dave-cohen.com> wrote:
>Indeed, I stand corrected.  This point could apply to a restrictive
>firewall, but the VM would need to network with the local VM running
>vncserver.

BTW, you could also pipe the network communication through qrexec. This could 
be more secure than restrictive firewall.

>I can imagine opening a terminal in the VM running vncserver and the
>window manager.  Could attacker open a terminal in other vm that has
>opened some application in that display?  (Application that is not a
>terminal, I mean.  I do see how an attacker could use any application
>shown in the display.)

It depends on what application you mean. I can see how a webbrowser can be used 
as a gadget to open terminal and some other applications (e.g., Libreoffice) 
can be used to open webbrowser. (And maybe LibreOffice supports macros or 
something similar, so attacker does not need to browser/terminal. Also, a text 
editor like Geany can be abused for editing files like .bashrc.

I am not sure about generic applications with no such option of saving files 
and opening them in some apps. I remember statements that X11 is not designed 
for isolation and some those statements look like this is possible generally by 
design. I was able to neither confirm nor deny it in a short time.

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

Maybe top-posting is bad. However, quoting whole message (including quotes of 
quotes and quotes of quotes of quotes etc.) before your message is even worse. 
Please don't let others scroll extensively.

-- 
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/0254EE1B-EC02-453F-BC96-A9D7218CFBA9%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Running Windows from Qubes VM ?

2018-02-01 Thread Vít Šesták
On Saturday, January 13, 2018 at 9:24:49 AM UTC+1, msg...@gmail.com wrote:
> Maybe there is no bootloader on /dev/sdc1? Try to boot from livecd and fix 
> bootloader.

This is very likely. Bootloader is usually installed on whole drive (e.g., 
/dev/sdc) rather than on its partition (e.g., /dev/sdc1). I am not even sure if 
BIOS could boot from bootloader installed on a partition. Maybe also Windows do 
not like the fact they have just a partition and not a partition table.

Moreover, I do not recommend booting Windows this way. If they are on a 
partition accessible to dom0, the dom0 might try to parse its filesystem etc., 
which might expose some vulnerabilities. It seems to be more wise to convert 
the /dev/sdc1 to some image file (or a LVM volume, provided that you have 
carefully configured LVM, like Q4 has).

-- 
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/8ba05d29-c9b2-43c4-8598-06e3798748f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-02-01 Thread Vít Šesták
I have installed the patch from security-testing. On system resume, I sometimes 
notice effects like:

* Time synced noticeably late. For example, when my laptop wakes up on morning, 
Thunderbird considers today's e-mails as e-mails from future day (so it 
displays date, not only time).
* Some VMs don't get the time synced at all (or at least after a huge delay 
that looks like forever). I've repeatedly seen this at some VM with a 
background bot.
* The same applies to Wi-Fi. It sometimes seems to be attached even after I 
type the password (which is not short).

I have also seen one strange change (not sure about the timing, but it might be 
related to the update) that might affect security of those who use some 
pseudo-DVM for sys-usb. When I remove USB „mouse“* and attach it back, the 
mouse is automatically allowed. Maybe the connection has not been closed. The 
strange part is that this does not apply for USB keyboard, although the input 
proxy works virtually the same.

So, before adding an untrusted device, it is not enough to disconnect USB 
keyboard/touchpad. I also have to reboot the sys-usb VM.

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

*) I have two USB „mice“, none of them is actual traditional mouse. One of them 
is a touchpad that uses mouse USB protocol. The other one is a keyboard that 
has capability of clicking and looks like multiple input devices on the USB 
protocol.

-- 
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/3bec4ff9-5ca5-4951-bf88-8478138b1fec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS screensharing

2018-01-28 Thread Vít Šesták


On January 27, 2018 7:57:02 AM GMT+01:00, Dave C <qu...@dave-cohen.com> wrote:
>* VMs that can't access the conference site (i.e. bluejeans.com) or
>can't access the net at all

How can a VM without network access open a window in the X11 accessible from 
network?

>* VMs that don't have vncserver installed, or don't have a plugin
>needed to screenshare
IMHO a minor gain.

>My approach lowers security while screensharing.  But the rest of the
>time, not screensharing, the VMs are running with normal firewall
>settings.

It is likely that a VM can infect any other of the VMs (or the screensharing 
VM). There are multiple potential ways to do so:

a. Exploit some vulnerability in X11 protocol implementation.
b. Open a terminal (if not already opened) and type a command. This is 
possible, because any client can inject any input events to other client.
c. Download some file using webbrowser and run/install it (e.g., using some 
packaging system).
d. I remember I have read that X11 effectively provides no isolation between 
apps and I had an impression that any app can by design even run some code in 
another client. However, don't take this point as verified unless you verify it 
from some other source.

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

General note: Maybe top-posting is bad. However, quoting whole message 
(including quotes of quotes and quotes of quotes of quotes etc.) before your 
message is even worse. Please don't let others scroll extensively.

-- 
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/85D57652-4F14-41F7-9020-506468F33FEC%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Save virtual machine state?

2018-01-25 Thread Vít Šesták
On pausing: Remember that there are some issues. For example, the VMs resume 
after sleep Also, it seems it does not work well with changes of 
monitor configuration.

On hibernation: This can work with standalone VMs, but it is problematic by 
design on template-based (although probably possible) VMs. once you hibernate a 
VM, you need to remember all the state, including the root filesystem. Unlike 
traditional systems, the root device can be updated outside the VM, just by 
running the TemplateVM. In such case, Qubes has to ensure that the VM won't see 
the changes before reboot. Qubes has some ways to achieve this for running VMs 
(you see, you don't need to shut the template-based VMs down when updating the 
template), but it probably degrades some performance. Having to maintain it for 
some forgotten hibernated VMs would be some unexpected source of performance 
hit. So, it would be probably technically feasible (though maybe not easy), but 
hard for UX.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/53c68803-2ed6-433c-bafa-ee12ffc123f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

2018-01-25 Thread Vít Šesták
Raspberry Pi as a DVM is not that easy, but it is probably possible:

1. Let's have an image for the "VM" in your laptop.
2. Insert a SD card to the laptop and dd the image.
3. Boot Raspberry Pi.

This assumes that:

* You perform this every time you want a clean state.
* Raspberry Pi has no persistent storage outside of the SD card.
* MicroSD card cannot be hacked (e.g., Raspberry Pi cannot overwrite the 
firmware).
* Your laptop is not configured to parse anything from the card. (If it is not 
that case, it could try to compromise your laptop.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8286b8c8-4b3c-4980-88a0-7bc77d87be83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: GPU?

2018-01-25 Thread Vít Šesták


On January 25, 2018 5:56:41 PM GMT+01:00, "taii...@gmx.com" <taii...@gmx.com> 
wrote:
>On 01/18/2018 04:00 PM, Alex Dubois wrote:
>Correct me if I am wrong but I don't see the issue with an apparmor 
>restricted qemu running in dom0...

Well, AppArmor might reduce the attack surface, but remember that:

1. Qubes was not intended to run QEMU in dom0 and
2. Qubes dom0 is often based on outdated Fedora. While ITL provides security 
updates for security-critical components, it does not necessarily cover all 
vulnerabilities in kernel and apparmor, because of #1.
3. Linux kernel is considered as quite weaker than Xen in terms of attack 
surface, so exploits in Linux kernel are more likely. AppArmor might mitigate 
*some* of them, but not all.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/203975FF-A8A0-4EEF-8C0B-20AC09EC19EE%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-25 Thread Vít Šesták
There actually is a GUI for checking dom0 updates. In Qubes VM manager, select 
dom0 and click the update button in top toolbar. Or you can also use the 
context menu.

OTOH, in this case, the main benefit of the GUI are the notifications. The 
update process itself is usually more friendly from commandline. And you cannot 
install security-testing using GUI.

-- 
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/17ef6cbe-00d4-45ac-93e2-3220d4c01e81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS screensharing

2018-01-25 Thread Vít Šesták
Dave, why you start a new VM and not just use a loopback? Is the reason sharing 
apps from multiple VMs? If si, you are at least significantly weakening 
isolation. Maybe you are not keeping any, not sure. X11 was not designed for 
isolation at all.

Nuno, this is probably possible, but not so trivial. You would need Grub (as 
HVMs and PVs have different boot mechanisms) and you would need to adjust some 
things made for PVs - probably some startup services and some X11 config files. 
Those changes (especially the Grub change) would require a modification of the 
template. And you would also need to reboot to change it.

I have some idea for full screensharing (considering Qubes-agnostic generic 
screensharing apps):

1. Scrap the screen in dom0 and send it to a VM through Qubes RPC. It seems 
that VLC can be used for that. Uncompressed video could be ideal for low 
latency and lower CPU usage. Compression does not make much sense within a 
physical computer. But compressed video could be also acceptable. I believe 
video encoding is not a risky operation, so it can be done in dom0 without any 
additional real risk.
2. In the VM, play the video in a VNC-loopback X11 session.
3. Run the screensharing app of your choice in the same X11 session.
4. Make the screensharing video fullscreen.

Of course, this would make some fractal effect when the VNC client is visible 
on screen ☺

I haven't tried it yet, but it seems

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/624034b4-6326-4a7a-9484-1eda6bfc5bea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-21 Thread Vít Šesták
On Thursday, January 18, 2018 at 2:06:08 AM UTC+1, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, Jan 14, 2018 at 03:24:04AM -0800, Vít Šesták wrote:
> > But it could be useful to use 32-bit stubdoms for those reasons. They do 
> > rather I/O-bound work (=> minimal performance penalty) and they don't need 
> > so much memory to utilize more than 32-bit pointers. (Also, using 32-bit 
> > pointers can make a minor performance gain.)
> > …
> > It is possible to use 32-bit stubdom on a 64-bit system?
> 
> That's interesting idea. Simon, what do you think about it?
> 


I've tried to implement this kind of protection and I'd like to report my 
failure achieve the result. Someone might be more successful. After all, I am 
not much experienced with Xen internals (I mostly configure Xen through Qubes). 
I've found there is a gzipped ELF with ioemu stubdom. Maybe replacing it with a 
32b one could do the trick. But I am not sure if it is enough, maybe this would 
just result in a 32-bit code running in 64-bit PV domain, which is not what we 
want. (I am not even sure how to check it.) I haven't found any relevant 
configuration where I could configure the stubdomain mode.

But I've decided to try to compile the stubdom and to try it. I've checked out 
the code and switched to 4.6.6 tag. The code looks promising, some parts seem 
to be ready for x86_32, despite the fact that it is no longer supported 
platform for Xen itself. I however have failed the compilation itself, 
regardless of the target architecture. I have tried debian-9. I needed few 
additional packages to pass ./configure, that's OK. (I won't name them, because 
you might miss different packages and because the error messages are pretty 
clear.) There seem to be some new warnings in GCC that make the compilation to 
fail, so I had to adjust tools/Rules.mk by adding line `CFLAGS += 
-Wno-misleading-indentation -Wno-unused-function`. This shifts me to another 
problem: command `./configure --enable-stubdom --disable-tools --disable-xen 
--disable-docs --host=x86_64 && make` results in the following error message I 
am unable to resolve:

…
make -C seabios-dir all
make[6]: Entering directory '/home/user/xen/tools/firmware/seabios-dir-remote'
  Compile checking out/src/stacks.o
src/stacks.c: Assembler messages:
src/stacks.c:635: Error: found '(', expected: ')'
src/stacks.c:635: Error: junk `(%ebp))' after expression
src/stacks.c:636: Warning: indirect call without `*'
…

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/72d9be30-473b-4840-a240-f29bea8a47ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] GPU?

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

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

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

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

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

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3a20b39b-7ee8-43ca-9cfc-1d5e2ed26f18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: GPU?

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

You right, one can, but:

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

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

Right.

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

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

V6

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/41aa2710-cfbf-4b9a-a432-d4666a0d5346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-18 Thread Vít Šesták
On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote:
> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote:
> > 
> > * If an application does not mitigate Spectre and attacker finds useful 
> > entry point, attacker can read memory of the application (but nothing more).
> > * If VM kernel does not mitigate Spectre and attacker finds useful entry 
> > point, attacker can probably read memory of whole VM (but other VMs are not 
> > affected).
> > * If Xen does not mitigate Spectre and attacker finds useful entry point, 
> > attacker can probably read memory of whole system.
> 
> Can you explain why you think that Spectre can't escape the container (VM)? 
> It seems that is the main issue, Spectre escapes the container.

It depends on what you mean by VM escape. Sure, both Meltdown and Spectre are 
about reading memory that should not be accessible. From your description 
below, I believe you have confused those two.

The reason why Spectre is much harder to actually exploit than Meltdown: For 
Meltdown, you just use your own code to read the memory. With Spectre, you have 
to use (and find!) a victim's code to perform innocently-looking operations.

Meltdown allows attacker to read any address in her address space. That's not 
always whole physical address space, but in case of Xen PV x64 domains, it is 
the case.

Spectre allows to read the memory in a different way. Imagine the _victim_ has 
code like this:

if((i > 0) &&(i < a_length)) {
return a[i];
} else {
return NULL; // or any other error code
}

This looks like a perfect code that prevents overreads and underreads. But an 
attempt to overread/underread will affect cache. Fortunatelly, such simple code 
is not much useful. The attacker rather needs something like this: 
foo[bar[index]]. Even with all the proper bounds checks (that will cause the 
code not to execute in traditional sense), attacker might try to perform 
overflow/underflow by using index variable out of range. But CPU might try to 
execute the branch speculatively (because the condition is usually satisfied), 
which can cause a read of arbitrary out-of-bounds bar[index]. The read of the 
value would be probably benign on its own, but then, it tries to load data from 
foo array based on this value, which might cause cache fetch depending on value 
of bar[index]. The attacker has not won yet, she has to determine what part of 
memory was loaded into cache. This can be done using timing attack.

Another interesting part of Spectre is branch target injection. I remember some 
double fetch vulnerability that can cause bad jump due to race condition 
(TOCTOU issue). With Spectre, attacker can try to abuse this for bad 
speculative jump even if there is no race condition possible.

But my main point is that for Spectre attack, the fact that nobody has cared 
about that when writing the software is not enough for successful exploitation. 
Actually, one needs to find a suitable code that processes some attacker's 
input in a suitable way. Moreover, the attacker needs some precise measurement, 
so passing some malicious input to some queue in order to be processed by code 
that can trigger speculative out-of-bounds read can be impractical.

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

That's true for both Spectre and Meltdown. But the fact that bounds checks 
aren't enough does not mean that those attack cannot be mitigated in software 
elsehow.

> Given the nature of the attack, I do not think that hardware virtualization 
> would stop this attack.

If this is about Spectre, you are right, hardware virtualization does not stop 
it on its own. For Meltdown, the situation is a bit different: Hardware 
virtualization makes the VM not to have the address outside the VM mapped in 
its address space. Trying to access the memory outside the VM is not prevented 
by bounds check, it is prevented by the simple fact that they have no address. 
Note that this AFAIU does not prevent attacking VM's kernel from VM's process, 
it just prevents attacking hypervisor from VM.


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

Well, you are mostly right. But maybe we should divide it to base system (e.g., 
Xen and dom0) and single VMs.

The base system is unfortunately affected by Meltdown, because it mostly does 
not use hardware virtualization. (Qubes 4 is quite better there, but still not 
perfect.) It might be also vulnerable to Spectre attacks, but I am not sure if 
they are practical.

Si

[qubes-users] Re: GPU?

2018-01-15 Thread Vít Šesták
It might be possible, just no one has implemented it in a way that does not 
require complex processing by trusted parts of system.

There is an attempt called XenGT (for Intel iGPUs), but I am not sure about its 
state and at least it is not integrated to Qubes yet.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8f99b20c-82c8-4771-9cfc-460883e2d10a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-15 Thread Vít Šesták
On Monday, January 15, 2018 at 12:57:09 PM UTC+1, awokd wrote:
> It matters a bit because Spectre is harder to exploit than Meltdown. IIUR,
> Qubes' design allowed it to constrict Meltdown to a single VM

Not in PV, which are primary type of VM in 3.2.

> I'm still
> somewhat unclear on how Spectre operates under hardware virtualization but
> you're right, it needs to be fixed.

As far as I understand, Spectre can read the memory available of victim. That 
is:

* If an application does not mitigate Spectre and attacker finds useful entry 
point, attacker can read memory of the application (but nothing more).
* If VM kernel does not mitigate Spectre and attacker finds useful entry point, 
attacker can probably read memory of whole VM (but other VMs are not affected).
* If Xen does not mitigate Spectre and attacker finds useful entry point, 
attacker can probably read memory of whole system.

Please note that:

* Attacker needs a suitable entry point. It might be difficult to find it.
* All code needs to be recompiled in order to mitigate Spectre. It is not 
binary that you are/aren't protected. Some parts of system might be protected 
at the same time when others aren't.
* Lowlevel components might need additional work because of assembly code.
* Microcode update is needed only for some variants of patches. But retpoline 
might be preferred for both performance reasons and not need of microcode 
update.

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

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


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

2018-01-15 Thread Vít Šesták
On Monday, January 15, 2018 at 2:15:34 AM UTC+1, Nik H wrote:
> Thanks, this is good info. I found instructions to update microcode in linux 
> - seems very simple. Xen instructions seem simple as well but where do I 
> enter this? In the Dom0 terminal? I am a bit unclear as to how Dom0 and Xen 
> interact.

Well, dom0 is a privileged domain and any administration of Xen should be done 
from it. So, dom0 terminal is probably a good start.

You will probably need to adjust Xen parameters. It depends if you have UEFI or 
legacy BIOS. You can see both variants (but you need to write something else 
than „iommu=no-igfx“) in this (otherwise unrelated) article: 
https://www.qubes-os.org/doc/intel-igfx-troubleshooting/

> I am guessing normal VMs do not have enough privileges to update microcode 
> (well... hopefully, otherwise compromised VMs could install malicious 
> microcode...)

I hope so. They are digitally signed (at least at Intel), but still…

> As a side-note, spectre does compromise the entire qubes architecture.

Not fully.

> Good that meltdown is not an issue, yes

As far as I understand, Meltdown _is_ an issue. It allows reading memory of 
whole system. It will be hopefully fixed soon.

Spectre is harder to exploit, but it will also take longer to fix it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d2a3b048-0494-47d1-bc31-00802d57395d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-14 Thread Vít Šesták
As far as I understand it, microcode update cannot fix it. It just brings some 
new instructions that can be used for Spectre fix. (But they don't help on 
their own.)

You can try to update your BIOS if it is well supported by your vendor. Mine is.

Alternatively, you can try to update microcode via Xen. (In fact, the new 
microcode is loaded on every boot, because CPU has no persistent storage for 
that. It should be loaded in early stage of boot.*) Xen has some documentation, 
it would be probably enough to use some Linux package and add something like 
“ucode=scan” to Xen parameters: 
https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update

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

*) Some μcode updates can be loaded even runtime, but this is not so general 
and I don't recommend it. As far as I understand, the result of runtime 
patching might vary on what instructions have been used before the attempt to 
patch it, so you could end up with some race condition.

-- 
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/a7654f30-92d4-4386-8001-f2d731c72e65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-14 Thread Vít Šesták
Good point, I forgot this one. of course, it would, but I am not sure if Qubes 
is ready for that.

But it could be useful to use 32-bit stubdoms for those reasons. They do rather 
I/O-bound work (=> minimal performance penalty) and they don't need so much 
memory to utilize more than 32-bit pointers. (Also, using 32-bit pointers can 
make a minor performance gain.)

On other VMs than stubdoms, it is not so easily deployable, because user might 
have some 64-bit only software there. At least, it is impossible to deploy it 
automatically (via update) without breaking anything.

It is possible to use 32-bit stubdom on a 64-bit system?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4e004690-cbab-4742-b625-0d583159dde1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: GPU?

2018-01-14 Thread Vít Šesták
Qubes does not have GPU virtualization for security reasons. As a result, 
additional GPU is used only in dom0 (od GuiVM in future). GPU might be useful 
for:

* additional output like HDMI (well, good luck…)
* window manager acceleration (but integrated GPU usually does the job well for 
less power)
* GPU passthrough to a VM (It might work, but it is not officially not 
supported and much work will be needed. Also, if the VM can rewrite GPU 
firmware, the GPU can perform a DMA attack during boot.)

When selecting my last laptop, I've decided to choose one without additional 
GPU. First, I don't need it much. Second, it adds some hassle. It would be 
ideal to have it switched off in order not to comsume power (=> lower heat, 
more quiet laptop, better battery life). On the other hand, I remember having 
HDMI output wired to the additional GPU, which was rather PITA. I was able to 
get it somehow working on my old laptop, but it used to crash X11.

HDMI through additional GPU will reportedly get better with Wayland, but we are 
not there yet.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2ad472cf-d74c-4a5c-970d-04e9b5018aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-13 Thread Vít Šesták
On Saturday, January 13, 2018 at 1:19:18 PM UTC+1, Vincent Adultman wrote:
> IIUC this still seems fairly awful from a usability perspective if we think 
> of the added cognitive load of watching what is running when and remembering 
> or making choices on what to close / restart when (I'm reading between the 
> lines and guessing this has had something to do with decision on 
> reintroduction of Qubes manager?).

It is just temporary countermeasure. Actually, Qubes was not designed with 
Meldown in mind. In fact, no OS was. The countermeasures are rather the best we 
can do until it gets fixed than something that shoul be smooth and user 
friendly.

IMHO it is just a coincidence that Qubes Manager was reintroduced those days.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/70f0d6e1-39bc-4a33-9d74-cac9fd4da1e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-13 Thread Vít Šesták
I have one more idea: The Vixen patch could be useful for VMs with PCI devices. 
Memory balooning is not supported there anyway. QEMU in dom0 looks ugly, but 
this case is a bit different: AFAIU, the attacker can directly talk to QEMU if 
and only if she has escaped from PV. Maybe it is not nice, but it is not that 
bad either.

With Qubes 3.2, I believe this can be a clean win. Compared to the proposal 
(focusing on VMs with PCI devices only):

* It fixes the Meltdown. The proposal does not address it for those VMs.
* Attacker can try to break out from both PV and then from HVM or (more likely) 
from PV and then pwn QEMU. This is arguably harder than breaking directly from 
PV.

With Qubes 4.0 (still focusing on VMs with PCI devices only), it is still 
probably an improvement:
* If attacker can pwn QEMU (but not PV), she can with the current proposal read 
the whole memory using Meltdown. With Vixen, QEMU vulnerability is probably not 
enough for Meltdown.
* If attacker can escape from PV (but not QEMU), she can do pretty nothing. 
Well, with Vixen, she can read the content of the container, but I don't think 
this is a serious issue.
* If attacker can both escape from PV and attack QEMU, you are doomed in either 
case.
* Theoretically: If attacker can escape from HVM, you are better protected with 
Vixen (because attacker needs to escape from PV first).
* If there are some vulnerabilities that do not allow full VM escape, you are 
probably still better protected with Vixen. Qemu in dom0 runs as an ordinary 
process (so attacks like buffer overread have quite limited impact) and it is 
the same case for PV.

Have I missed something?

I don't say that Qubes should go this way. Maybe there are better ways to 
achieve some goals (especially for 4.0+). I am just saying that QEMU in dom0 – 
however horrible it looks – might be acceptable in this special case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f51baeff-52eb-4d65-bfb7-7c15a3a0e102%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: memory management in dom0 ?

2018-01-13 Thread Vít Šesták
> My dom0 has no swap, I didn't disable it, it just never had any.
> I guess thats because in the installer I didn't assign any swap partition.

Not optimal IMHO, but it simplifies this case.

> > * How much of memory does the AppVM use? 
> 
> I looked at it at the time I got repeated crashes, it had some 800MB 
> assigned to it.
> 
> > What is the memory limit for the
> > AppVM? See VM settings » Advanced » Initial memory.
> The settings are 1GB initial and 4GB max.
> 
> I "solved" it by closing some VMs and my chromium got more space assigned.

This looks like it should not have behaved this way.

> I start a compile (8 cores times 0.6GB of mem used) and maybe 10 seconds 
> later I get out-of-memory issues.
> To my annoyance xentop shows me that there is still >10 GB free, 
> unallocated.

Again, it should not behave this way, Qmemman polls in 0.1s and tries to give 
the VM 130 % of its requirements. And all the VMs have 1GiB of swap space, 
unless you have made something custom. So, even if it was not fast enough, it 
should be temporarily covered by swap.

What is the status of qubes-qmemman.service? Do those issues persist after 
Qmemman restart or even after system reboot?

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7aabf3c3-4dc3-41af-b357-6fdd420fc194%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-13 Thread Vít Šesták
> There are two shims: PV-in-HVM aka Vixen and PV-in-PVH aka Comet. Both
have limitations making them incompatible (or at least suboptimal) in
Qubes

Marek, thanks for the clarification. So, IIUC, Vixien's shim is no-go and 
Comet's shim would do the same (but at higher cost) as migration to PVH where 
possible. Now, your solution looks like a reasonable tradeoff.

> Indeed, the table is about generic/default VMs. If one choose HVM, it
will have PV stubdomain, regardless of Qubes version. We'll clarify
this.

The problem is not just when explicitly requesting HVM (while not explicitly 
stated, I can understand it is not about that), it seem to be inaccurate even 
about the default VM types. As far as I know, PVH For Qubes 4, it seems OK, we 
got rid of some stubdoms. In Qubes 3.2, currently no stubdoms are used for such 
VMs, but you have PV in the table. For 3.2+ for VMs with PCI devices, you also 
have noted that there is PV stubdom, but there is AFAIU no stubdom.

> ## Only running VMs are vulnerable
> 
> Since Qubes OS is a memory-hungry system, it seems that an attacker
> would only be able to steal secrets from VMs running concurrently with
> the attacking VM. This is because any pages from shutdown VMs will
> typically very quickly get allocated to other, running VMs and get wiped
> as part of this procedure.

It depends. In fact, not letting more-trusted-VMs and less-trusted-VMs run 
together (as advised) makes Qubes less memory hungry. On a system with 
something like 32 GiB of RAM, this can lead to having much spare memory. I have 
upgraded to 32 GiB after realizing that I'd like to have slightly more than 16 
GiB and maybe it would be better to have two the same modules. As a result, I 
have much spare memory now. IIUC, the memory is usually not overwritten until 
it is assigned to another VM, so the data are at risk even after shutdown.

For this reason, I've created a BrickVM whose purpose is just to allocate 
unneeded memory. Unfortunately, the VM does not take much memory even if it 
could, so I have decided to run about twenty or thirty DVMs for this purpose. 
(OK, I could run something memory-intensive in the BrickVM, but running many 
DVMs (or closing them if needed) seems to be easier.)

-- 
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/6dab89ca-8b43-4066-bc59-99a08608c7bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: memory management in dom0 ?

2018-01-11 Thread Vít Šesták
Yes, there is qmemman. I hope this is relatively up-to-date: 
https://www.qubes-os.org/doc/qmemman/ .

It should manage dom0 memory as well. By default, it assigns 1 GiB – 4 GiB of 
RAM to dom0.

For your case, I have few questions:

* What's dom0 swap usage? Qmemman includes this amount in memory requirements.
* Where does your “1.3 GB is in use” claim come from?
* How much of memory does the AppVM use? What is the memory limit for the 
AppVM? See VM settings » Advanced » Initial memory.

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

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


Re: [qubes-users] Re: porting to ARM

2018-01-11 Thread Vít Šesták
Qubes is a desktop OS*, so it does not make much sense to target ARM servers.

*) I remember this has been emphasized by its authors somewhere. Of course, you 
can use it on server, but it if far from the intended usage.

-- 
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/a9c52a03-1c89-431d-99f3-c3b5c0b54a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: porting to ARM

2018-01-10 Thread Vít Šesták
Quick googling suggests that ARM has kind of IOMMU and there is Xen for ARMv8 
and even ARMv7. Everything looks doable at first sight. I am not sure how large 
class of ARM CPUs is ready for that nowadays, though.

Maybe it would not be so hard. In theory, I see no component where just 
changing some switches in compilation should not do it. But some unexpected 
issues might arise and I might have something overlooked.

Just nobody has invested the time so far, I guess.

What would be typical ARM devices for QubesOS?

* Phones? It would be cool and there are many ARM phones, but they have few RAM 
and require completely different UI.
* Tablets? The same applies there.
* Laptops? It would be easier, but market with ARM laptops is quite small 
today. And I am not sure about their RAM, but this might be also an issue.

Maybe absence of suitable hardware is the reason why we don't have it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/53e3ddf7-58f9-41d0-a9b3-1f09230dc69e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Announcement regarding the Meltdown and Spectre attacks

2018-01-10 Thread Vít Šesták
Meltdown can be mitigated by using HVM/PVH. If you look at the XSA, they also 
have prepared PV-in-PVH mode that mitigates it also for PVs. (This probably 
won't work for CPUs without VT-x/AMD-v, but those are rare today. It also 
probably won't work for VMs with PCI devices if system does not support IOMMU 
(AKA VT-d), but in this case, you are already doomed due to DMA attacks.) So, 
Meltdown seems to be easily mitigated, it is just matter of time.

It seems that PV-in-PVH is going to fix some other issues. IIUC, it should 
mitigate all PV-specific vulnerabilities and even bring PVH for stubdoms, which 
sounds as a nice side effect of Meltdown fix.

Spectre is harder to mitigate and you might need microcode update.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cedfb1cc-f143-4e68-952f-92ecdbf7f20b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Intel ME Backdoor, called Odin's Eye

2018-01-08 Thread Vít Šesták
> You could use POWER-KVM and have an assortment of VM's with shared 
> folders, you can replicate all the other stuff via various methods and 
> have a better security level it simply wouldn't look as slick.

Not sure about that. Qubes is not just set of tools. It is also a set of 
careful choices of configuration (e.g., strictly using HVMs with stubdoms). I 
might be wrong, but I don't think you can get a comparable level of security 
easily. You would have to take similar choices and maybe even to make a new 
decisions that affect security.

> Qubes isn't virtualization, it is simply a collection of tools that can 
> theoretically be compiled for POWER although currently the qubes VMM is 
> xen which isn't yet available for POWER (the xen devs are ignoring 
> requests to assist with porting efforts).

It is not just the collection of tools.

You are right that QubesOS can be probably ported to KVM. Even if this is a 
solution (not 100% convinced), it is not there yet. At best, TALOS 2 might be 
some solution for future, not something you can buy and use just now (for those 
purposes).

> If T2 is successful (ie: enough people buy it) there are plans for a 
> POWER laptop.

Cool.

But at the moment, it does not make me sense to buy a workstation I don't need 
and hope that some time later, they will release a laptop and someone else will 
port QubesOS for it. I could somewhat support efforts of porting QubesOS to 
POWER9, it makes me more sense.

> > * It is quite expensive for needs of most people.
> It fills the very high performance sector that previously had no libre 
> hardware, it isn't meant for those like you and me who would be 
> satisfied with the performance of one of the various libre firmware 
> available boards such as the KGPE-D16, KCMA-D8 ($300 MSRP) etc...

You are right. It is rather a good special-purpose workstation.

> No one ever found money or success trying to sell to the average yokel.

I could argue that selling to average yokel for low price can bring both 
success and money, because there are plenty of yokels.

I understand this is not for masses in the same scale as Windows. This is not 
necessary for success. But I am also afraid this is not suitable even for 1 % 
of Qubes user base. (Maybe it will be successful elsewhere, but it does not 
matter much in this discussion.)

> That option simply removes the PCI device and the Option ROM menu, it 
> doesn't disable PSP - like ME it is integral to the x86-64 boot process 
> so it simply can't be disabled.

OK, good to know.

> > But it is still matter of trust. Not having PSP/IME does not mean there 
> > cannot be any backdoor.
> On an owner controlled system that has libre hardware, firmware and 
> software it is incredibly difficult to add a backdoor function, one 
> truly could trust their computer in that case.

Not 100%. First, you cannot be 100% sure your CPU matches the design. Second, 
some backdoors can look like a regular vulnerability. Those are even worse. 
Good backdoor can be abused by few people, maybe it requires digital signature. 
That's not good, but regular (pseudo-)vulnerabilities are even worse, because 
they can be abused by much broader set of people.

But I agree that having open CPU design can be a good start.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/89dc0d5d-6997-4aa5-a107-fe447c15ac02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Intel ME Backdoor, called Odin's Eye

2018-01-08 Thread Vít Šesták
> Or you could just buy POWER 9/TALOS 2, have a libre high performance 
> system right now and stop waiting for what will never happen (and would 
> be immediately fixed if it did)

Talos 2 looks nice in theory, but:

* Qubes OS does not support this architecture. So you are going to have 
something  more resistant to backdoors, but it is also less resistant to 
classical exploits. If your typical threat is not like NSA, you probably lose 
security. And even if it is, it is at least not clear win, as NSA could use 
those classical exploits anyway.
* Not an option for those who want a laptop.
* It is quite expensive for needs of most people.

That's not to say Talos 2 has no merit. It might have some niche, but it is far 
far from a solution for masses.

> If you buy new Intel/AMD CPU's you are supporting future anti-feature 
> development.

Maybe this is not that bad for AMD: 
https://www.phoronix.com/scan.php?page=news_item=AMD-PSP-Disable-Option

But it is still matter of trust. Not having PSP/IME does not mean there cannot 
be any backdoor.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/751ae8ce-c183-4d2e-a17d-6637d029221c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-12-30 Thread Vít Šesták
Just another note: I have found that the laptop has accelerometers and they can 
be used for autorotation with a simple script: 
https://github.com/admiralakber/thinkpad-yoga-scripts/blob/master/rotate/thinkpad-rotate.py

I've tuned it a bit, so it does not configure touchpads. I use an external 
touchpad that is rotated, so its autoconfiguration by this script is not 
welcome.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/09e9e11f-d92d-46f1-b52a-9acbc35e8091%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Touchscreen not working on Qubes 3.2

2017-12-30 Thread Vít Šesták
While both mouse and touchscreen have some similarities (both are pointing 
devices), there are also some important differences:

First, mouse reports relative movements, while touchscreen reports absolute 
positions of touch.
Second, mouse reports two different types of events (movement and clicks*), 
while touchscreen reports just touches.
Third, touchscreen might report multiple pointers.

For those reasons, touchscreen needs a different proxy, which is not 
implemented yet.

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

*) Scrolling is AFAIK a specific type of button.

-- 
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/8677bc98-f7c1-490f-b28e-4cd6cb243f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Pointer lock API

2017-12-25 Thread Vít Šesták
I have encountered such issue and I have found a semi-solution. I usually don't 
use mouse (just mousekeys and touchpad), but for games, I do.

There is an exiting input proxy mechanism. It was originally intended for 
sys-usb->dom0, but other combinations can work, too.

As far as I remember, it does not work with the standard X11 instance in AppVM. 
Instead, I had to run a VNC loopback session. This also required the service 
file in target VM to set DISPLAY environment variable.

If someone is interested, I can look for details. Maybe I have something 
already posted here.

-- 
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/07c36e37-e419-4cb8-b697-51afde670103%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Touchscreen not working on Qubes 3.2

2017-12-25 Thread Vít Šesták
AFAIK this is related to kernel option rd.qubes.hide_all_usb, not to Xfce vs. 
KDE.

-- 
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/ed1775c2-c396-4451-87da-61e38027cec0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: How to hide all except one USB controller?

2017-12-24 Thread Vít Šesták
Actually, having a malicious hardware attached at boot time is something hard 
to defend. Even if Xen does not attach the hardware to dom0, there is some 
pre-Xen phase of boot – BIOS/UEFI. Qubes cannot affect this phase of boot. If 
you have attached a malicious device that for example pretends to be a USB 
keyboard, it can control the computer. It can also try to provide another boot 
medium or to exploit a vulnerability (e.g., some FS parsing vulnerability in 
UEFI).

So, I advise some Qubes-unrelated mitigations:

* If possible, avoid having untrusted devices connected at boot.
* Check your boot medium options in BIOS config.
* Set a BIOS password. Even if it can be bypassed by anyone with physical 
access, your malicious device is unlikely to take a screwdriver and disassembly 
your computer. :)

That's not to say that Qubes-related mitigations are useless. They are just not 
enough when you are concerned about boot time.

-- 
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/bb4a5f98-9605-4b15-b5c8-8cd10d574512%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Re: [qubes-users] Qubes 4rc3 :: 50% reduced battery runtime compared to Qubes 3.2 on Lenovo X230

2017-12-22 Thread Vít Šesták
As far as I remember, there was an idea to kill stubdoms after boot, which 
would both reduce risk (as stubdoms run in PV) and CPU+memory overhead. I 
cannot try it right now, because I haven't installed Q4.

> If I switch to disposable VMs, I assume the risk would be reduced.

You can sort reduce some risk of having your AppVMs permanently pwned. As a 
result, this  could prevent some kinds of gradual pwnage of dom0.

OTOH, if attacker pwns some your VM and has a reliable way to escape from the 
VM to dom0, it does not matter if it is DispVM or not.

> Can this be done for the sys-vms?

Not sure about 4, but I have done something similar for sys-usb in Q3.2. 
Strictly speaking, it is not a DVM, but it behaves similarly. The hack is 
simple in Q3.2: 1. Truncate VM's private.img to zero bytes. 2. Ensure that the 
VM template has created /home/user in root.img. (You can do something like 
this: sudo mkdir /tmp/root && sudo mount --bind / /tmp/root && sudo mkdir 
/tmp/root/home/user && sudo chown user:user /tmp/root/home/user && sudo chmod 
700 /tmp/root/home/user)

In Q4, you will probably be able to do something similar, but you probably 
can't truncate LVM volume to zero bytes, so this will require some elaboration.

The VM sys-firewall could utilize the same hack unless you have some scripts 
there. VM sys-net probably cannot utilize this (at least not that 
straightforwardly) because of network config you have there.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8e6be7ab-6e57-4e44-ade2-c391d24bc4c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-12-17 Thread Vít Šesták
Even though the MoBo officially supports up to 16 GiB of RAM, I've tried 32 GiB 
of RAM without any apparent issues.

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7385077b-2947-4986-8a09-a93ff3063402%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] R3.2: Debian 9 template fails to update 50% of the time

2017-12-09 Thread Vít Šesták
You can disable the two units just by one command:

sudo systemctl disable apt-daily.{service,timer}

You can do the same with the disable command, but it should not be necessary in 
most cases with Qubes TemplateVMs to call the stop command. Once you start the 
TemplateVM, the apt is likely to start. When you call stop command, I believe 
it lets the aready running command to commplete. Then, you are not likely to 
run TemplateVM for a day, so it is not likely to start again.

You should not need to mask the units, at least in theory.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bfea8e22-f36b-4ab4-b0f6-35141d6547d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] When transferring file between Qubes, MD5 changes.

2017-11-17 Thread Vít Šesták
Is it random, or deterministic?

Do you observe any signs of unstable system (e.g., freezes, app crashes, VM 
crashes, system crashes…)? If you do, it might be a faulty RAM.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e90d12e7-5423-4c5a-bb1b-88dc5d4b7cb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes & Quantum decryption Immunity

2017-11-13 Thread Vít Šesták
Hello,

I'll react to multiple questions and statements from multiple people.

> A figure I heard was that qc can cut search time for symmetric key merely in 
> half, whereas its can cut time for asymmetric key by orders of magnitude. 

No. For symmetric key, it does not halve the time. It works like halving key 
length. It is asymptotic improvement. With classical computer adding one bit 
doubles time for brute-force. With QC, adding *two* bits doubles time for 
probabilistic brute-force. See Grover's algorithm as I mentioned above.

For asymmetric cryptography, “orders of magnitude” can be true, but it does not 
express that it is asymptotic improvement – you can resolve some problems in 
*polynomial* time. But there are some ciphers that are believed to be 
quantum-resistant, meaning that there is no such known attack.

> in Qubes, the signature confirmation happens in dom0 or in the sys-net?

Dom0 updates are verified in dom0, template updates are verified in templates. 
But that's not important if your adversary can factorize release signing key.

> Doubling up the key length seems like an interesting prospect, but has the 
> potential risk to fail in the future by quantum computing

Why? Doubling key size is a asymptotic countermeasurement. Moreover, for 
bruteforce (but not necessarily for other types of attack), Grover's algorithm 
has been proven to be optimal, i.e., you can't go asymptotically bettter. 
Unless a QC can perform many many many more operations in the same time and at 
the same cost, it should suffice. Unless there is some extra breakthrough. 
Remember, virtually no cryptographic scheme has been proven to be secure 
(except some like  and Vernam cipher – but those have limited 
applicability), so, someone might theoretically break AES tomorrow. We just 
rely on the fact many that people have failed with this, so this is unlikely. 
But this is a theoretical issue even without QC.

> I've wondered for a good while if splitting up an symmetric encrypted file in 
> multiple of parts, say for example minimum two parts, and send one over the 
> internet, and carry the other on yourself in person, that if only one part is 
> stolen (for example someone steal your laptop with sensitive competitive 
> business trade secrets), then it's still uncrackable?

Usually no, unless you use a scheme specially designed for that. You might be 
interested in secret sharing, which is even more powerful concept.

> Wait, hold on, your last line, regarding that "some" asymmetric encryption is 
> believed to be secure against future quantum computing? Is it possible to 
> elaborate on that?

For example, see https://en.m.wikipedia.org/wiki/NTRU .

> Also if this turns out to indeed be quantum crack proof, whould it be 
> feasible to use these for what we currently use symmetric encryption for?

You could, but I see no reason for that. QC makes bruteforce considerably 
easier, but it is still considerably hard. With a proper key size, symmetric 
crypto will be still faster and have probably smaller keys for comparable 
security level.

For asymmetric ciphers, bruteforce is usually not much considered, because they 
are usually better attacks. But Grover's algorithm should be applicable even 
for asymmetric ciphers. It however does not make much sense (at least not 
without modifications), because they have much larger keys.

> Also, correct me if I'm wrong, but aren't there here two exponential effects, 
> one ontop of the other? Which may be overlooked by us too. I mean, imagine 
> the scale-ability of doubling the Qubits every day, it's not linier, it's 
> exponential. But the Qubits themselves are exponential too.

AFAIU, this is a common misconception. Well, you need exponentially growing 
space for emulating QC on classic computer. But you don't get exponentially 
faster computer. You get a computer with more memory. Such computer can process 
larger tasks, e.g., factorize larger numbers. But once you have enough memory, 
adding more qubits make AFAIU no improvement.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4c85ee7e-b7a2-4f25-be68-022132c517fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes & Quantum decryption Immunity

2017-11-11 Thread Vít Šesták
QC is a potential threat for both symmetric and asymmetric cryptography, just 
the symmetric cryptography is threatened quite a bit more. And even asymmetric 
cryptography is important for QubesOS security because of update signatures.

Symmetric cryptography is threatened by Grover's algorithm. The algorithm can 
perform bruteforce search in N elements in O(sqrt(N)) time. In other words, it 
reduces O(2^n) time to O(2^(n/2)) time. What's great: There is some proof that 
this algorithm is optimal (probably under assumption that P≠NP). So, just using 
double-length keys should be sufficient. This could justify AES256 instead 
AES128. Doubling the key length could be an issue for password, but if you use 
a memory-intensive key derivation function, it might be infeasible to run it on 
quantum computers for some time.

Asymmetric crypto usually (always?) relies on problems that are believed to be 
easier than NP. Some of them (integer factorization and discrete logarithm 
problem) can be solved in polynomial time on QC (they belong to BQP class), 
which would be a real threat for cryptography like RSA and ECC. There are some 
“QC-proof” 
asymmetric schemes that are believed to be secure against QC. But those aren't 
widely used yet. It could be useful to use them together with some old schemes 
like RSA or ECC.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ba81205c-adfb-416a-8b70-27b01aa2b80c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Reasonably secure laptop with touchscreen and enough ram for dictation in Windows App-VM?

2017-10-15 Thread Vít Šesták
Well, I am afraid this will be a bit hard:

Touchscreen. I've a laptop with touchscreen. I was a bit curious, but I don't 
feel much of need for touchscreen, it was simply not a reason to buy the 
laptop. When trying to use touchscreen with QubesOS, I've experienced several 
issues:

* The touchscreen is technically an USB device connected to the same USB 
controller as other USB devices. This implies any other USB device could spoof 
its touches. This issue is inherent to the hardware, i.e., not something 
QubesOS can resolve. Moreover, this is AFAIK a typical implementation of 
touchscreen.
* Qubes has input proxies for mouse and keyboard. You see, touchscreen is 
missing there. There are undocumented pieces of support and it should be 
reportedly easy to make it working, but it seems nobody takes it as a priority.
* Once you get touchscreen input working, it will probably work just like a 
mouse input. As far as I know, there is no support for passing touch events to 
VMs in other way than mouse movements and clicks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/29318c5e-19fe-4560-8756-3315fa8bc981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to change / swap behavior of Ctrl, Alt, Win, and fn keys?

2017-08-07 Thread Vít Šesták
AFAIK most laptops handle Fn key in firmware, but Macs do it in OS.

If you remap Fn key in BIOS, it should be transparent to the OS, so it should 
be applied to all domains.

The Xmodmap works on too high level, so you need to apply to all the VMs. I've 
tried few ways of remapping keys in dom0 transparently to all other domains, 
but I've failed. Some experiments with xdotool looked promising, but I was 
unable to get rid of some weird effects like sticky keys and spurious modifier 
keyup. (Well, I was able to get rid of some of them. But then, some other issue 
has appeared.) But this one looks the closest to the desired result.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a1a65ffd-13c9-4c65-a81f-d4c37b907574%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Copying between VMs from dom0

2017-06-29 Thread Vít Šesták
I feel this to be controversial. It is right as long as you implement it 
carefully (How would you handle the separator being present in the content of 
the file? How would you sanitize the filenames? And so on…) AND you don't 
exceed the complexity of tar format.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e936f907-412f-4a88-87d9-f92fae091303%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] switch to integrated Intel graphic

2017-06-29 Thread Vít Šesták
Hmm, HD graphics 2000 looks like old Sandy Bridge, so preliminary HW support 
should not have any effect in theory. Also, installing a new kernel is not much 
likely to help (it would be if you had a recent GPU that is too new for the 
kernel), but you might try it.

Eva, what does «sudo rmmod i915» do? If it proceeds, then the driver doesn't 
recognize the GPU. If it doesn't, then the driver recognizes GPU, but there is 
something wrong with config or with the driver.

You might also try checking if the same issue happens in Fedora 23.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8639be52-599f-4c26-9d18-7e5897a651ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How much inital and max memory for sys and template VMs?

2017-06-28 Thread Vít Šesták
I guess it consumes 3 GiB of RAM if and only if you have much of unneeded RAM. 
When you need the RAM for other VMs, it should be freed by the VMs.

But maybe a fixed amount of RAM is better suited for VMs that are expected to 
be using rather a constant amount of RAM, for two reasons. First, Qubes tries 
adding some margin for caches etc. Second, memory balancing must have some 
overhead.

Moreover, sys-net and sys-usb do have a constant amount of RAM assigned, as 
they have some PCI device assigned.

When tight on memory, I was able to go as low as 200 MiB for sys-net. The same 
would probably apply to sys-firewall and sys-usb. If you are not so tight, I'd 
recommend slightly more, like 250MiB or 300MiB.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c0626cfc-b2dd-421e-b38d-8d03dd2b4150%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Copying between VMs from dom0

2017-06-28 Thread Vít Šesták
It might be pointless to consider risks of passing result of qvm-run -p to dom0 
Bash expansion when you have path traversal in the first place. When command 
«ls 
/etc/NetworkManager/system-connections/» in sys-net returns paths like 
“../.bashrc ../../.bashrc ../../../.bashrc” and the cat command returns some 
arbitrary shell commands, you are close to be totally compromised by a 
malicious sys-net.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fb3d145c-770f-4123-92cd-b3deced1f3e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Weird graphical error on a i5 2500k integrated graphics

2017-06-17 Thread Vít Šesták
On June 17, 2017 10:19:40 PM GMT+02:00, Hugo Costa wrote:
>Sorry for taking so long to answer, I tested that today, my results
>were:
>
>1 - changing the cable had no effect. I used both another VGA cable as
>well
>as an HDMI cable, the result was the same. I swapped the cables and the
>issue moved to the other monitor, as expected
>2 - yes, I always did the testing with the cables tightned
>3 - I forgot this test, I'll try it again tomorrow
>4 - No, both on the BIOS and on other OSes (such as Linux Mint and
>Win10),
>it all works fine, I'm sure it's something to do with the integrated
>graphics compatibility with qubes :(
>
>Thanks for taking the time!
>

Since other OSes work well, it sounds like a driver issue. Since some other 
Linux distribution works well and this issue does not seem to be a common 
QubesOS issue (I don't remember any other occurrence of it on this 
mailinglist), I guess it is related to driver version. I suggest trying to 
update kernel to version from qubes-dom0-current-testing.

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

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


Re: [qubes-users] Re: Xen high CPU usage, but nothing is running in the VM

2017-06-17 Thread Vít Šesták
Interesting, I'd expect kswapd to be capable of performing I/O berserk, nou CPU 
berserk. The only CPU-intensive part should be dm-crypt, but it runs in dom0, 
not in standard AppVMs (unless you adjust it accordingly).

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

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


[qubes-users] Xen high CPU usage, but nothing is running in the VM

2017-06-17 Thread Vít Šesták
What CPU usage does  Qubes Manager show? I guess is shows low CPU usage.

Do you see any other symptoms of high CPU usage like heat or fan activity?

I guess the Xen just allocates some CPU time for some VMs, but the time is not 
used. As a result, xentop seems to overestimate actual CPU usage.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8ec64d6f-ecb4-44e9-892a-ac0b442e270d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-06-16 Thread Vít Šesták
Not using i915 driver on new CPU is my experience with i7-7500U (Intel HD 
graphics 620). But Haswell is not so new and I believe even Skylakes should be 
covered by i915.preliminary_hw_support=1.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8de2e809-6965-4605-9b4e-50eb36ca58c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Question(s) regarding Qubes minimal templates

2017-06-14 Thread Vít Šesták
Fedora 23 has EOLed, Fedora 24 should EOL in about two months. When Fedora is 
EOLed, it receives no security updates. So, looking to near future, I'd upgrade 
to Fedora 25 rather than to Fedora 24.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a03aaed0-c8ab-418f-b779-5d4393e77f43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   >