[qubes-users] Re: Motherboard change
I've found a related thread on Qubes OS forum: https://forum.qubes-os.org/t/if-i-change-my-motherboard/11346 On Thursday, November 9, 2023 at 4:48:45 PM UTC+1 Vít Šesták wrote: > Hello, > I'd like to change my motherboard (for a different model), while keeping > other computer parts. What should I be careful about. > > I am aware just about one issue: PCI devices will probably have different > numbers, which causes some troubles. There is a workaround, as long as I > think about it in advance: > https://github.com/QubesOS/qubes-issues/issues/8127#issuecomment-1791105502 > > Is there any other pitfall? > > 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/c9a9bdcc-80e3-4302-b26e-bc17da0ca66bn%40googlegroups.com.
[qubes-users] Motherboard change
Hello, I'd like to change my motherboard (for a different model), while keeping other computer parts. What should I be careful about. I am aware just about one issue: PCI devices will probably have different numbers, which causes some troubles. There is a workaround, as long as I think about it in advance: https://github.com/QubesOS/qubes-issues/issues/8127#issuecomment-1791105502 Is there any other pitfall? 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/78b12aff-ffd6-44d0-abeb-dac607992f98n%40googlegroups.com.
[qubes-users] Re: QSB-089: Qrexec: Memory corruption in service request handling
If the process is not reused, just an update without restarting anything is enough, isn't it? (This wouldn't be the case if the process was forking from a zygote.) After the update, I got a shower of notifications “Failed to execute qubes.WindowIconUdater (from to dom0)”, probably for each running domU qube. But this looks like a temporary issue, as QRPc seems to continue working, either for newly launched qubes and for qubes launched before 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/58ee4c42-1d8a-437e-b28e-7efb8758185bn%40googlegroups.com.
Re: [qubes-users] Injecting configuration files into appVM when it's created/started for the first time
The file location may vary by your distro, at least ChatGPT tells so. Also strace might help you to check what file locations are accessed: 1. strace -o /tmp/strace.log gnome-terminal 2. grep settings.ini /tmp/strace.log You'll probably want to use a Qt app rather than gnome-terminal, but the way to look for that is the same. Regards, Vít Šesták 'v6ak' On Thursday, May 4, 2023 at 2:31:52 PM UTC+2 Qubes wrote: > > Vít Šesták wrote: > > Perhaps my search terms are just out of whack, but I have had a good > > look around and I cannot find a system wide location for > > `~/.config/qt5ct/qt5ct.conf` that controls the Style and Icon Theme for > > example. > > > > > > It's easy to find. > > > > 1. Me: Do you know a system-wide file for ~/.config/qt5ct/qt5ct.conf? > > ChatGPT: Yes, the system-wide configuration file for > > ~/.config/qt5ct/qt5ct.conf is typically located at > > /etc/xdg/qt5ct/qt5ct.conf. This file contains the default settings for > > I tried `/etc/xdg/qt5ct/qt5ct.conf` and it didn't work. I also tried > `/etc/xdg/qt5ct.conf` (just to try my luck) but it also doesn't work. I > will try it again just to double check, maybe my midnight oil lamp was > already running out of oil when I did try and I made a mess of it. > > > the Qt5 Configuration Tool and is used as a fallback configuration file > > if no user-specific configuration is found. > > > > Note that the location of the system-wide configuration file may vary > > depending on your specific Linux distribution or operating system. You > > can use the locate or find command to search for the file on your system. > > > > 2. Verify by Google by searching "/etc/xdg/qt5ct/qt5ct.conf" (including > > quotes). It seems that this location is real. > > > > Even more frustrating I cannot > > find a list of the environment variables that I can potentially use. I > > only know of the `QT_QPA_PLATFORMTHEME=qt5ct` which I currently use and > > `QT_STYLE_OVERRIDE=` [3][4] which you can set to either `adwaita` or > > `kvantum` However there may be an environment variable one can use to > > set the path to the `qt5ct.conf`, but such a list alludes me. > > > > > > > > 1. Look where it is used: > > sudo grep -rl QT_QPA_PLATFORMTHEME /usr > > /usr/share/doc/qgnomeplatform-qt6/README.md > > /usr/share/doc/gnupg2/NEWS > > /usr/share/doc/qgnomeplatform-qt5/README.md > > /usr/lib64/libQt5Gui.so.5.15.9 > > /usr/lib64/libQt6Gui.so.6.4.3 > > > > 2. Look in the binary: > > strings /usr/lib64/libQt6Gui.so.6.4.3 | grep '^QT_' > > > > Thanks I will check 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/5371dedc-9fd6-4fd3-b29f-f40ce44a35afn%40googlegroups.com.
Re: [qubes-users] Injecting configuration files into appVM when it's created/started for the first time
Perhaps my search terms are just out of whack, but I have had a good look around and I cannot find a system wide location for `~/.config/qt5ct/qt5ct.conf` that controls the Style and Icon Theme for example. It's easy to find. 1. Me: Do you know a system-wide file for ~/.config/qt5ct/qt5ct.conf? ChatGPT: Yes, the system-wide configuration file for ~/.config/qt5ct/qt5ct.conf is typically located at /etc/xdg/qt5ct/qt5ct.conf. This file contains the default settings for the Qt5 Configuration Tool and is used as a fallback configuration file if no user-specific configuration is found. Note that the location of the system-wide configuration file may vary depending on your specific Linux distribution or operating system. You can use the locate or find command to search for the file on your system. 2. Verify by Google by searching "/etc/xdg/qt5ct/qt5ct.conf" (including quotes). It seems that this location is real. Even more frustrating I cannot find a list of the environment variables that I can potentially use. I only know of the `QT_QPA_PLATFORMTHEME=qt5ct` which I currently use and `QT_STYLE_OVERRIDE=` [3][4] which you can set to either `adwaita` or `kvantum` However there may be an environment variable one can use to set the path to the `qt5ct.conf`, but such a list alludes me. 1. Look where it is used: sudo grep -rl QT_QPA_PLATFORMTHEME /usr /usr/share/doc/qgnomeplatform-qt6/README.md /usr/share/doc/gnupg2/NEWS /usr/share/doc/qgnomeplatform-qt5/README.md /usr/lib64/libQt5Gui.so.5.15.9 /usr/lib64/libQt6Gui.so.6.4.3 2. Look in the binary: strings /usr/lib64/libQt6Gui.so.6.4.3 | grep '^QT_' 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/8b0a4074-5a2f-4954-94d4-8bb76861e40en%40googlegroups.com.
Re: [qubes-users] Re: Injecting configuration files into appVM when it's created/started for the first time
I have several ways: a. Google b. ChatGPT, e.g. “Can I configure XFCE Terminal for all users?” (real example copied from my history) c. Try to find a file with the same name (maybe without initial dot) in /usr, /etc, etc. Something like this: sudo find / -xdev -name zshrc 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/744da41a-f7a2-4764-9342-0bc82ae77c7dn%40googlegroups.com.
[qubes-users] Re: Injecting configuration files into appVM when it's created/started for the first time
I sometimes need something similar, but I prefer a slightly different approach. I prefer the config files to be in the TemplateVM, so that I can easily update them for all the VMs. There is no general solution for all the cases, but you often can find a global file. For example: * /etc/ssh/ssh_known_hosts * /etc/ssh/ssh_config.d/something.conf allows you to configure SSH client, e.g., RevokedHostKeys. * /etc/xdg/xfce4/terminal/terminalrc for XFCE4 Terminal settings * /usr/share/geany/geany.conf 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/cdf49d9c-8427-434a-a579-5cc1277c8af1n%40googlegroups.com.
[qubes-users] Re: Help with qrexec [#usb #StandaloneVMs #external_devices]
> I created a StandaloneVM that means that it doesn't communicate with other VMs and it souds great. No, it doesn't. It means it is not based on a TemplateVM. It has no impact on whether it can communicate with other VMs. > Could you tell me how I can open this channel ? so how I can make the usb available for the standaloneVM ? What do you mean by making it available to the StandaloneVM? Is the StandaloneVM Linux-based, or Windows-based? a. If it is Windows-based, the only feasible way with Qubes 4.0 is probably to assign the USB controller to the qube. This way, you assign all USB devices in the USB controller to the qube. Qubes 4.1 will probably also implement USB passthrough even for Windows, though. b. If it is Linux-based, what interface do you want it to be accessible from? 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/f4d9d47b-629e-4591-bf30-5b44d2694fa8n%40googlegroups.com.
Re: [qubes-users] How can I install new software in DOM0 ?
IIUC, you want to stream the screen via OBS. a. You can do this from a specific qube. That is, this way, you can stream only windows from apps from a specific qube. Maybe this fits your needs, maybe it doesn't. b. You can stream the dom0 screen to a qube and then capture it in OBS. I have managed doing so using few terrible hacks, but there is a noticable CPU load and low FPS on my machine (Ryzen 5800X, 1440p). Also you might need some work if you have multiple screens. If you are interested in it, I can share more when I am at PC. c. You can record (not stream!) the screen either from dom0. I think I have succeeded with gtk-recordMyDesktop. I have tried several tools that can allow streaming dom0 screen to a domU. I don't have notes about that, so I am writing just what I got from my memory: * Some of them looked useful, but they are not in the offici repositories and I didn't want to add any extra repository to dom0. Especially ffmpeg looked promising, but there were more such tools. * Some recording apps insist on saving the output to a file with a specific suffix. There is usually a workaround like ln -s /dev/stout /tmp/output.mp4. * Many recording apps tend to encode the data. For transferring from dom0 to domU, you would probably rather want raw data for multiple reasons: 1. Quality loss, 2. Latency and 3. CPU load. * I think there are some apps that record the data in /tmp and postprocess them. This makes real-time streaming impossible unless you inspect the internal data. * There are also some screenshoting apps. You can expect low FPS and high CPU usage, but this somehow works. * Once you manage to capture the data in dom0, you can play then in domU using ffplay. From domU perspective, you might want to have it always-on-top and fullscreen, from dom0 perspective, you might want it hidden. Both is possible. I can share scripts for that. Some manual work is still needed, but they can be useful. 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/5f5c9961-12ac-4ac8-9223-8b3271fa5e92n%40googlegroups.com.
Re: [qubes-users] Re: sys-net problems Intel 8265 / 8275
This looks cumbersome, but I have a similar situation with my Wi-Fi card and Fedora template. However, the Intel webpage also links https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ (see the note above the table) as a source for newer versions. I remember some issues with Wi-Fi in a minimal template (not sure if Debian or Fedora). Finally, I concluded it was not worth the hassle. This is the reason why I suggest trying some other template, even if it is not the preferred solution in long-term. 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/9666f0ea-1943-4810-b814-19603b72ed7bn%40googlegroups.com.
[qubes-users] Re: sys-net problems Intel 8265 / 8275
Wi-Fi needs drivers and microcode. This might be source of some troubles. Have you tried non-minimal template or Fedora template? 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/44186b02-2be2-457f-829e-675bd5daae3fn%40googlegroups.com.
Re: [qubes-users] Re: QSB-067: Multiple RPM vulnerabilities
Thank you, it seems that my update is successful. On Friday, March 19, 2021 at 11:42:41 PM UTC+1 a...@qubes-os.org wrote: > P.S. -- Please avoid top-posting, Vít. > Sorry for that, I sometimes forget to remove the quoted text. Anyway, I top post only if the quoted text is not important, i.e. when I don't quote selectively. 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/faf25ad4-3066-4913-b1cf-9c4d35b6bb97n%40googlegroups.com.
Re: [qubes-users] Re: QSB-067: Multiple RPM vulnerabilities
It seems to have been fixed now. The dom0 updates have passed. The DomU Fedora updates have succeeded with updating the macros.qubes file, which is supposingly the workaround by Qubes team. Regards, Vít Šesták 'v6ak' On Friday, March 19, 2021 at 1:59:48 PM UTC+1 a...@qubes-os.org wrote: > On 3/19/21 4:41 AM, Vít Šesták wrote: > > Hi, I've tried to install the updates. Even after removing systemtap and > > when using --clean, I am unable to install it. IIUC, I am trying to > install > > it too soon: > > > > $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing --clean > > Using sys-firewall as UpdateVM to download updates for Dom0; this may > take > > some time... > > 40 files removed > > Fedora 25 - x86_64 - Updates 272 kB/s | 24 MB > > 01:29 > > Fedora 25 - x86_64 3.6 MB/s | 50 MB > > 00:14 > > Qubes Dom0 Repository (updates) 1.3 MB/s | 1.3 MB > > 00:01 > > Qubes Dom0 Repository (security-testing) 1.5 MB/s | 3.0 MB > > 00:02 > > determining the fastest mirror (14 hosts).. done.-- B/s | 0 B --:-- > > ETA > > Qubes Templates repository 2.2 kB/s | 5.9 kB > > 00:02 > > Error: > > Problem 1: problem with installed package satyr-0.21-2.fc25.x86_64 > > - cannot install the best update candidate for package > > satyr-0.21-2.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > satyr-0.21-2.1.fc25.x86_64 > > Problem 2: problem with installed package > > qubes-core-dom0-linux-4.0.28-1.fc25.x86_64 > > - cannot install the best update candidate for package > > qubes-core-dom0-linux-4.0.28-1.fc25.x86_64 > > - nothing provides rpm >= 4.14 needed by > > qubes-core-dom0-linux-4.0.29-1.fc25.x86_64 > > Problem 3: problem with installed package > > python3-hawkey-0.6.4-3.fc25.x86_64 > > - cannot install the best update candidate for package > > python3-hawkey-0.6.4-3.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > python3-hawkey-0.6.4-3.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > python3-hawkey-0.6.4-3.1.fc25.x86_64 > > Problem 4: problem with installed package libsolv-0.6.29-2.fc25.x86_64 > > - cannot install the best update candidate for package > > libsolv-0.6.29-2.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > libsolv-0.6.29-2.1.fc25.x86_64 > > Problem 5: problem with installed package hawkey-0.6.4-3.fc25.x86_64 > > - cannot install the best update candidate for package > > hawkey-0.6.4-3.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > hawkey-0.6.4-3.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > hawkey-0.6.4-3.1.fc25.x86_64 > > Problem 6: problem with installed package drpm-0.3.0-3.fc25.x86_64 > > - cannot install the best update candidate for package > > drpm-0.3.0-3.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > drpm-0.3.0-3.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > drpm-0.3.0-3.1.fc25.x86_64 > > Problem 7: problem with installed package deltarpm-3.6-17.fc25.x86_64 > > - cannot install the best update candidate for package > > deltarpm-3.6-17.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > deltarpm-3.6-17.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > deltarpm-3.6-17.1.fc25.x86_64 > > Problem 8: problem with installed package > > createrepo_c-libs-0.10.0-6.fc25.x86_64 > > - cannot install the best update candidate for package > > createrepo_c-libs-0.10.0-6.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > createrepo_c-libs-0.10.0-6.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > createrepo_c-libs-0.10.0-6.1.fc25.x86_64 > > Problem 9: problem with installed package > createrepo_c-0.10.0-6.fc25.x86_64 > > - cannot install the best update candidate for package > > createrepo_c-0.10.0-6.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > createrepo_c-0.10.0-6.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > createrepo_c-0.10.0-6.1.fc25.x86_64 > > Problem 10: problem with installed package PackageKit-1.1.5-1.fc25.x86_64 > > - cannot install the best update candidate for package > > PackageKit-1.1.5-1.fc25.x86_64 > > - nothing provides librpm.so.8()(64bit) needed by > > PackageKit-1.1.5-1.1.fc25.x86_64 > > - nothing provides librpmio.so.8()(64bit) needed by > > PackageKit-1.1.5-1.1.fc25.x86_64 > > Problem 11: problem with installe
[qubes-users] Re: QSB-067: Multiple RPM vulnerabilities
Hi, I've tried to install the updates. Even after removing systemtap and when using --clean, I am unable to install it. IIUC, I am trying to install it too soon: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing --clean Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... 40 files removed Fedora 25 - x86_64 - Updates272 kB/s | 24 MB 01:29 Fedora 25 - x86_64 3.6 MB/s | 50 MB 00:14 Qubes Dom0 Repository (updates) 1.3 MB/s | 1.3 MB 00:01 Qubes Dom0 Repository (security-testing)1.5 MB/s | 3.0 MB 00:02 determining the fastest mirror (14 hosts).. done.-- B/s | 0 B --:-- ETA Qubes Templates repository 2.2 kB/s | 5.9 kB 00:02 Error: Problem 1: problem with installed package satyr-0.21-2.fc25.x86_64 - cannot install the best update candidate for package satyr-0.21-2.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by satyr-0.21-2.1.fc25.x86_64 Problem 2: problem with installed package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64 - cannot install the best update candidate for package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64 - nothing provides rpm >= 4.14 needed by qubes-core-dom0-linux-4.0.29-1.fc25.x86_64 Problem 3: problem with installed package python3-hawkey-0.6.4-3.fc25.x86_64 - cannot install the best update candidate for package python3-hawkey-0.6.4-3.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64 Problem 4: problem with installed package libsolv-0.6.29-2.fc25.x86_64 - cannot install the best update candidate for package libsolv-0.6.29-2.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by libsolv-0.6.29-2.1.fc25.x86_64 Problem 5: problem with installed package hawkey-0.6.4-3.fc25.x86_64 - cannot install the best update candidate for package hawkey-0.6.4-3.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64 Problem 6: problem with installed package drpm-0.3.0-3.fc25.x86_64 - cannot install the best update candidate for package drpm-0.3.0-3.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64 Problem 7: problem with installed package deltarpm-3.6-17.fc25.x86_64 - cannot install the best update candidate for package deltarpm-3.6-17.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 Problem 8: problem with installed package createrepo_c-libs-0.10.0-6.fc25.x86_64 - cannot install the best update candidate for package createrepo_c-libs-0.10.0-6.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64 Problem 9: problem with installed package createrepo_c-0.10.0-6.fc25.x86_64 - cannot install the best update candidate for package createrepo_c-0.10.0-6.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64 Problem 10: problem with installed package PackageKit-1.1.5-1.fc25.x86_64 - cannot install the best update candidate for package PackageKit-1.1.5-1.fc25.x86_64 - nothing provides librpm.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64 Problem 11: problem with installed package python2-deltarpm-3.6-17.fc25.x86_64 - cannot install the best update candidate for package python2-deltarpm-3.6-17.fc25.x86_64 - package python2-deltarpm-3.6-17.1.fc25.x86_64 requires deltarpm(x86-64) = 3.6-17.1.fc25, but none of the providers can be installed - nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 - nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64 (try to add '--skip-broken' to skip uninstallable packages) Regards, Vít Šesták 'v6ak' On Friday, March 19, 2021 at 11:40:02 AM UTC+1 a...@qubes-os.org wrote: > Dear Qubes Community, > > We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM > vulnerabilities. The text of this QSB is reproduced below. This QSB and > its accompanying signatures will always be available in the Qubes > Security Pack (qubes-secpack). > > View QSB-067 in the qubes-secpack: > > https://github.com/QubesOS/qubes-secpack/
Re: [qubes-users] Re: Fullscreen Multiple Monitors not possible?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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?
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)
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)
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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)
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
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
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
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 ?
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)
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
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?
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
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?
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)
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
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)
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?
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?
On Thursday, January 18, 2018 at 10:00:19 PM UTC+1, Alex Dubois wrote: > You can use GPU computing in Dom0 with the assumption that: > - You trust the software you plan on using >- 3D design software such as Blender >- GPU compute such as CUDA libs, Tensorflow, Keras, etc.. > - You only create assets/code and export them out of Dom0 You right, one can, but: * At least, this goes against the nature of Qubes. * You don't have any Internet connection there. * Creating only (and not importing anything) is a very important (and often unrealistic) assumption. So, you should not open any file you download. If there is some vulnerability in such software (well, Blender: https://developer.blender.org/T52924), you are actually potentially more affected than with traditional OS like Ubuntu: In Qubes, dom0 sometimes gets out of date (like Q3.2 being based on EOLed F23), so you don't receive any security update for software like Blender. That's not because ITL does not care about security, that's because Blender is not a a security-critical component like Xen or Linux kernel are. That's the cost of using Qubes in a way it was never intended. > If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen > to do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however: > - It is far from trivial and only limited setups are known to work Right. > - The security of it is not as robust (I can't remember where I read that, I > think it was in the GPU Pass-through page of the Xen wiki) I guess one of potential reasons: Some people have succeeded only without stubdom, i.e., with QEMU running in dom0. V6 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/41aa2710-cfbf-4b9a-a432-d4666a0d5346%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: GPU?
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)
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)
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)
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)
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?
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)
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)
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 ?
> 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)
> 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 ?
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
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
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
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
> 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
> 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)
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
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
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
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?
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
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)
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
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.
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.
