Re: [qubes-users] Is Qubes effected by the Intel kernel memory leaking bug?
Dnia Wednesday, January 3, 2018 1:27:38 PM CET 'awokd' via qubes-users pisze: > On Wed, January 3, 2018 11:55 am, stephenatve...@gmail.com wrote: > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > > > > > http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-o > > f-the-linux-page-table > > > > It seems as if Linux countermeasures will involve a significant rewrite > > aka. FUCKWIT. > > > > Is this perhaps why there is no final 4.0 release? > > Believe PCI passthrough had been the major holdup for 4.0 release but I > could be wrong. I'm curious to see if Xen/Qubes is impacted as well. One > article says there was a rumor Xen was, another says there are comments in > the code that Xen PV/HVM is not. Embargo lifts on the 4th, so there should > be more facts then. Wouldn't want to engage in making speculative > assumptions (cough). And here we are: https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html https://googleprojectzero.blogspot.pt/2018/01/reading-privileged-memory-with-side.html https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " During the course of our research, we developed the following proofs of concept (PoCs): A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries. A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4] A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.) A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache. " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/40959822.UoTSMkEhtd%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Is Qubes effected by the Intel kernel memory leaking bug?
Dnia Thursday, January 4, 2018 9:33:04 AM CET Andrew David Wong pisze: > We've just published an announcement about this: > > https://www.qubes-os.org/news/2018/01/04/xsa-254-meltdown-spectre/ Thank you, much appreciated. Good luck to the whole team in dealing with this. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5334706.ITVnm1lE8D%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)
Dnia Saturday, January 6, 2018 9:32:20 PM CET Sven Semmler pisze: > On 12/15/2017 03:20 AM, kotot...@gmail.com wrote: > > It does boot but the X server cannot start. Text installation did > > not work. > > Based on swami's post from 9/15/17 I suspect you need kernel 4.9 in > dom0 ... > > https://groups.google.com/d/msg/qubes-users/ZFZT7mQNeWY/xZ1AiCYOAwAJ I can confirm that T470 won't work with stock R3.2 kernel. Just go for R4.0, works pretty well. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1585569.CqqnvMDoyJ%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
[qubes-users] R4.0 on T470, Suspend-to-RAM issues
Hey all, R4.0 rc3 used to work pretty well, but with recent updates (yes, I have testing repos enabled), I started having some serious issues around Suspend- to-RAM: 1. Suspend-to-RAM does not work reliably When trying to suspend for the first time after a full reboot, the screen goes blank for a few seconds and then immediately I am greeted with the lock screen. The system does not suspend at all. After unlocking the screen and trying again, system suspends to RAM, but after wake-up the screen is *not* locked. 2. No networking after suspend After suspend-to-RAM (even unsuccessful, like the first scenario described above), the system completely loses networking; sys-net becomes unresponsive (and with it, the NetworkManager applet), restarting it does not seem to work, it is also impossible to start a terminal in sys-net. 3. USB mouse becomes unusable After suspend-to-RAM (again, including the first scenario from the top of this e-mail), the USB mouse becomes unusable, as if the system was not aware it is plugged in. Unplugging it and plugging it back in does not solve the issue. The only way to fix these is to reboot the machine. I am happy waiting for rc4 and I assume these are some temporary issues related to the current state of R4.0 pre-rc4, but thought it might be useful to put them out there. Perhaps someone else has seen such issues? Perhaps there is something I could do to debug them? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5814775.Jzv2KBC6MB%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
[qubes-users] R4.0-rc1 on T470: unable to boot (reboot loop)
Hi all, first of all, hello. Been meaning to sign up for this list for some time, some of you might remember me from the IRC channel (from when I was setting up my own Qubes devel builds). Anywhoo. I decided to give R4.0-rc1 a spin on my Thinkpad T470, and after successfully going through the installation process, I am stuck at this issue: https://groups.google.com/forum/#!topic/qubes-users/Pf1Cd87KSsk Selecting any of the two options in GRUB ends up rebooting the device. Tried removing "quiet" from kernel options, nothing changed. Any suggestions on how can I get some debugging output? QubesOS R3.2 does not run on T470s at all (old kernel vs. new hardware; new hardware clearly wins). Thanks! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2493743.SxXS9MZMd7%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] R4.0-rc1 on T470: unable to boot (reboot loop)
Dnia Saturday, September 16, 2017 3:16:16 PM CEST rysiek pisze: > Selecting any of the two options in GRUB ends up rebooting the device. Tried > removing "quiet" from kernel options, nothing changed. Any suggestions on > how can I get some debugging output? Problem solved. For the record, the solution was removing `iommu=no-igfx` from Xen params. Without it, R4-rc1 boots fine on a T470. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/35019748.LKnDF4ot2K%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this
Hey, Dnia Monday, September 18, 2017 9:43:15 AM CEST jes...@gmail.com pisze: > In the past I have used a Firefox plugin called "Better Privacy" to try to > push back against multi-front user fingerprinting and analysis mechanisms > such as the kind used by large advertising and user demographics companies > which include the abuse of Flash LSOs, HTML5 local storage, Silverlight, et > al to confirm that the same user is browsing along a website or a > distributed ad network even when they "clear private data" or use incognito > mode, even when they switch to different browsers installed on the same > machine, even if they're using coffee shop wifi or VPNs so that they appear > from different IP addresses, etc. > (...) O..k. Straight from the bat, why not Incognito/Private window? I mean, on my non-Qubes system I have a "work" browser (a normal Firefox window, keeping sessions, accepting cookies, etc); and a "fun" browser (Chromium Incognito) for everything that I am concerned might track me. On Qubes, the disposable VM is probably what you're after. But remember, even in an incognito window or in a disposable VM, you can be tracked as long as the session lasts (i.e. until you close the browser, or reboot the VM). > So I am curious to what extent Qubes security domains may be sufficiently > complete as to defeat potentially all of these mechanisms simultaneously? > Especially if end-user configures one or more domains to pipe all network > traffic over a VPN or tor to additionally differentiate their IP address? Most of these mechanisms are browser-bound. Use the browser in your disposable VM. Using it through a VPN or Tor is a good idea too. > I am especially interested to hear about how Qubes security domains interact > with Flash LSOs, and .. whatever-it-is that Silverlight and other > multi-browser plugins do, and whether *that* data leaks between domains. :/ Think of each AppVM as a separate machine yoiu're running stuff on. Flash/ Silverlight/etc do not have a way to break out of a VM. > Thank you for any insight you guys may have on this matter, as it sounds > like it speaks directly to Qubes primary mission goals of security by > compartmentalization. :D Compartmentalization does not do much for anonymity. As in, you can use Qubes, and be tracked through each of your AppVMs. You'll have three "identities", but all of them will be tracked, since regular AppVMs keep state (including browser cookies, etc, unles sthe browser is explicitly configured otherwise). To combat tracking, I would use the Incognito/Private mode in your browser, or a browser in a disposable VM in Qubes. Or both. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3563889.KxQ3rpsauL%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this
Dnia Monday, September 18, 2017 10:56:33 AM CEST Micah Lee pisze: > Qubes security domains don't necessarily help solve this problem because > really the problem is how your web browsers are configured. > > So a tracking company can't link your browsing activity between Qubes > domains -- your "personal" traffic and "work" traffic might look like > two separate people -- but within one of those domains, they can still > track you, and do all of those tricks. > > If you want web privacy, you'll have to configure your browser within > Qubes the same way you have to outside of Qubes. Or, you can do all of > your browser in DisposableVMs. Or use Tor Browser, which has taken many > steps to prevent browser tracker as a design goal. Damn, beat me to it! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2241560.q67QAilk6l%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this
Hey, Dnia Monday, September 18, 2017 12:27:21 PM CEST jes...@gmail.com pisze: > My only concern is working to ensure that to an outside observer such as > webservers and ad networks nothing short of the shared IP address (and via > Tor or VPN or different IPs honestly allocated to different domains perhaps > not even that) can act as a reliable indicator that web browsing activity in > one Qubes security domain is "linked" to activity from another security > domain via any secretly stored cookie-like reference identifiers that get > somehow leaked across domains. Right. > For example: if I browse to a Flash or Silverlight website using Browser X > in my [untrusted] domain, would those plugins be able to store any kinds of > LSOs or HTML5 local storage or cached E-tags or anything else deep enough > into the system backend that they could pull them back out again in my > [work] domain when I browse back to that same site again? > (...) As far as I understand, the answer for Qubes is "this should absolutely not happen", but the Qubes developers should probably weigh-in on that. I for one would find a "how deep does the rabbit-hole get here" discussion on this very informative. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3904660.0aLW21G1cK%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Supercookies / Zombie cookies / Web Tracking — how effective are Qubes security domains against this
Dnia Monday, September 18, 2017 8:23:46 PM CEST Ted Brenner pisze: > Not sure if Chromium is free of Google or not. Me neither, but this does not build confidence: https://bugs.chromium.org/p/chromium/issues/detail?id=500922 https://news.ycombinator.com/item?id=9724409 They fixed it soon after it was discovered, but sill. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1764884.RZTnbDx7hM%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Re: Anyone disabled the Intel ME yet?
Dnia Sunday, September 24, 2017 9:23:06 PM EEST filtration pisze: > My motherboard has a "Disable ME" jumper. Not good enough for many of > you, I know. > > As far as AMT, apparently the entry is through Intel NICs. I hoped to > mitigate it by using a third party NIC. The Intel device stayed lit > (amber, not green) on power off, my new one is completely off when > powered off. These are not really good options for laptops. :( -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2185343.oOzdqdhnf9%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Dnia Sunday, October 1, 2017 4:03:43 PM CEST Unman pisze: > On Sun, Oct 01, 2017 at 04:45:59AM -0700, Foppe de Haan wrote: > > Just an fyi: building ubuntu templates in/for R4 isn't currently possible, > > getting errors related to qubesxdg while building core-agent-linux-vm. > Yes, I'm working on this. I'm traveliing just now but will finish off > when I get home. I have a build environment I was meaning to get back up to speed, if you need a tester, let me know! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1690704.oVrfNTYTF3%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Hey all, got the build environment up and running, tried building Ubuntu Xenial and Zesty images, both failed with: debian/rules override_dh_install make[1]: Entering directory '/home/user/qubes-src/core-agent-linux' dh_install --fail-missing dh_install: qubes-core-agent missing files: lib/systemd/system/avahi- daemon.service.d/30_qubes.conf dh_install: qubes-core-agent missing files: lib/systemd/system/ exim4.service.d/30_qubes.conf dh_install: qubes-core-agent missing files: lib/systemd/system/netfilter- persistent.service.d/30_qubes.conf dh_install: usr/lib/python2.7/dist-packages/qubesxdg.pyc exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/python2.7/dist-packages/qubesxdg.pyo exists in debian/tmp but is not installed to anywhere dh_install: missing files, aborting debian/rules:28: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory '/home/user/qubes-src/core-agent-linux' debian/rules:12: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 /home/qubes/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:200: recipe for target 'dist-package' failed make[2]: *** [dist-package] Error 2 Using git://github.com/marmarek/qubes-builder.git master branch. What am I missing? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6060751.WfBia4mgdj%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Dnia Saturday, October 14, 2017 11:30:16 PM CEST Unman pisze: > It's the same error resported by OP. > Ubuntu template build hasnt yet been updated to 4.0 Ah, so it is. Any way I can help with debugging/testing/fixing this? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/12069081.DriIOzV88N%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Re: Idea for (resonable secure) cloud-storage usage with Qubes
Dnia Monday, October 16, 2017 8:20:40 PM CEST Ron Qubed pisze: > Have you considered using SSHFS rather than NFS? I'm no security expert, but > it would seem to me to be more secure than NFS. For what it's worth, we're using (not with Qubes, just generally) a system of LUKS volumes in large (hundreds of GiB) files on SSHFS-mounted volumes (for backups), and we're quite happy with that set-up. Everything works great as long as the connection is stable; if the connection breaks, stuff needs to be remounted, but we have not had any data corruption (so far, ~15TiB of data pushed through this). Perhaps this helps someone. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1577152.NcO5tUtStF%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Re: Idea for (resonable secure) cloud-storage usage with Qubes
Hey, Dnia Saturday, October 21, 2017 9:48:56 AM CET [799] pisze: > Regarding my specific use case I would like to synchronize the data to keep > a copy at another location. Using LUKS images can cause a problem depending > on the transfer mechanism, as I need to use a mechanism which will only > transfer the qctual changed blocks not the whole image. As such I'd like to > use an encryption which works with file based encryption - knowing that > this has reduced security as metadata etc. can be used to attack the > encryption. But that's also what we're doing with LUKS+SSHFS. The LUKS volume is cryptsetup luksOpened and mounted on the *client*, not on the (SSH) *server*, meaning the (SSH) server only has access to encrypted data. Then we're doing regular file-based operations, like rsync or whatnot. Only modified bytes of the LUKS image seem to be actually transferred. We're not transferring the whole images back and forth. That would defeat the purpose. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2086835.dST5jOF2SY%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Hey, Dnia Saturday, October 14, 2017 11:30:16 PM CET Unman pisze: > Ubuntu template build hasnt yet been updated to 4.0 is there any movement on this? Is there any way I can jump into this and help? Any docs I should read to get me started along the way of fixing Ubuntu templates for R4.0? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2067280.OE9g9Sp3eV%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Hey, Dnia Sunday, November 12, 2017 4:51:20 PM CET rysiek pisze: > is there any movement on this? Is there any way I can jump into this and > help? Any docs I should read to get me started along the way of fixing > Ubuntu templates for R4.0? got it to start building. For this I had to make some changes in: - debian/qubes-core-agent.install (from `qubes-core-agent-linux` repo) - debian/qubes-gui-agent.install (from `qubes-gui-agent-linux` repo) Diffs at the bottom. Didn't make a PR since I have no idea what are the ramifications and potential consequences of these particular changes for the operation/security of built templates. I assume the files removed are important (otherwise they wouldn't have been there in the first place). Now, during template build I got: ./create_template_list.sh: line 13: xenstore-read: command not found Not sure how serious it is; the template seems to have been built. Installing it, however, spits out an error: trusty: qubes.PostInstall service failed (full log below). Running anything in a new AppVM based on this template fires it up for a few seconds, shows what I can only assume are boot messages (screenshot attached) and then the window disappears and nothing else happens. Any pointers how to proceed with debugging and fixing the Ubuntu templates would be appreciated. $ sudo yum install qubes-template-trusty-4.0.0-201711122203.noarch.rpm Redirecting to '/usr/bin/dnf install qubes-template- trusty-4.0.0-201711122203.noarch.rpm' (see 'man yum2dnf') Qubes OS Repository for Dom0 13 MB/s | 77 kB 00:00 Dependencies resolved. Package Arch Version Repository Size Installing: qubes-template-trustynoarch4.0.0-201711122203@commandline436 M Transaction Summary Install 1 Package Total size: 436 M Installed size: 1.9 G Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : qubes-template-trusty-4.0.0-201711122203.noarch 1/1 trusty: Importing data 2621440+0 records in 2621440+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 30.3018 s, 354 MB/s trusty: qubes.PostInstall service failed Verifying : qubes-template-trusty-4.0.0-201711122203.noarch 1/1 Installed: qubes-template-trusty.noarch 4.0.0-201711122203 Complete! diff --git a/debian/qubes-core-agent.install b/debian/qubes-core-agent.install index 7c1b0c3..ea90569 100644 --- a/debian/qubes-core-agent.install +++ b/debian/qubes-core-agent.install @@ -56,15 +56,12 @@ lib/systemd/system/NetworkManager-wait-online.service.d/ 30_qubes.conf lib/systemd/system/NetworkManager.service.d/30_qubes.conf lib/systemd/system/anacron-resume.service.d/30_qubes.conf lib/systemd/system/anacron.service.d/30_qubes.conf -lib/systemd/syst
Re: [qubes-users] Anything like Split GPG for Keepass?
Dnia Monday, November 13, 2017 2:04:00 AM CET Patrick Schleizer pisze: > Eric Shelton: > > I am curious how people are making effective use of Keepass in a vault > > domain. It seems like with a browser plugin, you might be able to take a > > Split GPG type of approach, and avoid all of the cutting and pasting > > across > > domains. Any comments or suggestions? > > > > - Eric > > An inter-VM password manager for Qubes OS based on pass Should also be possible with Keyringer: https://keyringer.pw -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1741875.XalDMoeGcs%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Dnia Tuesday, November 14, 2017 1:55:06 AM CET Unman pisze: > I've just put in a couple of PRs to allow building for Xenial in 4.0. Cool! Would you mind linking them here? I'd love to understand more about Qubes internals and that seems like a good place to start. :) > If anyone wants to try Xenial in 4.0 there's a ready-built template at > qubes.3isec.org/Templates Woo! Thanks! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2053777.zbLx8grGH0%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Ubuntu Template
Hye, Dnia Tuesday, November 14, 2017 1:55:06 AM CET Unman pisze: > I've just put in a couple of PRs to allow building for Xenial in 4.0. Are these the ones you're talking about? https://github.com/QubesOS/qubes-gui-agent-linux/pull/23 https://github.com/QubesOS/qubes-core-agent-linux/commit/ 54867b6eabed3a6dca0e932ff77f67aedfe43e03 The latter is merged, I believe, and the former I applied manually. However, while building, now I get: mkdir: cannot create directory ‘chroot-qubuntu’: File exists mount: mount point chroot-qubuntu/tmp/qubes-deb does not exist /home/qubes/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:275: recipe for target 'update-repo-prepare' failed make[1]: *** [update-repo-prepare] Error 32 Makefile:297: recipe for target 'template-local-xenial' failed make: *** [template-local-xenial] Error 1 Not sure where to dig now. More debug info below. -> Building meta-packages (debian) for xenial vm (logfile: build-logs/meta- packages-vm-xenial.log) ╔══ DEBUG ══ ║ Repo Variables ╠─── ║ SRC_DIR: qubes-src ║ CHROOT_DIR: /home/qubes/qubes-builder/chroot-xenial ║ CHROOT_REPO_DIR: chroot-qubuntu ║ CHROOT_DEBIAN_DIR: /home/qubes/qubes-builder/chroot-xenial// ║ BUILDER_REPO_DIR:/home/qubes/qubes-builder/qubes-packages-mirror-repo/ xenial ╠─── ║ Chroot Variables ╠─── ║ DIST_BUILD_DIR: /home/user ║ DIST_SRC: ║ DIST_SRC_DEBIAN_DIR: / ╠─── ║ Build Variables ╠─── ║ DEBIAN_PARSER: /home/qubes/qubes-builder/qubes-src/builder-debian// scripts/debian-parser ║ DEBIAN_PLUGIN_DIR: /home/qubes/qubes-builder/qubes-src/builder-debian/ ║ OUTPUT_DIR: pkgs/xenial ║ PACKAGE_LIST: ║ DISTRIBUTION:qubuntu ║ DIST:xenial ║ DEBIANVERSION: xenial ║ UPDATE_REPO: /home/qubes/qubes-builder/qubes-src/linux-template- builder/pkgs-for-template/xenial ║ REPO_SUFFIX: ║ DISTRIBUTION_CAP:Qubuntu ║ REPO_PROXY: ║ APT_GET_OPTIONS: ║ CHROOT_ENV: BACKEND_VMM=xen ╚═══ ╔══ DEBUG ══ ║ Repo Variables ╠─── ║ SRC_DIR: qubes-src ║ CHROOT_DIR: /home/qubes/qubes-builder/chroot-xenial ║ CHROOT_REPO_DIR: chroot-qubuntu ║ CHROOT_DEBIAN_DIR: /home/qubes/qubes-builder/chroot-xenial//debian-vm/ debian ║ BUILDER_REPO_DIR:/home/qubes/qubes-builder/qubes-packages-mirror-repo/ xenial ╠─── ║ Chroot Variables ╠─── ║ DIST_BUILD_DIR: /home/user ║ DIST_SRC: ║ DIST_SRC_DEBIAN_DIR: /debian-vm/debian ╠─── ║ Build Variables ╠─── ║ DEBIAN_PARSER: /home/qubes/qubes-builder/qubes-src/builder-debian// scripts/debian-parser ║ DEBIAN_PLUGIN_DIR: /home/qubes/qubes-builder/qubes-src/builder-debian/ ║ OUTPUT_DIR: pkgs/xenial ║ PACKAGE_LIST:debian-vm/debian ║ DISTRIBUTION:qubuntu ║ DIST:xenial ║ DEBIANVERSION: xenial ║ UPDATE_REPO: /home/qubes/qubes-builder/qubes-src/linux-template- builder/pkgs-for-template/xenial ║ REPO_SUFFIX: ║ DISTRIBUTION_CAP:Qubuntu ║ REPO_PROXY: ║ APT_GET_OPTIONS: ║ CHROOT_ENV: BACKEND_VMM=xen ╚═══ mkdir: cannot create directory ‘chroot-qubuntu’: File exists mount: mount point chroot-qubuntu/tmp/qubes-deb does not exist /home/qubes/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:275: recipe for target 'update-repo-prepare' failed make[1]: *** [update-repo-prepare] Error 32 Makefile:297: recipe for target 'template-local-xenial' failed make: *** [template-local-xenial] Error 1 -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, se
Re: [qubes-users] When transferring file between Qubes, MD5 changes.
Dnia Thursday, November 16, 2017 9:16:49 AM CET Chris Laprise pisze: > On 11/16/2017 02:35 AM, vegetarianst...@gmail.com wrote: > > I am transferring a windows ISO file between qubes.. however, the file's > > MD5 sum changes every time I complete the transfer. > > > > Why might this be so? > > It might be a bug? > > What version of Qubes? And what OS are the source & destination VMs? Is > the same mdsum program being using on both ends? Also, what if you transfer the file with the changed md5 back into the original VM? Does the md5 sum change back to what it was, or to something different yet? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1817646.1gal37gNey%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Re: When transferring file between Qubes, MD5 changes.
Dnia Friday, November 17, 2017 8:27:22 PM CET vegetarianst...@gmail.com pisze: > The nature of the error was deterministic, deterministic as in "stupid > human." > > I really appreciate all the support but I had some really similar file names > and way too much faith in my command line history. We've all been there. :) > Sorry guys. > (I had also been working 16+ hours at the time.) Hope you got some rest. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1976462.SOsYJ1chng%40lapuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
[qubes-users] R4.0, Ubuntu, and Qt4/Qt5, and Salt
Hey, I am playing with R4.0 rc2, and with a Kubuntu Zesty VM in it. My idea is to use this Kubuntu VM as a stepping stone (my current main system is Kubuntu Zesty), letting me move to Qubes gradually, by mounting /home in the VM. This will let me have access to all my files and setup while I move it between the VMs. So far so good, there were some hurdles -- for instance, gpg-agent refuses to work properly with pinentry unless I manually start gpg-agent with a shell: gpg-agent --daemon /bin/bash Two issues I was thus far not able to debug, though: One annoying thing that happens is that while Qt4 applications in the VM are using my color, icon, and widget settings (as defined in Kubuntu $HOME), Qt5 uses a weird mix of *some* parts of the color scheme, and *some* of the icons. This is not only annoying and an eye-sore, but also the particular mix of colors makes some parts of the interface simply unusable. Tried switching the color settings, widget theme, tried figuring out if I am missing any (KDE/Qt theme/icon/etc) packages, but am at a loss. I am starting to think Qubes somehow messes with the Qt style settings. Anybody any ideas? Also, started playing with Salt, wrote a nice sls file to install all the stuff I need in the Kubuntu VM, but... each time I run it I get an "ERROR". I am guessing this is related to the less-than-stellar support for Ubuntu templates in Qubes R4.0. I'd love to know where I could start digging to perhaps help fix that. Any pointers welcome! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1701644.fFZ7PIiRsO%40qubuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Disk password
On Sunday, November 19, 2017 10:48:11 AM UTC tbennett1...@gmail.com wrote: > Haven’t used my computer for a few months, can’t remember the disk password > to boot the os. Possible to change it? The whole point of full disk encryption is making sure that without the password nobody can get in... So, no. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1686166.FoxXDqDcxE%40qubuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Disk password
On Sunday, November 19, 2017 11:15:01 AM UTC tbennett1...@gmail.com wrote: > I have bitcoin in a vm wallet. So it turns into a very costly issue. Depending on how much time and money you're willing to invest, how long and complicated the password is, and how much of the password you remember, you might be able bruteforce your way in. Qubes uses LUKS to encrypt the disk: https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup There is a number of LUKS bruteforcing tools you might try and resources you might dive into: https://github.com/glv2/bruteforce-luks http://irq5.io/2014/11/19/bruteforcing-luks-volumes-explained/ https://www.hacker10.com/other-computing/brute-force-linux-encryption-with-luks-volume-cracker/ Note the second link -- it talks about LUKS headers, which is the only thing you need to copy off of your drive to start bruteforcing on other machines. Don't try bruteforcing on your laptop, it will take forever. Instead, get the LUKS header off of it, get some solid CPU power somewhere and use that. When I needed to recover a lost LUKS password (it was a 6-word diceware passphrase, 4 words and the first letter of the 5th I remembered), it took me ~30h of bruteforcing on some 20 cores to get it. Good luck! -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2206727.TezqhYYeyA%40qubuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] R4.0, Ubuntu, and Salt
On Saturday, November 18, 2017 10:30:49 PM UTC Marek Marczykowski-Górecki wrote: > On Sat, Nov 18, 2017 at 06:36:17PM +0000, rysiek wrote: > > Also, started playing with Salt, wrote a nice sls file to install all the > > stuff I need in the Kubuntu VM, but... each time I run it I get an > > "ERROR". I am guessing this is related to the less-than-stellar support > > for Ubuntu templates in Qubes R4.0. > > Run qubesctl with --show-output, or check /var/log/qubes/mgmt-*.log for > details. Thanks. This only gives me this error: 2017-11-19 22:06:19,000 calling 'state.highstate'... 2017-11-19 22:06:55,812 output: qubuntu: 2017-11-19 22:06:55,813 output: -- 2017-11-19 22:06:55,813 output: _error: 2017-11-19 22:06:55,814 output: Failed to return clean data 2017-11-19 22:06:55,814 output: retcode: 2017-11-19 22:06:55,814 output: 1 2017-11-19 22:06:55,814 output: stderr: 2017-11-19 22:06:55,814 output: stdout: 2017-11-19 22:06:55,814 exit code: 20 is tehre any way to enable more debug output? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1905541.GLcTUDNXif%40qubuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Re: Disk password
On Sunday, November 19, 2017 1:29:03 PM UTC tbennett1...@gmail.com wrote: > I have no idea the order any of it was put in You can still try to bruteforce it, but I would start getting used to the fact that the contents of this drive are lost for good. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5010802.BaddXavdCM%40qubuntu. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [qubes-users] Qubes 4.0.x - Linux kernel 4.19.15 package available in testing repository
Hey, On 1/29/19 10:33 AM, Patrik Hagara wrote: > Managed to get rid of the error (and more importantly, the annoying > artifacts) by forcing Xorg to use the generic modesetting driver instead > of i915/i965. > > Steps (all commands in dom0): > > 1) check the driver currently in use (`xrandr --listproviders`), it's > the last string (should be "name:Intel" now) > > 2) create file /etc/X11/xorg.conf.d/20-intel.conf (as root) with the > following contents (also make sure there are no other files in that > directory with "Device" "Driver" set to "intel"): > >> Section "Device" >> Identifier "Intel Graphics" >> Driver "modesetting" >> Option "AccelMethod" "glamor" >> Option "DRI" "3" >> EndSection > > 3) restart the X server (eg. using `sudo systemctl restart lightdm`) > > 4) use the same xrandr command as in step 1, the driver should now be > "modesetting" and you should see no errors in /var/log/Xorg.0.log, nor > any graphical artifacts After this procedure, do you get hardware acceleration? In my case, I do get `name:modesetting`, but I also get these in Xorg.0.log (and no hardware acceleration, obviously): [29.654] EGL_MESA_drm_image required. [29.654] (EE) modeset(G0): glamor initialization failed (...) [29.728] (EE) AIGLX: reverting to software rendering Did you install/remove any packages? Can you share the output you get from `dnf list mesa* libdrm* xorg*`? > My hardware (sorry for not mentioning this earlier): Lenovo T480s with > i7-8650U, no discrete GPU. I'm on a T490. Will also test on a T470 later. -- Best r -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4818b401-2add-13c8-4d8e-0a4bf71a323e%40hackerspace.pl. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes 4.0.x - Linux kernel 4.19.15 package available in testing repository
On 9/26/19 11:59 AM, donoban wrote: >> On 1/29/19 10:33 AM, Patrik Hagara wrote: >>> Managed to get rid of the error (and more importantly, the >>> annoying artifacts) by forcing Xorg to use the generic >>> modesetting driver instead of i915/i965. ... ... >>> >> After this procedure, do you get hardware acceleration? In my case, >> I do get `name:modesetting`, but I also get these in Xorg.0.log >> (and no hardware acceleration, obviously): > (...) > I did same steps and I have acceleration working fine. Right. Just tried on a T470 (i5-7200U) and it worked! Many thanks. So it's the T490 Intel chipset that refuses to cooperate. R4.1 will have Fedora 29 in dom0, so I guess that should fix it too. -- Best, r -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/77c11851-3a94-0105-c590-8e410160daa0%40hackerspace.pl. signature.asc Description: OpenPGP digital signature
[qubes-users] Salt Orchestration, vol.2
Hey hey, I started diving more deeply into Salt on QubesOS, since now I have two laptops with very similar config. One thing I'd like to use is Salt Orchestrate runner: https://docs.saltstack.com/en/latest/topics/orchestrate/orchestrate_runner.html My use-case is: I need to enable networking on some templates (`dom0: qvm.prefs`) to pull code on them (`I:qubes:type:template: git`), and then disable networking on those templates. So basically, I need Salt's `require`, but working *across* minions. Seems like it's available on R4.0. Before I dive deep into trying to get it into a functioning state (ha!), has anyone played with it? And most importantly: how bad of an idea is it? Yes, I know enabling networking in templates is a Bad Idea, that's why I only want to do it temporarily and in a well-managed way. But yes, other ideas on how to get this code into the templates are obviously welcome too -- I considered just putting it directly in my salt configs repo (that I then manually copy to dom0:/srv/salt/), but why would I want code that is supposed to be only running on TemplateVMs in dom0 at all, right? -- rysiek -- You received this message because you are subscribed to the Google Groups "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/a8e862aa-244a-0c15-d43e-1bb5c0d543f1%40hackerspace.pl. signature.asc Description: OpenPGP digital signature
[qubes-users] Audio leakage?
Dear List, I just had a weird issue that got me somewhat concerned about the security of audio separation between cubes. Two cubes were involved: - teams-vm, running Google Chrome with a Microsoft Teams meeting happening - dispN, running Firefox with a meet.jit.si call open I was trying to debug why the microphone was not working in the Teams meeting in teams-vm. When I attached the microphone to dispN, I got sound there, but... it was the audio stream from the Microsoft Teams call in teams-vm! I double-checked this by opening the Jitsi call link separately on a smartphone. I could *clearly* hear the audio stream from the Teams call by joining the Jitsi call in dispN. It seems that the wrong audio stream got assigned as a microphone to dispN. Instead of the actual microphone source, it seems to have been the output audio stream from the Teams meeting in teams-vm. Actual microphone did not work in either call. I will test it more later and report back. A USB-C docking station was connected at the time when the Teams call was starting, perhaps it creates an additional audio source, which confused Qubes? -- Best, r -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3335122.QJadu78ljV%40mail-personal.
Re: [qubes-users] Qubes 4.1 & ThinkPad P15 Gen 2 (type 20YQ): Help in Remedying Reduced Functionality?
Hey, On Thursday, 24 March 2022 12:39:27 GMT 'Johannes Graumann' via qubes-users wrote: > > On 24.03.2022 12:16 'Johannes Graumann' via qubes-users > > wrote: ... > > As the laptop's HDMI port also does not work (likely due to being > > hardwired to the NVDIA card), I currently have no means of setting up > > multiple screens. > > > > I want to use Qubes and this machine as my daily driver and non > > functioning dock as well as the lack of a multiple screen options are > > show stoppers for this. The latter is possibly fixable through NVIDIA > > support in `dom0` and that's what I'm working on next, but I would highly > > appreciate any hint on how to get the dock working. > Installing `kernel-latest` in `dom0` (which currently brings in 5.16) and > setting graphics to `discrete` in the BIOS renders the on board HDMI port > active. `Hybrid` graphics settings results in a black screen when the > display manager comes up. Interesting. I am on a P1 gen4 with a nVidia card (so, a similar hardware config), and I simply cannot get any X when using the "discrete" UEFI setting. In "hybrid" mode, initially `kernel-latest` here also meant no X. Only after creating an `xorg.conf` file and *explicitly* setting "modesetting" driver for the integrated card I got X to work with `kernel-latest`. X was working out of the box with the original kernel though in "hybrid" mode (I am guessing some timing changes leading to card initialization happening in different order or some such). HDMI ports refuse to work in X regardless of what I do. Tried the binary driver, tried nVidia modesetting, tried nouveau. Tried "hybrid", tried "discrete". To no avail. Best I got was the Qubes loading screen and FDE password prompt on the external monitor -- both in "hybrid" and "discrete", only with binary driver and nVidia modesetting. Enabling nVidia binary driver and configuring it in `xorg.conf` always ends in this line in `Xorg.0.conf`: > Failed to allocate push buffer What a mess! -- Best, rysiek -- You received this message because you are subscribed to the Google Groups "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/2234076.ElGaqSPkdT%40mail-personal.
[qubes-users] nVidia binary in dom0 (ThinkPad P1 gen4)
Hey all,
I am trying to get the nVidia binary driver to work in dom0. Using the latest
version of it (510.60.02) always ends up with this line in `Xorg.0.log`,
followed by X crashing:
> Failed to allocate push buffer
Running `nvidia-smi` shows the card is available, kernel modules loaded; I can
get temperature readouts, for example.
Tried changing UEFI settings ("discrete" vs "hybrid" mode), tried fiddling with
kernel parameters (modesetting, iommu), to no avail.
Not sure what I could try next. Any ideas welcome!
--
Best,
rysiek
--
You received this message because you are subscribed to the Google Groups
"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/2097878.irdbgypaU6%40mail-personal.
Re: [qubes-users] nVidia binary in dom0 (ThinkPad P1 gen4)
Hey,
On Monday, 18 April 2022 13:37:25 GMT Demi Marie Obenour wrote:
> On Mon, Apr 18, 2022 at 02:57:32AM +, Michał "rysiek" Woźniak wrote:
> > Hey all,
> >
> > I am trying to get the nVidia binary driver to work in dom0. Using the
> > latest version of it (510.60.02) always ends up with this line in
> > `Xorg.0.log`,>
> > followed by X crashing:
> > > Failed to allocate push buffer
> >
> > Running `nvidia-smi` shows the card is available, kernel modules loaded; I
> > can get temperature readouts, for example.
> >
> > Tried changing UEFI settings ("discrete" vs "hybrid" mode), tried fiddling
> > with kernel parameters (modesetting, iommu), to no avail.
> >
> > Not sure what I could try next. Any ideas welcome!
>
> Have you considered using sys-gui-gpu instead?
I have not, for a very specific reason: in the laptop in question, all external
video outputs are hard-wired to the nvidia card. That is, I *cannot* use an
external display *unless* I get the nvidia card to work, somehow.
I had *some* small progress: if I go the nouveau route (with
nouveau.modeset=1), I get an external display recognized and configured in X
now. I can move my mouse to it. I cannot display any actual windows on it.
> Binary drivers in dom0 are a bad idea, both from a security and reliability
> perspective.
I am well aware of that. But as far as security is concerned, GPU passthrough
has its own problems. It's turtles all the way down!
> In particular, dom0 has an old version of both X11 and Mesa, which may well
> be incompatible with the blob driver.
That's true. I am going to try some older ones. Already tried 495.46, got a
different error:
> Failed to allocate shared surface
I guess I should try to figure out which binary driver was the newest when the
dom0 versions of xorg and Mesa were released.
> Alternatively, if your computer has an integrated Intel GPU, you could
> use that.
That's what I've been using, but that leaves me without the ability to use
external displays.
> Nouveau might also be an option, if it supports your card.
It doesn't seem to (see above).
--
Best,
rysiek
--
You received this message because you are subscribed to the Google Groups
"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/4729623.31r3eYUQgx%40mail-personal.
Re: [qubes-users] nVidia binary in dom0 (ThinkPad P1 gen4)
On Monday, 18 April 2022 15:40:32 GMT Michał "rysiek" Woźniak wrote: > > Have you considered using sys-gui-gpu instead? > > I have not, for a very specific reason: in the laptop in question, all > external video outputs are hard-wired to the nvidia card. That is, I > *cannot* use an external display *unless* I get the nvidia card to work, > somehow. Wait, that was almost certainly a brainfart. With sys-gui-gpu, the nVidia GPU would get passed-through to that VM, and so any driver installed there (and presumably more likely to work than in dom0) would also have access to all the external displays hard-wired to that GPU. Right? That's something I will try next then, and report back. Thank you for the suggestion! -- Best, rysiek -- You received this message because you are subscribed to the Google Groups "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/4702703.GXAFRqVoOG%40mail-personal.
Re: [qubes-users] Whonix 15 has been released
Hey, On 7/3/19 4:44 PM, 'trichel' via qubes-users wrote: >> I got the impression that a complete reinstall requires (a) a fedora >> appvm (I have none), (b) does not work over TOR, since the AppVM's >> based on whonix must be removed (or set to dummy template) before >> removing the whonix-14-templates. Then sys-whonix is gone, right? >> That seems awkward asprocedure. Can someone explain, please? Why can't I >> install whonix-gw-15 and whonix-ws-15 via dnf in dom0 and THEN remove >> the -14- ones? Cheers, Bernhard > > After botching the whonix-14 template with an unsuccessful upgrade attempt I > reinstalled it by entering sudo qubes-dom0-update > --enablerepo=qubes-templates-community --action=reinstall > qubes-template-whonix-gw-14 as explained at > https://www.whonix.org/wiki/Qubes/Reinstall > > Because this page gives 'sudo qubesctl state.sls qvm.anon-whonix' as a > mandatory step I executed that after the reinstall. This installed 2 new > templates whonix-gw-15, whonix-ws-15 and a whonix-ws-15-dvm, with all the old > stuff still present. I deleted the Whonix 14 templates with dnf and all seems > fine now. > > So, apparently just entering sudo qubesctl state.sls qvm.anon-whonix is the > easiest way to install new Whonix 15 templates. I didn't create a special > update VM for this. Probably it is best to remove the old ones first even > though it also works if you don't, apparently. If you need to *upgrade* for > some reason (instead of simply replacing the templates with new ones) then > you should *NOT* follow this procedure, of course. > Also see: https://www.whonix.org/wiki/Qubes/Install > > I find it pretty confusing too ... Maybe an expert can give some additional > info :) No expert here, but tested stuff on a QubesOS R4.0 with a working Whonix 14 installation. Running `sudo qubesctl state.sls qvm.anon-whonix` alone would *not* install Whonix 15 for me, it would just note that all relevant VMs exist already and call it quits. What worked for me was: 1. Install the Whonix 15 templates: sudo qubes-dom0-update \ --enablerepo=qubes-templates-community \ --action=install \ qubes-template-whonix-gw-15 \ qubes-template-whonix-gw-15 2. Using Qube Manager, change the templates for relevant qubes (sys-whonix, anon-whonix, whonix-ws-14-dvm) to relevant Whonix 15 templates. Restart any modified qubes afterwards, of course, and test stuff works. 3. Remove the unneeded Whonix 14 templates: sudo dnf remove \ qubes-template-whonix-gw-14 \ qubes-template-whonix-gw-14 So far so good. -- Regards, rysiek -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/06ca8210-42ab-a398-f959-259d65d7f126%40hackerspace.pl. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
