Re: [qubes-users] Qubes Structure
>If you understand very little, then the most paranoid of setups will get you very little in terms of security, because you will end up making choices that compromise that security -- or you will just end up wasting a great deal of time on things that don't matter. I do have some experience in computers and cybersecurity, and I want to know more. I came here to find more information about qubes architeturing; get the most out of it. If you can provide some links or advice that help me to make better qubes setup, I would be thankful to you. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/16f551a47ee.d18df96243681.4660457132775699060%40privacy.com.co.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Sun, Dec 29, 2019 at 01:44:28PM +, 'awokd' via qubes-users wrote: tetrahedra via qubes-users: On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users wrote: Unfortunately I need to get work done so have to reboot to "just make it go away" but I am still interested in troubleshooting ideas (for when it happens next). Investigate xl top more thoroughly. You can identify offending VMs with it, and see if all your RAM is in use which triggers swapping to (slow) disk. My disk is a pretty fast SSD, and I did use xentop (`xl top` is just an alias for xentop) and it didn't show anything unusual as far as I can recall. Perusing the xentop man page doesn't show any potentially relevant options except for `--full-name` and that option doesn't seem to do anything. Pressing "B" (for "vBds") seems to list a number of devices for each VM but none of them have any 2-digit unique identifying number (as `iotop` seems to display). -- You received this message because you are subscribed to the Google Groups "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/20191230043233.GE1185%40danwin1210.me.
Re: [qubes-users] Qubes Structure
On Sun, Dec 29, 2019 at 10:56:31AM +0100, xao wrote: Hi! Sorry for the bad question structure, don't know how to write it properly. I've seen some examples of how people setup their system and the most paranoid ones create separate standalone vm for each application and firewall that allows only this application to connect to the internet. Currently, I have 4 template vms - debian 10 with all programs I use installed in it, fedora 30 minimal for netvms, and whonix templates. All my vms that I use on day to day basis are made with debian template. After seeing all those setups I feel that my system is an open garden for hackers and they can do whatever they want, and I will find it out only after I get completely hacked. So, my question is how to setup your system for maximum security? Is there any guidelines on how to do so? I understand that it may be a silly question because it mostly depends on from whom I protect myself, but let's imagine I need to protect from everyone. If you need to protect from everyone then you should turn your computer off, lock it in a vault, embed the vault in a block of solid concrete, bury the whole mess at the bottom of a mine, and post an armed guard at the door. Then you *may* be safe. Ultimately your security is not the product of some "setup" but of the degree to which you understand how your setup works and what the implications are of the choices that you make. If you understand very little, then the most paranoid of setups will get you very little in terms of security, because you will end up making choices that compromise that security -- or you will just end up wasting a great deal of time on things that don't matter. If you need security but don't understand computers, avoid using computers! -- You received this message because you are subscribed to the Google Groups "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/20191230042414.GC1185%40danwin1210.me.
Re: [qubes-users] Is it plausible to use Debian template with sys-XXX VM?
Check this article - https://www.qubes-os.org/doc/templates/minimal/ (scroll down untill you see "Debian" header) It explains what you need to install so that debian template will work as expected. -- You received this message because you are subscribed to the Google Groups "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/16f54eb5419.d5ce551041786.2978495989138483988%40privacy.com.co.
[qubes-users] Re: Recommended laptop?
On Sunday, December 29, 2019 at 5:35:52 PM UTC-5, Blake S wrote: > > On Wednesday, December 25, 2019 at 10:09:24 PM UTC-6, brend...@gmail.com > wrote: >> >> My own longterm Qubes primary has been a used W520 quad core with four >> 8GB DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual >> core versions: they only have two memory slots and can only support 16GB >> Max.] >> > > What BIOS are you using? I have a W520 coming in soon that I plan to use > for Qubes. I've been using a G505s for a while but it isn't terribly well > built and suspend/resume doesn't work on it. > Lenovo BIOS for W520, v1.46 (most recent last I checked). Qubes R4.0 (updated as of today, including current-testing repo). Using kernel-latest in dom0 (5.4.3-1, but 5.4.5-1 on next reboot). Suspend/Resume appear to be working ok. B -- You received this message because you are subscribed to the Google Groups "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/14936bfa-4880-4acd-a1d5-9953880dc7a2%40googlegroups.com.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
On Sunday, December 29, 2019 at 7:25:49 PM UTC-5, Claudia wrote: > > Ha. Now that you mention it, I do remember laptops used to have PCIe > slots. But I think those days are pretty much over. > > On a side note, I remembered I saw some error about the IOMMU in the > kernel logs at some point. I just ignored it at the time because I was > dealing with bigger problems. I'm going to start a new thread for that. > Yup, many early-mid 2010s Lenovo Thinkpads have an externall expresscard slot: X230, T520, W520, T530, W530, T540, W540... 1 entire lane of PCIe 2.0 (3.2 Gbit/s ... ~300MB/s) bliss! But more seriously, people actually used to use these for external gaming GPUs way back when. For Qubes, on some of these models, the slot is very helpful: you can add an additional USB 3.0 root hub for external devices that can be mapped independently, even if you can only get about half-throughput from it. B PS - Also, some internal laptop slots for wifi/etc. are mPCIe...but using them for other purposes generally means leaving the laptop disassembled, which means...well...why use a laptop? -- You received this message because you are subscribed to the Google Groups "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/5b0b98c7-dd90-4b70-8d9c-f2a35b2122c1%40googlegroups.com.
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 always inherently in the same de facto group? Or does the BDF structure have little to do with grouping? It seems likely that functions of the same device would communicate directly instead of via the bus/IOMMU. But it's also conceivable that some devices would intentionally send data
Re: [qubes-users] Lost USB-Controller, lost tty-credentials, emergency
> mastor: > Now I have to solve "unable to reset PCI device, 00:14.0: no FLR, PM reset > or bus reset available ...", but there's a thread on Github. > > awokd:> Enable the "no strict reset" option for the PCI device that is causing > problems via Qube Settings on the problem VM, then Devices tab, then > large button at the bottom. > Yes, thank you, I already did. I also had to detach and attach: (user@dom0)$ qvm-pci detach sys-usb dom0:00_14.0 (user@dom0)$ qvm-pci attach --persistent -o no-strict-reset=True sys-usb dom0:00_14.0 See Github, Qubes issues #3205 and #3262 I'll never move the USB controller away from sys-usb again. Especially with challenge-response Yubikey in the machine ... -- You received this message because you are subscribed to the Google Groups "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/LxJ5PZL--3-2%40tuta.io.
[qubes-users] Re: Recommended laptop?
On Wednesday, December 25, 2019 at 10:09:24 PM UTC-6, brend...@gmail.com wrote: > > My own longterm Qubes primary has been a used W520 quad core with four 8GB > DIMMs for 32GB of RAM. Not bad for 2012 era laptop. [Avoid the dual core > versions: they only have two memory slots and can only support 16GB Max.] > > > B What BIOS are you using? I have a W520 coming in soon that I plan to use for Qubes. I've been using a G505s for a while but it isn't terribly well built and suspend/resume doesn't work on it. -BS -- You received this message because you are subscribed to the Google Groups "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/fdaaeef1-530a-4ca2-9cfc-c9dc8ebe1e0d%40googlegroups.com.
Re: [qubes-users] Is it plausible to use Debian template with sys-XXX VM?
trueriver: > I tried simply changing the template in qube settings, and some things worked > and others didn't. Notably sys-usb stops recognising any USB device, and > sys-net doesn't recognise WiFi. > > Is this a stupid idea, or are there straightforward ways to make it work? > > Ideally I'd like to stop using fedora template altogether, to get one less > thing to be backed up. However it's not important enough to put a lot of work > into making that happen. > Normally that's all you should have to do. Wifi cards sometimes need their driver package installed in the corresponding template. Not sure about your USB controller; haven't heard of needing drivers for those. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "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/dcec0b0d-2f61-85c4-5d15-77071f89f00e%40danwin1210.me.
Re: [qubes-users] Using Debian 10 template with D 9 VM; Q 4.0.1
trueriver: > Hi, I am upgrading from Qubes 4.0 to 4.0.1 anyway. I notice that there is now > a Debian 10 template and there are clear instructions for how to install, but > that Q 4.0.1 still uses Debian 9. > > > Am I right in thinking that the template from the newer version of Debian > should just work with VMs created with the older template? Debian is usually pretty reliable for that. > Are there any pitfalls I should know about before using Debian 10 template > with my VMs that were created with Debian 9 template? > > While I have to do the reinstall anyway for other reasons it seems handy to > go to the newer Debian, so long as it's reasonably straightforward. > You might consider going with R4.0.2rc3, which includes Debian 10 out of the box. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "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/81529b3d-4b66-b02c-6c5d-ba355dd457cb%40danwin1210.me.
Re: [qubes-users] Lost USB-Controller, lost tty-credentials, emergency
mas...@tuta.io: > Now I have to solve "unable to reset PCI device, 00:14.0: no FLR, PM reset > or bus reset available ...", but there's a thread on Github. Enable the "no strict reset" option for the PCI device that is causing problems via Qube Settings on the problem VM, then Devices tab, then large button at the bottom. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "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/45c883e5-01d1-1078-02c5-13c49eaf001f%40danwin1210.me.
Re: [qubes-users] Backup issues with external USB and ESATA devices
Charles Peters: > In late September I backed up qubes using a new WD Elements external > drive. At the time I don't think I had sys-usb installed. Yesterday when > I tried to do the backups I was unable to mount the WD Elements drive, > another USB connected Toshiba hard drive, or the Toshiba drive connected > with ESATA. I can mount USB flash drives, but with a vfat filesystem it > will not support the large multi GB backup file. > > Booting Debian with the ESATA connected Toshiba drive I can mount the WD > Elements drive without any problems. However I haven't figured out how to > mount the SSD with Qubes OS lvm to copy the backup files. > > Does anyone have any suggestions? Pass the external partition through to a VM with qvm-block, then mount it from inside the VM. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "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/aab9ab93-d1a0-2d00-c576-a58886123409%40danwin1210.me.
Re: [qubes-users] Hyperthreading is turned off by Qubes
>> I'm now wondering if there is a Xen >> setting to force Xen to allocate both virtual cores in the same physical >> core together? > I don't know but I wouldn't expect one to appear in an old xen. > Given R4.0 is 4.8 so if such feature is there, most likely that's not available until some future Qubes version. Turns out that's exactly so. The Xen wizards were working on it August 2019, and it's now in a testing or unstable build, so it will be a while before it gets into a stable Xen release, and then longer till Qubes adopts it. https://patchwork.kernel.org/cover/11086677/ The parameter is sched-gran=core (or socket or cpu) with the default bring CPU. The version of Xen currently used by Qubes 4.0.1 accepts the parameter without giving an error, but also without complying. -- You received this message because you are subscribed to the Google Groups "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/1f234d42-c9ca-4b23-8e2f-2cec1ee28687%40googlegroups.com.
[qubes-users] Qubes 4.0.1 - no grub2 menu during boot
Booting into recent install of Qubes 4.0.1 I have just realised I have not been setting the grub2 menu: it goes right in to loading Xen and then I see the four Tuxes. Is this an EFI thing, or a new feature of this version? (I ask because as well as changing Qubes versions I've finally got EFI booting instead of legacy) Also, I can't find grub.cfg anywhere on the disk: is there one? Where? Apols if I've missed a relevant document, I did look, and if so please post the link -- You received this message because you are subscribed to the Google Groups "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/161ffebf-00a1-41e4-b285-7fd4aa83557d%40googlegroups.com.
[qubes-users] Is it plausible to use Debian template with sys-XXX VM?
I tried simply changing the template in qube settings, and some things worked and others didn't. Notably sys-usb stops recognising any USB device, and sys-net doesn't recognise WiFi. Is this a stupid idea, or are there straightforward ways to make it work? Ideally I'd like to stop using fedora template altogether, to get one less thing to be backed up. However it's not important enough to put a lot of work into making that happen. -- You received this message because you are subscribed to the Google Groups "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/766dee3f-b917-42d3-a8ce-0a5fe942563c%40googlegroups.com.
[qubes-users] Using Debian 10 template with D 9 VM; Q 4.0.1
Hi, I am upgrading from Qubes 4.0 to 4.0.1 anyway. I notice that there is now a Debian 10 template and there are clear instructions for how to install, but that Q 4.0.1 still uses Debian 9. Am I right in thinking that the template from the newer version of Debian should just work with VMs created with the older template? Are there any pitfalls I should know about before using Debian 10 template with my VMs that were created with Debian 9 template? While I have to do the reinstall anyway for other reasons it seems handy to go to the newer Debian, so long as it's reasonably straightforward. -- You received this message because you are subscribed to the Google Groups "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/b8ad40b2-0aa4-47b2-9292-0c7ed9faf9a5%40googlegroups.com.
Re: [qubes-users] Hyperthreading is turned off by Qubes
Thanks Ilpo. I had half guessed the same. -- You received this message because you are subscribed to the Google Groups "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/89c6e274-da6a-4afe-a4b5-dae3632db4e9%40googlegroups.com.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rulesfor PCI passthru
On Sun, 29 Dec 2019, '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. > > > 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 > 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. I got an impression from somewhere, that AMD platform itself should support really good IOMMU grouping but that there's then a BIOS option to enable it (like "IOMMU: auto/enabled", where "auto" got you the default conflicting groups; I read two lspcis from the same HW somewhere with very different PCI dev layouting where the other was with the "enabled" setting but I guess it was a desktop MB). I suspect, however, laptop vendors may not be putting that much effort on including such options. -- i. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.1912291951080.10565%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Hyperthreading is turned off by Qubes
On Sun, 29 Dec 2019, trueriver wrote: > > HT is turned off intentionally for security purposes. Some of the > Intel CPU vulnerabilities demonstrated within the recent years depend on > the side channels within the resources shared by the threads of the same > physical core. Thus it's advisable to not enable it > > Thanks for that explanation - yes that's sensible. > > With the option set to allow HT, I'm now wondering if there is a Xen > setting to force Xen to allocate both virtual cores in the same physical > core together? I don't know but I wouldn't expect one to appear in an old xen. Given R4.0 is 4.8 so if such feature is there, most likely that's not available until some future Qubes version. > That would mean you'd always get an even number of virtual cores, they > would always be "core buddies", and this it's only that VMs own code > that can attempt those exploits. That would give almost the same level > of security but allow the extra performance. > > Or am I missing some nasty potential exploit? -- i. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.1912291947290.10565%40whs-18.cs.helsinki.fi.
Re: [qubes-users] Hyperthreading is turned off by Qubes
> HT is turned off intentionally for security purposes. Some of the Intel CPU vulnerabilities demonstrated within the recent years depend on the side channels within the resources shared by the threads of the same physical core. Thus it's advisable to not enable it Thanks for that explanation - yes that's sensible. With the option set to allow HT, I'm now wondering if there is a Xen setting to force Xen to allocate both virtual cores in the same physical core together? That would mean you'd always get an even number of virtual cores, they would always be "core buddies", and this it's only that VMs own code that can attempt those exploits. That would give almost the same level of security but allow the extra performance. Or am I missing some nasty potential exploit? -- You received this message because you are subscribed to the Google Groups "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/a463b6a5-4e41-4b9b-82be-78275deac5c7%40googlegroups.com.
Re: [qubes-users] Lost USB-Controller, lost tty-credentials, emergency
Dec 28, 2019, 19:31 by claud...@disroot.org: > 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. > Success! Thank you SO much for the most important hint, Claudia: Losing the USB controller in Qubes has nothing to do with booting the laptop from USB. Of course. After creating the third Live USB Stick (Tails) I
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
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. > 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 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. > This is a laptop, so I can't add any cards. This didn't used to be mutually exclusive. Thanks, Apple. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "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/42654600-e501-aad9-f15b-a394d38b262f%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
tetrahedra via qubes-users: > On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users wrote: >> Unfortunately I need to get work done so have to reboot to "just make it >> go away" but I am still interested in troubleshooting ideas (for when it >> happens next). Investigate xl top more thoroughly. You can identify offending VMs with it, and see if all your RAM is in use which triggers swapping to (slow) disk. > One thing I noticed on reboot -- the initial round of stop jobs (when > shutting down the system, things like unmounting LUKS volumes) all timed > out. Not sure if related. > Don't think it's related. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "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/95de61fb-889c-1398-7253-87498801e439%40danwin1210.me.
[qubes-users] Qubes Structure
Hi! Sorry for the bad question structure, don't know how to write it properly. I've seen some examples of how people setup their system and the most paranoid ones create separate standalone vm for each application and firewall that allows only this application to connect to the internet. Currently, I have 4 template vms - debian 10 with all programs I use installed in it, fedora 30 minimal for netvms, and whonix templates. All my vms that I use on day to day basis are made with debian template. After seeing all those setups I feel that my system is an open garden for hackers and they can do whatever they want, and I will find it out only after I get completely hacked. So, my question is how to setup your system for maximum security? Is there any guidelines on how to do so? I understand that it may be a silly question because it mostly depends on from whom I protect myself, but let's imagine I need to protect from everyone. I would appretiate any advice on how to improve my system's security or where to look for the information. Thanks for reading and have a nice day! Some examples of people's setups: 1. https://www.reddit.com/r/Qubes/comments/eevf02/whats_your_user_setup_i_love_reading_about_how/fbxybtk/ 2. https://old.reddit.com/r/privacytoolsIO/comments/dq8haz/iyho_firefox_vs_tor_vs_brave_for_browser_selfhost/f6192p4/ 3. https://github.com/Qubes-Community/Contents/tree/master/docs/user-setups -- You received this message because you are subscribed to the Google Groups "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/16f5115f7ef.100d89f5d36957.8467996131458729295%40privacy.com.co.
