Re: [qubes-users] Scary Systemd Security Report
February 12, 2020 6:09 AM, ronp...@riseup.net wrote: > On 2020-02-11 11:39, unman wrote: > >> On Tue, Feb 11, 2020 at 01:34:15AM -0800, ronp...@riseup.net wrote: >>> I've been reading a blog from the renowned Daniel Aleksandersen at >>> https://www.ctrl.blog/entry/systemd-service-hardening.html >>> >>> The output from a Debian-10 based Appvm looks a little scary!! Should I >>> be concerned? >>> >>> user@tmp3:~$ systemd-analyze security >>> UNIT EXPOSURE PREDICATE HAPPY >>> ModemManager.service 5.6 MEDIUM >>> NetworkManager.service 7.6 EXPOSED >>> avahi-daemon.service 9.5 UNSAFE >>> cron.service 9.5 UNSAFE >>> cups-browsed.service 9.5 UNSAFE >>> cups.service 9.5 UNSAFE >>> dbus.service 9.5 UNSAFE >>> dm-event.service 9.5 UNSAFE >>> emergency.service 9.5 UNSAFE >>> exim4.service 9.5 UNSAFE >>> getty@tty1.service 9.5 UNSAFE >>> haveged.service 5.6 MEDIUM >>> lvm2-lvmpolld.service 9.5 UNSAFE >>> polkit.service 9.5 UNSAFE >>> qubes-db.service 9.5 UNSAFE >>> qubes-firewall.service 9.5 UNSAFE >>> qubes-gui-agent.service 9.5 UNSAFE >>> qubes-meminfo-writer.service 9.5 UNSAFE >>> qubes-qrexec-agent.service 9.5 UNSAFE >>> qubes-sync-time.service 9.5 UNSAFE >>> qubes-updates-proxy.service 9.5 UNSAFE >>> rc-local.service 9.5 UNSAFE >>> >>> rescue.service 9.5 UNSAFE >>> rsyslog.service 9.5 UNSAFE >>> rtkit-daemon.service 6.9 MEDIUM >>> serial-getty@hvc0.service 9.5 UNSAFE >>> systemd-ask-password-console.service 9.3 UNSAFE >>> systemd-ask-password-wall.service 9.3 UNSAFE >>> systemd-fsckd.service 9.5 UNSAFE >>> systemd-initctl.service 9.3 UNSAFE >>> systemd-journald.service 4.3 OK >>> systemd-logind.service 4.1 OK >>> systemd-networkd.service 2.8 OK >>> systemd-timesyncd.service 2.0 OK >>> systemd-udevd.service 8.3 EXPOSED >>> tinyproxy.service 8.7 EXPOSED >>> udisks2.service 9.5 UNSAFE >>> user@1000.service 9.1 UNSAFE >>> wpa_supplicant.service 9.5 UNSAFE >>> xendriverdomain.service 9.5 UNSAFE >> >> It does look scary. >> The output from a Fedora based qube looks much the same.. >> You should run the analysis against each service and see where you think >> they could be hardened. Post back your conclusions here. >> Also, I see that you have many services that need not be there - some >> of these will be disabled by Qubes- some you do not need in every qube >> (cups-browsed, exim4, tinyproxy etc). >> You need to review what services you are running, and disable those you >> do not want. My list in an ordinary qube looks rather different from >> yours. Those are steps you should be taking in any case. >> Also, bear in mind that the analysis doesn't take in to account any >> security features in the programs themselves, or other mitigations. >> So you need to do a good deal more work before reaching any conclusions >> about your system. >> Look forward to hearing from you >> unman > > As I read it, your suggesting that the output is influence by User > preferences as opposed to default system settings? To test that theory, > I loaded a vanilla version of Qubes 4.0.3 onto a spare box and ran the > command systemd-analyze security against the virgin Debian-10 Template. > The output is identical to the one I originally posted. As you inferred, > the output from Fedora Template is similar. I'm curious how this compares to a vanilla (non-Qubes) Fedora or debian install. In general most packages' default service files use very few if any systemd security features on most distros. I think that's more of a DIY thing. > I'm not sure if you'll agree, but my conclusion from this experiment is > that the Qubes Team have some work to do in hardening Qubes? Like you > say,"I see that you have many services that need not be there"; so my > question is, why are they present in a vanilla version of Qubes? > My impression of the official Qubes developers' stance on this is "security by isolation," i.e. Xen is the only component they actually consider secure. This is the rationale for passwordless sudo for example. In practice, I can agree, it's difficult enough to develop and maintain an OS as sophisticated as Qubes in the first place, let alone if they had to also harden guest OSes at various levels. In principle, I say fair enough, I suppose it's not really Qubes' concern what goes on within VMs. Qubes just polices the border. You might be interested in Chris's Qubes hardening tools, however I don't know it uses the systemd security features at all so it may not improve systemd's report. -- You received this message because you are subscribed to the Google Groups "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
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 9, 2020 8:52 PM, "Marek Marczykowski-Górecki" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote: >> On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote: >>> >>> >>> Has anyone tried utilizing the xen command line options to mask bits in >>> the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? >>> >>> The man page below says that "Settings applied here take effect globally, >>> including for Xen and all guests." This *might* mean it is applied *before* >>> the resume from sleep CPU bit checks (but I'm not promising anything, as I >>> have not traced through the source). And also "*Warning: This option is >>> not fully effective on Family 15h processors or later.*" >>> >> >> Just noticed that the warning applies only to 1.2.34, which is AMD-only, >> apparently. Unclear to me if the other items 1.2.35 and higher, which is >> for "x86" apply only to intel or to all x86 architecture. > > I may be missing it in this thread, but have anybody tried Qubes 4.1 > builds (with Xen 4.13) on such system? Does it have the same issue? I also had the same problem with unpatched Xen 4.13, it was on the fc31-based R4.1 build right before christmas. The check was introduced in 4.8.3.3 and probably hasn't changed. For what it's worth, R4.1 and R4.0 both resume fine when booted without Xen. See https://www.mail-archive.com/qubes-users@googlegroups.com/msg31518.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/874173b083a3c9426f120f68814a9bf7%40disroot.org.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
> marmarek: > This is a very bad idea to "fix" it. Those missing/changed CPUID bits later > on will cause issues. > And given most of the microcode updates recently are about speculative > execution, missing those > features will make the host vulnerable to those issues again. There are > multiple ways it can > manifest - from crashes when Xen uses (now not present) CPU feature, to > silent failures when Xen > tries to use some feature and assume it protects the system, while it does > not in practice. > > For this particular case (microcode included in BIOS newer than in OS), I see > two options: make > BIOS (coreboot, right?) apply microcode update on resume too, or include > newer microcode in OS. I want to make one thing clear: I am **not** suggesting this check be removed altogether. I am suggesting adding an **optional**, even undocumented, override parameter which defaults to the **current behavior** which is to panic. I've found the patch to be quite stable so far. Unpatched is guaranteed to cause a crash (xen panic) at resume; patched so far has not caused any noticeable stability issues for the four of us using it, afaik. Just saying. Also, not everyone has the option of coreboot. And we're not even completely certain this a post-resume microcode update issue, either. > lunarthegray: > @marmarek the "fix" is a hack for sure but it's currently the only way to get > some AMD Ryzen > laptops to work with Qubes. I built Qubes R4.1 the other day and with kernel > 5.4 and Xen 4.13 the > issue remains.Laptop users often suspend and are on the go as I am. There was > some discussion on > the qubes-users mailing list about other solutions. I'm no firmware/Xen > expert though. Would > pinning dom0 to 1 vCPU prevent the issue of missing or changed CPU bits?I'm > not exactly sure what > the fix would be with standard BIOS, as I'm not brave enough to flash > coreboot on my very new > ThinkPad. Should I start trying to get in contact with Lenovo? I'm assuming > AMD needs to release a > microcode patch as it's not really an issue with Xen itself. At least in my case, CPU pinning did not fix this issue. The bits still change and (would) cause a Xen panic as before. Pinning dom0 to CPU0 merely fixed a separate post-resume issue with my SATA controller. In that thread, I link to the original Xen archives thread about pinning which had nothing to do with Ryzen. February 9, 2020 2:09 AM, "Marek Marczykowski-Górecki" wrote: > (continuing discussion from the above PR) > > The patch as it is, is not acceptable, as it may introduce security > and/or stability issues on some machines. Xen (and Linux too) assumes > what CPU features is can use based on CPUID flags. If those changes > during system runtime (including suspend/resume) some instructions or > control registers may no longer be valid (->crash) or safe to use > (->security issue). Like I said, it's been very stable for me so far. I've only had one bad resume in the months I've been using it, suspending at least once a day. Security issues on the other hand are indeed unknown at this point. Also worth noting that this is Xen-specific. Afaik, the Linux kernel doesn't check for these changes. So everyone using plain old Ubuntu or whatever would be subject to the same stability and security implications caused by this patch. > If that's just about microcode updates, that's probably BIOS bug - if it > applies microcode update on system startup, it should do the same on Weird that it's happening equally on various vendor BIOSes as well as coreboot, the only thing they have in common is Ryzen 2xxx-3xxx chips. It doesn't sound to me like a **BIOS** bug, per se, unless all these vendors and the Coreboot developers wrote the same bug independently. More likely an AMD bug, imo. > system resume too. Anyway it's worth trying updating linux-firmware > package, which carries microcode updates for AMD. This should make Xen > apply microcode updates too - before checking those flags. > I've just uploaded updated version of the package to the current-testing > repository (both R4.0 and R4.1). Thanks for the tip. I'll try it when I have a chance. `--enablerepo=qubes-dom0-current-testing kernel-latest linux-firmware` I'm guessing? > If that's about something else, then fixing it would require finding > what exactly is changing (and preferably also why). And only then find > how to mitigate this issue. If specific flags would turn out to be not > related to security features or otherwise having unwanted effects, then > ignoring those changes would be an option. But ignoring _only those > flags verified to be safe to ignore_, not all of them. See my other reply about that. But I would like to mention, there are already all kinds of options and parameters throughout the Xen, Qubes, and Linux codebases that come with stability/security implications. This isn't Apple iOS. You can easily shoot yourself in the foot. That's the nature
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 9, 2020 9:52 AM, zachm1...@gmail.com wrote: > On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote: > >> On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek >> Marczykowski-Górecki wrote: >>> If that's about something else, then fixing it would require finding >>> what exactly is changing (and preferably also why). And only then find >>> how to mitigate this issue. If specific flags would turn out to be not >>> related to security features or otherwise having unwanted effects, then >>> ignoring those changes would be an option. But ignoring _only those >>> flags verified to be safe to ignore_, not all of them. >> >> I hope it doesn't come to that but we'll see. I wouldn't really know what >> else to do besides >> complain to Lenovo and hope they yell up at AMD to investigate. I assume >> it's something weird >> between hardware manufacturers and AMD. >> >>> - -- >>> Best Regards, >>> Marek Marczykowski-Górecki >>> Invisible Things Lab >>> A: Because it messes up the order in which people normally read text. >>> Q: Why is top-posting such a bad thing? >>> -BEGIN PGP SIGNATURE- >>> >>> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4/abcACgkQ24/THMrX >>> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq >>> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F >>> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh >>> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM >>> 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz >>> iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg== >>> =h62J >>> -END PGP SIGNATURE- >> >> P.S. the bits do change for me as stated in the Xen log when I resume from a >> suspend. Here is what >> mine says. >> >> (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b) > Thanks for sharing that. Just as I expected, bits 31 and 27, xor 0x8800. That makes three of us now. I finally did some digging. I'm wondering if it has to do with the RDRAND issue which has been well known since at least May 7, 2019 to affect Fam15h. This stands to reason, as I immediately updated to the May 19 BIOS update when I bought this machine. awokd had suggested this update, specifically an AGESA update contained within, might have been the cause of an unrelated problem. https://www.phoronix.com/scan.php?page=news_item=AMD-CPUs-RdRand-Suspend https://linuxreviews.org/AMD_finally_submits_kernel_patch_for_broken_RDRAND_on_older_AMD_APUs https://www.mail-archive.com/qubes-users@googlegroups.com/msg31568.html - User awokd's note about AGESA update https://www.mail-archive.com/qubes-users@googlegroups.com/msg31689.html - User Qubes123's investigation into CPUID bits >From linuxreviews.org: "There have been reports of RDRAND issues after resuming from suspend on some AMD family 15h and family 16h systems. [...] RDRAND support is indicated by CPUID Fn0001_ECX[30]. This bit can be reset by clearing MSR C001_1004[62]. Any software that checks for RDRAND support using CPUID, including the kernel, will believe that RDRAND is not supported. " According to the page below, RDRAND is bit 30 in ECX, not 31. And that still doesn't explain the 27th bit turning on after resume. 27: OSXSAVE (turns ON) 30: RDRAND (unchanged) 31: Not used, always 0 (turns ON) https://www.felixcloutier.com/x86/cpuid#fig-3-7 So it doesn't sound like the same problem at all, but all my search queries seem to lead back to the RDRAND issue. I'm hoping someone with more expertise in this area can make some better sense of this. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/86dfd10b83e568a734521dfd61f5af90%40disroot.org.
Re: [qubes-users] screenshot: send to VM ??
February 8, 2020 12:19 PM, "haaber" wrote:
>>> Hi, when I press PrintScreen (under xfce), I get several options, among
>>> which save-in-dom0. It would be nice to be able to send it directly to a
>>> VM. Can this be done? Cheers, Bernhard
>>
>> I haven't tested it, but try something like this:
>>
>> #!/bin/bash
>> qvm-copy-to-vm $(zenity --entry --title='Send to VM' --text='Destination
>> VM') "${BASH_ARGV[@]}"
>>
>> Save that as an executable script, such as "~/.local/bin/send-to-vm.sh".
>> Then, open dom0 file
>> manager, right click any png, click open with other application, and under
>> "use a custom command"
>> enter "send-to-vm.sh %s". Then, when you take a screenshot, instead of
>> choosing "save", choose
>> "open with..." and see if your script shows up in the list of available
>> applications. If not, you
>> might have to write a simple .desktop file in ~/.local/share/applications in
>> order for it to show
>> up as an option.
>>
>> Again, this is just an idea off the top of my head and totally untested.
>
> Thank you. Of course I can do a second step after PrintScreen: change to
> my dom0 terminal to run qvm-copy-to-vm. That is what I do since ever. My
> question is rather how to integrate a new "send-to-VM" function in the
> screenshot application so that it is only one step: PrintScreen & select
> destination appVM ...
Okay, no offense, but that's pretty much *exactly* what I described. The idea
is that from the screenshot menu, instead of clicking save, you click "open
with send-to-vm.sh", and then a zenity GUI window will pop up asking you for
the destination VM name. If you want a list to select from, change it to
something like `qvm-ls | cut zenity --list`. I don't see how it could be any
more integrated. If you believe I am mistaken, please point out exactly how my
solution differs from what you're trying to achieve.
You might also be interested in the Qubes Screenshot Tool instead
https://github.com/evadogstar/qvm-screenshot-tool
> I guess the PrintScreen "app" is a simple script,
> hidden somewhere, as well? I'd like to extend it. Bernhard
No, it's a binary. https://git.xfce.org/apps/xfce4-screenshooter
The PrintScreen key is mapped to screenshooter by default, but you can map it
to something else via System Tools > Keyboard. You can also remap it to
"screenshooter --open send-to-vm.sh" to skip the save/open/upload dialog and
instead go right to the destination VM dialog.
See also
https://docs.xfce.org/apps/screenshooter/usage
https://askubuntu.com/questions/252738/configure-xfce4-screenshooter-settings
https://www.commandlinux.com/man-page/man1/xfce4-screenshooter.1.html
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/80c51b481d80c5de4f4afe2f96ad73fd%40disroot.org.
Re: [qubes-users] How to install software in an AppVM without loosing persistence?
February 8, 2020 11:51 AM, "Monsieur DuPont' via qubes-users" wrote: > Dear Qubes users/fans; > > I was trying the other day to install some piece of software in a Debian-9 > based AppVM but after a > reboot it was reset to its usual state and that piece of software was no > longer found. > > Hence how is it possible to install persistently software in AppVMs? > > Thank you in advance! > > Yours faithfully, > > Signed, your fellow Qubes user/fan You have to install it in the TemplateVM that the AppVM is based on. Then, power off the TemplateVM and reboot the AppVM. The package will now be available in all AppVMs which are based on that template. Optionally, you can clone the TemplateVM first and then set the AppVM to use the new template. Alternatively, you can install the app in a Standalone VM. https://www.qubes-os.org/doc/templates/ https://www.qubes-os.org/doc/software-update-domu/ -- You received this message because you are subscribed to the Google Groups "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/70639038d37ad6e7806e341e428c8e3c%40disroot.org.
Re: [qubes-users] screenshot: send to VM ??
February 8, 2020 9:01 AM, "haaber" wrote:
> Hi, when I press PrintScreen (under xfce), I get several options, among
> which save-in-dom0. It would be nice to be able to send it directly to a
> VM. Can this be done? Cheers, Bernhard
I haven't tested it, but try something like this:
#!/bin/bash
qvm-copy-to-vm $(zenity --entry --title='Send to VM' --text='Destination VM')
"${BASH_ARGV[@]}"
Save that as an executable script, such as "~/.local/bin/send-to-vm.sh". Then,
open dom0 file manager, right click any png, click open with other application,
and under "use a custom command" enter "send-to-vm.sh %s". Then, when you take
a screenshot, instead of choosing "save", choose "open with..." and see if your
script shows up in the list of available applications. If not, you might have
to write a simple .desktop file in ~/.local/share/applications in order for it
to show up as an option.
Again, this is just an idea off the top of my head and totally untested.
--
You received this message because you are subscribed to the Google Groups
"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/a42f6d34f4b880b585823f17a3992eec%40disroot.org.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 7, 2020 8:10 PM, zachm1...@gmail.com wrote: > On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com wrote: > >> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote: >>> February 7, 2020 6:00 AM, zach...@gmail.com wrote:> I have a Thinkpad T495 >>> with an AMD Ryzen Pro >>> 3700U and Vega 10 graphics. Everything seems to be >>>> working besides suspend/resume which is crucial for me since I'm on the go >>>> a lot. I had to build >>> my >>>> own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ >>>> kernel for the graphics >>>> driver. I installed `kernel-latest` from qubes-dom0-current testing but >>>> still didn't work. After >>>> trying every kernel option on the face of this Earth I decided to use an >>>> experimental Qubes R4.1 >>>> build as some things were pointing to dom0 Fedora 25 being the issue. On >>>> dom0 Fedora 31 it's >>> still >>>> an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost >>>> the whole day trying to >>>> figure the issue out. >>>> >>>> When I suspend, it clearly suspends but when I open it back up the screen >>>> is off but the power >>> LED >>>> is on. I can hear the fan spin up for a bit but nothing happens. CTRL + >>>> ALT + Backspace does >>>> nothing. I also tried switching to text mode before suspending with CTRL + >>>> ALT + F2. Nothing... I >>>> also disabled the compositor in XFCE to give it a try in both R4.0 and >>>> R4.1, no difference. It >>>> totally seems like an X server or amdgpu issue but I really don't know >>>> what to do. >>>> >>>> I don't have any VMs running when I test the suspend and I don't have a >>>> sys-usb VM to take that >>> out >>>> of the equation. Any ideas? I'm scratching my head over here and I'm at a >>>> loss on what to try >>> next. >>>> >>> >>> Did you try the Xen power.c patch? >>> >>> It sounds like a Xen panic. Some or all AMD Fam15h processors change their >>> CPUID feature bits after >>> resume, which triggers a Xen panic (LEDs and fans on, screen off, keyboard >>> and power button >>> unresponsive). There is a patch and instructions towards the end of this >>> thread: >>> https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - >>> It takes some work but it >>> sounds very likely it will fix your problem. Sys-usb causes other problems >>> on a lot of Ryzen >>> machines, so continue to keep it disabled for now. >>> >>> It doesn't sound like a graphics problem. Usually X or amdgpu issues result >>> in the screen's >>> backlight coming on but displaying a blank screen, and often the keyboard >>> is responsive just not >>> the screen. At least in my experience. >>> >>> PS: when replying to mailing lists please write your response *below* the >>> quoted text you're >>> replying to. >> >> Thanks for responding Claudia! I haven't tried that patch but I saw it in >> your other thread. I >> guess my options are pretty exhausted at this point so I'll give it a try. >> I've never actually >> built an RPM outside of qubes-builder. I'm assuming I should just build the >> entire Qubes R4.0 >> (stable) ISO with the edit included. I've never had such a complex issue >> before so this is all new >> to me. Not sure what you mean about building an RPM outside qubes-builder. This is all done within qubes-builder. So if you have any experience at all with that, then you're already off to a way better start than I was. It wasn't nearly as bad as I thought it would be either. The GUI script does most of the work for you. I tried to leave a sufficiently detailed diary of what I did because I knew it would come in handy later (whether for myself or others). And, you can always ask the mailing list for help. I just built the RPMs. Building the whole ISO apparently takes many hours and many GB of disk space. And, as with building anything, keep in mind if something goes wrong mid-build, there's a good chance you'll have to start over from the beginning. It took me several attempts. Either method should work the same though, so it's up to you. >> Should we get the Qubes team to include this patch as a fix for AMD? I'm not >> sure what the security >> implications are but I would assume it co
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 7, 2020 1:03 PM, "Claudia" wrote: > February 7, 2020 6:00 AM, zachm1...@gmail.com wrote: > >> I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics. >> Everything seems to be >> working besides suspend/resume which is crucial for me since I'm on the go a >> lot. I had to build my >> own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ >> kernel for the graphics >> driver. I installed `kernel-latest` from qubes-dom0-current testing but >> still didn't work. After >> trying every kernel option on the face of this Earth I decided to use an >> experimental Qubes R4.1 >> build as some things were pointing to dom0 Fedora 25 being the issue. On >> dom0 Fedora 31 it's still >> an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost >> the whole day trying to >> figure the issue out. >> >> When I suspend, it clearly suspends but when I open it back up the screen is >> off but the power LED >> is on. I can hear the fan spin up for a bit but nothing happens. CTRL + ALT >> + Backspace does >> nothing. I also tried switching to text mode before suspending with CTRL + >> ALT + F2. Nothing... I >> also disabled the compositor in XFCE to give it a try in both R4.0 and R4.1, >> no difference. It >> totally seems like an X server or amdgpu issue but I really don't know what >> to do. >> >> I don't have any VMs running when I test the suspend and I don't have a >> sys-usb VM to take that out >> of the equation. Any ideas? I'm scratching my head over here and I'm at a >> loss on what to try next. > > Did you try the Xen power.c patch? > > It sounds like a Xen panic. Some or all AMD Fam15h processors change their > CPUID feature bits after > resume, which triggers a Xen panic (LEDs and fans on, screen off, keyboard > and power button > unresponsive). There is a patch and instructions towards the end of this > thread: > https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - It > takes some work but it > sounds very likely it will fix your problem. Sys-usb causes other problems on > a lot of Ryzen > machines, so continue to keep it disabled for now. > > It doesn't sound like a graphics problem. Usually X or amdgpu issues result > in the screen's > backlight coming on but displaying a blank screen, and often the keyboard is > responsive just not > the screen. At least in my experience. > > PS: when replying to mailing lists please write your response *below* the > quoted text you're > replying to. Also I forgot to mention, if the patch works but you still run into other post-resume problems, you may have to pin dom0 to CPU0. See https://www.mail-archive.com/qubes-users@googlegroups.com/msg31737.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/98262c7f7b6c7ec43a72657febed1545%40disroot.org.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 7, 2020 6:00 AM, zachm1...@gmail.com wrote: > I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics. > Everything seems to be > working besides suspend/resume which is crucial for me since I'm on the go a > lot. I had to build my > own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ > kernel for the graphics > driver. I installed `kernel-latest` from qubes-dom0-current testing but still > didn't work. After > trying every kernel option on the face of this Earth I decided to use an > experimental Qubes R4.1 > build as some things were pointing to dom0 Fedora 25 being the issue. On dom0 > Fedora 31 it's still > an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost the > whole day trying to > figure the issue out. > > When I suspend, it clearly suspends but when I open it back up the screen is > off but the power LED > is on. I can hear the fan spin up for a bit but nothing happens. CTRL + ALT + > Backspace does > nothing. I also tried switching to text mode before suspending with CTRL + > ALT + F2. Nothing... I > also disabled the compositor in XFCE to give it a try in both R4.0 and R4.1, > no difference. It > totally seems like an X server or amdgpu issue but I really don't know what > to do. > > I don't have any VMs running when I test the suspend and I don't have a > sys-usb VM to take that out > of the equation. Any ideas? I'm scratching my head over here and I'm at a > loss on what to try next. > Did you try the Xen power.c patch? It sounds like a Xen panic. Some or all AMD Fam15h processors change their CPUID feature bits after resume, which triggers a Xen panic (LEDs and fans on, screen off, keyboard and power button unresponsive). There is a patch and instructions towards the end of this thread: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - It takes some work but it sounds very likely it will fix your problem. Sys-usb causes other problems on a lot of Ryzen machines, so continue to keep it disabled for now. It doesn't sound like a graphics problem. Usually X or amdgpu issues result in the screen's backlight coming on but displaying a blank screen, and often the keyboard is responsive just not the screen. At least in my experience. PS: when replying to mailing lists please write your response *below* the quoted text you're replying to. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/929c8ac5e136abf7258a1c91d6f58fae%40disroot.org.
Re: [qubes-users] Machine reboots when I log in
February 5, 2020 7:34 AM, "Günter Zöchbauer" wrote: > When I come back to my computer > > and log in on the dom0 lock screen, the machine often just reboots. > > Has anybody seen this? > Any suggestions how to debug? You can try journalctl -b -1 -e, but it's probably not syncing the journal before it reboots. Does it seem to freeze for five seconds before it reboots, or does it reboot immediately? Does this also happen when you have no VMs running? For me, Xen seems to reboot most often when it's low on memory. You can try adding noreboot=1 to the Xen command line, and look for any console output when it crashes. If you're up to the task, you could try enabling kernel crash dumps: https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0989764e0cfafe2257f265b4625c1cf2%40disroot.org.
Re: [qubes-users] cannot find if my hardware will meet the min requirements for the latest qubes os' install - need some help!
February 4, 2020 4:40 PM, "unman" wrote: > At first setup do NOT choose to create a sys-sub - I've done it and it > is an unfortunate mistake to make. Last time I did a USB install (R4.1), the option was greyed out and "Unavailable because the root filesystem is on a USB device" or something like that :) Honestly I don't recommend using the sys-usb init config option at all unless you're sure it's going to work, i.e. you've used sys-usb on that machine before. You should do the installation without sys-usb and get everything else working, then enable it later using the instructions, because if it causes problems it's *much* easier to attribute to sys-usb. If you have it enabled from the start, it's not easy to see the cause-effect relationship. Just my opinion. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9acf2f6740bf2e50ed624252f300a778%40disroot.org.
Re: [qubes-users] cannot find if my hardware will meet the min requirements for the latest qubes os' install - need some help!
February 2, 2020 11:19 PM, "rickey" wrote: > Good evening Everyone, > > I have red about the minimum, and recommended system requirements for Qubes > OS latest installation > but still cannot define if my Intell NUC8i7HVK will meet them. > > Could you, please give me a help how to find if the Intel VT-x, VT-d and TPM > are present in my > hardware? > > I have attached the pdf with the tech spec of the unit too. > > Thank you, and Best Regards, According to the spec sheet it has the i7-8809G, which does support VT-x and VT-d. https://en.wikichip.org/wiki/intel/core_i7/i7-8809g If you want to check for yourself (including TPM): Important: make sure these features are enabled in your bios setup, or they will appear not present to the OS. See: https://www.intel.in/content/www/in/en/support/articles/07139/server-products.html If you're on Linux now, you can check /proc/cpuinfo for VT-d grep vmx /proc/cpuinfo if it shows the cpu flag for it, it means you have VT-d. You don't really have to check for VT-x. The qubes-hcl-report tool checks for a TPM using: find /sys/devices/ -name pcrs (https://github.com/QubesOS/qubes-core-admin/blob/master/qvm-tools/qubes-hcl-report) TPM is required only if you want to use AEM, but it's not required for a basic Qubes installation. Those requirements are just the very first step. You should boot the Qubes installer and make sure you get to the graphical installation screen - this is a good sign Qubes will work on that machine. If you want, you can also try installing Qubes on a USB flash drive without touching your existing OS. https://www.qubes-os.org/doc/installation-guide/#installation-destination -- You received this message because you are subscribed to the Google Groups "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/32c871686e803acf3e7a8f6db75cd5fb%40disroot.org.
Re: [qubes-users] Custom guid.conf settings appear to be ignored
February 1, 2020 7:21 PM, "awokd' via qubes-users" wrote: > Claudia: > >> I tried to increase my startup timeout in guid.conf according to >> https://www.qubes-os.org/doc/config-files > > Are you looking for qvm-prefs [vmname] qrexec_timeout? I wonder if that > value was for Qubes 3.2. That seems to have done the trick. Thanks! I've seen the guid.conf method a few places, and I thought I saw it semi-recently on the mailing list. Also I looked at the qubes-guid code a few days ago and it looked like startup_timeout was still there. Who knows. -- You received this message because you are subscribed to the Google Groups "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/8bb75ff455ee981f00db8395bd631081%40disroot.org.
Re: [qubes-users] Firefox discontinues addon sideloading
February 1, 2020 9:13 AM, "David Hobach" wrote: > One could also follow their suggested path by setting up one's own addon > server; it sounds a lot like overkill to me though. I'm not sure if that would achieve the desired result though. I think that's no different from using the official update server, in that you'd still have to "download" and install/update addons through the UI. I don't think that approach offers silent loading/updating. BTW, if you find a solution, please let us know what you came up with. I don't currently have a use for this kind of setup, but it sound like it could be useful in the future. -- You received this message because you are subscribed to the Google Groups "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/7d378f1927778949901180261869ee23%40disroot.org.
[qubes-users] Custom guid.conf settings appear to be ignored
I tried to increase my startup timeout in guid.conf according to
https://www.qubes-os.org/doc/config-files/ , but no matter what I change it to,
the desktop notification still says cannot start after "60" seconds and `time
qvm-start ...` still reports about a minute. Interestingly, the commented out
value of 45, which is presumably the hardcoded default, doesn't seem to be
correct either. Nothing I've tried changes the reported nor actual wait time to
anything other than 60 seconds, even after a reboot. Also, qvm-start doesn't
complain even if I intentionally introduce a syntax error. It's like I'm
editing the wrong file. Any ideas?
/etc/qubes/guid.conf
# Sample configuration file for Qubes GUI daemon
# For syntax go http://www.hyperrealm.com/libconfig/libconfig_manual.html
global: {
# default values
#allow_fullscreen = false;
#allow_utf8_titles = false;
#secure_copy_sequence = "Ctrl-Shift-c";
#secure_paste_sequence = "Ctrl-Shift-v";
#windows_count_limit = 500;
#audio_low_latency = true;
# see man qubes-guid
#trayicon_mode = "border1";
#startup_timeout = 45;
startup_timeout = 120;
};
# most of setting can be set per-VM basis
VM: {
work: {
#allow_utf8_titles = true;
};
};
--
You received this message because you are subscribed to the Google Groups
"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/ee52261bd2522e4b1f302944f8f2ee4c%40disroot.org.
Re: [qubes-users] Firefox discontinues addon sideloading
January 28, 2020 7:09 PM, "David Hobach" wrote: > Dear all, > > apparently Mozilla decided to discontinue that feature [1] without providing > a lot of alternatives > [2]. > > It was quite useful in the past to update addons inside Qubes OS template VMs > by downloading them > to another VM and pass them to the template VM without having to start > firefox and perform a lot of > clicking. > > That'll be gone. > > So does anyone have an alternative available apart from a dedicated template > VM just for firefox? > > Update the addons on every disposable VM start? ^^ > > BR > David > > [1] > https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions > [2] > https://discourse.mozilla.org/t/questions-on-sideloading-alternatives/49245 Not sure, but it looks like this change only affects loading from a *global* directory (/usr/share/mozilla/extensions), and loading from inside the individual profile directories (~/.mozilla/extensions) will still be enabled. If that's the case, I imagine you could just symlink the XPI directory to somewhere on root.img. However it's not clear if they are still loaded silently, or if the user has to confirm it. I haven't been able to track down any specific commits or anything related to this. Might be worth looking at the Tor Browser mailing list / bug tracker for clues, as that's how they ship NoScript and HTTPS Everywhere, I think. They're currently on FF68 ESR, but I'm sure there's some buzz about what they're eventually going to do after FF72. Come to think of it, switching to FF ESR might be a temporary workaround for you. https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/#comment-226503 https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/#comment-226508 https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/#comment-226614 https://github.com/mozilla/geckodriver/issues/1517#issuecomment-513537686-permalink -- You received this message because you are subscribed to the Google Groups "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/0fd9126f9e4f1dfadf3dea7b16ecb832%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 25, 2020 6:46 PM, "M" wrote: > Thank you very much ! - I’ll try that... > > By grub menu you probably mean this one: > https://www.qubes-os.org/attachment/wiki/InstallationGuide/grub-boot-menu.png > > But I do not get so far as it seems to first show after the installation. > > The menu I see is this: > https://www.qubes-os.org/attachment/wiki/InstallationGuide/boot-screen.png Grub doesn't work on R4.0 in UEFI mode, so the installer probably uses syslinux at least for 4.0, not sure about 4.1. Looking at the screenshot, it looks like you just have to press tab instead of "e" and the rest should be the same. Also the troubleshooting menu is probably worth checking out. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/88796dec14c20580381b5b070f5f44ae%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 25, 2020 4:09 PM, "M" wrote:
> 1) I have tried to install R4.0.3 in legacy mode with the same result. And I
> have also tried the
> other installation possibilities that the DVD offer with the same result.
> Can I somehow save the logs on a USB-drive as I’m running the installer from
> a DVD, or is it only
> possible to get access to the log files afterwards by installing Qubes OS
> from a USB-drive ?
>
> 2) I have tried to look for the “xen.cfg” file you mentioned, but can’t find
> a file with that name
> in the downloaded ISO-file. Where to find it or is it called something else ?
Make sure you're looking in the first partition (/dev/sdb1). I'm not sure what
directory it's in on the installer and I don't have a copy of it handy. On an
installed system it's under (/dev/sdb1)/EFI/qubes/xen.cfg. Note this is for
R4.0 only.
You might want to start a new thread about that, so someone with more
experience in the installer can help you with that.
> 3) By “R4.1 pre-release” do you then mean “R4.0.1” ?
No, R4.1 is an upcoming version that hasn't been released yet, but has unstable
builds available.
https://openqa.qubes-os.org/tests/5493/asset/iso/Qubes-4.1-20200113-x86_64.iso
R4.0.x versions are the same as R4.0, but with updates preinstalled.
> I have tried to load R4.0.1 in legacy mode and when the grub boot menu
> appears, there isn’t any
> option labeled “Qubes R4.1, with Xen Hypervisor”. Just the same installer
> menu as on the later
> versions. And if I press “e”, nothing seems to happen.
It might be called something different. It'll most likely be the default menu
entry which is already highlighted, usually the first in the list.
I have no idea why "e" doesn't work. Can you move up and down to different menu
entries?
> 4) I’m also not totally sure where to add “nomodeset” when you just say at
> the end of the kernel
> line (it looks something like “multiboot2 vmlinuz”)... Sorry, could you be a
> little more precise on
> where I shall write it? Maybe show it in a picture... Just to make sure I add
> it the right place.
Here's a copy from an installed R4.1 system, but the entry in the installer
should look similar. nomodeset is on the second-to-last "module2" line (don't
type the asterisks). In legacy mode this line will start with "linux /vmlinuz-"
(I think) but works the same way. If you add it in the wrong place, don't worry
just reboot and try again.
menuentry 'Qubes, with Xen hypervisor' --class qubes --class gnu-linux --class
gnu --class os --class xen $menuentry_id_option
'xen-gnulinux-simple-2136e4d1-da52-4921-90c1-f7617ab8a31f' {
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
039dd247-6c6e-40c5-a8ec-890d4462da53
else
search --no-floppy --fs-uuid --set=root ...
fi
echo'Loading Xen 4.13.0 ...'
if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
xen_rm_opts=
else
xen_rm_opts="no-real-mode edd=off"
fi
multiboot2 /xen-4.13.0.gz placeholder console=none
dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan smt=off
${xen_rm_opts}
echo'Loading Linux 4.19.89-1.pvops.qubes.x86_64 ...'
module2 /vmlinuz-4.19.89-1.pvops.qubes.x86_64 placeholder root=UUID=...
ro rd.luks.uuid=luks-... plymouth.ignore-serial-consoles rhgb quiet
**nomodeset**
echo'Loading initial ramdisk ...'
module2 --nounzip /initramfs-4.19.89-1.pvops.qubes.x86_64.img
}
--
You received this message because you are subscribed to the Google Groups
"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/cfcf581f7a52bbf3403fe30a609fd402%40disroot.org.
Re: [qubes-users] feature request
January 25, 2020 1:53 PM, "Chris Laprise" wrote: > On 1/25/20 7:15 AM, haaber wrote: > >> Hello, I have several virtual screens; I guess many user have. Is it >> possible to reserve one of them exclusively for dom0 and templateVM >> terminals -sort of a separated "admin screen"- to avoid other >> appVM-windows popping up and being able to capture input from keyboard? >> Bernhard > > KDE lets you confine windows to certain screens or virtual desktops > under System Settings / Desktop Management / Window Rules. You can > specify how it matches the window, such as pattern matching on the > window title. > > For example, if you set Window Title to 'Regular expression' and the > text to '^\[personal', then under Size/Position select 'Desktop', 'Apply > Initially' and 'Desktop 2' ... that will make windows from any VM > beginning with "personal" open only on Desktop 2. You can also use > 'Force' instead of 'Apply Initially' and that will prevent you from > moving those windows to a different desktop. > > I think the regular expression matching is probably powerful enough to > do what you want. For example, a rule for any window title NOT beginning > with '[' and NOT having also ']' would be a dom0 window. Another rule > could have the names of all your templates. 1) At least on my machine (XFCE), dom0 windows start with "[Dom0]". But I get your point. 2) The "[]" part of the window title is not actually part of the WM_NAME property. It's the WM_CLIENT_MACHINE property. But as long as you can match on that, it makes it even easier to write rules. You can see it with xprop: [user@dom0 ~]$ xprop -id 0x1614d7d | grep -i 'Dom0' WM_CLIENT_MACHINE(STRING) = "dom0" WM_ICON_NAME(STRING) = "Terminal - user@dom0:~" _NET_WM_ICON_NAME(UTF8_STRING) = "Terminal - user@dom0:~" WM_NAME(STRING) = "Terminal - user@dom0:~" _NET_WM_NAME(UTF8_STRING) = "Terminal - user@dom0:~" Interestingly, I don't actually see a property equal to the full titlebar of the window, so I guess that's constructed by the window manager. -- You received this message because you are subscribed to the Google Groups "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/ff15a51104bd134e89d4a4ae32a4e89f%40disroot.org.
Re: [qubes-users] feature request
January 25, 2020 1:40 PM, "Claudia" wrote: > January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > >> I think some window managers allow one to pin certain applications to >> particular virtual desktops. >> But those aren’t really security features, more just window manager tricks >> to help users organize >> windows. >> >> My preference would be something along the lines of support for allowing >> multiple local x-servers >> in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and >> guests/domUs each or >> in groups to a particular x-server. Certain features would not work across >> x-windows sessions, e.g. >> inter vm copy/paste. One could also enforce it at the qubes policy level >> (e.g. no qvm-copy either). >> >> Useful if you want to reduce the chances of mistakenly leaking data across >> client work and/or >> personas. > > It seems to me like you could almost do this today, by starting another X on > another TTY each with > its own qubes_guid, optionally as different user. Each guid could probably be > patched* to listen on > different vchan "ports" (libvchan_[server|client]_init()), however I don't > think the vchan > infrastructure has any kind of real access control below the VM level. So in > order to really > isolate them on the dom0 side, you'd probably have to run a separate > xenstored for each X server, > so that you could control which server has access to the xenstore device > node. But I don't think > that would really be necessary if you're just trying to prevent accidental > leakage by the user. > > (*Currently it appears to use a hardcoded vchan "port" of 6000. See > qubes-gui-daemon/xside.c, and > qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is > actually the server, and > guid (dom0) is actually the client.) > Actually, what was I thinking. If the VM is the server and dom0 guid is the client, they wouldn't have to use different ports, assuming the vchan semantics works like TCP/IP. You'd just have to come up with some way to control which domains can send MSG_CREATE requests to which instance of guid. -- You received this message because you are subscribed to the Google Groups "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/ef06df5178ac410b480ddae583002b04%40disroot.org.
Re: [qubes-users] feature request
January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > I think some window managers allow one to pin certain applications to > particular virtual desktops. > But those aren’t really security features, more just window manager tricks to > help users organize > windows. > > My preference would be something along the lines of support for allowing > multiple local x-servers > in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and > guests/domUs each or > in groups to a particular x-server. Certain features would not work across > x-windows sessions, e.g. > inter vm copy/paste. One could also enforce it at the qubes policy level > (e.g. no qvm-copy either). > > Useful if you want to reduce the chances of mistakenly leaking data across > client work and/or > personas. It seems to me like you could almost do this today, by starting another X on another TTY each with its own qubes_guid, optionally as different user. Each guid could probably be patched* to listen on different vchan "ports" (libvchan_[server|client]_init()), however I don't think the vchan infrastructure has any kind of real access control below the VM level. So in order to really isolate them on the dom0 side, you'd probably have to run a separate xenstored for each X server, so that you could control which server has access to the xenstore device node. But I don't think that would really be necessary if you're just trying to prevent accidental leakage by the user. (*Currently it appears to use a hardcoded vchan "port" of 6000. See qubes-gui-daemon/xside.c, and qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is actually the server, and guid (dom0) is actually the client.) Then, optionally you could implement some sort of policy to enforce which VMs are allowed to connect to which guid. Whether as a qubes-rpc policy of some sort, within guid, or just a simple X hook/script using the _NET_QUBESVM window property. https://www.qubes-os.org/doc/gui/ https://www.cs.uic.edu/~xzhang/vchan/ https://github.com/QubesOS/qubes-core-vchan-xen https://github.com/QubesOS/qubes-gui-daemon PS: I can't believe the devs are actually thinking about rolling out GUI domains by default in 4.1. It's hard enough to get Qubes running on a given machine as it is now, let alone the fact that VGA passthru is a total crapshoot even under the best conditions. I still can't even get sys-usb to work without corrupting memory space of my VGA controller and SATA controller. -- You received this message because you are subscribed to the Google Groups "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/30823052eccdc181ca9a0774fc3cd678%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 24, 2020 3:02 PM, "M" wrote: > I use DVD’s so that the files can’t be edited or a malicious file can’t be > placed on the > installation media in case it’s inserted in a compromised pc. But yes, it > seems to require a lot of > disc as Qubes OS not always develops linear. :j This is good security practice. I recommend it if you don't mind the inconvenience. > Regarding editing ISO-files, I’m not as technical as you. So that would > require some detailed > instructions. The process for editing the ISO kernel parameters is described in https://www.qubes-os.org/doc/uefi-troubleshooting/ , except in your case you are adding the "nomodeset" option instead of the ones they tell you in the guide (based on your symptoms). Add "nomodeset" to the end of each "kernel=" line in xen.cfg. Note: after you rebuild the ISO, optionally you may want to run it in a VM to make sure you got everything right, before you burn a DVD. Don't expect it to actually work correctly, but just make sure you're able to select the "Install Qubes" boot menu entry and that it doesn't complain about a bad config file or anything. If everything goes as it should, most likely you'll get a "sorry, this system doesn't support virtualization" type of message because it's already running in a VM. If so, that's good, burn to DVD. However, that being said... Honestly, the easiest thing right now would be download the R4.1 pre-release, burn it, try it with default settings first, and if you get the same problem as before, add nomodeset. To do that just press 'e' when you see the grub boot menu (with option "Qubes R4.1, with Xen hypervisor" highlighted) and then add "nomodeset" at the end of the kernel line (it looks something like "multiboot2 vmlinuz ..."). > Just to rule the option out: Could it be possible that when installing from a > burned ISO-file the > installation fails, while installing from a USB with a transferred ISO-file > using Rufus in dd-mode > the installation of Qubes OS succeed ? - If so, I would try that first. But > then I have to buy a > new USB flash drive. In this situation, I kind of doubt it. The problem seems to be at a higher level than that, since you're getting to an anaconda console at least. It's probably kernel version issue or graphics driver issue. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1e5ca5f11ce0d02263ec9f694609a9df%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 24, 2020 12:55 PM, "M" wrote: > Thank you for your answer. > > What do you mean by “nomodeset” ? - is it regarding legacy and UEFI mode > or... ? In 4.0, to enable nomodeset you have to edit the bootloader files files in the installation media. I just realized, since you're using DVDs instead of USB, this is going to be a lot more difficult. You'll have to unpack the ISO, modify the boot loader file, and then repack the ISO and burn it. I would recommend using a USB drive in this case if you can. That way you can do the modifications directly to the USB drive, and you don't have to waste additional DVDs. In R4.1, you just have to press 'e' at the boot menu, and you can make last minute changes to the boot parameters without modifying anything. This would probably be the easiest option. nomodeset is a kernel command line option that disables kernel-modesetting and prevents graphics drivers from being loaded, so they just use a basic minimal driver essentially. In 4.0 this would be the "kernel=" line of the xen.cfg file. > As I only have tried with Qubes OS stable version 4.0.1 and 4.0.2 and is now > going to try 4.0.3 the > kernel version is 4.19. How can I try to install Qubes with a newer kernel. I'm not sure if there's any easy way to install a newer kernel into the installer. The way most people do it is to do the installation on a different machine, install kernel-latest, and then move the drive to the other machine. However 4.0.3 should come with a newer LTS kernel at least, so try that first. When the installer fails, copy or screenshot /tmp/X.log and post it. > Could an idea be to try to install Linux Mint or Fedora 31 if 4.0.3 doesn’t > work either ? - just to > make sure they work and rule basic things out. R4.0 is based on Fedora 25, so you could try booting that just to make sure it works, just to rule that out. However there's still a big difference between Qubes and Fedora 25, so it won't tell us very much. > Both PartedMagic (24/12-2019) and Trial 4.2.2 live-versions runs fine (and > also Windows 10). -- You received this message because you are subscribed to the Google Groups "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/59e5a533a852824cd467c1815cc08a41%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 23, 2020 4:57 PM, "M" wrote: > Hello Claudia > > It seems you got Qubes OS working with your AMD Ryzen 5 2500U with integrated > Vega 8 Graphics. > > I have bought a AMD Ryzen 3200G also with Vega 8 Graphics, and I have tried > install Qubes 4.0.1 and > 4.0.2 on the pc (from a DL-DVD both in UEFI and Legacy mode), but without any > luck so far. > > In UEFi the cursor ends up blinking on a black screen. > > In Legacy mode I end up just before loading the graphical interface by > getting an error message: > Failing to load kernel modules/X startup failed -> Aborting installation. > > For screenshots, see here: > https://github.com/QubesOS/qubes-issues/issues/4510 > > I have also tried the other possibilities to install Qubes that the two > ISO-DVD’s offer. But that > also ended with the same result. > > Maybe I can learn from your experiences... > > I have tried to read your threads in this post, but as a newbie it isn’t > explained in a way that I > can try to follow. > > So I hope you will explain to me what I can try to do to make Qubes OS > running on my pc. > > Here is my hardware settings in case it should be relevant: > > Motherboard: Asrock X570M Pro4 > CPU: AMD Ryzen 3 3200G w. integrated Vega 8 Graphics > Ram: 32 GB G.Skill > Hard drive: SSD + HDD For me, the boot and install mostly just worked out of the box. I never experienced the installer drop to shell or "X failed to start" or anything like that. I did have the installer screen freeze sometimes on one version, I think 4.0.2-rc2, but I was able to get past it and never really investigated the cause. In my case, it was the post-installation stuff that took some real troubleshooting. So I don't have much to offer beyond the generic troubleshooting tips. I looked at your thread, but it doesn't appear to have /tmp/X.log, please post that if you can. You're at least making it to the console, so that's good. I would definitely try booting with nomodeset if you haven't already. It can fix a wide variety of different X-related problems. Also please mention what Qubes ISO versions and kernel versions you've tried. You may want to try an R4.1 pre-release build. Look for the link Brendan posted earlier in this thread. You may also want to try installing Qubes on a different machine, upgrading to kernel-latest, and then moving the disk or USB drive to the target machine. For what it's worth, the "[Firmware bug]" and "ACPI Error" lines are quite common, if not universal, on Ryzen systems. However they don't seem to be related to any specific problems in practice, so I wouldn't worry too much about those. The "Failed to load kernel modules" error seems to be common in Qubes and even other OSes, regardless of hardware, so I wouldn't worry about that either. I doubt any of those are directly related to the X failure you're experiencing. I can also say, sys-usb causes all manner of problems on my machine and for some other Ryzen users as well. So when you do finally make it to that point, I definitely would not recommend enabling that option until you have everything else working. -- You received this message because you are subscribed to the Google Groups "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/26a98d95fe9f52c368d172e98427cd38%40disroot.org.
Re: Aw: Re: [qubes-users] Installation freezes before displaying installer - UEFI-Troublshooting impossible
January 22, 2020 11:36 AM, anbe2...@joker.ms wrote: > Hello Claudia, > > thanks so much for your answer. > >> Once you write the image file with dd, you should be able to mount the ext3 >> /boot filesystem > read/write > >> just like you would any partition on a flash drive. It should no longer >> appear as an iso once > it's written to > >> the flash drive, it should show up like an external hard drive would. You >> may have to unplug it > and plug it > >> back in for the kernel to recognize the new partitions on it. Also, make >> sure you're writing to > /dev/sdb > >> and not /dev/sdb1 for example. > > My system mounts the usb-stick as following: > > $ mount -l > > $ /dev/sdb1 on media/username/Qubes-R4.0.2-x86_64 type iso9660 > (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=1000,dmode=500,fmode=40 > ,uhelper=udisks2) [Qubes-R4.0.2-x86_64] What was the full command you used to write the ISO to the USB drive? Are you absolutely sure you wrote it to /dev/sdb and not /dev/sdb1? It should be mounted as vfat, not iso9660. You can try mounting it as vfat with `mount -t vfat /dev/sdb1 /mnt`, but I don't think it'll work without being rewritten. -- You received this message because you are subscribed to the Google Groups "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/a57791a95220e0af8578c82b5ed4128a%40disroot.org.
Re: [qubes-users] Upgrading/creating "special" VMs (sys-net, vault, etc)
January 22, 2020 12:21 PM, "unman" wrote:
> On Wed, Jan 22, 2020 at 03:09:31AM +, Claudia wrote:
>
>> January 21, 2020 7:04 PM, "Dan Krol" wrote:
>>
>> So to clarify:
>>
>> Sys-net and sys-firewall (and sys-vpn if you use it) will need it enabled.
>>
>> When you say "need it enabled", you're just referring again to "provides
>> network", is that correct?
>>
>> And secondly: Do I understand correctly so long as any qube sits in between
>> two other qubes in the
>> networking chain, it automatically acts as a basic firewall? That's all that
>> sys-firewall is?
>>
>> From what I understand, sys-firewall is special in that it dynamically
>> changes firewall rules for
>> different VMs. That's where the firewall rules in the VM Settings GUI and
>> qvm-firewall are applied.
>> If you just create a new blank VM in place of sys-firewall, you can set up
>> static firewall rules,
>> but it won't by default know how to do any of the dynamic / user-defined
>> rule stuff.
>
> This isn't quite true - there's nothing special about sys-firewall. *Any* qube
> which provides network (and has relevant packages installed) will
> provide dynamic firewall. If you use the full templates it will work
> automatically.
O, so that's what "provides network" means? Now it's starting to make
sense. Thanks for clarifying.
Is there anything special about any VMs, other than:
dom0: obviously
debian-10, fedora-30, whonix-{ws,gw}-15: install path is controlled by rpm,
i.e. reinstalling the package would overwrite the templateVM image - unlike a
user-created or cloned TemplateVM
sys-net: provides network, assigned PCI network devices by default, clocksyncd
service
sys-usb: assigned USB controllers by default
sys-firewall: provides network, netVM=sys-net (as opposed to the global default
of sys-firewall or sys-whonix)
sys-whonix: provides network, netVM=sys-firewall (as opposed to the global
default of sys-whonix in some installations)
So in other words, you could delete any of these, and then just make a new VM
with the same template and the same VM settings, and it would function just
like the original, without any modifications inside the VM itself?
I've heard that recreating a broken sys-net for example is not that simple, so
I assumed there was something special about the sys-* VMs (or at least
sys-net). Is that not actually the case?
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/c3317508c056ed1da28cddac69d8ca63%40disroot.org.
Re: Aw: Re: [qubes-users] Installation freezes before displaying installer - UEFI-Troublshooting impossible
January 22, 2020 11:36 AM, anbe2...@joker.ms wrote: > Hello Claudia, > > thanks so much for your answer. > >> Once you write the image file with dd, you should be able to mount the ext3 >> /boot filesystem > read/write > >> just like you would any partition on a flash drive. It should no longer >> appear as an iso once > it's written to > >> the flash drive, it should show up like an external hard drive would. You >> may have to unplug it > and plug it > >> back in for the kernel to recognize the new partitions on it. Also, make >> sure you're writing to > /dev/sdb > >> and not /dev/sdb1 for example. > > My system mounts the usb-stick as following: > > $ mount -l > > $ /dev/sdb1 on media/username/Qubes-R4.0.2-x86_64 type iso9660 > (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=1000,dmode=500,fmode=40 > ,uhelper=udisks2) [Qubes-R4.0.2-x86_64] There's your problem. It's mounted with the "ro" flag. Not sure why, but it should be easy to get around. > Can you say me the exact command I have to write into my terminal to mount > the ext3 / boot > filesystem read/write just you mentioned above? Try this first: sudo mount -o remount,rw /dev/sdb1 /media/username/Qubes* sudo nano /media/username/Qubes*/EFI/BOOT/BOOTX64.cfg sudo umount /dev/sdb1 Or, if that doesn't work, do this instead: sudo umount /dev/sdb1 sudo mount /dev/sdb1 /mnt sudo nano /mnt/EFI/BOOT/BOOTX64.cfg sudo umount /mnt >> Actually, are you getting "Read-only filesystem" or "Permission denied" when >> you mount the first > partition > >> of the USB drive (not the iso file) and edit BOOTX64.cfg? > > The filesystem ist "read-only". > >> Also, try a different flash drive if you have one. It's possible it's >> showing up as write > protected for one >> reason or another which causes the fs to be mounted readonly. > > Same problem with another usb-stick. > >> Alternatively, I once had an issue with the installer freezing, and I was >> able to get around it > by repeatedly >> pressing ctrl-alt-f2 early during the boot process, and about 50% of the >> time it would change > TTYs without >> freezing and then I could switch back to the graphical installer on TTY1. I >> don't know if it has > worked for >> anyone else, but it might be worth a try. > > Unfortunately it doesn't work. > > These are the last lines, before my installation-process freezes: > > [XEN] echoes > 3...2...1... > Xen is relinquishing VGA console > > and then the black screen and after a moment, the system shuts down. if I try > it with plugged power > cord, the system boots after the black screen and than the same thing again > and again... -- You received this message because you are subscribed to the Google Groups "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/eac8e5890e5b9549a11f13e983f144b2%40disroot.org.
Re: [qubes-users] Installation freezes before displaying installer - UEFI-Troublshooting impossible
January 22, 2020 2:48 AM, anbe2...@joker.ms wrote: > Hello Everybody, > > I want to install QubesOS R4.0.2 on a Tuxedo Book XC1510 (Intel i7-9750H, > Nvidia GeForce GTX > 1660Ti, 32 GB RAM, Samsung 970 EVO Plus M.2 SSD, insydeH2O BIOS 1.07.14RTR1) > > I downloaded the *.iso, multiple verified key-fingerprints, signatures and > checksums and "dd" the > iso-image on a 16GB USB-2.0-Stick with Ubuntu. > > If I start up, the installation freezes before displaying the installer as > discribed in > "https://www.qubes-os.org/doc/uefi-troubleshooting;. > > I tried the following things: > > - troubleshooting as discribed in > "https://www.qubes-os.org/doc/uefi-troubleshooting; , but: the > bootable USB-Stick I created with "dd" from the *.iso-file is "read-only" and > trying to modify > "EFI/BOOT/BOOTX64.cfg" directly in the *.iso is the same problem: the system > mounted it read-only, > so I can't modify anything. Actually, are you getting "Read-only filesystem" or "Permission denied" when you mount the first partition of the USB drive (not the iso file) and edit BOOTX64.cfg? Also, try a different flash drive if you have one. It's possible it's showing up as write protected for one reason or another which causes the fs to be mounted readonly. Tip: when asking for help, consider posting screenshots and/or copies of the exact errors or terminal outputs along with the exact commands you ran, as it helps us identify the problem and get you to a solution faster. Small details can sometimes make a big difference. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4c8246309e75e90050c9b968dc7b2d9e%40disroot.org.
Re: [qubes-users] Installation freezes before displaying installer - UEFI-Troublshooting impossible
January 22, 2020 2:48 AM, anbe2...@joker.ms wrote: > Hello Everybody, > > I want to install QubesOS R4.0.2 on a Tuxedo Book XC1510 (Intel i7-9750H, > Nvidia GeForce GTX > 1660Ti, 32 GB RAM, Samsung 970 EVO Plus M.2 SSD, insydeH2O BIOS 1.07.14RTR1) > > I downloaded the *.iso, multiple verified key-fingerprints, signatures and > checksums and "dd" the > iso-image on a 16GB USB-2.0-Stick with Ubuntu. > > If I start up, the installation freezes before displaying the installer as > discribed in > "https://www.qubes-os.org/doc/uefi-troubleshooting;. > > I tried the following things: > > - troubleshooting as discribed in > "https://www.qubes-os.org/doc/uefi-troubleshooting; , but: the > bootable USB-Stick I created with "dd" from the *.iso-file is "read-only" and > trying to modify > "EFI/BOOT/BOOTX64.cfg" directly in the *.iso is the same problem: the system > mounted it read-only, > so I can't modify anything. Once you write the image file with dd, you should be able to mount the ext3 /boot filesystem read/write just like you would any partition on a flash drive. It should no longer appear as an iso once it's written to the flash drive, it should show up like an external hard drive would. You may have to unplug it and plug it back in for the kernel to recognize the new partitions on it. Also, make sure you're writing to /dev/sdb and not /dev/sdb1 for example. > - deactivate Nvidia graphics card from discrete to hybrid-modus in the BIOS, > in hope, that will use > the Intel-Grafik first, nothing. > - deactivate the Audio- and the WiFi-/Bluetooth-Adapter, nothing. > > - can't find any legacy-mode-option in BIOS to change it from EFI to Legacy... > > I'm not really experienced in Linux, worked 1,5 years with Ubuntu. But I read > the full > Qubes-Documentation, learned about this fantastic system as much as I can, > informed about it over > some days with youtube-videos, too. And now I want this amazing OS so much, > but that "EFI- and/or > Nvidia-Thing" stops me... > > Can somebody help me or give more infos, how I can solve the problem? > Thank You so much. > Greetings, Andreas. I would first try to edit the /boot files as mentioned above. Another idea is to enable nomodeset in the installer. Open /boot/efi/EFI/qubes/xen.cfg on the usb drive (mount the first partition, which is the EFI system partion, and edit /EFI/qubes/xen.cfg) and add "nomodeset" at the end of the "kernel=..." line. Alternatively, I once had an issue with the installer freezing, and I was able to get around it by repeatedly pressing ctrl-alt-f2 early during the boot process, and about 50% of the time it would change TTYs without freezing and then I could switch back to the graphical installer on TTY1. I don't know if it has worked for anyone else, but it might be worth a try. Finally, you have a couple of different options for Qubes image versions. R4.0, R4.0.1, R4.0.2 (which has a non-security-related bug which may or may not affect you), and R4.0.3-rc1. Once brought fully up to date, these all result in the exact same system ultimately. There are often slight variations between them, with regards to the installer, kernel, and so on, so one might work for you and another might not. -- You received this message because you are subscribed to the Google Groups "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/b299226b700559e855efb8f2d656a341%40disroot.org.
Re: [qubes-users] Upgrading/creating "special" VMs (sys-net, vault, etc)
January 21, 2020 7:04 PM, "Dan Krol" wrote: > So to clarify: > >> Sys-net and sys-firewall (and sys-vpn if you use it) will need it enabled. > > When you say "need it enabled", you're just referring again to "provides > network", is that correct? > > And secondly: Do I understand correctly so long as any qube sits in between > two other qubes in the > networking chain, it automatically acts as a basic firewall? That's all that > sys-firewall is? >From what I understand, sys-firewall is special in that it dynamically changes >firewall rules for different VMs. That's where the firewall rules in the VM >Settings GUI and qvm-firewall are applied. If you just create a new blank VM >in place of sys-firewall, you can set up static firewall rules, but it won't >by default know how to do any of the dynamic / user-defined rule stuff. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4bee0fcbad6da1abf3ee7def4eb6fa81%40disroot.org.
Re: [qubes-users] Should I chose a TemplateVM or a StandaloneVM for a Windows 10 VM ?
January 16, 2020 5:55 PM, "M" wrote: > I read about a TemplateVM and a StandaloneVM in the “Glossary of Qubes > Terminology”. But I’m still > not sure about which kind of VM to choose for a Windows 10 VM. > > Can someone please tell me more clearly when to chose these kinds of VM’s, > and which you would > recommend for a Windows 10 VM and why ? Something else I forgot to mention is that with Standalone VMs, you can install/upgrade software and just start using it, whereas with TemplateVMs you have to reboot the AppVM. For me, this is probably the biggest reason for using a Standalone VM. It can be a real pain to have to close all my work and reboot a VM just to install something in it. Of course, you can also install it temporarily the running AppVM and use it immediately, but then you have to install/configure it twice. -- You received this message because you are subscribed to the Google Groups "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/0c3af43a571ca36fdde76e83cd99f5cc%40disroot.org.
[qubes-users] Screen recording in Qubes VMs
I was wondering if anyone has had any luck with recording screen captures in Qubes. I tried the following FFmpeg line, which worked fine except it's only capturing a 640x480 corner of the screen. I'm not sure if this is Qubes-related or if I'm just not using it correctly. Note, I'm running this inside a Fedora VM, meaning other VMs' windows seem to be invisible (which is what I want in this case). Also, window borders and anything else drawn by dom0 seems to be invisible, but window content appears to be captured fine apart from the capture area being too small. $ ffmpeg -f x11grab -i :0.0 -vcodec libvpx -s 1920x1080 /tmp/ffout.webm [...] Input #0, x11grab, from ':0.0': Duration: N/A, start: 1579388031.870036, bitrate: N/A Stream #0:0: Video: rawvideo (BGR[0] / 0x524742), bgr0, 640x480, 29.97 fps, 29.97 tbr, 1000k tbn, 1000k tbc File '/tmp/ffout.webm' already exists. Overwrite ? [y/N] y Stream mapping: Stream #0:0 -> #0:0 (rawvideo (native) -> vp8 (libvpx)) Press [q] to stop, [?] for help [libvpx @ 0x56c7902a5900] v1.8.1 Output #0, webm, to '/tmp/ffout.webm': Metadata: encoder : Lavf58.20.100 Stream #0:0: Video: vp8 (libvpx), yuv420p, 1920x1080, q=-1--1, 200 kb/s, 29.97 fps, 1k tbn, 29.97 tbc Metadata: encoder : Lavc58.35.100 libvpx Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1 [...] Even though I'm setting the output resolution to my screen size, it seems to be detecting the input resolution at 640x480, and I haven't found any way to specify input resolution. I've tried with several different codec/container combinations but it still only captures the upper left corner. I was wondering if it could have something to do with Qubes because of the way the desktop is shared by different VMs. -- You received this message because you are subscribed to the Google Groups "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/e6656cf4c1a92e5766aad253a0fc252a%40disroot.org.
Re: [qubes-users] Why Windows 10 is slow? Is it because of HVM?
January 19, 2020 6:34 AM, "Guerlan" wrote: > Windows 10 VM is considerably slower than my traditional PV VMs, the ones > that come with Qubes. In > fact no one would notice that my PV VMs are virtualized, they look just like > regular bare metal > machines. > However, Windows 10 has lags. Anyone would notice and think either the > computer is slow or the > system is badly virtualized. For example, when I press Win button, it takes a > while for the menu to > appear. I can only think that it's because Windows 10 is running in HVM mode. > Should I try running > it in PV mode? If so, how? You could try it in PV mode. I'm not sure if it's supported by Qubes but you could probably make it work. https://xenproject.org/windows-pv-drivers/ Also consider that Windows might simply be slower than Linux, especially in resource-constrained environments like a VM. Are your Linux HVMs also slow/laggy? -- You received this message because you are subscribed to the Google Groups "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/13bd70f93be3ec92017d4b60f9c15211%40disroot.org.
Re: [qubes-users] Re: Why Windows 10 is slow? Is it because of HVM?
January 19, 2020 6:58 AM, "Claudio Chinicz" wrote: > Hi, > > As far as I understand, HVMs should be faster than PV. With the latter, the > OS makes hyper calls to > the hyper-visor while HVMs simply see virtualized hardware through the hyper > visor. I always thought the opposite was true. PVs should be faster because they don't have to go through a hardware emulator, they can just communicate with the hypervisor using an efficient protocol. I think that was the only reason for creating PVs in the first place (other than historical reasons before VT-x maybe). Otherwise they would have made HVM the only mode, much like KVM does. Btw, Qubes 4.0 uses PVH as the default mode, except for PCI passthru VMs. The reason is that the PV, while efficient, has become really insecure and is becoming deprecated. PVH runs the VM under VT-x like an HVM, but also has special guest-side PV drivers to make I/O faster by bypassing the emulated hardware. For example, PV(H) guests use the blkback driver (e.g. xvda) while HVM guests use a virtual SATA controller (e.g. sda) which is emulated by Qemu in userspace. Similarly, PV(H) uses netfront (e.g. "vif0" network interface) while HVMs use an emulated ethernet device (e.g. "eth0"). For PCI devices, PV(H) uses pcifront, however I think this is deprecated, which is why Qubes 4.0 uses HVM for all passthru VMs. HVMs use the platform features (e.g. IOMMU) to passthru the actual PCI hardware. HVM: DomU driver -> Xen -> Qemu -> Dom0 hardware driver -> Dom0 hardware PV: DomU PV driver -> Xen -> Dom0 hardware At least that's my understanding. -- You received this message because you are subscribed to the Google Groups "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/e7845a66f425df1eceff215ed57821b8%40disroot.org.
Re: [qubes-users] How different from bare metal linux is Qubes NVME interaction?
January 18, 2020 6:47 PM, "Guerlan" wrote: > On Saturday, January 18, 2020 at 8:27:05 AM UTC-3, Claudia wrote: > >> January 18, 2020 1:57 AM, "Guerlan" wrote:> I have a >> problem where any linux >> distro in my Razer Blade Stealth will suffer from NVME corruption >>> (nvme enters in read only mode) many times a day. I tried the most recent >>> kernel, old ones, etc. >>> Tried opening a bug in canonical launchpad, got some help, some kernel >>> patches to try, but none >>> worked. I made two independent tests that prove it's not a problem in my >>> notebok or SSD: 1, I >>> bougth a brand new SSD, same problem. 2: neither Windows or Qubes will give >>> the error. >>> >>> Actually, I installed Qubes just to see what would happen, because I wanted >>> to run something non >>> linux in my machine just to test. Turns out something in Qubes makes the >>> dom0 access the NVME >>> without any problems. >>> The way I think Xen/Qubes NVME interaction works is like this: xen has pci >>> front and back >> drivers. >>> Front is in xen, back is in dom0. dom0 then accesses the NVME through PCI. >>> The nvme driver in >> dom0 >>> is the same as the nvme driver in my older bare metal linux distributions >>> which had the bug, so I >>> can only think the bug happens in the PCI level, because it's the only >>> thing different here. >>> >>> Can someone with better understanding of Xen and Qubes give me a better >>> picture and maybe guess >>> what's happening and why I don't feel the bug at all in Qubes? >> >> Qubes doesn't use a storage domain, so the SATA controller (or in your case, >> NVME) doesn't use >> pciback as far as I know. If not for that, I would say it's probably because >> pciback blocks writes >> to read-only config space of PCI devices. However storage devices in Qubes >> just use the normal >> driver in dom0, just like any other Linux. You can check with `lspci -k`. >> Unfortunately I don't >> know enough about NVME to be much help. >> >> Have you tried installing Xen in any other distro? See if the problem occurs >> there. You can also >> test suspend/resume while you're at it. If you find that it fixes the NVME >> problem and suspend >> works, you can continue using that distro under Xen, even if you don't >> actually use any domUs. > > Thanks. Here's my lspci -k > > [lz@dom0 ~]$ lspci -k > 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor > Host Bridge/DRAM > Registers (rev 02) > Subsystem: Razer USA Ltd. Device 6752 > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: i915 > Kernel modules: i915 > 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI > Controller (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: pciback > Kernel modules: xhci_pci > 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP > Thermal subsystem (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: intel_pch_thermal > Kernel modules: intel_pch_thermal > 00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP > Serial IO I2C Controller > #0 (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: intel-lpss > Kernel modules: intel_lpss_pci > 00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP > Serial IO I2C Controller > #1 (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: intel-lpss > Kernel modules: intel_lpss_pci > 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME > HECI #1 (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: mei_me > Kernel modules: mei_me > 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port > #3 (rev f1) > Kernel driver in use: pcieport > 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port > #9 (rev f1) > Kernel driver in use: pcieport > 00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-LP > Serial IO UART Controller > #0 (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > Kernel driver in use: intel-lpss > Kernel modules: intel_lpss_pci > 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21) > Subsystem: Razer USA Ltd. Device 6752 > 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) > Subs
Re: [qubes-users] Are there any security benefits of setting up standalonevm instead of appvm?
January 8, 2020 6:28 PM, dhorf-hfref.4a288...@hashmail.org wrote: > "dont run software in places where you dont want it to run" should > cover this. note the term "run", not "install". In practice, I think there are some exceptions to this. Some software doesn't have a clear line between installing and running, from the user's perspective. Consider for example, multimedia codecs, link handlers, device drivers, plugins for other apps. It's not realistic to expect the user to examine the metadata of every image or video on every web page to make sure a particular codec won't run. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/10497fd7e39d94fc4eca09548b475a63%40disroot.org.
Re: [qubes-users] How different from bare metal linux is Qubes NVME interaction?
January 18, 2020 1:57 AM, "Guerlan" wrote: > I have a problem where any linux distro in my Razer Blade Stealth will suffer > from NVME corruption > (nvme enters in read only mode) many times a day. I tried the most recent > kernel, old ones, etc. > Tried opening a bug in canonical launchpad, got some help, some kernel > patches to try, but none > worked. I made two independent tests that prove it's not a problem in my > notebok or SSD: 1, I > bougth a brand new SSD, same problem. 2: neither Windows or Qubes will give > the error. > > Actually, I installed Qubes just to see what would happen, because I wanted > to run something non > linux in my machine just to test. Turns out something in Qubes makes the dom0 > access the NVME > without any problems. > The way I think Xen/Qubes NVME interaction works is like this: xen has pci > front and back drivers. > Front is in xen, back is in dom0. dom0 then accesses the NVME through PCI. > The nvme driver in dom0 > is the same as the nvme driver in my older bare metal linux distributions > which had the bug, so I > can only think the bug happens in the PCI level, because it's the only thing > different here. > > Can someone with better understanding of Xen and Qubes give me a better > picture and maybe guess > what's happening and why I don't feel the bug at all in Qubes? Qubes doesn't use a storage domain, so the SATA controller (or in your case, NVME) doesn't use pciback as far as I know. If not for that, I would say it's probably because pciback blocks writes to read-only config space of PCI devices. However storage devices in Qubes just use the normal driver in dom0, just like any other Linux. You can check with `lspci -k`. Unfortunately I don't know enough about NVME to be much help. Have you tried installing Xen in any other distro? See if the problem occurs there. You can also test suspend/resume while you're at it. If you find that it fixes the NVME problem and suspend works, you can continue using that distro under Xen, even if you don't actually use any domUs. -- You received this message because you are subscribed to the Google Groups "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/9d7885e7b35799ae169f7e88eab77a62%40disroot.org.
Re: [qubes-users] Xen doesn't recognize that a VM has finished starting
January 14, 2020 12:29 PM, "tetrahedra via qubes-users" wrote: > I have a HVM VM that I'm trying to set up as a new sys-net. > > However, when I boot it, Xen / Qubes doesn't seem to recognize that the > domain has finished > starting. > > The Qubes menu at the top right shows the red circling progress logo, even > though the domain has > booted already. > > When I try to start another VM which has been set to use the new-sys-net VM > as its NetVM, the > startup times out and I get the error "libxenlight has > failed to create new domain NEWVM"... > > /var/log/xen/console/guest-NEWSYSNET-dm.log doesn't show anything obviously > wrong, apart from some > call traces of unclear origin. Not sure, but it sounds like maybe the guest's qrexec isn't connecting to the host. Make sure it's installed and running properly in the guest. Check `systemctl status qubes-qrexec-agent.service` in the guest, and /var/log/qubes/qrexec..log on dom0. -- You received this message because you are subscribed to the Google Groups "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/57ab4930a68179b8a74859b7c59df401%40disroot.org.
Re: [qubes-users] Autostart on login in minimal templates
January 12, 2020 11:33 AM, "Abel Luck" wrote: > The systemd route does seem promising. Thanks. > > If I edited the template vm, I could just put my unit file in > /etc/systemd/system and it would work fine. > > However I'd like to do this for a specific AppVm, so I dropped the unit > file in /usr/local/lib/systemd/system. This file persists across boots > as expected, however systemd doesn't load units from it until I > daemon-reload after boot. > > I suppose this is because /usr/local is symlinked from /rw/usrlocal > sometime after systemd has loaded its units. > > Is there anyway to get systemd to load units from > /usr/local/lib/systemd/system as part of appvm boot? > > ~abel Try putting `systemctl daemon-reload` in rc.local. I haven't tried it, but this should work, as rc.local itself resides on /rw, so /rw has to be available by that time. (Arguably the stock rc.local in Qubes templates should be preinstalled with this line. But then, arguably, systemd should always automatically reload units any time it mounts something.) -- You received this message because you are subscribed to the Google Groups "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/d27f149b5018ef1a57c971707e224ef7%40disroot.org.
Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "
January 11, 2020 8:26 PM, cyber.citi...@tutanota.com wrote: > Thank you for your reply. If the problem recurrs, I would like to try this > solution before wiping > and reinstalling my entire system; but could you please provide a bit more > detail? How would I boot > with nomodeset? Boot into installation media and choose "rescue a qubes system", follow the prompts to mount and chroot, then edit /boot/efi/EFI/qubes/xen.cfg (UEFI systems) and add "nomodeset" at the end of the "kernel=" line for the version that is set as default. On grub systems, just press 'e' when you see the grub menu at boot up, and add nomodeset on kernel line. You might have to hold down shift or esc while booting to make it show the menu. Or, when it gets stuck, if you are able to switch to tty2 (ctrl alt f2), you can just do the same thing from there. -- You received this message because you are subscribed to the Google Groups "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/b1daa70a85c5b2621d7192aef755b0cd%40disroot.org.
Re: [qubes-users] Autostart on login in minimal templates
January 11, 2020 2:06 PM, "Abel Luck" wrote: > Hi there, > > Using the fedora and debian minimal templates, how can I execute a > script on *login*? I'm aware of /rw/config/rc.local, but that runs on > system boot. > > Rather, I want to run something after X11 has initialized and my user is > logged in. > > Since no DE is installed, .desktop files in ~/.config/autostart are not > executed in the minimal templates > > ~abel Would .xinitrc work? Systemd units with After=graphical.target and properly configured User=, Display=, Session=, Seat=, and/or whatever else might be necessary. Or maybe user-mode systemd units. https://wiki.archlinux.org/index.php/Systemd/User Or maybe rc.local with `systemctl is-system-running --wait` before your commands - I often have to use this with qvm-run. Running from rc.local though, commands might not be running as the right user/session/seat/slice/scope/whatever, I don't know. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cb9602caf03cf1401b51e2bb40a8cbb2%40disroot.org.
Re: [qubes-users] Debugging a sleep/suspend problem on Razer Blade Stealth 2016 - Qubes
January 9, 2020 1:55 AM, "Guerlan" wrote: > First of all, here's the HCL for my Razer Blade Stealth 2016 4K touchscreen > 16gb RAM 512gb SSD: > https://groups.google.com/forum/#!searchin/qubes-users/razer$20blade|sort:date/qubes-users/PalZ-1inx > A/D3mQ4OI3CAAJ > > When I close the lid and open again, keyboard wont ligth up, screen wont turn > on (it's LED so I can > see a brigth black when it turns on), and hitting keyboard or touchpad does > nothing. I have to > reboot. I don't know, however, if keyboard not ligthing when I open the lid > is because sys-usb, > which contains the keyboard, is not waken. Every other aspect of the laptop > seems to be working > perfectly. When you're testing, make sure there are no VMs set to start on boot, especially not sys-net and sys-usb, and make sure rd.qubes.hide_all_usb is not set. You can try to get that stuff working later on. Does pressing caps lock or num lock turn on/off their lights on the keyboard? Does ctrl-alt-delete, or Alt-SysRq-B (you have to enable it first) cause it to reboot? If you suspend with sound playing, can you hear it when you try to resume? > I followed Ubuntu's guide on kernel suspend bugs: > https://wiki.ubuntu.com/DebuggingKernelSuspend > > Then, following what they suggest > > `sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend"` > > and find the lines that says hash matches in dmesg rigth after reboot (what > does that mean?) > > Well, I found two: > > ``` > [ 3.583591] ima: Allocated hash algorithm: sha1 > [ 3.593050] input: AT Raw Set 2 keyboard as > /devices/platform/i8042/serio0/input/input4 > [ 3.638808] Magic number: 0:929:176 > [ 3.638867] acpi device:39: hash matches > [ 3.638893] acpi device:0c: hash matches > [ 3.639073] rtc_cmos 00:01: setting system clock to 2016-01-01 12:09:51 UTC > (1451650191) > ``` > > I couldn't find anything related to those acpi devices. I thougth first that > there was a driver for > them, so I should just rmmod those drivers before sleep and insmod when > wakeup, but couldn't find > anything. There's this issue > https://ubuntuforums.org/archive/index.php/t-2393029.html which have > those exact hash matches, but no answer. I don't know a lot about pm_trace, but it seems like there might be a problem decoding the hash. Normally it should show you a PCI address, /sys device name, driver name, or something more specific (see example in link below). According to s2ram kernel documentation: If no device matches the hash (or any matches appear to be false positives), the culprit may be a device from a loadable kernel module that is not loaded until after the hash is checked. You can check the hash against the current devices again after more modules are loaded using sysfs: cat /sys/power/pm_trace_dev_match https://www.kernel.org/doc/html/latest/power/s2ram.html#using-trace-resume However, in qubes we may also have the opposite problem. Qubes takes over your network cards and sometimes USB controllers in early userspace, so the drivers are not available anytime. To disable this behavior for USB controllers, remove rd.qubes.hide_all_usb from the kernel cmdline. For network cards it's a little more complicated. You can try modifying the qubes initramfs hook. First, make sure there are no VMs configured to start automatically at boot. Move /usr/lib/dracut/modules.d/90qubes-pciback/ to your home directory, or open the qubes-pciback.sh file and comment out the last 9 or so lines (from "for dev in $HIDEPCI"). Rebuild the initramfs. Then, do the pm_trace again as you did before. Then, try pm_trace_dev_match as described in the link above. It might give you better information about the problem device, or it might just give you the same info as before, but it's something to try. If it doesn't work, don't forget to put that file back how it was, and rebuild initramfs again. > Then I asked for help on a forum and they found this problematic line on my > dmesg: > > `[ 2.543596] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM` > > seems like ASPM is disabled on my Qubes. I don't know why. Should this be > considered a bug? Is > there anything I can do to get it working? This looks promising. > > It's worth noting that on Ubuntu 18, 19, Fedora 30, Linux Mint, etc, all > these systems work like a > charm with the sleep process. I can close the lid and open and it works. So > the problem seems to be > **related to Qubes**. I even tried qubes most recent dom0 kernel, based on > 5.x linux kernel, but > the problem persists. There's a pretty big difference between Fedora and Qubes. R4.0 is based on Fedora 25, not 30. Also have you tried suspend on any of those OSes with Xen installed and running? Or, have you tried booting Qubes without Xen? (Here's how to boot Qubes 4.0 without Xen: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31138.html - however it may be easier for you to install Qubes 4.1 on a removable drive to test
Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "
January 11, 2020 5:15 PM, cyber.citi...@tutanota.com wrote: > Yet another of my Qubes machines fell victim to this problem today. That's > two separate computers > in one week. The first was my production laptop. Today, it was my production > desktop. Of course, I > am inconvenienced by the time I have lost diagnosing the problem and > restoring my systems. I love > Qubes, and I won't abandon it; but I am worried that other users are not so > committed. I cannot be > the only user affected by this problem in recent weeks. I am saddened by the > thought that other > users will abaondon Qubes because of this issue, which is both unpredictable > and crippling. I urge > the developers to implement a fix sooner rather than later. I didn't see your original thread, but I think I had a somewhat similar problem. A workaround was to boot with nomodeset, and ultimately I had to disable sys-usb in order to boot without nomodeset. -- You received this message because you are subscribed to the Google Groups "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/e7590ddc44568ad337fdf343a00b3293%40disroot.org.
Re: [qubes-users] How to use QEMU with Qubes?
January 7, 2020 7:43 PM, "Guerlan" wrote: > I undrstand that HVM uses QEMU to emulate some devices and BIOS. However, > what if I want to have > total control of QEMU? > > What if there's an OS for which there's a QEMU tutorial and I want to do > exact what is in the > tutorial but in Qubes? > Do I need Qemu on dom0? dom0 has qemu-img-xen and qemu-nbd-xen. What are they > for? > > Or does QEMU runs inside xen, not in dom0? Xen uses QEMU just to emulate virtual hardware devices for HVMs, not for the actual virtualization. "Normal" Qemu is actually Qemu/KVM, which is not supported on Xen as far as I know. The next best thing is to create an HVM, see https://www.qubes-os.org/doc/standalone-and-hvm/#installing-an-os-in-an-hvm qemu-img-xen is used for formatting image files or block devices for VMs. qemu-nbd-xen is for network block devices, though I'm not sure if/how they're used in Qubes. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c5507405058f20884de80c525785dde8%40disroot.org.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
January 8, 2020 12:10 AM, "Guerlan" wrote: > On Tuesday, January 7, 2020 at 8:41:31 PM UTC-3, Claudia wrote: > >> January 7, 2020 6:08 PM, "Guerlan" wrote:> On Monday, >> January 6, 2020 at >> 12:43:40 AM UTC-3, Claudia wrote: >>> >>>> January 6, 2020 3:14 AM, dmoe...@gmail.com wrote:> On Sunday, January 5, >>>> 2020 at 9:49:42 PM >> UTC-5, >>>> Guerlan wrote: >>>>>> can you tell me how you figured this out? I've been trying to fix a >>>>>> suspend bug in mine and >> It'd >>>> be >>>>>> helpful to know how you debugged things >>>>> >>>>> Mostly trial and error, trying all the things listed above. Two little >>>>> tricks to use: >>>>> >>>>> 1. Look at the end of journalctl right before it tries to suspend. This >>>>> is where I saw that it >>>> was >>>>> going into s2idle, which then brought me to this thread: >>>>> >>>> >> https://groups.google.com/forum/#!msg/qubes-users/TmGDlkluJgM/1BFsQZWNDAAJ;context-place=forum/qubes >>>>> users This Dell did not have the lack of S3 that the new Thinkpads have, >>>>> but it did still try >> to >>>>> use s2idle. >>>> >>>> /sys/power/mem_sleep will list supported modes, with the default in >>>> brackets. You can echo to it >> to >>>> set the default at runtime, or use the boot parameter. >>> >>> [lz@dom0 ~]$ cat /sys/power/mem_sleep >>> s2idle [deep] >>> >>> What does this mean? It means that it detected only s2idle or that my >>> system does not support >>> suspend to RAM? I've used Ubuntu and Fedora and lid closing always worked, >>> I just don't know if >> it >>> was idle or to ram or other thing. >> >> This means that s2idle mode and deep mode are the two modes supported by >> your machine, and that >> deep is the mode that will be used for sleep when no specific mode is >> specified, such as using the >> lid switch or the logout menu or systemctl suspend for example. In OP's >> case, deep is manually set >> as default using the kernel parameter mem_sleep_default=deep. Generally the >> kernel chooses the >> deepest mode supported (s2idle -> shallow -> deep) to be the default, but on >> some machines the >> kernel will choose s2idle as the default even if deep is supported. >> >> https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-sy >> tem-suspend-and-hibernation > > Thanks! I now understand how it works. I've checked and indeed my system > defaults to deep. I tried > s2idle by doing echo freeze > /sys/power/state and the screen turns off but > they keyboard keeps > with lights on. Pressing buttons does nothing. Pressing touchpad, nothing. > Pressing power rapidly, > nothing. Had to reboot by long pressing power. Shouldn't s2idle always work > since it's software > based? I don't know much about s2idle, but yes, in theory it should be the most reliable of the sleep states. It could be a graphics driver issue. However, from your log it looks like it's still entering deep sleep. > I have no other ideas. If someone know a little more on how to debug, I'd be > glad. Remember that I > found this error in ACPI https://github.com/QubesOS/qubes-issues/issues/ > on dmesg. It indicates > that ASPM does not work. Maybe this is crucial? Debugging suspend is a long and complicated process. I don't want to get any more off-topic in this thread. Please start a new thread for your machine detailing everything you've tried so far, including logs and any other relevant information, so it's all in one place. -- You received this message because you are subscribed to the Google Groups "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/3a967cec86c0cf40795e6511e062e471%40disroot.org.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
January 7, 2020 6:08 PM, "Guerlan" wrote: > On Monday, January 6, 2020 at 12:43:40 AM UTC-3, Claudia wrote: > >> January 6, 2020 3:14 AM, dmoe...@gmail.com wrote:> On Sunday, January 5, >> 2020 at 9:49:42 PM UTC-5, >> Guerlan wrote: >>>> can you tell me how you figured this out? I've been trying to fix a >>>> suspend bug in mine and It'd >> be >>>> helpful to know how you debugged things >>> >>> Mostly trial and error, trying all the things listed above. Two little >>> tricks to use: >>> >>> 1. Look at the end of journalctl right before it tries to suspend. This is >>> where I saw that it >> was >>> going into s2idle, which then brought me to this thread: >>> >> https://groups.google.com/forum/#!msg/qubes-users/TmGDlkluJgM/1BFsQZWNDAAJ;context-place=forum/qubes >>> users This Dell did not have the lack of S3 that the new Thinkpads have, >>> but it did still try to >>> use s2idle. >> >> /sys/power/mem_sleep will list supported modes, with the default in >> brackets. You can echo to it to >> set the default at runtime, or use the boot parameter. > > [lz@dom0 ~]$ cat /sys/power/mem_sleep > s2idle [deep] > > What does this mean? It means that it detected only s2idle or that my system > does not support > suspend to RAM? I've used Ubuntu and Fedora and lid closing always worked, I > just don't know if it > was idle or to ram or other thing. This means that s2idle mode and deep mode are the two modes supported by your machine, and that deep is the mode that will be used for sleep when no specific mode is specified, such as using the lid switch or the logout menu or systemctl suspend for example. In OP's case, deep is manually set as default using the kernel parameter mem_sleep_default=deep. Generally the kernel chooses the deepest mode supported (s2idle -> shallow -> deep) to be the default, but on some machines the kernel will choose s2idle as the default even if deep is supported. https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation -- You received this message because you are subscribed to the Google Groups "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/edea108d519cb88e335f236b52b5f8c2%40disroot.org.
Re: [qubes-users] Default fedora-30 template asking for password that I don't have
January 7, 2020 5:07 AM, fiftyfourthparal...@gmail.com wrote: >> Also, try using `su` with no arguments and see if that asks for a password >> also. > > The problem was resolved by using the "su" command on its own (as opposed to > "su user", which > prompted me for a password), which brought me straight into "bash-5.0#", > where I used the "cat > > 00-macrandomizer.conf" command. > > Typing "sudo cat > test.txt" into the user (non-su) prompt returned "bash: > test.txt: Permission > denied". Glad you got it working. In case you're curious: I think that means that `cat` was running as root, but bash, and therefore the '>' operator, was still running as user. The '>' takes precedence over the command. You can think of it like this: ((sudo cat) > test.txt). >> Also, don't type your dom0 passwords or disk password into VMs. You may want >> to change them just > to be safe. > > My machine has never been connected to the internet when I typed in the > passwords (like, in the > lifetime of the machine), so I figured they'll be safe unless a verified iso > has been compromised, > but I'll do things the Qubes way and change them anyways. In theory, for example, fedora-30 could save the password somewhere in its root filesystem, which would be accessible later by a networked AppVM based on that template. It's very unlikely though. I was just covering all bases. -- You received this message because you are subscribed to the Google Groups "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/1c715fbd5b4a2509907b1733c713cad4%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 7, 2020 4:18 AM, "Chris Laprise" wrote: > On 1/6/20 4:11 PM, Claudia wrote: > >> January 6, 2020 8:20 PM, "Chris Laprise" wrote: >> On 1/5/20 11:30 PM, Claudia wrote: >>> >> >> I don't know much about PSP, or ME for that matter, but it seems to me >> you're mostly screwed either >> way, so I figured I might as well save some money while I'm at it. This was >> even before the recent >> Intel shit show. >>> Indeed. These management engines are ubiquitous, so I think we should >>> try to answer the question: Can they be properly deactivated? >>> >>> Given everything else, its possible the answer is 'no' for Intel (we >>> already know this) and 'yes' for AMD. >> >> Plus, I got a really good deal on this particular machine (so admittedly a >> bit of an impulse buy). >> And I have to say, despite a lot of troubleshooting and a few remaining >> glitches, it actually runs >> Qubes surprisingly well, all things considered. But... yeah, kids, don't try >> this at home. >>> I tend to shy away from 'consumer' models, bc they almost always >>> misconfigure advanced features like the IOMMU as the firmware isn't >>> carefully managed. Dell describes Inspiron models as "Home and Home Office". >> >> On top of that, though, IOMMU problems and ACPI bugs and such appear to be >> widespread in the Ryzen >> family, across different computer makes and models, including higher-end >> ones and motherboards. I >> think there are some links about it in some of my other threads. That's what >> makes me think Ryzen >> itself has some problems of its own, or at least certain generations or >> something. Bad firmware can >> break good hardware, but good firmware can't fix bad hardware. Other AMD >> product lines though like >> Threadripper for example don't seem to be any worse than Intel from what >> I've heard. But like I >> said, it's really not that bad, all things considered -- I now have fully >> working suspend/resume >> which is more than a lot of Qubes users can say. One correction I thought of: A lot of motherboards have three options for IOMMU: enabled, disabled, and auto (default). Changing it from auto to enabled sometimes makes the grouping more granular (but not always, and usually not by very much). A lot of consumer BIOSes, including mine, only has two modes: enabled and disabled, though I think my "enabled" is really just "auto". So that might be one aspect where firmware is to blame. It's hard to say, unless you can collect detailed information on a lot of different hardware. I'm just going by the vague and scattered reports that I've come across. > That's good to know. I just noticed your long HCL update thread for the AMD > Inspiron. Since I'm > behind with the HCL list and you put so much work into your report, I'll move > yours to the top of > my queue. It should get listed sometime this week. Thanks for the detailed > reporting! No rush. I still have a few changes to make to the report itself, including the fix for suspend. I'll go over it again and post an updated copy. Do you prefer updates be posted in a new thread or the same thread? Also, some things like USB Qube are still a work in progress... or at least I haven't totally given up yet. A recent finding makes me think it could be a PCI reset problem. But that stuff can be updated again later if/when I have a fix for 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/2e38f2aaf8bdf4e43cb235d5bfe059d3%40disroot.org.
Re: [qubes-users] Default fedora-30 template asking for password that I don't have
January 6, 2020 8:45 PM, "Chris Laprise" wrote: > On 1/6/20 3:22 PM, Claudia wrote: > > I think s/he is really using a "minimal" template here. That would cause > sudo to be disabled by default. On these minimal templates, you can only > gain root privs by using 'qvm-run -u root' in dom0 or by using that > qvm-run command to install the 'qubes-core-agent-passwordless-root' > package which adds the no-password sudo capability back. Oh, that's possible. >>> P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between >>> whonix/TAILS appVM and >>> whonix-15-gw netVM) increase security or just waste computational resources? >> >> This came up a while back. I'll try to find the thread for you. In short, I >> remember reading in the >> Tor documentation that anyone with access to your SOCKSPort can potentially >> learn information about >> what sites you're visiting. So in that case, yes, separate whonix gateways >> would be beneficial. On >> the other hand, the Whonix developers know more about this than I do, and >> I'm assuming they did >> everything right. I never got around to investigating though. You might have >> better luck asking on >> the Whonix forum or Tor stack exchange. > > I think you'll find different opinions about this. IMO, as with adding > extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw > already has 'low' attack surface and firewall capability, and they > typically filter which external gateways they do and don't talk to based > on crypto-enforced identification. Well, to me there's a difference between theoretical attack surfaces and stuff like that, versus official documentation telling you it's not safe to share SOCKSPorts. If that's the case, that is. It was a really long time ago and I don't remember what it said exactly. But yeah, I agree, I wouldn't necessarily go adding redundant VMs just out of paranoia. Personally I only run one whonix gateway even though I probably have enough ram to run a dozen. -- You received this message because you are subscribed to the Google Groups "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/14769721819d68b68ee1815ab4a1a10d%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 6, 2020 8:20 PM, "Chris Laprise" wrote: > On 1/5/20 11:30 PM, Claudia wrote: > >> I don't know much about PSP, or ME for that matter, but it seems to me >> you're mostly screwed either >> way, so I figured I might as well save some money while I'm at it. This was >> even before the recent >> Intel shit show. > > Indeed. These management engines are ubiquitous, so I think we should > try to answer the question: Can they be properly deactivated? > > Given everything else, its possible the answer is 'no' for Intel (we > already know this) and 'yes' for AMD. > >> Plus, I got a really good deal on this particular machine (so admittedly a >> bit of an impulse buy). >> And I have to say, despite a lot of troubleshooting and a few remaining >> glitches, it actually runs >> Qubes surprisingly well, all things considered. But... yeah, kids, don't try >> this at home. > > I tend to shy away from 'consumer' models, bc they almost always > misconfigure advanced features like the IOMMU as the firmware isn't > carefully managed. Dell describes Inspiron models as "Home and Home Office". On top of that, though, IOMMU problems and ACPI bugs and such appear to be widespread in the Ryzen family, across different computer makes and models, including higher-end ones and motherboards. I think there are some links about it in some of my other threads. That's what makes me think Ryzen itself has some problems of its own, or at least certain generations or something. Bad firmware can break good hardware, but good firmware can't fix bad hardware. Other AMD product lines though like Threadripper for example don't seem to be any worse than Intel from what I've heard. But like I said, it's really not that bad, all things considered -- I now have fully working suspend/resume which is more than a lot of Qubes users can say. -- You received this message because you are subscribed to the Google Groups "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/7b61a202c5a8f480ed8a0fb10c59c529%40disroot.org.
Re: [qubes-users] Default fedora-30 template asking for password that I don't have
January 6, 2020 5:02 AM, fiftyfourthparal...@gmail.com wrote: > Hello, Oops, I forgot to reply to this. Sorry. > I have a fresh installation of Qubes 4.0.2 on a Dell Inspiron 5593 with an > untouched fedora-30 > template. Aside from some minor hiccups during installation, no compatibility > issues have been > detected. (Note: I know more about tech than the layperson, but not enough to > call myself a > 'techie'). > > Following the instructions on the Qubes guide to randomizing my MAC address, > I cloned the template > and attempted to modify it for my netVMs. When creating the > '00-macrandomizer.conf' file in the > '/etc/NetworkManager/conf.d' folder, I was told that I don't have permission > to do so. This struck > me as odd, since I recently read Joanna's message in the sudoers' folder > about passwordless root. I > tried every password that I've set on the machine (including the root > password set during > installation), but nothing works. > > Anyone have any idea what's going on? In case it's relevant, the command line > starts with "user". If running as user, you'll get "Permission denied" but it won't ask for a password as far as I know. You need to put sudo in front of the command. This is when it would normally ask you for a password, but it *should* just work without asking for a password. Also, try using `su` with no arguments and see if that asks for a password also. Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just to be safe. Run `sudo -l`, you should see User user may run the following commands on fedora-30: (ALL) NOPASSWD: ALL (root) NOPASSWD: /bin/udevadm trigger --action\=add --sysname-match\=event[0-9] When you're prompted for the password, check /var/log/xen/console/gues-fedora-30.log (on dom0) for any problems. You should see an audit line about the su or sudo command. Normally it should say "res=success" towards the end. > P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between > whonix/TAILS appVM and > whonix-15-gw netVM) increase security or just waste computational resources? This came up a while back. I'll try to find the thread for you. In short, I remember reading in the Tor documentation that anyone with access to your SOCKSPort can potentially learn information about what sites you're visiting. So in that case, yes, separate whonix gateways would be beneficial. On the other hand, the Whonix developers know more about this than I do, and I'm assuming they did everything right. I never got around to investigating though. You might have better luck asking on the Whonix forum or Tor stack exchange. -- You received this message because you are subscribed to the Google Groups "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/de8a36d828a4d7af38bc4f9b1525c345%40disroot.org.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 30, 2019 7:12 PM, "qubes123" wrote:
>> The improper grouping is probably somewhere in AGESA, which is provided
>
>>> to the manufacturers by AMD. It could be because of hardware related
>>> limitations, which again are supplied by AMD. Sometimes vendors take
>>> liberties (cost cutting measures) with both and break functionality, as
>>> their primary/sole concern is that Windows boots. This can especially be
>>> the case with consumer class machines such as Ryzen. Agree it would be
>>> nice if Xen handled this failure mode more gracefully. Not sure there is
>>> much Qubes can do here, though. On the other hand, my older AMD
>>> (pre-Ryzen) consumer laptop running Coreboot has correct groupings.
>
> I could be wrong, but aren't these PCI assignments and hierarchies coded
> within the ACPI DSDT table
> in BIOS?
I guess in some cases they are, and in other cases they're in hardware. For
example if you have two devices between a physical PCI bridge, communication
between those two devices might be sent across the bridge without ever making
it to the IOMMU. I don't think there's any software approach could do anything
about that kind of situation.
In my case, the USB controllers and most of the other devices are functions of
the same PCI device, 00:03.0{1,2,3,4,6}. Therefore most likely any
communication between them is happening within the device and not going to the
IOMMU (00:00.2). However I don't know if this is because of the physical
structure, or if it could be changed by modifying ACPI tables. I guess the only
way to know would be to try it.
> I remember as if in UEFI the ACPI tables could be overridden somehow...
>
> Or - since kernel 5.3.x(?) you can supply certain ACPI tables (as files,
> stored in initrd) to the
> kernel using commandline parameters* (some additional acpi manipulations are
> needed to extract the
> current dsdt to see what is in there and make changes in aml...)
I understand the part about uploading the ACPI tables via initrd, but I would
have no idea how to extract them, what they mean, or what changes to make to
them.
Also, I haven't figured out if ACPI override actually changes the behavior of
PCI devices, or if it just spoofs the information provided to the
kernel/hypervisor (which would make it unnecessary/ineffective on Xen).
According to the OSDev wiki: "AML interpreter can build up a database of all
devices within a system and the properties and functions they support (in
reference to configuration and power management)."
> Or - before all - you can simply try to boot the kernel with cmdline:
> acpi=nocrs (or off) and let
> the kernel "enroll" the PCI devices. Maybe worth to try - just one reboot...
I did some tests by playing sound in a VM and then binding pciback to the USB
controllers to simulate passthru. None of them were successful. At the time of
the bind command, audio stopped, and the screen would freeze unless nomodeset
was on. I did the testing in the 4.1 pre-release.
I tested four combinations of parameters: (none), acpi=off, acpi=nocrs, and
acpi=nocrs pci=nocrs, each with and without Xen. In the non-Xen tests,
iommu_groups was the same every time. In the Xen tests, xl dmesg and xl info
were identical every time. In all tests, lspci and lspci -t were identical.
Kernel logs and lspci -kvvnn had some differences each time, but nothing that
looked important. If I should look for anything specific please let me know.
Note, the data was collected right after I logged in, before I performed the
passthru. Not one of my better decisions.
However the only thing I recall seeing in the logs at the time of the passthru
was this, with acpi=nocrs pci=nocrs:
xhci_hcd :03:00.4: Host halt failed, -110
xhci_hcd :03:00.4: Host controller not halted, aborting reset.
xhci_hcd :03:00.4: USB bus 3 deregistered
pciback :03:00.3: seizing device
xen: registering gsi 55 triggering 0 polarity 1
Already setup the GSI :55
pciback :03:00.4: seizing device
xen: registering gsi 52 triggering 0 polarity 1
Already setup the GSI :52
Could it be a PCI reset related problem?
Finally, a possible workaround I thought of is putting sys-usb into PV mode,
since PV passthru doesn't use the IOMMU. It wouldn't be quite as secure as HVM,
as it wouldn't prevent a DMA attack, but it would still be better than having
USB in dom0. However it looks like Qubes 4.1 isn't going to support any kind of
passthru for PVs, so I'll ultimately end up back where I started. I don't
currently have sys-usb installed, but I might try it when I have some 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 view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/b88a85b62f2e84c57ec5fbf87f14b9ec%40disroot.org.
Re: [qubes-users] Re: Perplexed, why do so many here seem to prefer Fedora instead of ?
January 6, 2020 2:20 PM, "gorked" wrote: > To Morph this post a bit, being a lot of intrusions are now coming in with > the Web Browser, which > Web Browser is now the recommended one for Security? I have been using > Firefox, with a lot of > Addons, but I had to turn off the Java Script to buy items online. I would definitely not say Firefox is the most secure (though it is among the best for privacy). But the good news is that, that doesn't really matter in Qubes. Qubes always assumes the browser is compromised. As long as you use Qubes correctly (use different VMs for different tasks/identities, use DispVMs where possible, etc), you can mostly rely on the hypervisor instead of the browser for security. For example, use a different VM for buying things online with JS enabled, than for your regular browsing. Arguably there should be security/hardening at all levels and not just the hypervisor, but the Qubes core principle is security by isolation. > Is there a movement to create a standard about what a Web Page should never > be allowed to do, to > facilitate security on the internet? Not sure what you mean. In terms of JS functions and permissions and things like that? The w3c is who decides the standards for what web pages should be allowed to do and access, and even that is not totally standard: ultimately each browser, and each user, makes their own decisions. I don't think there will ever be a universal list of rules that suits all users and all websites. This is more a matter of privacy than security. I.e. no rules or standards are going to prevent a heap overflow vulnerability or something like that. > Surveillance Capitalism now rules. -- You received this message because you are subscribed to the Google Groups "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/b37fd87705416e6d4b1864b283f3e45b%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 6, 2020 5:16 AM, fiftyfourthparal...@gmail.com wrote: >> What can I say, I like doing things the hard way. > > Some might say it's good for character building--like climbing Everest with > minimal assistance when > you can instead just hire a bunch of Sherpas to carry you. > >> I don't know much about PSP, or ME for that matter, but it seems to me >> you're mostly screwed either >> way, so I figured I might as well save some money while I'm at it. > > Well, if the motivation is money then I think the amount of time someone with > your level of > knowledge has put into fixing the machine has gone way past $200 by now. I > think you're in it for > the journey. Looking at it that way, you have a good point. I'm certainly no expert though. I've only been using Qubes about three years, and only tinkering with it less than a year at most. I've learned a *lot* in the last six months, and I still haven't even scratched the surface. I wouldn't have been able to do it without the help from the mailing list. > I was going to say "why not an ARM computer" when I realised that a) there > isn't a single non-Intel > or AMD PC on the HCL, and b) ARM computers are hard to come by. Non-Intel/AMD x86 machines suitable for Qubes are probably just as hard to come by, I would imagine. But besides the issue of trust/transparency with regards to AMD and Intel, I think much of the problem is also rooted in the design and cruft of the x86 architecture itself (read Joanna's "x86 Considered Harmful"). There has been some talk about porting Qubes to other architectures like ARM and POWER9, both historically and recently, but I haven't been following it at all and I don't know how realistic any of it is. For example: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31704.html I seem to remember an FSF-approved ARM laptop made by some Chinese company with a funny name a long time ago that ran Debian or something. But yeah, I don't think ARM desktop/laptop computers are going to catch on any time soon. And from what I understand porting to ARM is a little more complicated due to lack of ACPI and all that stuff. Even if there were ARM options, I don't know if the Qubes development community could really handle 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/141ae179fd5994e307e8150be547157c%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 6, 2020 3:52 AM, fiftyfourthparal...@gmail.com wrote: >> Inspiron 5575, AMD 2500U > > A newly-released machine with an AMD CPU and GPU? Are you a masochist or > someone who's looking to > perform feats of strength? (Like climbing Everest). Or is Intel really that > unpalatable for you? > From what I've read, AMD's PSP is much more opaque and questionable compared > to Intel's ME. Is this > true? Now you understand why it's taken me this long! What can I say, I like doing things the hard way. I went with it mainly for cost reasons. The 2500U is roughly equivalent to the i5-8250U performance-wise but seems to run about $200 cheaper. And at the time I thought Qubes compatibility was about the same for AMD and Intel, which may be true for most product lines but not for Ryzen apparently. I don't know much about PSP, or ME for that matter, but it seems to me you're mostly screwed either way, so I figured I might as well save some money while I'm at it. This was even before the recent Intel shit show. Plus, I got a really good deal on this particular machine (so admittedly a bit of an impulse buy). And I have to say, despite a lot of troubleshooting and a few remaining glitches, it actually runs Qubes surprisingly well, all things considered. But... yeah, kids, don't try this at home. -- You received this message because you are subscribed to the Google Groups "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/2525db23536f8634762989746ae6caee%40disroot.org.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
January 6, 2020 3:14 AM, dmoer...@gmail.com wrote: > On Sunday, January 5, 2020 at 9:49:42 PM UTC-5, Guerlan wrote: >> can you tell me how you figured this out? I've been trying to fix a suspend >> bug in mine and It'd be >> helpful to know how you debugged things > > Mostly trial and error, trying all the things listed above. Two little tricks > to use: > > 1. Look at the end of journalctl right before it tries to suspend. This is > where I saw that it was > going into s2idle, which then brought me to this thread: > https://groups.google.com/forum/#!msg/qubes-users/TmGDlkluJgM/1BFsQZWNDAAJ;context-place=forum/qubes > users This Dell did not have the lack of S3 that the new Thinkpads have, but > it did still try to > use s2idle. /sys/power/mem_sleep will list supported modes, with the default in brackets. You can echo to it to set the default at runtime, or use the boot parameter. -- You received this message because you are subscribed to the Google Groups "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/c90b972acea666dd9454ad277bb3%40disroot.org.
Re: [qubes-users] Feature request
January 5, 2020 7:50 PM, "Franz" <169...@gmail.com> wrote: > May be it already somehow exists and I am not aware of it, but it would be > very interesting to be > able to save backup settings, that is a list of VMs that contain your current > ordinary activity and > you want to backup more often and fast. > > I mean not everything which in my case is over 250gb, not only vaultVM, which > is easy to set, but > lacking other important VMs. > > Rather being able to save a list of perhaps 5-7 more important VMs so that > they are ready for a > fast backup. > > I know there is a CLI that does just that and once even wrote a script for > that, but I am never > sure it still works as intended over so many Qubes upgrades and after every > new Qubes installation > all my scripts are moved from home to elsewhere for some reasons that do not > understand yet. > > So backup is important and any incentive to win backup lazyness is worth > every effort, particularly > because automating Qubes backups is impossible or extremely difficult. > > Is it complicated to add this "save backup setting" to the GUI? > Best Isn't that sort of what "Qube Settings > Basic > Include in backups by default" does? -- You received this message because you are subscribed to the Google Groups "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/08ab9bda08ab38dc0a70263986dcafaf%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 5, 2020 12:30 PM, fiftyfourthparal...@gmail.com wrote: >> My HCL report for this machine is now almost six months in the making, all >> told. > > If an HCL report is taking someone with your level of knowledge six months to > compile, then it's > probably incredibly discouraging for many, if not most, would-be > contributors. I know I'm > discouraged, despite the fact that my new Inspiron 5593 (Ice Lake) is almost > unbelievably > compatible with Qubes once some minor obstacles during installation have been > overcome based on > what I've experienced so far. > > Is there a simplified HCL report process for someone that's not as > technically inclined as someone > like you are? It's not the HCL report that takes that long. When I first installed Qubes I had my initial HCL report done in a couple of minutes. It's all the troubleshooting, much of which is optional depending on your needs. I've been continuing to update my report as I fix things, which is why it's taking so long. Like you said, there's a lot of luck to it. I had pretty bad luck initially, although I've been able to fix a lot of the problems with time. In your case, for example, you may find that pretty much everything just works, and you can have a fairly complete report done in no time. And if something doesn't work, you can just put down "doesn't work," you don't have to fix it unless you need to or want to. Of course, the more thoroughly you test the machine, the more time it will take. For example things like setting up AEM, flashing Coreboot, setting up LUKS to work with a USB keyboard, can be non-trivial even if you're successful on the first try. Even little things can add up: UEFI mode, secure boot, firmware updates, wifi, audio, bluetooth, touchscreen, keyboard backlight, HDMI video and audio, DisplayPort, USB passthru, USB 3.0 support, wired networking, SD card slot, screen power management, webcam and microphone, headphone jack, lid switch, multimedia keys, accelerated graphics, WWAN etc. Like I said, if you suspend/resume with a youtube video playing, you've already tested all the most commonly used features. Also you don't have to test everything at once. You can always update your report later. On top of that, keep in mind everything is subject to change with every update you install. My advice is don't worry too much, and don't let yourself get discouraged. Do what you can, and when you've had enough, just submit what you have so far and come back to it later. -- You received this message because you are subscribed to the Google Groups "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/ebaff9812b90860bf0454f2d3d921b40%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 5, 2020 3:14 AM, fiftyfourthparal...@gmail.com wrote: >> However there's probably no way to fully automate it. > > As someone somewhat knowledgeable about tech, but without deep knowledge, > this is annoying but > manageable. Should someone write a "First Boot Checklist" for the wiki, if > only to increase the > accessibility of Qubes? It would be helpful, sure. I'd also even be interested in outputs like lspci, lsusb, dmesg, alsa-info.sh, /proc/cpuinfo, iommu_groups, xl demsg, pm_trace, and so on for different machines. But then again, most people are just going to test what they actually need and leave it at that. Probably only a small minority of Qubes users even submit an HCL report, and even a smaller fraction of them troubleshoot issues and update their reports. Fact is, testing and troubleshooting can take a lot of time, effort, expertise, and sometimes additional hardware. My HCL report for this machine is now almost six months in the making, all told. The HCL doc mentions some of the basics like video, networking, and sleep. Also the remarks column of the HCL page is a great place to look for ideas. However, I'd say if you can suspend and resume in the middle of a youtube video without any noticeable problems, you've already hit all the features for 90% of use cases. And keep in mind you can always add to your report later. -- You received this message because you are subscribed to the Google Groups "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/607af9d86add9e1eabd0d6cafc91b3a6%40disroot.org.
Re: [qubes-users] Does the latest Linux kernel improve security for qubes?
January 4, 2020 5:19 PM, dhorf-hfref.4a288...@hashmail.org wrote: > On Sat, Jan 04, 2020 at 09:01:35AM -0800, fiftyfourthparal...@gmail.com > wrote: >> Also, is there a quick diagnostic tool to check if a new installation on a >> new laptop have all functions working? (like sound, SLAT, TPM, etc.) qubes-hcl-report checks for the basics, like SLAT, TPM, VT-x, VT-d. Beyond that... I sort of wondered about that too. However there's probably no way to fully automate it. E.g., most hardware can't resume itself from suspend, the user has to press a key. Same goes for things like external USB device detection, HDMI ports, ethernet ports, and so on - you have to physically connect it. And e.g. the code wouldn't know if audio is actually coming out of the speakers, even if it's writing to the sound card (see below for a real world example). Same goes for things like the screen brightness, framebuffer corruption, and so on. So at best, a diagnostic tool could only guide the user through the process, which would still be helpful but I don't know of any such tool, other than what qubes-hcl-report does. https://www.qubes-os.org/doc/hcl/ > "sound" and "tpm" are simply a question of "is this supported by linux", > nothing qubes-specific about it. Well, for the most part, but there are some edge cases. For example in several versions of Qubes/Xen my sound card would show up, no errors, but would not play any sound other than some slight static. When I booted Qubes without Xen, sound worked fine. It turned out it was because the USB controllers are IOMMU-grouped with the sound card, so passing one without the other causes undefined behavior. I had to disable sys-usb and remove rd.qubes.hide_all_usb. Actually I just realized I never followed up on that thread with the actual solution. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31105.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f83cd216f34f4204d77fcf7856148b4d%40disroot.org.
Re: [qubes-users] Problem during installation of Qubes 4.0.2
January 4, 2020 12:28 PM, "Fabian" wrote: > Hello, > > I recently bought new hardware and tried to install Qubes on it, sadly > without any success at all. > > I tried it with UEFI only and with CSM (Compatibility Support Module) only, > but neither had worked. > > The media I used is the recent Qubes 4.0.2 ISO, I had the same issues 2 weeks > ago with the Qubes > 4.0.2 RC3 image. > > I copied it to the USB Stick with Rufus (In both MBR/CSM Mode and GPT/UEFI > Mode) as well as just > copying it over to the USB drive and then extract it. > > First of all, the Hardware: > > CPU: AMD Ryzen 9 3950X > > GPU: AMD Radeon RX 5700XT > > Mainboard: ASUS TUF Gaming X570-Plus WiFi > > I made the mainboard decision because of the price and the good VRMs on the > board - most other > "cheap" x570 mainboards are having big problems with VRM temperatures. > > Other parts shouldn't play a significant role here, because I didn't come far > enough. > > UEFI Problem: > When I boot the USB Stick in UEFI Mode, the screen simply stays blank after a > couple lines of > output appeared on the screen. > I then tried what's written on the "UEFI Troubleshooting" site: > https://www.qubes-os.org/doc/uefi-troubleshooting > The output which appears then is visible in the attachment "UEFI.jpg". I also > saved the logfile, > the last lines are the following: > >> [ 9.681987] localhost kernel: usb 3-3.3: New USB device strings: Mfr=1, >> Product=2, SerialNumber=0 >> [ 9.682372] localhost kernel: usb 3-3.3: Product: USB2.0 Hub >> [ 9.682754] localhost kernel: usb 3-3.3: Manufacturer: VIA Labs, Inc. >> [ 9.724854] localhost kernel: hub 3-3.3:1.0: USB hub found >> [ 9.725585] localhost kernel: hub 3-3.3:1.0: 4 ports detected >> [ 9.792658] localhost kernel: usb 3-6: new full-speed USB device number 6 >> using xhci_hcd >> [ 9.933606] localhost kernel: usb 3-6: config 1 has an invalid interface >> number: 2 but max is 1 >> [ 9.933988] localhost kernel: usb 3-6: config 1 has no interface number 1 >> [ 9.945601] localhost kernel: usb 3-6: New USB device found, idVendor=0b05, >> idProduct=18f3, >> bcdDevice= 1.00 >> [ 9.945983] localhost kernel: usb 3-6: New USB device strings: Mfr=1, >> Product=2, SerialNumber=3 >> [ 9.946358] localhost kernel: usb 3-6: Product: AURA LED Controller >> [ 9.946732] localhost kernel: usb 3-6: Manufacturer: AsusTek Computer Inc. >> [ 9.947100] localhost kernel: usb 3-6: SerialNumber: 9876543210 >> [ 9.965764] localhost kernel: hid-generic 0003:0B05:18F3.0006: >> hiddev97,hidraw5: USB HID v1.11 >> Device [AsusTek Computer Inc. AURA LED Controller] on >> usb-:07:00.3-6/input2 >> [ 134.331670] localhost dracut-initqueue[703]: Warning: dracut-initqueue >> timeout - starting timeout >> scripts >> [ 134.861553] localhost dracut-initqueue[703]: Warning: dracut-initqueue >> timeout - starting timeout >> scripts >> [ 135.382539] localhost dracut-initqueue[703]: Warning: dracut-initqueue >> timeout - starting timeout >> scripts > > I saved the full Logfile of course, but I prefer to not poste it completely > public on this list. So > if any developer wants it for further inspection, please just let me know, I > mail it to you then. > This all happened before I was able to see the menu (Test this media and > Boot, Boot, > Troubleshooting). > > Then I tried the CSM option in the BIOS. I was at least able to pick an > option in the boot menu > (Test this media and Boot, Boot, Troubleshooting), which then quickly ended > in the screenshot > "CSM.jpg" in normal boot and also in basic graphics mode form Troubleshooting. > The attachments "CSM_anaconda.log" and "CSM_X.log" are from the installation > in CSM Mode. > > Any ideas what the problem could be, and/or how to fix it? > The hardware is pretty new (GPU released in August 2019, CPU in December > 2019, most mainboards with > X570 Chipset in July 2019. So I suspect it's a driver issue. > Also a hint from me: I tried to install Debian and Fedora as well, neither > has worked. Seems like > only Windows runs on it for now. > I somehow expected that already, but maybe my logs help to identify the > problem so this hardware > gets usable sooner for others as well. Hmm, if you couldn't get the latest Fedora or Debian to run on it, there's probably not much hope for Qubes any time soon. But here are some ideas anyway. Especially on newer hardware, UEFI mode is strongly recommended if you can get it to work, although there's no guarantee. If you want to try the UEFI route: Try setting rd.debug in the kernel command line, and note the last few lines. This should show you the exact shell command that is timing out. See also: https://fedoraproject.org/wiki/How_to_debug_Dracut_problems#Summary_of_dracut_kernel_command_line_options Otherwise... Try the "nomodeset" kernel parameter which can often fix X problems. It's worked for me many times. If it works, after installing and updating you can work on getting the graphics driver
Re: [qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"
January 4, 2020 9:35 AM, "awokd' via qubes-users" wrote: > Claudia: > >> I'm getting this message in my logs, about an IOMMU error, on both 4.0.2 and >> the F31-based 4.1 >> build. I'm as certain as I can be that the IOMMU is enabled in BIOS. I'm >> having issues with >> passthru and I'm wondering if this might be the cause. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1404139 >> This thread says it's not a bug, it's just because the system doesn't >> support IOMMUv2 and amdkfd >> (whatever that is) requires IOMMUv2 (whatever that is) for HSA (whatever >> that is). I don't really >> know what any of that means. >> >> Or does it just mean that my GPU is not protected by the IOMMU (same as >> iommu=no-igfx on Intel) and >> I don't have to worry about it? > > I saw in a different thread you made progress, so this is probably > outdated. However, I think your conclusions are correct. If your IOMMU > was not working correctly, you would have problems starting HVMs period. > I made progress on a couple of things, but not USB Qube. I was just wondering if might have something to do with USB controller passthru. However it may be that USB Qube is simply not supported on this system due to IOMMU grouping. Other passthru HVMs such as sys-net work fine, though, so I guess that means the IOMMU is working despite the error. > The Xen logs look similar to mine. I don't have kfd on my system. >From what I saw, I think kfd is an AMD thing. Do you have AMD? -- You received this message because you are subscribed to the Google Groups "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/2d227faa21653704c60f57d5032e684a%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 3, 2020 5:53 PM, "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. And... SUCCESS 2.0! Perhaps it's still too early to celebrate, but after six months of troubleshooting I think I might finally have working suspend/resume. I did some googling around, and eventually came across a rather inconspicuous post[1] from 2013 in the Xen archives that mentioned something I hadn't tried or heard about before. All I had to do was add to the Xen command line "dom0_max_vcpus=1 dom0_vcpus_pin". And that's it. Couldn't have been simpler. I should not have had to go to the 20th page of search results to find out about this. This runs dom0 on CPU0 and only CPU0. My understanding is that it has to be running on the boot CPU at the exact moment of suspend and resume. Or something like that. Not sure of the specifics. Note that this may have a performance impact depending on your situation. At first, I thought maybe this would render the Xen patch unnecessary: e.g. that it was suspending on one core and resuming on another causing an apparent change in cpuid bits. But I can see from the log the cpuid capability bits are still changing as before. (Those of you just tuning in, the patch and instructions are earlier in this thread. However you probably won't need it unless you have an AMD Fam15h processor. Note that there may be security implications associated with this patch.) I've only had a chance to test about 15-20 cycles or so, but it works great so far. Suspends fast, resumes fast, lid-switch triggers both suspend and resume, WiFi automatically reconnects. I suspended in the middle of a YouTube video and came back up seamlessly. However after resume all instances of Firefox seem to jump to 100% CPU (but not frozen) until I close it, but that appears to be a known issue outside of Qubes and Xen also. Tested on R4.0 stable with kernel-latest 5.3.11-1.qubes.x86 on Xen 4.8.5-14.fc25 (patched). I haven't tried this yet on the default kernel but I think it would probably work just as well. It also very well might work on other Qubes/Xen versions. I'll update my HCL accordingly when I have a chance. [1] https://lists.gt.net/xen/devel/270965#270965 -- You received this message because you are subscribed to the Google Groups "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/87602866f77e6fa8866448a22b48b4a1%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
January 3, 2020 7:17 PM, brendan.h...@gmail.com wrote: > On Friday, January 3, 2020 at 12:53:31 PM UTC-5, Claudia wrote: >> January 1, 2020 5:09 PM, "Claudia" wrote: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. > > Maybe not directly helpful, but I've been looking to be able to better debug > Xen issues, so > reposting this from https://github.com/QubesOS/qubes-issues/issues/5529 > ... > Since it appears the old made-for-purpose USB 2.0 EHCI Debug port dongles are > impossible to find > these days, I've been looking around for alternatives and stumbled upon use > of the raspberry pi > zero w/ USB Gadget drivers to log chromebook coreboot debug data. Pretty sure > (but not 100%) the > same could be done for Xen debug data: > > https://johnlewis.ie/pi-zero-w-flashrom-and-usb-gadget-debug/ > https://johnlewis.ie/wp-content/uploads/2017/04/ehcidebug.gif > raspberrypi/linux#1907 > https://gist.github.com/gbaman/50b6cca61dd1c3f88f41 > > So...now I have a pi zero on the way. Funny you should mention that. I happened to have a Pi Zero W lying around, and I almost did go that route. However when I started looking into USB 2.0 EHCI debug (thanks to user Qubes123 for the tip), it looked pretty complicated and somewhat unreliable, so I decided to try some simpler techniques first. Also my USB controllers don't list the debug capability so I don't think it would work on this machine. Luckily Qubes123's patch worked, or at least fixed the Xen panic, so I don't think I have a need for USB debugging at the moment. However it is something I'd like to learn more about in case I need it in the future. Please let me know how you make out! Also something you might be interested in is USB 3.0 XHCI Debug Capability, or DbC, which is built into the USB 3.0 spec. It's a host-to-host protocol so it doesn't require any OTG/gadget hardware, just two devices that support USB 3.0 Enhanced Superspeed, a USB 3.0 Enhanced Superspeed cable, and the target device (USB controller) must support XHCI Debug Capability (DbC). https://www.kernel.org/doc/html/v4.17/driver-api/usb/usb3-debug-port.html The machine I was trying to debug does have a USB 3.1 controller, but it doesn't list the either the XHCI nor EHCI debug capability, even when USB debug is enabled in firmware. Just because there's a setting for it in firmware doesn't necessarily mean the hardware supports it, I suppose. -- You received this message because you are subscribed to the Google Groups "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/de518a5fbdcafb8e65c8e64fa6cc768c%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
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 the Google Groups "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/8b5cad4abcdce9da863ab033c86752d7%40disroot.org.
Re: [qubes-users] Recommended laptop?
December 31, 2019 1:02 PM, "eira wahlin" wrote: > I use qubes on an AMD system (thinkpad with Ryzen 5 pro 2500u). While I'm > happy with it, I've had > to make some sacrifices. AMD systems are tricky with hardware forwarding, so > I cannot (at the > moment) use a sys-USB. There is an inherent security problem there. > > Also, I've had to make my own versions of the (horribly elitistic and > class-hatingly named) AEM > system. I use my machine's TPM2 to verify that my BIOS hasn't been infected, > but that was difficult > as hell to set up. AEM relies on Intel's TPM module, and doesn't work with > AMD machines. > > So while most of it all works, it's been tricky to set up, and it's not all > functional yet. > > <3 > /panina Hi again, processor buddy. I have the Ryzen 5 (non-Pro) 2500U. I've also had a lot of problems with it. The IOMMU grouping is terrible, the kernel has a lot of problems with the firmware and ACPI, it doesn't support USB Qube, and so on. I haven't dared to even try AEM on this machine. But considering the performance for the money, I guess I really can't complain. I recently got suspend/resume half working. Turns out, some or all of the Fam15h processors including the 2500U change their cpuid feature bits when resuming from suspend, which causes a Xen panic. This means the fans come back on, but the screen doesn't power back on and it can't save any logs, so it's really hard to diagnose. You can patch Xen to disable the feature check. If you don't mind patching Xen, it's very likely that this will fix it for you (although you may run into other post-resume problems). And it's really not as difficult as it sounds. This link contains a patch and instructions for building it. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31697.html -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7cb86fb029b7e582b13e5cf32013d7c4%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 30, 2019 6:44 PM, "qubes123" wrote:
> Answering to your earlier question, my CPU capability information bits change
> like this after
> suspend:
>
> (XEN) Entering ACPI S3 state.
> (XEN) AMD-Vi: Applying erratum 746 workaround for IOMMU at :00:00.2
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) CPU0: cap[ 1] is 3e98320b (expected b698320b)
> (XEN) Missing previously available feature(s).
> (XEN) Enabling non-boot CPUs ...
>
> Without the patch this result in xen panic.
>
>> I decided to give this a try, but I don't really know how to use the build
>> system. I did `make
>> vmm-xen`, modified the file
>> chroot-dom0-fc29/home/user/rpmbuild/BUILD/xen-4.12.1/xen/arch/x86/acpi/power.c,
>> but it appears
>> after running `make vmm-xen` again my changes have been reverted. After it
>> finishes the line is no
>> longer commented out. Do I have to commit the change, or generate a patch
>> file, or something like
>> that?
>
> After you configure the qubes builder (easiest done with ./setup) and
> download all the sources
> (including the qubes-vmm-xen extra sources), you have to put the patch file
> in the
> qubes-src/vmm-xen directory.
>
> Then, include this patch in xen.spec.in file (somewhere below the last patch
> line eg. as Patch
> 1202: xxx --> filename is relative to the vmm-xen directory).
> Then, change the release (rel file) number to avoid mixing the "official" and
> your custom versions.
> Then run: make wmm-xen, and the new rpms will be available in the pkgs folder.
> You can check the logs meanwhile xen compiles if your patch was applied
> sucessfuly or not.
> Then, install all the rpms (7), that are currently installed in dom0 (eg. the
> devel and the debug
> files etc. are not needed.
>
> PS: my patch looks like this (it will show the CPUID capability bits changing
> in the hypervisor
> log)
>
> diff -ruN a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> --- a/xen/arch/x86/acpi/power.c 2019-12-15 18:26:11.18300 +0100
> +++ b/xen/arch/x86/acpi/power.c 2019-12-15 18:23:15.43900 +0100
> @@ -257,7 +257,7 @@
> microcode_resume_cpu(0);
>
> if ( !recheck_cpu_features(0) )
> - panic("Missing previously available feature(s).");
> + printk(XENLOG_ERR "Missing previously available feature(s).\n");
>
> /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
> ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
Thanks for the patch and the instructions. The qubes-builder documentation is
outdated and sorely
lacking (it doesn't even mention ./setup!). I applied the patch for marek's 4.1
repo but I couldn't
get to produce an fc31 package. It kept building for fc29 which I don't
currently have installed.
Then I built it for fc25 4.0 stable, but the patch wouldn't apply cleanly so I
just modified the
existing patch-x86-check-feature-flags-after-resume.patch to print an error
instead of panic, and
changed the message slightly.
patch-x86-check-feature-flags-after-resume.patch
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 3d26d4be31..e8fb3f6f31 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -255,6 +255,9 @@ static int enter_state(u32 state)
microcode_resume_cpu(0);
+ if ( !recheck_cpu_features(0) )
+ printk(XENLOG_ERR "Missing previously available feature(s). Ignoring.\n");
+
/* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
spec_ctrl_exit_idle(ci);
Installed the seven packages already present in dom0. In case anyone is
wondering those are:
xen-libs-4.8.5-14custom.fc25.x86_64.rpm
xen-4.8.5-14custom.fc25.x86_64.rpm
xen-hypervisor-4.8.5-14custom.fc25.x86_64.rpm
xen-runtime-4.8.5-14custom.fc25.x86_64.rpm
python3-xen-4.8.5-14custom.fc25.x86_64.rpm
xen-licenses-4.8.5-14custom.fc25.x86_64.rpm
xen-hvm-4.8.5-14custom.fc25.x86_64.rpm
Note that 4.8.5-14 -> 4.8.5-14custom shows up as a downgrade.
Ran `strings -a /boot/efi/EFI/qubes/xen.efi | grep Ignoring` to check for my
unique message, just to be sure.
Rebooted. Checked xl info. Looks good. (Yes, it actually truncated the last
character of the
version, apparently. Odd.)
xen_major : 4
xen_minor : 8
xen_extra : .5-14custom.fc2
xen_version : 4.8.5-14custom.fc2
cc_compile_date : Wed Jan 1 01:11:51 UTC 2020
Hit suspend from the XFCE menu. Waited 30 seconds or so. Crossed my fingers and
resumed.
And... SUCCESS!
xl dmesg
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S3 state.
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b)
(XEN) Missing previously available feature(s). Ignoring.
(XEN) Enabling non-boot CPUs ...
Thank you for your help! It appears your machine is not a special case. Exact
same result for both of us. Bit 27 flips on and bit 31 flips off (xor of
0x8800). No idea what those mean, though.
However, I still have a long road ahead of me. I did several
[qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"
I'm getting this message in my logs, about an IOMMU error, on both 4.0.2 and the F31-based 4.1 build. I'm as certain as I can be that the IOMMU is enabled in BIOS. I'm having issues with passthru and I'm wondering if this might be the cause. In dom0 kernel logs: AMD IOMMUv2 driver by Joerg Roedel https://community.amd.com/thread/170292 This thread recommends creating /etc/udev/rules.d/kfd.rules with MODE="0666". Qubes 4.1 has file /usr/lib/udev/rules.d/50-udev-default.rules which contains: SUBSYSTEM=="kfd", GROUP="render", MODE="0666" although 4.0.2 appears to have no such file. However I get the same error even on 4.1 so I don't think that's the fix. https://unix.stackexchange.com/questions/263901/kfd-error-getting-iommu-info This thread says add kernel parameter "iommu=pt" but I don't know if that's effective or safe in Qubes, because Xen handles the IOMMU instead of the kernel I think. I'm not really sure what that parameter does. https://bugzilla.redhat.com/show_bug.cgi?id=1404139 This thread says it's not a bug, it's just because the system doesn't support IOMMUv2 and amdkfd (whatever that is) requires IOMMUv2 (whatever that is) for HSA (whatever that is). I don't really know what any of that means. Is it an error? Should I be worried? Could it be causing my passthru problems? Or does it just mean that my GPU is not protected by the IOMMU (same as iommu=no-igfx on Intel) and I don't have to worry about 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/22518f58b4489a980ec75ccce0e7d71b%40disroot.org.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 29, 2019 2:19 PM, "awokd' via qubes-users" wrote: > Claudia: > >> December 26, 2019 12:59 PM, "awokd' via qubes-users" >> wrote: >> >>> Claudia: >>> >>> TLDR; check bottom of https://community.amd.com/thread/241650, looks >>> like there was a recently released related updated. Not sure if >>> applicable to your situation. >> >> Thanks for the link! I'm not sure if it affects me or not. I did install a >> Dell BIOS update dated >> March 2019, so it sounds like that could have contained this Agesa update. >> So downgrading might fix >> the grouping issue, but this update also contained an "urgent" security >> update which I'd have to >> look into before downgrading. > > I'd assumed AGESA version numbers were from a common code base, but > apparently not. The one mentioned in that thread was released around > Oct. 2019, but may not be applicable to your hardware. They also don't > specifically reference USB controller grouping in that thread, so it > might do nothing for you even if it is applicable. The fixed version appears to be for 3000-series processors. At least, when I was googling around I didn't see any 2000's. I have the 2500U. And besides that, I don't think there's any way for me to install it without Dell releasing a firmware update, is there?. The fix was from October, but the original/broken Agesa update was from July or earlier. So I thought maybe the March firmware update broke it, but the first thing I did was update firmware so I don't know if grouping was any different before. >> I sort of blame Xen for not enforcing IOMMU grouping, especially considering >> that it hides that >> info from the OS. KVM does enforce IOMMU grouping rules, so I don't see why >> Xen wouldn't. Xen >> leaves it up to the user software to be careful what it passes where, but >> that's kind of hard when >> you don't have /sys/kernel/iommu_groups for a hint. > > I am a bit fuzzy here too. It seems like if ACS is working correctly, > you can get better granularity within IOMMU groups. It would be > disappointing if it does not on recently released hardware. In your (TL;DR - I don't think ACS matters in Xen) I do recall seeing some info about ACS. I don't know how to check if it's supported/working. But I don't think it matters. When I say IOMMU grouping I'm actually talking about two different things. One is the grouping "policy" (so to speak), that shows up in /sys/kernel/iommu_groups, and the grouping structure is determined using the ACS protocol. This provides an interface so that software like KVM can prevent you from accidentally separating inter-dependent devices into different VMs, which can cause memory corruption or security holes or whatever. If ACS is not supported or not working, the kernel has to assume that basically all devices on the same bus(?) are interdependent, and then you end up with crappy grouping. However, unlike KVM, Xen does not, I repeat, does not enforce this policy. Xen leaves it up to the user to know what they're doing. Hence this leads us to the second sense of IOMMU grouping: the "de facto" grouping (so to speak), which means some set of devices really actually truly are interdependent, by virtue of directly sharing untranslated memory addresses for example, and will cause a crash if separated. Case in point: KVM users sometimes install an unofficial "ACS override patch" that lies about the "policy" part, in order to separate devices that normally belong to the same group, and sometimes it will work mostly fine as long as the devices in question are not "de facto" interdependent. (Patches are also added to the official kernel for specific devices when the vendor certifies that they can safely be separated.) There is no such thing for Xen, because Xen doesn't attempt to enforce the grouping policy in the first place. So ACS should be a non-issue in Xen. So in my case, I'm pretty sure that most of my devices are de facto interdependent, because separating the USB controllers from the rest of the group causes an instant crash. The de facto groups probably can be influenced by firmware/microcode in addition to the hardware. That's my understanding anyway. I could be wrong. > case, the USB controller appears as a different function of the same PCI > device, which could be the case from a hardware perspective. This is > even worse for a passthrough scenario than IOMMU grouping. There is a > Realtek controller that often comes up on the list that makes people > passthrough the SD card controller to their sys-net along with WIFI for > the same reason. That's something I haven't been able to figure out: are functions of the same device a
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 7:31 AM, "qubes123" wrote: > For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend (some > of the high bits), > resulting in Xen Panic (see xen/arch/x86/acpi/power.c). So, more > investigation would be needed to > check why the CPUID bits are changing after resume and whether it had any > security implications or > not. > For the time being - if you accept the possible security implications - you > can disable that check > eg. by commenting the panic line out after "recheck_cpu_features" in the > above mentioned power.c > file, compile xen for dom0 via qubes builder and test it in your system. I decided to give this a try, but I don't really know how to use the build system. I did `make vmm-xen`, modified the file chroot-dom0-fc29/home/user/rpmbuild/BUILD/xen-4.12.1/xen/arch/x86/acpi/power.c, but it appears after running `make vmm-xen` again my changes have been reverted. After it finishes the line is no longer commented out. Do I have to commit the change, or generate a patch file, or something like that? -- You received this message because you are subscribed to the Google Groups "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/bc81395ceb7d2abdc48d96964f9ddc05%40disroot.org.
Re: [qubes-users] Can containers be saved and copied to another qubes install?
December 28, 2019 7:13 PM, tobozoc...@gmail.com wrote: > Hi, > > Is it possible to take a container from Qubes that has some app installed and > copy it to another > system? > > Reason why this would be interesting, bc if containers can run windows apps > (thinking about > hardware development, microcontroller and FPGA connectivity through USB), > > and windows tends to crash over time, so it needs to be reinstalled, with > every program in it... > > It would make life easier if it is possible to use the containers as > containers on freight ships, > unload and load it on another ship (os), so only the platform has to be > changed underneath. > (while Qubes would be the harbor in this metaphor) > Is that possible? I would try it myself, but cannot run qubes in virtual > machine and messing up my > pc is not an attractive option. > > Appreciate your answers! Qubes has built-in backup and restore for VMs, so yes. Just copy the backup file to another Qubes machine and restore it. However I don't know what you mean by "so only the platform has to be changed underneath." Qubes VMs aren't really intended to be portable to other virtualization platforms (like KVM or VirtualBox), if that's what your asking. Not sure how template VMs work with Windows guests, but with Linux guests you can keep apps separate from user data, so that you don't have to reinstall apps when you create or delete VMs. Also, you can install Qubes on a USB flash drive if you just want to try it out. https://www.qubes-os.org/doc/backup-restore/ https://www.qubes-os.org/doc/windows-template-customization/ https://www.qubes-os.org/doc/installation-guide/#installation-destination -- You received this message because you are subscribed to the Google Groups "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/4b3cc7c3297e3baeaad9abe034cd9859%40disroot.org.
Re: [qubes-users] Lost USB-Controller, lost tty-credentials, emergency
December 28, 2019 6:02 PM, mas...@tuta.io wrote: > my USB controller is attached to nothing, but needed for Yubikey login. > >> I lost my tty2-credentials (the username), so I'm locked out of the system. >> BIOS changes don't help. >> Is there any way to "free" USB during boot? Or get rid of the tty login >> credentials? >> >> not sure what "tty login credentials" means. >> but you can always boot some random live-linux (like "fedora >> workstation"), open the qubes luks device and mount the dom0 >> root and check/change whatever needs fixing there. >> >> if you are just missing your dom0 username (huh?), getting it >> through liveboot is probably easiest. >> you can also change the boot config to remove all mentions >> of hide-all-usb. (check a guide on how to configure a qubes >> for usb-keyboard usage, basicly same thing) >> >> I think he means he uses his yubikey as an emulated keyboard to type his >> disk password, and >> probably enabled a USB Qube and now the yubikey can't type in early >> userspace. >> >> So yeah, you'll have to boot into the installer and enter rescue mode, or >> boot into some other live >> linux distro, and disable the USB Qube. Follow these instructions for >> removing your USB Qube: >> https://www.qubes-os.org/doc/usb-qubes/#removing-a-usb-qube >> >> Note, if you're using Grub, all you have to do is press 'e' when you're at >> the boot loader, and >> remove rd.qubes.hide_all_usb from the kernel command line. Then you should >> be able to login, and >> remove that same option from /etc/default/grub >> >>> Thanks! Well, I can boot into nothing because my USB connection is gone. >>> >>> I know my dom0 username but it doesnt work, and therefore the Yubikey >>> authentication at login >>> neither. >>> >>> So I thought there could be a trick reattaching the USB controller to >>> sys-usb during early boot. >>> >>> If I had access to tty2 there would be no big problem. I would delete the >>> Yubikey pam.d entry for >>> login. >>> Best, mastor >> >> (when replying please use reply-all to make sure a copy goes to the list and >> not just to me) > > Sorry, this is a mess on a/my mobile phone. > >> Ah, I see. So you're able to type in your disk passphrase and get to the >> user login screen? Either >> lightdm or a TTY, I'm assuming? And I'm assuming you're able to switch to >> TTY2, but you can't login >> to it? > > Yes, lightdm. > >> The username shouldn't have anything to do with the yubikey or USB at all. >> What do you mean the >> dom0 username doesn't work? I thought the problem was that you can't sign in >> because the yubikey >> isn't working in Qubes anymore due to enabling a USB Qube. > > Both. No tty login, no Yubikey, because the controller is not attached to the > USB qube. > >> Also, did you disable password authentication after you set up the yubikey? > > I use this, and it usually worked fine for years: > > https://old.mig5.net/content/yubikey-2fa-qubes-redux-adding-backup-key.html > >> And what do you mean your USB connection is gone? Unless there's something >> physically wrong with >> it, you should be able to boot from a USB drive regardless of whether a USB >> Qube is enabled or not. >> Have you tried booting into the installer from USB (the same way as when you >> first installed >> Qubes)? > > Hm, no, no USB boot option in Bios, no way to boot from USB. I tried > everything, I think. > > Thanks for your patience! Thanks for the link. That explains a lot. I don't know anything about this setup, so I don't know if there's a failsafe for this type of situation, such as when sys-usb won't start or it malfunctions. Something you could try: when qubes is first starting, *before* you get to the disk password prompt, press f12 to switch into text mode. You should see console output and a text-based disk password prompt. From there, see if you can do anything: switch TTYs, press Ctrl-C, type the password wrong three times, or whatever you can think of. You might be able to get an early rescue shell. Also here are some other threads about Yubikey on Qubes. See if any of them look like the same problem you're having. https://www.mail-archive.com/search?q=+Yubikey=qubes-users%40googlegroups.com Also, how did you install Qubes in the first place if you can't boot from USB? If you booted from a CD, then do that again. If you did the installation on a different machine and then physically installed the disk, do the reverse. Basically, do whatever you did to install Qubes, but instead of installing, use the rescue option. -- You received this message because you are subscribed to the Google Groups "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/ffe4b16fea5dbb572e3ef027698322f6%40disroot.org.
Re: [qubes-users] Lost USB-Controller, lost tty-credentials, emergency
December 28, 2019 5:20 PM, mas...@tuta.io wrote: > Dec 28, 2019, 17:42 by claud...@disroot.org: > >> December 28, 2019 4:31 PM, dhorf-hfref.4a288...@hashmail.org wrote: >> >>> On Sat, Dec 28, 2019 at 08:00:46AM -0800, mastor wrote: >> >> my USB controller is attached to nothing, but needed for Yubikey login. >> I lost my tty2-credentials (the username), so I'm locked out of the system. >> BIOS changes don't help. >> Is there any way to "free" USB during boot? Or get rid of the tty login >> credentials? >> >>> not sure what "tty login credentials" means. >>> but you can always boot some random live-linux (like "fedora >>> workstation"), open the qubes luks device and mount the dom0 >>> root and check/change whatever needs fixing there. >>> >>> if you are just missing your dom0 username (huh?), getting it >>> through liveboot is probably easiest. >>> you can also change the boot config to remove all mentions >>> of hide-all-usb. (check a guide on how to configure a qubes >>> for usb-keyboard usage, basicly same thing) >> >> I think he means he uses his yubikey as an emulated keyboard to type his >> disk password, and >> probably enabled a USB Qube and now the yubikey can't type in early >> userspace. >> >> So yeah, you'll have to boot into the installer and enter rescue mode, or >> boot into some other live >> linux distro, and disable the USB Qube. Follow these instructions for >> removing your USB Qube: >> https://www.qubes-os.org/doc/usb-qubes/#removing-a-usb-qube >> >> Note, if you're using Grub, all you have to do is press 'e' when you're at >> the boot loader, and >> remove rd.qubes.hide_all_usb from the kernel command line. Then you should >> be able to login, and >> remove that same option from /etc/default/grub > > Thanks! Well, I can boot into nothing because my USB connection is gone. > > I know my dom0 username but it doesnt work, and therefore the Yubikey > authentication at login > neither. > > So I thought there could be a trick reattaching the USB controller to sys-usb > during early boot. > > If I had access to tty2 there would be no big problem. I would delete the > Yubikey pam.d entry for > login. > Best, mastor (when replying please use reply-all to make sure a copy goes to the list and not just to me) Ah, I see. So you're able to type in your disk passphrase and get to the user login screen? Either lightdm or a TTY, I'm assuming? And I'm assuming you're able to switch to TTY2, but you can't login to it? The username shouldn't have anything to do with the yubikey or USB at all. What do you mean the dom0 username doesn't work? I thought the problem was that you can't sign in because the yubikey isn't working in Qubes anymore due to enabling a USB Qube. Also, did you disable password authentication after you set up the yubikey? And what do you mean your USB connection is gone? Unless there's something physically wrong with it, you should be able to boot from a USB drive regardless of whether a USB Qube is enabled or not. Have you tried booting into the installer from USB (the same way as when you first installed Qubes)? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9c3d4891b7e950b7c0b126af21d3dd29%40disroot.org.
Re: [qubes-users] Lost USB-Controller, lost tty-credentials, emergency
December 28, 2019 4:31 PM, dhorf-hfref.4a288...@hashmail.org wrote: > On Sat, Dec 28, 2019 at 08:00:46AM -0800, mastor wrote: > >> my USB controller is attached to nothing, but needed for Yubikey login. >> I lost my tty2-credentials (the username), so I'm locked out of the system. >> BIOS changes don't help. >> Is there any way to "free" USB during boot? Or get rid of the tty login >> credentials? > > not sure what "tty login credentials" means. > but you can always boot some random live-linux (like "fedora > workstation"), open the qubes luks device and mount the dom0 > root and check/change whatever needs fixing there. > > if you are just missing your dom0 username (huh?), getting it > through liveboot is probably easiest. > you can also change the boot config to remove all mentions > of hide-all-usb. (check a guide on how to configure a qubes > for usb-keyboard usage, basicly same thing) I think he means he uses his yubikey as an emulated keyboard to type his disk password, and probably enabled a USB Qube and now the yubikey can't type in early userspace. So yeah, you'll have to boot into the installer and enter rescue mode, or boot into some other live linux distro, and disable the USB Qube. Follow these instructions for removing your USB Qube: https://www.qubes-os.org/doc/usb-qubes/#removing-a-usb-qube Note, if you're using Grub, all you have to do is press 'e' when you're at the boot loader, and remove rd.qubes.hide_all_usb from the kernel command line. Then you should be able to login, and remove that same option from /etc/default/grub -- You received this message because you are subscribed to the Google Groups "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/8efdf119f5087039bb63bf09614d3f3e%40disroot.org.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 26, 2019 12:59 PM, "awokd' via qubes-users" wrote: > Claudia: > > TLDR; check bottom of https://community.amd.com/thread/241650, looks > like there was a recently released related updated. Not sure if > applicable to your situation. Thanks for the link! I'm not sure if it affects me or not. I did install a Dell BIOS update dated March 2019, so it sounds like that could have contained this Agesa update. So downgrading might fix the grouping issue, but this update also contained an "urgent" security update which I'd have to look into before downgrading. >> This caused a very sneaky problem on my machine. My USB controllers are in >> the same group as my >> GPU, sound card, and SATA controller. So when sys-usb (or >> rd.qubes.hide_all_usb) takes over those >> two USB controllers, everything stops working. [4] It was quite difficult to >> trace. It would have >> been much easier to diagnose if grouping was enforced somewhere. I would >> much rather have an error >> in my logs about being unable to assign USB controllers, than have my whole >> screen freeze up with >> no indication why. (I got lucky that it just crashed; if something >> interferes with your SATA >> controller's address space it can cause disk corruption. [5]) >> >> I don't really know who's at fault here. Qubes? Xen? AMD? Dell? > > The improper grouping is probably somewhere in AGESA, which is provided > to the manufacturers by AMD. It could be because of hardware related > limitations, which again are supplied by AMD. Sometimes vendors take > liberties (cost cutting measures) with both and break functionality, as > their primary/sole concern is that Windows boots. This can especially be > the case with consumer class machines such as Ryzen. Agree it would be > nice if Xen handled this failure mode more gracefully. Not sure there is > much Qubes can do here, though. On the other hand, my older AMD > (pre-Ryzen) consumer laptop running Coreboot has correct groupings. Yeah, my impression is the firmware can influence IOMMU grouping to an extent, within the bounds of the physical hardware. If this problem was indeed caused by an update then I assume it's (at least partly) firmware-related. According to that thread, a fix has been released for some boards/CPUs, "ComboPI", but the only feedback I can find on it is for Ryzen 3000-series which doesn't help me. Also I don't even know if or when my machine will receive a BIOS update with this Agesa fix. I sort of blame Xen for not enforcing IOMMU grouping, especially considering that it hides that info from the OS. KVM does enforce IOMMU grouping rules, so I don't see why Xen wouldn't. Xen leaves it up to the user software to be careful what it passes where, but that's kind of hard when you don't have /sys/kernel/iommu_groups for a hint. >> Intel systems >> seem to just to have better grouping usually (or, are less likely to crash >> when grouping rules are >> violated). [6] > > I think that is overbroad. There are plenty of Intel systems with broken > passthrough. iommu=no-igfx itself is a workaround for broken passthrough > of Intel graphics. There are also plenty of AMD systems with properly > implemented passthrough. Very possible. I don't have experience with a lot of other hardware, so I'm just going by what I've heard. It definitely seems to be a Ryzen problem at least, maybe not AMD in general. I just seemed to come across a lot more complaints about AMD than Intel, though. It would be nice if the HCL contained more detailed information about the IOMMU such as grouping, so we could get a better idea. At any rate, that's the least of my worries. TBH I don't really understand what no-igfx does, so I don't know if an AMD-equivalent option would help in this case or not. It's just worth noting that it's an Intel-specific fix which could improve Intel compatibility compared to AMD generally. >> Thoughts? Is there anything Qubes can do to do avoid splitting up IOMMU >> groups? Is there anything >> Qubes *should* do? Should Qubes attempt to guess the IOMMU groups before >> taking over devices? >> Should the USB Qube option be disabled on AMD systems (you can still >> manually set up sys-usb of >> course)? Should we just blame Xen for not enforcing IOMMU groups in the >> first place? > > Ultimately, it's a hardware/firmware issue. Threadripper and Epyc based > AMD systems ought to be more thoroughly vetted to support passthrough. > My suggestions are to disable automatic IOMMU grouping in your UEFI > configuration, if possible. Otherwise, try a newer firmware version with > updated AGESA code and see if it helps, or possibly add a card with > additional USB controllers as t
Re: [qubes-users] HOWTO: Enable screen poweroff (instead of blanking)
December 27, 2019 11:32 AM, dhorf-hfref.4a288...@hashmail.org wrote: > On Sun, Dec 22, 2019 at 02:45:34PM +0000, Claudia wrote: > >> overrides the XFCE Power Manager settings. Xscreensaver is only >> configured to blank the screen; I'm not sure if it even supports >> powering it off. To return control to XFCE, go to Menu > System Tools > > it does, and it works (for me). > > check "grep dpms .xscreensaver" and edit. > or use "xscreensaver-demo" to adjust in a clicky way. Thanks for adding that. Personally I don't want or need the lockscreen so for me it made more sense just to disable Xscreensaver altogether. Good to know you can have lockscreen and blanking at the same time though :) -- You received this message because you are subscribed to the Google Groups "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/3e176ea5f45d5c34d747b5c4990d0c9d%40disroot.org.
Re: [qubes-users] Re: Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 27, 2019 11:37 AM, "John Mitchell" wrote: > "This can especially be the case with consumer class machines such as Ryzen." > I had to lol about this since I have had many Intel systems with one problem > or another and this is > certainly not isolated to Ryzen. I am also running a Ryzen system running > three VMs with > PCI-passthrough on one of the VMs with no problems. I do not know if my > motherboard is consumer > grade (ASrock) however it does rock. ;) > It's not passthru in general, it's passthru of specific devices, in this case USB controllers. My network devices passthru just fine because they're in their own groups. Since you said "PCI-passthrough on one of the VMs" I'm assuming you're talking about sys-net, and that you're not using a USB Qube (which would make it two VMs). And just because passthru doesn't work on one (Intel) system or another doesn't necessarily mean it's because of IOMMU grouping. There are plenty of different reasons it could break. In any case, yeah, I'm sure Intel systems have their problems too. I just happened to come across a lot of complaints about IOMMU grouping on AMD, especially Ryzen. But my main point was about Xen and Qubes with regards to IOMMU grouping. The AMD-vs-Intel matter is the least of my concerns. -- You received this message because you are subscribed to the Google Groups "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/3b7081f22268b304d5f056efa2a82d68%40disroot.org.
Re: [qubes-users] how to install or use pm-suspend similar command on Qubes
December 27, 2019 8:35 AM, "awokd' via qubes-users" wrote: > Guerlan: > >> I'm following https://wiki.ubuntu.com/DebuggingKernelSuspend to debug >> kernel suspend problems. However, on dom0 there's no pm-suspend command. >> >> How can I install SECURELY this command or how to substitute for another >> one? >> >> This is the command: >> >> sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend" >> >> Which command does xfce use when I click the suspend button? > > Try systemctl suspend. If that doesn't work, there's also `echo mem > /sys/power/state` https://www.kernel.org/doc/Documentation/power/s2ram.txt -- You received this message because you are subscribed to the Google Groups "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/170955a3fb8a673f96436a7fb7d33252%40disroot.org.
Re: [qubes-users] upgrade: latest stable -> latest testing RC
December 25, 2019 6:49 PM, taschent...@posteo.de wrote: > Hey. > > i have two questions: > > how can i upgrade from the latest stable release 4.0.1 to the latest RC 4.0.2- > rc3? The older upgrade guides, for instance > https://www.qubes-os.org/doc/upgrade-to-r4.0 look like i'd have to reinstall. You don't have to reinstall. Just use the built in Qubes Update tool. Point releases (the last digit) are not new versions of their own, they're just a "checkpoint" where the ISO is rebuilt with the newest packages. Installing 4.0.2 is the same as installing 4.0.1 and fully updating it (with a few minor exceptions occasionally, see below). Note that rc releases might contain a few packages that are newer than what's available in the stable repos. If you want, you can switch to the current-testing repos for the latest packages. Even rc releases only update from the stable repos, though, unless you manually change it. You only have to reinstall for a minor or major version upgrade, e.g. 3.1 -> 3.2, or 3.2 -> 4.0. The article you referenced is about upgrading an existing R3.2 installation to R4.0, as I recall. -- You received this message because you are subscribed to the Google Groups "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/ebc938978d83c0d7c80de222fb9655a4%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 7:31 AM, "qubes123" wrote: > Suspend/resume problem is most likely caused by a recently added security > feature in Xen, that > checks CPUID after resume with the previously (at boot time) known CPUID. > This is to ensure, that > the CPU microcode level - along with the resulting Spectere/Meltdown etc. > mitigations - still > persist after system resume and there are no features missing. > > For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend (some > of the high bits), > resulting in Xen Panic (see xen/arch/x86/acpi/power.c). So, more > investigation would be needed to > check why the CPUID bits are changing after resume and whether it had any > security implications or > not. > For the time being - if you accept the possible security implications - you > can disable that check > eg. by commenting the panic line out after "recheck_cpu_features" in the > above mentioned power.c > file, compile xen for dom0 via qubes builder and test it in your system. So I installed the new F31-based R4.1 with Xen 8.13. Suspend/resume still isn't working; same symptoms as before. A few corrections: I dug up some old threads and found that suspend/resume actually did work correctly in F29, and on F25 the screen would power on, but just remain blank. So in fact I never got the same symptoms on Qubes as I did with Fedora 25. This means that very likely could be a Xen panic. Something new, I booted R4.1 on bare metal without Xen, and it resumes fine. It probably will even under R4.0 without Xen, too, but I haven't tried yet. So apparently it's not a version issue. While booted without Xen, I checked /proc/cpuinfo before and after resume and they were the same except for clock rates. The output is significantly different under Xen than bare metal, but the microcode version is the same. In Xen, I obviously can't compare before- and after-resume outputs. Not sure what to do. I'm really not looking forward to patching Xen. > I use a Corebooted system, where the latest AMD microcode is compiled into > the BIOS statically. And yes, I use a newer version of the AMD Fam15h > microcode, than the version in the Linux Firmware package. > This change in some of the CPUID bits after resume could be a result of > xen/kernel trying to load the published microcode, and then fails because > the BIOS version is newer. > However, the /proc/cpuinfo reported microcode version always stays the same > - the BIOS version. (..assuming the /proc/cpuinfo output is updated on any > microcode upgrade attempts..) > > As noted, I have a "special" use case, so testing the recommended change in > power.c for Claudia's newer AMD system could show, that this CPUID change > issue after resume is "special" for my case or "general" for some AMD users. That kind of makes sense. With your patch applied, can you see the CPUID bits in /proc/cpuid change after resume, or is the output the same as before? Like I said, in my case nothing in /proc/cpuinfo changes before and after resume without Xen (although it could be different under Xen). -- You received this message because you are subscribed to the Google Groups "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/162650f9ca7407a9f96832e27ad1a875%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 3:08 PM, "Brendan Hoar" wrote: > On Mon, Dec 23, 2019 at 9:46 AM Claudia wrote: > >> Awesome, in time for Christmas even! Downloading it now. Looks like it >> failed a few tests, so I >> don't know if it'll be usable enough to really test suspend/resume on it but >> we'll see. Not sure if >> I'll get a chance to install it today but I'll follow up when I do. Thanks >> for the link brendan. > > Yeah. Looks like Openqa can’t (or isn’t configured to) utilize iommu under > the kvm hosting...and > with Xen 4.13 the approach taken to workaround that in the test bed cannot be > used any more. > > So it’s possible that the large percentage of failed/incomplete tests might > not have a significant > impact on how well it works in your case. > > That being said I’m curious about how Marek will get openqa working with Xen > 4.13 and onward. > > Brendan Installed the new F31-based 4.1. Near the end of the installation, it said The following error occurred while installing the boot loader. This system will not be bootable. Would you like to continue? failed to write boot loader configuration I don't know why that happened, but sure enough grub.cfg was missing. I guess the installer keeps logs in /tmp, but I didn't know that at the time. Rebooted into recovery, chrooted, and ran grub2-mkconfig. I also noticed the UEFI boot menu situation changed. It added two entries "QubesOS" and "Fedora", and installed some other efi file in the default path \EFI\BOOT\. The former two pointed to she shim binary (under different paths), not sure about the default one. All three of them caused an instant reboot. Weird, but I didn't really investigate. I ended up just using my old "Qubes" boot entry (for grubx64.efi) after generating grub.cfg. After installation it worked fine during my hour or two of casual usage. When I was using it, it seemed noticeably faster than previous versions. So you're right it probably just had to do with the new Xen under openqa. Suspend/resume still doesn't work though. -- You received this message because you are subscribed to the Google Groups "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/68d788683e0fae63390cb616b145f950%40disroot.org.
Re: [qubes-users] Recommended laptop?
December 24, 2019 12:51 PM, taschent...@posteo.de wrote: > On Tue, 2019-12-24 at 12:48 +0000, Claudia wrote: > >> Personally I would try to avoid AMD systems, > > why that? > > -- > You received this message because you are subscribed to the Google Groups > "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/8137b39c393fd7d7192a72a8620706ae13f4150b.camel@posteo. > e. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31520.html Not scientific evidence or anything, just my personal opinion/experience. -- You received this message because you are subscribed to the Google Groups "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/dbb007537f3a3cae3b2356ea6df374b2%40disroot.org.
Re: [qubes-users] Recommended laptop?
December 24, 2019 9:43 AM, "Ondřej Šulák" wrote: > Hello pals, > > for the last release of Qubes, what laptop would you recommend? Is there any > cheaper option which > does have HW compatibility with latest Qubes (ideally with shipping from EU), > than this one: > > https://insurgo.ca/produit/qubesos-certified-privacybeast_x230-reasonably-secured-laptop > ? > Thanks for any tips! > There are two tested, but not certified, models: Thinkpad X1 Carbon gen 5, and Thinkpad x230. https://www.qubes-os.org/doc/hardware-testing/ In general Thinkpads are usually pretty safe. Personally I would try to avoid AMD systems, as well as consumer models. Look for business class or mid-range hardware where possible, as they tend to have more solid firmware. Look for Intel 4th gen (I think) and newer, as prior generations did not have integrated chipsets. Avoid buying the latest models. Qubes is based on older versions of Fedora and LTS kernels, so look for hardware that has been on the market for at least a little while. Look for models that advertise Linux compatibility or ship with Ubuntu preinstalled, and prefer vendors that tend to have good Linux support, such as Lenovo, Dell, and HP. Other than that, check the HCL, and google around and see what other users have reported. Also search the mailing list for HCL reports, as it takes a long time for them to show up on the website. Above all, make sure you can return it for a refund in case it doesn't run Qubes! Now, all that being said, I recently took a chance on a very cheap consumer-grade Dell Inspiron with AMD, and I have to say I had pretty good luck, all things considered. USB Qube is not supported, and I still haven't gotten suspend/resume to work, but everything else works, and it was a steal for the price. So even going against all recommendations you can still get lucky, it just depends how much risk you're comfortable with and how much trial-and-error you have time for. However, even following all the best practices won't guarantee success on the first try: case in point there are Thinkpads on the HCL with more problems than my cheap Inspiron. Good luck! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dccf3314376502a699a313ce2fcca986%40disroot.org.
Re: [qubes-users] UPnP in Qubes
December 23, 2019 6:09 PM, "hut7no' via qubes-users" wrote: > I have a setup like this: > AppVM -> FirewallVM -> NetVM -> internet > and want to be able to use UPnP for the AppVM. > Do any of you know how you would set this up in Qubes? > > -- You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > qubes-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/4800d296-0722-9b78-b16c-de83c5bfaffe@tt3j2x4k5ycaa5zt. > nion. I don't know, but I was actually wondering about this too. You mean for automatic port forwarding, right? I would imagine you can get a UPnP daemon that allows you to set commands to be run when a client requests port forwarding, and have it run qvm-firewall or iptables/nftables accordingly. You may have to write some glue code but it should be fairly simple. See: https://www.qubes-os.org/doc/firewall/ https://qubes-core-admin-client.readthedocs.io/en/latest/manpages/qvm-firewall.html https://www.qubes-os.org/doc/networking/ https://manpages.ubuntu.com/manpages/precise/man5/upnpd.conf.5.html (Just an example. There are many implementations out there and this one may or may not be the best choice.) If you find a solution, please follow up and share what you came up with. -- You received this message because you are subscribed to the Google Groups "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/21f6a5aaf83de6e09ca5e1c6b6fa43fb%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 1:17 PM, "qubes123" wrote: > As I remember, distribution releases (Fedora, Debian) without Xen were OK for > me, however, with > upstream Xen installed, obviously all had this suspend issue. > I don't have a debug card, so the symptoms are: when the computer wakes up > with this issue, the > screen remains blank and the processor start to heat up and the PC remains > unresponsive. It doesn't > turn off automatically you have to forcibly turn it off using the power > button >5 sec. When you say it remains blank, do you mean the screen is totally powered off, or do you mean the backlight comes on but it just displays a black screen? Going from memory here, but I *think* in F29 (without Xen) the backlight would come on, but the screen was just blank, and I could make the caps lock light come on and hear sounds from the OS, and ctrl-alt-delete would cause it to reboot after 60 seconds as expected. Possibly a graphics driver problem. In Qubes R4.1 (F29-based) with Xen, when I resume I can hear the fans come on, but that's it. The backlight remains powered off, the caps lock light won't come on, sound doesn't resume playing, and I have to hold the power button to force reboot. Sounds to me like it could be a Xen panic, although I believe this is the same as what happened in F25, if memory serves. Also, I don't know what a debug card is, but my BIOS has an option called "USB Debugging" which is enabled. Do you know anything about that, or how to make use of it? I'm not looking to get into any serial/UART type stuff, but USB might be an option, depending on what it does, what you need to have, and how difficult it is. -- You received this message because you are subscribed to the Google Groups "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/4818737d63628d0503182f62fa0e0224%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 2:27 PM, "Brendan Hoar" wrote: > On Mon, Dec 23, 2019 at 6:45 AM Claudia wrote: > >> I'm not sure this is the problem, though, because I get the same symptoms >> when suspending in a >> Fedora 25 livecd. Which makes me think it's a Fedora problem not a Xen >> problem, at least for R4.0. >> In Fedora 29 I think the symptoms were slightly different, the system was >> responsive but the screen >> just didn't power back on after resume. I don't think suspend/resume >> actually worked correctly >> until Fedora 30. We should have an F31-based R4.1 developer release by the >> end of the month, which >> would be a more accurate test. > > See Marek’s post near the end of this issue, he has a link to a F31 R4.1 ISO > built on openqa: > > https://github.com/QubesOS/qubes-issues/issues/5529 > > -Brendan Awesome, in time for Christmas even! Downloading it now. Looks like it failed a few tests, so I don't know if it'll be usable enough to really test suspend/resume on it but we'll see. Not sure if I'll get a chance to install it today but I'll follow up when I do. Thanks for the link brendan. -- You received this message because you are subscribed to the Google Groups "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/fa130935edfb581463fd0d65dd8e2e54%40disroot.org.
Re: [qubes-users] wipe released diskspace of a disposable VM's
brendan.h...@gmail.com: Other discussions involved performing the encryption inside the VMs, but as I mentioned earlier, if the content in the VM that is being manipulated is untrustworthy...then is the VM's internal encryption really trustworthy? This is a good point which I hadn't thought of. Forgive me I still haven't read the whole discussion, I was just coming up with some ideas for the OP. For networked VMs, it's a moot point because malware could just as easily send the data to attacker.gov instead of breaking encryption. But for non-networked VMs, it's a very good point. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- You received this message because you are subscribed to the Google Groups "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/0a687a91-e980-7576-2e8d-4d13ebaa2715%40vfemail.net.
Re: [qubes-users] Intel's continued security meltdown, MDS edition:
Chris Laprise: From Kim Zetter at the New York Times: https://twitter.com/KimZetter/status/1194374230109868032 When Intel released patch for CPU vulns last May, it said the patch fixed all the vulns. But researchers at @vu5ec say this isn't true and Intel knew it. Intel asked them not to disclose this and to alter conf. paper about the vulns. “We think it’s time to simply tell the world that even now Intel hasn’t fixed the problem,” Herbert Bos (@herbertbos ) says. “There are tons of vulnerabilities still left, we are sure. And they don’t intend to do proper security engineering until their reputation is at stake.” https://www.nytimes.com/2019/11/12/technology/intel-chip-fix.html https://mdsattacks.com/ - Its worth noting that the lion's share of these vulns are vendor-specific to Intel. I have long held the position that Spectre+Meltdown showed AMD x86 to be "substantially" better engineered with respect to security; I now believe that assessment to be an understatement. Competition between Intel and AMD is very asymmetrical, as the former amounts to a monopoly and the latter is the only one that feels acute competitive pressure (and hence, AMD has felt a greater need to engineer responsibly). OTOH, Intel has maintained their position with lazy engineering shortcuts, rigged benchmarks, and anti-competitive threats lodged against PC makers. For their threats, the company even announced it will refuse to pay a hefty EU judgment against them. That is the "merit" in how they maintain dominance. Even though I greatly favor the development and promotion of open source hardware (including CPUs), there are no open alternatives for Qubes users in the short-mid term. So recognizing that open source is not a singular guiding principle – that competition is vitally important for the availability of desirable and safe products – I think it would be best if the Qubes project and community recognized the situation and made a modest effort to certify AMD hardware as a safer alternative to Intel. Thanks for the info. As you may remember, I recently switched to AMD just for cost reasons. The problem is, it's hard enough to find an Intel machine that runs Qubes well, let alone an AMD machine. I know conventional wisdom says AMD is about equal to Intel in terms of compatibility, but lately I'm starting to question that. Aside from the fact that Intel is more widely used and tested, here are a couple of specific examples I've come across. https://www.mail-archive.com/qubes-users@googlegroups.com/msg29776.html This user has a mid-range business class Ryzen laptop which experienced a lot of the same problems as my low-end consumer Ryzen laptop with the same processor. The kernel complains of ACPI problems and firmware bugs. Sys-usb doesn't work, possibly due to the way USB controllers are grouped on AMD's IOMMU implementation. And suspend/resume doesn't work right, although that's not uncommon for any machine. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31199.html This is an issue I ran into with the amdgpu driver, where I found that Xen has an Intel-specific option for disabling the IOMMU for the integrated graphics device, but no AMD-equivalent option. (I don't know if that's the actual problem, I'm just saying it's an Intel-specific option, of which there are several.) https://www.mail-archive.com/qubes-users@googlegroups.com/msg31512.html Here I discovered a problem with IOMMU grouping which seems to be common on Ryzen processors and perhaps AMD systems in general. The USB controllers are in the same group as the GPU, SATA controller, and audio devices. So when I try to assign USB controllers to sys-usb, everything stops working. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31515.html Here a user points out that many AMD processors slightly change their feature set (cpuinfo) after a suspend/resume cycle, which causes Xen to panic due to Spectre/Meltdown mitigation. Not sure where Intel stands on this. While there may be security benefits to AMD, I think there are also some compatibility gotchas to watch out for. You're already taking your life in your own hands when you install Linux, especially a hardware-sensitive distro like Qubes. The last thing you probably want to throw into the mix is a second-place CPU vendor. I just don't know if Qubes on AMD is quite ready for primetime. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 7:31 AM, "qubes123" wrote: > Suspend/resume problem is most likely caused by a recently added security > feature in Xen, that > checks CPUID after resume with the previously (at boot time) known CPUID. > This is to ensure, that > the CPU microcode level - along with the resulting Spectere/Meltdown etc. > mitigations - still > persist after system resume and there are no features missing. > How recent? Is it present in Xen 4.8-fc25 (R4.0)? Xen 4.12-fc29 (R4.1)? > For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend (some > of the high bits), > resulting in Xen Panic (see xen/arch/x86/acpi/power.c). So, more > investigation would be needed to > check why the CPUID bits are changing after resume and whether it had any > security implications or > not. > For the time being - if you accept the possible security implications - you > can disable that check > eg. by commenting the panic line out after "recheck_cpu_features" in the > above mentioned power.c > file, compile xen for dom0 via qubes builder and test it in your system. Thanks for the info. I'm not sure this is the problem, though, because I get the same symptoms when suspending in a Fedora 25 livecd. Which makes me think it's a Fedora problem not a Xen problem, at least for R4.0. In Fedora 29 I think the symptoms were slightly different, the system was responsive but the screen just didn't power back on after resume. I don't think suspend/resume actually worked correctly until Fedora 30. We should have an F31-based R4.1 developer release by the end of the month, which would be a more accurate test. What are the symptoms of a Xen panic? Would it prevent the screen from powering back on? Would it reboot after five seconds? Or would it just hang? I'll try booting qubes R4.1 on bare metal without Xen and try suspend/resume. If it works I'll post cpuinfo before and after. -- You received this message because you are subscribed to the Google Groups "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/35df692b5dc1538f4762cc54eef9c77b%40disroot.org.
[qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
I'm very new to all this iommu stuff, but as I understand it, devices in the same iommu group are supposed to be treated as a single unit, meaning if any of them are assigned to a VM then they all must be assigned to the same VM. This is because those devices cannot be isolated from each other -- they can communicate directly without going through the IOMMU at all, for example. This not only creates obvious security holes, but can also cause compatibility problems. For example, devices in different VMs will have different perspectives of system memory. [3] Or something like that. Like I said, I'm still trying to wrap my head around it. Point is, the entire group is supposed to be treated as a single unit. Linux/KVM enforces this, Xen does not, I'm not sure about any other platforms. [1] This caused a very sneaky problem on my machine. My USB controllers are in the same group as my GPU, sound card, and SATA controller. So when sys-usb (or rd.qubes.hide_all_usb) takes over those two USB controllers, everything stops working. [4] It was quite difficult to trace. It would have been much easier to diagnose if grouping was enforced somewhere. I would much rather have an error in my logs about being unable to assign USB controllers, than have my whole screen freeze up with no indication why. (I got lucky that it just crashed; if something interferes with your SATA controller's address space it can cause disk corruption. [5]) I don't really know who's at fault here. Qubes? Xen? AMD? Dell? Unfortunately, Qubes has no way of knowing anything about iommu grouping because Xen takes over the IOMMU (and therefore grouping is not visible in dom0). [2] So probably the only way Qubes could enforce grouping is by some kind of heuristic. For example, assume all functions of a device are grouped. Or, assume all devices on a hub are grouped. Or just disable the USB Qube option on AMD systems entirely, or warn the user that it may cause serious problems that are hard to diagnose. As for fixing the actual problem, that is, grouping them in a more sensible way so that the GPU and USB controllers can be isolated for example, can only be done in a firmware (or microcode?) update by the vendor, if at all. There are some hacks for KVM to spoof the grouping restrictions (which Xen doesn't enforce in the first place), but they don't solve the underlying problem. VFIO seems like it could work (by emulating some IOMMU functionality in software), but I don't know if it's supported by Xen. I'm guessing part of the reason this problem doesn't usually come up on Intel systems is because of the Xen option iommu=no-igfx. This means that the integrated GPU is always exempt from IOMMU control altogether, but this option is Intel-specific and has no AMD equivalent. However, that doesn't do anything about other devices such as sound cards or SATA controllers. Intel systems seem to just to have better grouping usually (or, are less likely to crash when grouping rules are violated). [6] At least that's my understanding so far. Thoughts? Is there anything Qubes can do to do avoid splitting up IOMMU groups? Is there anything Qubes *should* do? Should Qubes attempt to guess the IOMMU groups before taking over devices? Should the USB Qube option be disabled on AMD systems (you can still manually set up sys-usb of course)? Should we just blame Xen for not enforcing IOMMU groups in the first place? [1] https://lists.gt.net/xen/devel/345279#345279 [2] http://xen.1045712.n5.nabble.com/IOMMU-group-dissapear-in-XEN-td5737357.html [3] https://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html [4] https://www.mail-archive.com/qubes-users@googlegroups.com/msg31494.html [5] http://xen.1045712.n5.nabble.com/VGA-passthrough-with-USB-passthrough-td5738340.html [6] https://hardforum.com/threads/ryzen-and-iommu-groups-is-this-ever-going-to-get-fixed.1944064 --- Dell Inspiron 5575, AMD Ryzen 5 2500U, Qubes R4.1 booted without Xen: # lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:01.6 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] 00:01.7 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus A 00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 22, 2019 5:45 PM, "Vít Šesták" wrote: > Helllo, > > Dec 22, 2019 15:17:27 Claudia : > > >> I don't know which step -- unbinding xhci_pci, or binding pciback -- >> actually causes the crash in > this case. I can say, however, that one of them does cause an immediate > crash, before sys-usb ever > starts or has a chance to take over the USB controllers. > > That (and the specific script) is an interesting finding. Maybe it would be > possible to run the > commands one-by-one to see which one crashes the system. > I think I might try that sometime, just out of curiosity. > BTW, could you confirm that the USB Controller is an AMD one? This could be > helpful for anyone > wanting a Qubes laptop with AMD. > Yes, as far as I can tell. 03:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 [1022:15e0] 03:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 [1022:15e1] -- You received this message because you are subscribed to the Google Groups "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/bdc095fbe5db7ccce547c6d1e09c%40disroot.org.
[qubes-users] HOWTO: Enable screen poweroff (instead of blanking)
I just wanted to drop a note here before I forget. Out of the box, Qubes blanks the screen after a few minutes, but never powers off the screen, even though it's configured to do so in the XFCE Power Manager. I've had this problem on several machines, all the way back to R3.2, and I always blamed it on lack of hardware support. Turns out, it's because Qubes comes with Xscreensaver enabled which overrides the XFCE Power Manager settings. Xscreensaver is only configured to blank the screen; I'm not sure if it even supports powering it off. To return control to XFCE, go to Menu > System Tools > Session and Startup > Application Autostart, and uncheck "Screensaver". Then you can logout, reboot, or go to Menu > System Tools > Screensaver > File > Kill Daemon. You may have to also open Menu > System Tools > Power Manager > Display, and switch "Display power management" to off and then on again. Note this will disable the lockscreen. This is not recommended if you use a USB keyboard or mouse and a USB Qube, or if someone has physical access to your computer while it's on. Otherwise, I recommend enabling screen poweroff in order to conserve energy and lengthen the lifespan of your screen's backlight. -- You received this message because you are subscribed to the Google Groups "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/bbc604dc7a210432fe6f418a6eaa0834%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 22, 2019 10:33 AM, "Vít Šesták"
wrote:
> 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'
Thanks for the info. Yes, that sounds correct from what I could tell, too. More
specifically, what rd.qubes.hide_all_usb actually does is looks for USB
controllers device files in /sys/bus/pci, and then calls their driver/unbind,
driver/new_slot, and driver/bind functions. So basically, it forces the Linux
USB driver (xhci_pci, in my case) to detach from the USB controller, and then
attaches it to Xen's pciback driver so that it can be used by sys-usb later
(although I don't know if this step is actually necessary, since starting
sys-usb without hide_all_usb works just fine). I'm assuming this step happens
before udev trigger, which probes devices including USB devices. Maybe that's
why the hook assigns pciback instead of just unbinding the USB driver - so udev
doesn't see that the device has no driver and attempt to bind the USB driver to
it again. Or maybe the act of binding pciback is what actually places the USB
controller under IOMMU isolation by Xen (otherwise the USB controller could
still perform a DMA attack even with no driver bound to it).
I don't know which step -- unbinding xhci_pci, or binding pciback -- actually
causes the crash in this case. I can say, however, that one of them does cause
an immediate crash, before sys-usb ever starts or has a chance to take over the
USB controllers.
The same hook does the same thing for networking devices as well, so that those
are never exposed. In my case this doesn't cause a problem because both network
cards are their own devices on their own busses and have their own IOMMU
groups, unlike my USB controllers.
Here's the actual code from
/usr/lib/dracut/modules.d/99qubes-pciback/qubes-pciback.sh
#!/usr/bin/sh
type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
# Find all networking devices currenly installed...
HIDE_PCI="`lspci -mm -n | grep '^[^ ]* "02'|awk '{print $1}'`"
# ... and optionally all USB controllers...
if getargbool 0 rd.qubes.hide_all_usb; then
HIDE_PCI="$HIDE_PCI `lspci -mm -n | grep '^[^ ]* "0c03'|awk '{print $1}'`"
fi
HIDE_PCI="$HIDE_PCI `getarg rd.qubes.hide_pci | tr ',' ' '`"
modprobe xen-pciback 2>/dev/null || :
# ... and hide them so that Dom0 doesn't load drivers for them
for dev in $HIDE_PCI; do
BDF=:$dev
if [ -e /sys/bus/pci/devices/$BDF/driver ]; then
echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
fi
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
done
As for USB controllers being on the CPU, yes that's what I found as well; all
current CPUs bundle their integrated USB controllers right on the chip. I don't
think code in the Linux kernel expects the USB controllers to be available.
Rather I think it has to do with IOMMU grouping, which tends to be structured
differently for AMD than Intel. I'm going to start a new thread about that here
soon.
--
You received this message because you are subscribed to the Google Groups
"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/7b07608331097f1747144fff3291f423%40disroot.org.
Re: [qubes-users] Dual booting Qubes and Qubes?
December 20, 2019 2:19 PM, "Claudia" wrote: > > I decided I'm going to try the dual-ESP approach first and see if it works. > If not, then I'll try > the EFI directory hack. > > I formatted my disk like: ESP, /boot, root, ESP, /boot, root, (swap); and > installed Qubes into the > first "slot". I still have to install another Qubes instance into the second > "slot" and make sure > they both work. I'll follow up when I do. The dual ESP approach seems to be working fine for me, but you do have to manually fiddle around with efibootmgr. The installer overwrites existing Qubes entries, although I'm not sure what exactly it looks for. Maybe changing the label would be sufficient to preserve it. Dual booting R4.1 and R4.0, both using btrfs on dm-crypt. I can't speak to how LVM or anything else might be affected. -- You received this message because you are subscribed to the Google Groups "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/b673b6683a5fa2bd9008f6e45a64e0a2%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 20, 2019 9:13 PM, "Claudia" mailto:claud...@disroot.org?to=%22Claudia%22%20)> wrote:
December 20, 2019 6:05 PM, brendan.h...@gmail.com
(mailto:brendan.h...@gmail.com) wrote:
On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote:December 19,
2019 12:13 AM, "Claudia" wrote:
> This is R4.1 build 20191013
>
> It works pretty well, definitely better than 4.0, but there are some weird
> boot issues. If I let it
> boot with everything as default, it will boot loop before reaching the disk
> password screen. I
...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I
remove it, it boots fine with the graphical splash and passphrase prompt.
Another AMD Ryzen user mentioned having the same problem a while back.
Something about AMD's IOMMU grouping of USB controllers, or something.
Unfortunately, (my understanding is) that exposes the dom0 to the USB ports.
Even if you have a sys-usb, dom0 is still exposed temporarily on boot.
Thanks for the tip. I actually thought removing that parameter just simply
disabled USB Qube functionality and attached all devices to dom0, but I guess
that's only when sys-usb is not running. Once sys-usb is running, it takes over
the USB controllers from dom0, I guess. It's just that they're exposed before
sys-usb starts, in that case.
It would be nice to have working, but I've never had a USB Qube before, even on
my old machine, so I haven't lost anything. I don't use a lot of USB devices,
and it's not a big part of my threat model. I'll play around with it when I
have a chance.
I realized I had disabled autostart for all VMs including sys-usb to speed up
boot time (systemctl disable sys-{net,usb,firewall,whonix}@qubesvm.se
(mailto:whonix...@qubesvm.se)rvice), and I hadn't actually run sys-usb at all
since then. I decided to start sys-usb while the system was running, and
everything went to hell: the screen froze, audio stopped, even the caps lock
light wouldn't come on.
So this isn't limited to hide_all_usb, just USB controller passthru in general
on this machine.
So I reinstalled 4.0.2-rc3, once again, this time without USB Qube, and
everything works (except suspend/resume which doesn't work anywhere except
Fedora 30, not even F29 iirc), including audio and amdgpu without nomodeset.
All this time I was blaming it on the old-ness of 4.0, but it was hide_all_usb
all along. The only reason I tried getting rid of hide_all_usb in 4.1 is
because the nomodeset trick didn't work in 4.1 so I had to continue
troubleshooting, whereas in 4.0 it worked and I moved on. And also grub makes
it way more convenient to modify boot options.
So in summary, for 4.0 and 4.1 alike, everything works except suspend/resume,
as long as you don't set up a USB Qube. I attached updated HCL reports to
reflect this, and will update them as I do more testing.
I'm going to try and figure out some of this IOMMU grouping stuff and start
another thread about this issue. But like I said, I never had a USB Qube
before, so I'm not going to miss 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/bbdf183debac9338e0f46d32bbcb%40disroot.org.
Qubes-HCL-Dell_Inc_-Inspiron_5575-20191220-220355.yml
Description: Binary data
Qubes-HCL-Dell_Inc_-Inspiron_5575-20191221-021654.yml
Description: Binary data
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 20, 2019 6:05 PM, brendan.h...@gmail.com (mailto:brendan.h...@gmail.com) wrote: On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote: December 19, 2019 12:13 AM, "Claudia" wrote: > This is R4.1 build 20191013 > > It works pretty well, definitely better than 4.0, but there are some weird > boot issues. If I let it > boot with everything as default, it will boot loop before reaching the disk > password screen. I ...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I remove it, it boots fine with the graphical splash and passphrase prompt. Another AMD Ryzen user mentioned having the same problem a while back. Something about AMD's IOMMU grouping of USB controllers, or something. Unfortunately, (my understanding is) that exposes the dom0 to the USB ports. Even if you have a sys-usb, dom0 is still exposed temporarily on boot. Thanks for the tip. I actually thought removing that parameter just simply disabled USB Qube functionality and attached all devices to dom0, but I guess that's only when sys-usb is not running. Once sys-usb is running, it takes over the USB controllers from dom0, I guess. It's just that they're exposed before sys-usb starts, in that case. It would be nice to have working, but I've never had a USB Qube before, even on my old machine, so I haven't lost anything. I don't use a lot of USB devices, and it's not a big part of my threat model. I'll play around with it when I have a chance. -- You received this message because you are subscribed to the Google Groups "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/de0f6b78201db24d5474eeb050e09650%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 19, 2019 12:13 AM, "Claudia" wrote: > This is R4.1 build 20191013 > > It works pretty well, definitely better than 4.0, but there are some weird > boot issues. If I let it > boot with everything as default, it will boot loop before reaching the disk > password screen. I > found I can get it to boot successfully if I add to the Xen commandline > noreboot=1 loglvl=all > and remove from the linux commandline > rhgb quiet rd.qubes.hide_all_usb > > Still working on narrowing down which of those is/are responsible for fixing > the problem (I can't > figure out why any of them would). Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I remove it, it boots fine with the graphical splash and passphrase prompt. Another AMD Ryzen user mentioned having the same problem a while back. Something about AMD's IOMMU grouping of USB controllers, or something. I'm planning on installing kernel-latest and I'll test it again when I do. -- You received this message because you are subscribed to the Google Groups "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/0b276a64d383722c4057879b527f261c%40disroot.org.
Re: [qubes-users] Dual booting Qubes and Qubes?
December 19, 2019 3:44 PM, "awokd' via qubes-users"
wrote:
> Claudia:
>
>> My original thought was to just give each one its own directory in
>> /boot/efi/EFI/, but the /boot/efi/EFI/qubes/ path seems to be hard coded
>> somewhere, probably either in the grub2-efi package (which installs a
>> precompiled efi binary to that directory) or in a grub2-install hook
>> somewhere. Not sure which of those methods Qubes uses. At least, I
>> couldn't figure out any way to persistently change the name of the EFI
>> directory. Of course you could make your own directories by copying the
>> files. e.g. /boot/efi/EFI/qubes{0,1}/, but when it updates (or you
>> reinstall one of them), they would both try to install to
>> /boot/efi/EFI/qubes/ again. And you'd have to manually change the path
>> each time with efibootmgr.
>
> This is partly what I need to do anyways on an older UEFI system. I
> wrote a script that copies the updated files over to BOOTX64, and run it
> after every update that touches EFI. Shouldn't be too hard to add
> efibootmgr to it, and an edit to the .cfg file pointing at the
> appropriate root=. Ignore the redundant .efi copies at the end; I'm
> still not entirely sure which one my half broken UEFI implementation uses.
>
> rm /boot/efi/EFI/BOOT/init*
> rm /boot/efi/EFI/BOOT/vmlinuz*
> cp /boot/efi/EFI/qubes/init* /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/vmlinuz* /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg
> ls /boot/efi/EFI/qubes/xen-*.efi
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/BOOTX64.efi
>
I see. I'm guessing your firmware only attempts to read from
/boot/efi/EFI/BOOT/BOOTX64.efi, even if the menu entry has a different path? I
think an approach like this could work for managing EFI directories manually.
Automated by a script of course, but still manual in the sense it's not handled
by the OS.
I was really hoping there was a config setting or variable somewhere that could
change the EFI directory, e.g. to /boot/efi/EFI//. On systems that
use grub-install, this is specified by --bootloader-id= argument. So in that
case you may be able replace /usr/bin/grub-install with a wrapper script that
forces your desired --bootloader-id argument. However Fedora doesn't use
grub-install, it uses a package which installs a prebaked grubx64.efi binary
which is installed to the hardcoded path /boot/efi/EFI/fedora. This is in order
to support Secure Boot. I'm assuming Qubes does it the same way. I'm also
assuming that "fedora" gets changed to "qubes" by a patch or a compile-time
variable but is not configurable at runtime. Maybe there's an option in Yum/dnf
similar to apt's redirect option, to configure a file to be installed at a
different path than what it's packaged as. I have no idea.
I did some research, and apparently this is a very common flaw. In fact, Mint
uses the hardcoded directory /boot/efi/EFI/ubuntu/, meaning you can't dual boot
Mint and Ubuntu from the same ESP. But the good news is that you can use more
than one ESP, as long as your firmware supports it (it sounds like most of them
do). So that's also an option. I was originally worried it would cause problems
that they're using the same UUID, but actually they don't. I was confusing the
filesystem UUID, which is unique, with the GPT partition identifier (GUID),
which is a magic value. And I remembered you could also mount them by label
anyway.
https://www.zdnet.com/article/hands-on-linux-uefi-multi-boot-part-three-problem-solving/
So I guess I could use /boot/efi/EFI/qubes/ as a sort of staging area for both
instances of Qubes, and then religiously after every update, run a script to
move the directory to /boot/efi/EFI/qubes{0,1,...}, and then delete the
newly-created efibootmgr entry for \EFI\qubes\grubx64.efi and (if necessary)
re-create the one for \EFI\qubesN\grubx64.efi. Or, perhaps there's some way to
prevent modification of efibootmgr entries so the package install hook (or
whatever) can't mess with it.
I decided I'm going to try the dual-ESP approach first and see if it works. If
not, then I'll try the EFI directory hack.
I formatted my disk like: ESP, /boot, root, ESP, /boot, root, (swap); and
installed Qubes into the first "slot". I still have to install another Qubes
instance into the second "slot" and make sure they both work. I'll follow up
when I do.
--
You received this message because you are subscribed to the Google Groups
"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/f5c224eda7a05920ab205a2224c58b64%40disroot.org.
[qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
This is R4.1 build 20191013 It works pretty well, definitely better than 4.0, but there are some weird boot issues. If I let it boot with everything as default, it will boot loop before reaching the disk password screen. I found I can get it to boot successfully if I add to the Xen commandline noreboot=1 loglvl=all and remove from the linux commandline rhgb quiet rd.qubes.hide_all_usb Still working on narrowing down which of those is/are responsible for fixing the problem (I can't figure out why any of them would). Improvements since 4.0: Screen power management works - brightness controls, and screen poweroff after inactivity (in 4.0 it would just blank but not power off) Audio works, which it did not work in 4.0 even after many days of troubleshooting amdgpu works correctly - doesn't freeze when booting without nomodeset Multimedia keys - not sure if they worked in 4.0 or not Still working: UEFI mode wifi touchpad keyboard Still NOT working: Suspend/resume Not tested (yet): Legacy mode HDMI audio & video USB Qube SD card reader Microphone Webcam Wired networking I'll try to do some more testing and update this thread when I have a chance. Just putting this out there for now. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ae710f3839c46261d257d7d188da32b9%40disroot.org. Qubes-HCL-Dell_Inc_-Inspiron_5575-20191218-015203.yml Description: Binary data
