[qubes-users] Xentop: MEM greater than MAXMEM

[Brendan Hoar]

Hi folks,

Occasionally I will have a VM lock up (UI remains on screen but windows Dow
not respond) and notice that the MEM size in xentop is greater than the
MAXMEM value in xentop, while at least one associated cpu is spinning
(xentop shows state as perpetually r aka running).

Memory ballooning is enabled.

Swap is available in the vm and not really being used much.

First…what is the definition of MAXMEM vs. MEM in xentop (e.g. is MAXMEM a
limit or a high water mark)?

Second, depending on the answer to the above, I may ask…how can MEM be
larger than MAXMEM?

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/CAOajFec1qpAoK%2BEBSXXWNcWXdh%3DJdTD%3DEbxMQr%2BttpX4_D%3DG_w%40mail.gmail.com.

Re: [qubes-users] Re: External Fully Encrypted SSD Drive. What do you think?

[brendan . hoar]

On Wednesday, July 29, 2020 at 2:33:29 AM UTC-4, Qubes wrote:
>
> On 7/29/20 1:56 AM, ludwig...@gmail.com wrote: 
> > *What if it saves a spare set of encryption keys somewhere in its flash 
> for 
> > the "lawful investigator" to find?* 
>  > 
> I am not aware of any proof to support this line of thinking. 
>

My position: if you have critical secrets, then your solution should be 
combining belt and suspenders, that is, you should apply layers of 
encryption with different keys and passwords.

1. First if your main drive supports it, enable hardware encryption. Even 
if you don't trust the device manufacturer (perhaps they, as posited aove 
"save a spare set of encryption keys somewhere in its flash"*), it is still 
an additional layer of protection. In particular, the password/pin should 
be different than password/pin used for LUKS in section #2 for separation 
of trust. This can also provide some boot drive tamper protection by at 
least a subset of attackers.
  alternate 1a. boot qubes off of a a SED SATA/NVME drive: implement using 
something like sedutil or even TCP Opal Class 0 encryption if your BIOS 
supports it (Class 0 leverages the TCG Opal SED engine using an ATA 
Password with some bits of security lost due to password filtering 
depending upon BIOS implementation) and you semi-trust the drive 
manufacturer. 
  alternate 1b. boot qubes off of a USB drive with a hardware encryption 
bridge/enclosure and a pinpad password (very long is better, if supported). 
Again, you must semi-trust the manufacturer of the encryption engine, of 
course.

2. Set up qubes with a LUKS layer and a password (pretty much, the standard 
install) on the drive you have configured above. You must semi-trust the 
Qubes, LUKS and linux developers, of course (open source allows audit, so 
either do it yourself or...hope/verify someone else did). Password should 
be different than the hardware device password in #1 for separation of 
trust.

Above are the basic belt and suspenders. 

Section #1 utilizes the hardware encryption you may already have and gives 
you a bonus of some additional protection against modification of the boot 
data on the drive. The TCG Opal Class 0 approach should not interfere with 
installation of AEM. Standard TCG Opal via sedutil requires additional 
custom work to support AEM.

Section #2 gives you the more trusted layer of software encryption.

Now for some additional soap-box comments, generally under the heading of 
Qubes currently != anti-forensics: 

1. Disposable VMs do not promise any anti-forensics properties if your 
system is up and running (that is, the LUKS volume is mounted). Disposable 
VMs have a primary purpose which is* not* to "forget" information, but 
rather to prevent attacks inside a VM from being permanent (prevent 
foothold) and partition your data so that attacks within the disposable VMs 
cannot accessing your data. Typically**, the data used in a disposable VM 
remains on the storage device even after the VM is shutdown until that 
space is needed again to store something else.

2. Attaching devices to dom0 puts dom0 at risk. Even unmounted devices can 
be unintentionally automatically mounted or at least partition/volume 
scanned when running various toolkit-based executables such as thunar 
(xfce's file explorer equivalent) or anything else that invokes the xfce 
windowing toolkit components or similar in dom0.

3. Attaching devices to dom0 can pollute dom0 memory/storage with content 
from that device. For the above reasons, among others.

4. Fragments of VM sessions can end up in the dom0 or GUIVM user folder 
and/or system/application logs. E.g. one can find the window titles of domU 
VM windows (including disposable VMs or even VMs stored in secondary pools) 
stored in the dom0 main user's dot (hidden) directories.

5. Until very recent changes to the qubes thin pool driver (available in 
4.1 only?), disposable VM's volatile volumes on LVM were always being 
stored in the primary pool. EVEN if the disposable VM and the disposable VM 
templates were stored in a secondary pool on a separately encrypted device. 
This behavior was surprising to many and I consider it a defect.

Hope this is helpful,
Brendan

* Most SED/TCG OPAL drives can be fully rekeyed using one or more of the 
following ATA SANITIZE CRYPTO EXT, ATA SECURE ERASE ENHANCED, or a PSID 
REVERT. Some support all three invocations, some a subset. Some 
manufacturers go out of their way to *only* rekey (and not erase) when 
invoking the first two, so you can check to see your data is irrevocably 
scrambled after invocation. Ok, maybe you don't trust the drive 
manufacturer to not log all keys in the clear for entities they have 
relations with? Fine. But at least get in the practice of rekeying the 
drive a couple times before putting data on it that way if they're only 
storing the factory key, well...(takes off tin foil hat).

** Note that the Qubes thin volume storage driver will attempt to 

[qubes-users] Re: HCL - Lenovo ThinkPad W520

[brendan . hoar]

On Sunday, July 12, 2020 at 2:51:25 PM UTC-4, pok...@gmail.com wrote:
>
> I have the W520 with CPU type i7-2630QM and Nvidia Quadro 2000M (Lenovo 
> 4284-E78).
>
> https://ark.intel.com/content/www/us/en/ark/compare.html?productIds=52219,53474
>
> This laptop version doesnt have VT-d, but I completed the installation of 
> Qubes R4.0.3 even though there was a warning about this. 
> When booting the system however, the laptop screen goes black and I cant 
> see what's going on. 
>
> Any suggestions?
>
>
For Qubes 4.0 on the W520, I configure the BIOS to use the Integrated 
graphics only, disabling the NVIDIA GPU entirely.

That being said, it'd be worth it to switch to a W520 with a higher feature 
level CPU that does support vt-d.

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/37b69690-3b37-4d6e-9eb6-976d1d196de0o%40googlegroups.com.

Re: [qubes-users] Accessing files on a different SSD on the same laptop...

[brendan . hoar]

On Sunday, June 7, 2020 at 12:29:28 PM UTC-4, Andrew Sullivan wrote:
...

On the fedora-based VMs, the tool `gnome-disks` is a gui way of manually 
mounting filesystems.

[I tend to forget the order of operations and/or flags for things like 
mount (which is the mountpoint? which is the source device?) so either 
script it or use GUI tools when my brain is a bit fuzzy.]

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/230048f2-5bb9-469b-8e0c-153285ad37e9o%40googlegroups.com.

Re: [qubes-users] Multiple X sessions in Dom0?

[brendan . hoar]

On Friday, May 29, 2020 at 6:15:31 AM UTC-4, donoban wrote:
>
> On 2020-05-29 02:34, brend...@gmail.com wrote: 
> > Can Qubes support multiple X sessions in dom0? 
> Or do you mean multiple X sessions with the same user? 
>
 
Yes, exactly.

On Friday, May 29, 2020 at 6:23:19 AM UTC-4, Frédéric Pierret wrote:

> On 2020-05-29 02:34, brend...@gmail.com  wrote: 
> > Can Qubes support multiple X sessions in dom0? 
> I guess you want to see VMs in separate X sessions. Without speaking of 
> user management, yes it can but currently gui-daemon is running on 
> DISPLAY=:0 waiting for all VM start/shutdown and starting a proper server 
> for them. In your case of having multiple DISPLAY, that would mean to adapt 
> the automatic start of each deamon per VM. 
>
> I would say, wait or try the (undocumented) GuiVM implementation in R4.1, 
> that would ease such use-case/management.. 
>
 
That sounds reasonable. As it is, without further adjustment, I cannot get 
a second X server to start up correctly under 4.0.

I'm using window manager workspaces now to mentally separate out different 
work-streams across a dozen running VMs sometimes. 

However, it might be nicer to have a stronger organizational (and mental) 
partition and multiple X servers with the UI of running VMs associated with 
different X servers would be nice. 

Perhaps multiple GUIVMs could serve that purpose?

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/5c4abbdd-f9c0-40fa-a39c-13f05d36836d%40googlegroups.com.

[qubes-users] Multiple X sessions in Dom0?

[brendan . hoar]

Can Qubes support multiple X sessions in dom0? 

e.g. default session on primary terminal (via ctrl-alt-f1), then start 
another session on the third pty (ctrl-alt-f3) after logging in as the 
primary qubes user in dom0?

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/0a1e00b8-fd1f-4e09-85b7-058825e3176a%40googlegroups.com.

[qubes-users] Re: Next update of Qubes?

[brendan . hoar]

On Saturday, May 23, 2020 at 11:32:31 AM UTC-4, Catacombs wrote:
>
> I see that Qubes does not announce planned new releases of Qubes, or state 
> what should trigger an update. 
>
> Just seems like it would be so much easier if we had an entire new version 
> of Qubes, which I could install.  At the same time, I am making sure any 
> Malware I might have picked up gets clobbered.   And leaving me with the 
> problem of re installing all of my personal files, my own personal fixes to 
> Template VMs.  Instead many are learning Salt.  
>
> This question also comes back to making Qubes easy for Human Rights 
> Activists and Journalists.   I do not think those two groups will go to the 
> trouble of learning how to install Salt.  I agree that since most of the 
> changes for Human Rights Activists/Journalists are made inside Template VMs 
> of (now usually Debian, or Fedora), that the folks who create Qubes for us, 
> should not concern themselves with those things.  
>
>  
Following along the work in all of the github repos and in qubes-issues, I 
would say definitely this calendar year.

4.1 is being tested (major changes: dom0 moving from fedora 26 to fedora 32 
; xen moving from 4.8 to 4.13 or potentially 4.14, depending on timing.).

Personally, I'm waiting for "finalization" of the work on the installer 
disk layout changes which move dom0 storage into a dedicated pool, with all 
the VMs in a separate pool (see here: 
https://github.com/QubesOS/qubes-anaconda-addon/pull/7 ). 

Once that occurs, I'll try another 4.1 testing ISO from 
https://openqa.qubes-os.org/  [I really only want to dive back into 4.1 
testing when I know it's close to or at the final disk layout and likely to 
end up in a similar state as if I'd installed once 4.1 is released.]

In addition ITL/Qubes is working with the Freedom of the Press foundation 
on some potential changes to make Qubes usage more straightforward 
(primarily UX) for all but also to support journalists / activists (that, 
in addition to FOTPF's fork that adds Secure Drop for that audience). See 
here: 
https://github.com/freedomofpress/securedrop-ux/wiki/Qubes-Journalist-Workstation
 
and follow along in the qubes-issues github repository for the UX work.

My mental bandwidth (WF a very small H w/ partner and toddler) isn't 
available for getting up to speed to formalize configs with salt at the 
moment, esp. as Qubes is more of a hobby for me. I just keep notes about 
what I need to "sudo dnf install" and/or "sudo apt-get install" in various 
templates should I need to upgrade, and then throw all 
notes/downloads/scripts into a vault VM that I backup from time to time. 
But I only support myself.

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/b09e1c0a-4622-4d9d-9c85-fb14e7efb8a0%40googlegroups.com.

Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed

[brendan . hoar]

On Monday, May 18, 2020 at 6:01:13 PM UTC-4, TheGardner wrote:
>
> understood. 
> Guess I have to do some backups, which I have to move to my NAS. The new 
> machine will take two months longer. Have to come out with the current 
> space until then.
>
>
Is it possible that you haven't invoked the --clean parameter (sudo 
qubes-dom0-update --clean) to ensure the local cache in your updatedvm 
(sys-firewall) is cleared before the next download?

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/b533ff86-a9c8-48fc-be56-b24097481ebe%40googlegroups.com.

[qubes-users] Re: HCL - Dell Latitude E5470 + Docking Station

[brendan . hoar]

On Monday, May 11, 2020 at 6:13:21 PM UTC-4, Rafael Reis wrote:

> My only concern right now is the decisions for the GUI of Qubes 4.1. I 
> wonder if the separation of the GUI and dom0 would result in 
> incompatibility with E5470 or even a big decrease in performance. This 
> thing is perfect for Qubes if your threat model isn't government agencies 
> high.
>

Following the developer discussion, my understanding is that for Qubes 4.1, 
GUI/dom0 separation will be an optional feature and not the default. 

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/ee3bd705-b849-4924-88fb-871db3d69cb6%40googlegroups.com.

[qubes-users] Re: Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing

[brendan . hoar]

On Friday, May 1, 2020 at 12:39:54 AM UTC-4, seshu wrote:
>
> One question that just occured to me about upgrading the template VM's. 
> Many of the comments and posts in this forum are assuming Qubes is 
> installed on a laptop. I have it installed on a desktop, and my keyboard / 
> mouse uses sys-usb. I need to have this appVM running to use the peripheral 
> obviously. But, since the appVM is running, I can't update the templateVM?
>
> Is their any workaround, or do I need to go get a ps/2 keyboard and then 
> turn off sys-usb, update the template and then restart it? Is that the only 
> option I have? IT seems like there could be a better way?
>

If you have a desktop, you probably have at least one pcie slot available 
for an additional USB controller, yes? Some laptops already have multiple 
pci controllers for usb, and some have expresscard slots that can accept an 
additional usb controller. This works for all these cases:

Clone the template.
Do the update in the clone of the template.
If successful continue, otherwise stop.
Create a sys-usb2 based on the cloned/updated template.
Attach your secondary USB controller to it.
Make sure a backup keyboard/mouse is properly seen in that controller.

If that works:
-Set up your system autostart both sys-usb (using primary usb) and sys-usb2 
(using secondary usb).
-Set up your system to allow keyboard/mouse from both sys-usb and sys-usb2 
(see qubes documentation)

If that doesn't work:
-Stop

Set your sys-usb template to the updated clone, so both sys-usb (with 
primary usb controller) and sys-usb2 (with secondar usb controller) can 
provide keyboard and mouse to the system, including LUKS password.

Reboot.

Once you are sure everything works, you can get rid of your secondary 
sys-usb2 if you want.

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/de10c671-78e8-42ca-91b5-e59c36111b5e%40googlegroups.com.

[qubes-users] Blanking memory for security?

[brendan . hoar]

Xen hypervisor overwrites memory before allocating it to a domU VM.

-- 
You received this message because you are subscribed to the Google Groups 
"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/eb4184c3-1469-4872-b656-6f59f35c7614%40googlegroups.com.

Re: [qubes-users] KDE Plasma in dom0 under R4.0.3

[brendan . hoar]

On Saturday, April 11, 2020 at 7:10:18 PM UTC, Sven Semmler wrote:
>
> On Sat, Apr 11, 2020 at 02:48:17PM -0400, Chris Laprise wrote: 
> > I've never had a problem with KDE in dom0 as long as the display manager 
> is 
> > switched to sddm and BIOS is set to integrated graphics. "Discrete 
> graphics" 
> > usually means Nvidia, which is poorly supported in open source operating 
> > systems. 
>
> Funny enough, motivated by your comment I went and switched back to 
> "hybrid" (aka integrated) graphics ... and all my issues came back! 
>
> So while I am sure your statement is correct in general, on my 
> particular setup switching to the discrete graphics makes everything 
> work. Every rule has an exception I guess. 
>

Hybrid graphics routing for nvidia optimus has changed over the years. 

On older laptop models, one could select among integrated, hybrid and 
discrete. For many of us, selecting integrated graphics was the most stable 
option.

On more recent optimus laptops, integrated is no longer an option, you can 
only select between hybrid and discrete. I believe this limitation is due 
to how the signal routing now requires some level of firmware support in 
the discrete chipset to get video out. 

In any case, hybrid has always (nearly?) impossible to get working under 
Xen/Qubes...so the next best option has been making discrete work.

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/ea9af9e6-3584-4779-b0b2-1399c19b71d8%40googlegroups.com.

Re: Antw: [EXT] [qubes-users] probable lvm thin_pool exhaustion

[brendan . hoar]

On Wednesday, March 11, 2020 at 1:34:17 AM UTC, maiski wrote:
>
>
> Quoting brend...@gmail.com : 
> > 
> > Qubes 4.1 (in development) has added a warning (in addition to the 
> current 
> > lvm space usage warning) for lvm metadata usage above a threshold. 4.0 
> > doesn't have the metadata nearing full warning, and that's what tends to 
> > cause these types of thinpool issues. 
> > 
> > In addition to the warning, Qubes 4.1 is also doubling (vs. the lvm 
> default 
> > value) the amount of space set aside for lvm thinpool metadata which 
> will 
> > substantially reduce the chances of ever hitting this issue under 4.1. 
> > 
> > Brendan 
> > 
> > PS - above is not helpful for recovering this machine, of course. 
> However, 
> > recovery from this can be very difficult and even after recovery not 
> > guaranteed to recover all the data. The Qubes devs are aware of this and 
> > very much want to avoid these issues in the next release. 
>
> Hm, yes, this does not help:/ 
> What about running fstrim on the ssd and try booting again? 
> @brendan: I've seen that you had some thoughts about lvm in some postings, 
> so would you care to elaborate/brainstorm on the situation i   
> described, you know, every input is valuable right now :) 



 TBH, I wouldn't know what to do. Ran into a similar problem with 4.0 a 
long while back and just reinstalled because it seemed insurmountable at 
the time.

I've been reducing my main pool usage and manually monitoring the metadata 
to avoid the situation with my current install, waiting for 4.1 to become 
stable before moving to it.

Chris Laprise (tasket) would be a better resource, if he's willing to jump 
in.

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/0c13f771-7bdc-4246-8459-216cb5dabbe2%40googlegroups.com.

Re: Antw: [EXT] [qubes-users] probable lvm thin_pool exhaustion

[brendan . hoar]

On Tuesday, March 10, 2020 at 11:49:58 AM UTC, maiski wrote:
>
> Quoting Ulrich Windl >: 
> > For some reason I have a "watch -n30 lvs" running in a big terminal.   
> > On one of the op lines I see the usage of the thin pool. Of course   
> > this only helps before the problem... 
> > 
> > But I thought some app is monitoring the VG; wasn't there some space   
> > warning before the actual problem? 
>
> Of course there was. But atm of failure there was none visible, which   
> does not excuse that beforehand I had created 3 new and downloaded a   
> minimal template for fun, so... why can it be simple, when it can be   
> complicated 
>


Qubes 4.1 (in development) has added a warning (in addition to the current 
lvm space usage warning) for lvm metadata usage above a threshold. 4.0 
doesn't have the metadata nearing full warning, and that's what tends to 
cause these types of thinpool issues.

In addition to the warning, Qubes 4.1 is also doubling (vs. the lvm default 
value) the amount of space set aside for lvm thinpool metadata which will 
substantially reduce the chances of ever hitting this issue under 4.1.

Brendan

PS - above is not helpful for recovering this machine, of course. However, 
recovery from this can be very difficult and even after recovery not 
guaranteed to recover all the data. The Qubes devs are aware of this and 
very much want to avoid these issues in the next release.

-- 
You received this message because you are subscribed to the Google Groups 
"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/54c72ea0-be0b-4414-bc01-7fee409b7c73%40googlegroups.com.

[qubes-users] Re: SSD and safety.

[brendan . hoar]

The diskashur and similar projects will come under the same scrutiny as SED 
devices’ built-in TCG Opal: that the encryption layer is closed source and not 
publicly auditable (unlike LUKS w/dm-crypt under Linux which is auditable).

The summary of my position is: use the hw encryption features available, but 
also use open-source software encryption on top.  Belts and suspenders.

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/439e6634-11de-4d84-aabd-a0c89b06313a%40googlegroups.com.

Re: [qubes-users] SSD and safety.

[brendan . hoar]

PS - don't experiment with erasing drives on your daily driver. the drive 
is going to do what you asked it to do, no matter, say, whether you booted 
on that drive or not. POOF!

-- 
You received this message because you are subscribed to the Google Groups 
"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/184f53fc-996c-4658-8cb5-7092201c16a8%40googlegroups.com.

Re: [qubes-users] SSD and safety.

[brendan . hoar]

On Wednesday, February 26, 2020 at 3:37:27 PM UTC, Steve Coleman wrote:
>
> On 2/26/20, ggg...@gmail.com  > 
> wrote: 
>
> > I discovered there is no program to clear an SSD. 
>
> If you are using an Opal 2 compliant SSD and had created an encrypted 
> range before formatting your partition then all that data disappears 
> instantly when you reset the SSD. The one requirement is the SSD drive 
> must be functional in oder to reset it, and it won't matter much if 
> there are unuseable blocks or file corruption as all the bits on the 
> drive, good or bad, get flipped all at once. 
>
... 

> On the label of the Opal 2 SSD drive there would be a long hex PSID 
> number printed on it, and if you supply that # to the sedutil-cli 
> command: 
>
> # sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID MYPSID /dev/sdc 
>
> then everything previously stored on that drive becomes unrecoverable 

 
[Many users of Qubes aren't too keen on relying on the 
black-box/closed-source hardware encryption that comes on SED SSDs - can 
they trust it? They can't review the code/implementation. There have been 
in-depth analysis showing issues with both design as well as 
implementations with many devices. Their points are valid. However, I don't 
want to get into a long digression on the pros/cons.]

In addition to what Steve said about ranges or PSID revert, most tcg opal 
devices support utilizing the same hardware crypto engine for "CLASS 0" 
encryption, which allows use of the ATA PASSWORD as an alternate unlocking 
scheme. This generally allows suspend if, say, your laptop supports the ATA 
PASSWORD method. Flipside is that generally the complexity of the password 
data sent to the drive is < 90 bits no matter what you choose. Sometimes 
substantially less (depends upon BIOS).

I don't recommend relying on that for all of your security. If you use it, 
use LUKS on top of it as well. There's no performance loss, it's 
transparent (the drive was always doing it anyway, you just chose to lock 
it).

My point, however, is that the ATA Password support under "TCG OPAL CLASS 
0" comes with a nice side-benefit

Generally, when utilizing TCG OPAL CLASS 0, when you send an ATA SECURE 
ERASE ENHANCED request to the drive, it actually simply rekeys the hardware 
crypto engine of the drive.

So, if you have non-zero data in a block, then use the ATA SECURE ERASE 
ENHANCED command and then read the block, it will be scrambled. Send the 
command again, it's scrambled a different way.

So, other than throwing the device into the Sun, my recommendation is 
always to:

1. Sample (non-zero) data (random block list) on the device.
2. Execute ATA SECURE ERASE ENHANCED.
3. Verify sampled data (same block list) is all scrambled.
4. Execute ATA SECURE ERASE ENHANCED again.
5. Verify sampled data (same block list) is all scrambled again.
6. TRIM the entire drive.
7. Verify sampled data (same block list) is all now zero'd data.
8. Execute ATA SCURE ERASE *NORMAL* (might erase additional data beyond 
user-readable data, depending upon manufacturer).

BTW, if ATA SECURE ERASE ENHANCED does not scramble the data, but the drive 
supports the ATA SANITIZE command, then use ATA SANITIZE CRYPTO instead, 
should do the same thing.

Brendan

PS - paranoid people might say "well, maybe the drive is keeping a list of 
all keys, hey they are small". Possible. Maybe a flash-thrashing "fill 
entire drive full of random data" step will help a bit, assuming you're 
worried about user data left behind and not targeted exfiltration into 
non-user-accesible flash by a nation-state agency, etc.

-- 
You received this message because you are subscribed to the Google Groups 
"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/faff5ede-8399-4977-848f-54a3dc35af13%40googlegroups.com.

[qubes-users] Re: Relative comparison of Qubes OS, and its multiple VM's versus Boxes.

[brendan . hoar]

On Wednesday, February 26, 2020 at 12:18:48 PM UTC, ggg...@gmail.com wrote:
>
> Boxes being the Sandboxing software available in Linux.  It is my hunch, 
> that the VM's are taking advantage of some hardware feature that insulates 
> them that might be a security hole for Boxes.  I dunno?
>

Background: Boxes is simply a nice front end for KVM and QEMU, which is 
what most Linux virtualization solutions utilize.

Reasons that Qubes project initially chose Xen over KVM+QEMU (probably 
better explained on the Qubes website):
1. The hypervisor code baseis substantially smaller in the Xen case. 
Smaller generally means less security issues.
2. Xen came with better suited vt-d/IOMMU support at the time.
3. When parts of qemu are needed for certain virtualization scenarios, Xen 
supports sandboxing qemu into stub domains.
4. QEMU has been historically problematic when it comes to security issues, 
at least relative to Xen or even Xen w/ qemu in a stub domain.
 

> Also, as I have not gotten a computer to run Qubes OS, I notice that the 
> App VM seem to be loading a full featured version of a Linux OS.  I am 
> guessing that in reality you guys are using a smallish Limited version of a 
> Linux Distro.   
>

Generally standard fedora and standard debian come as VM templates under 
Qubes, yes. With caveats, Qubes also provides slimmer versions of the 
template distros as well as optional downloads.
 

> I was expecting to see some advice about how to uninstall the module that 
> runs the camera, and the microphone.   I know I rarely use them, so it 
> would seem like a good idea.   OR I guess, it is left to the individual 
> with the individual distro.  
>

Assuming your camera is USB based (generally the case, even for internal 
camera devices).

Generally, the default installation:
1. Hides all USB devices from dom0, making them unusable.
2. Puts all USB devices into device sandbox called sys-usb (this part is 
optional, but useful if you want USB devices to work).
 
Generally, you can use command line or the devices widget to assign the 
devices, including the microphone, to a VM if you choose (some limitations 
on usbip support being broken for certain device types).

I was looking for a list of;  If you want to be secure,   "Never do 
> this."Another check list, like a pilot uses before taking off, that is 
> what the proper procedure is for some of the types of things one might 
> routinely do with Qubes OS.  
>

This would vary by threat model. Without a threat model, a general 
checklist would be impossible to provide.
 

> About my hardware deficiency, wait for another month for me to be able to 
> upgrade RAM, and maybe buy a Programming device.   So please be patient 
> with questions that would be obvious if I was running Qubes OS already.
>

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/ef997e2a-b27c-43fd-ae2b-21c3317f3173%40googlegroups.com.

Re: [qubes-users] Creating snapshot

[Brendan Hoar]

On Tue, Feb 18, 2020 at 8:41 PM Thierry Laurion - Insurgo Technologies
Libres / Open Technologies  wrote:

> I'm talking on top of my head but snapshots are supposed to be taken
> automatically, with 2 reverts possible, by default.


This may be up to interpretation but...

I assumed the original question w/r/t VM snapshots (a thing under VMWare
and other VMMs) and not storage volume snapshots.

Cloning a VM is more akin to VMWare snapshots and doesn’t require tracking
auto-expiration of numbered lvm snapshots.

>

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAOajFec7FbC6W1uzP-%3DZfcaP3r6Ns_L9LvkRGxqwLTF7Ssu8aA%40mail.gmail.com.

[qubes-users] Creating snapshot

[brendan . hoar]

Assuming a standard qubes 4.0.x install, just clone the VM each time you are 
making risky changes...before each change of course.*

The use of lvm thin pool makes clones essentially use zero storage other that 
the bits where they diverge from the original VM, where copy on write preserves 
the differences.

Brendan

* ok, technically...make the clone anytime *before* shutting down the vm after 
the risky change...but purposely cutting it that close has risks.

-- 
You received this message because you are subscribed to the Google Groups 
"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/8f1c91d3-c6ae-4822-9e0c-5daa55d5c29d%40googlegroups.com.

[qubes-users] Using secondary storage

[brendan . hoar]

I see reference to both /dev/sdc and /dev/sbc in your post. Which is 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/36d150f9-ad00-4cfb-9643-2f713da3f108%40googlegroups.com.

Re: [qubes-users] Re: Upgrade to 16 GB RAM for an X230

[brendan . hoar]

Two inter-related arguments for switching to Coreboot so that one can replace 
an Intel wireless card with another card:

1. Lenovo BIOS generally has a small whitelist of WiFi cards that work and 
block all others.

2. Presumably the reason for this whitelist is support for AMT “out of band and 
silent” organizational inventory, configuration and tracking of laptops 
regardless of what OS it is running (e.g. even after wipe). The BIOS only has 
drivers for specific intel WiFi and Ethernet chipsets and can only “phone home” 
using known networking hardware. 

If you avoid the in-built Ethernet and the factory specified WiFi cards, it is 
much more difficult to leverage AMT and similar technologies for remote control 
and tracking of a device. Not impossible but more difficult.

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/601ce3bf-4b86-4613-8711-041ad4f5d07f%40googlegroups.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

[brendan . hoar]

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.
 
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/4e3833ec-12e9-4f12-a128-52d449ec336d%40googlegroups.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

[brendan . hoar]

On Sunday, February 9, 2020 at 3:19:34 PM UTC, Claudia wrote:
>
> > 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.
>
>
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.*"

https://xenbits.xen.org/docs/4.13-testing/misc/xen-command-line.html

Excerpted:

```
1.2.34 cpuid_mask_cpu 

= fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b

Applicability: AMD

If none of the other *cpuid_mask_** options are given, Xen has a set of 
pre-configured masks to make the current processor appear to be 
family/revision specified.

See below for general information on masking.

*Warning: This option is not fully effective on Family 15h processors or 
later.*
1.2.35 cpuid_mask_ecx 1.2.36 cpuid_mask_edx 1.2.37 cpuid_mask_ext_ecx 1.2.38 
cpuid_mask_ext_edx 1.2.39 cpuid_mask_l7s0_eax 1.2.40 cpuid_mask_l7s0_ebx 
1.2.41 cpuid_mask_thermal_ecx 1.2.42 cpuid_mask_xsave_eax 

= 

Applicability: x86. Default: ~0 (all bits set)

The availability of these options are model specific. Some processors don't 
support any of them, and no processor supports all of them. Xen will ignore 
options on processors which are lacking support.

These options can be used to alter the features visible via the CPUID 
instruction. Settings applied here take effect globally, including for Xen 
and all guests.

Note: Since Xen 4.7, it is no longer necessary to mask a host to create 
migration safety in heterogeneous scenarios. All necessary CPUID settings 
should be provided in the VM configuration file. Furthermore, it is 
recommended not to use this option, as doing so causes an unnecessary 
reduction of features at Xen's disposal to manage guests.
```

-- 
You received this message because you are subscribed to the Google Groups 
"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/808b8f43-2501-4419-a710-f9cd2bb65235%40googlegroups.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

[Brendan Hoar]

On Sun, Feb 9, 2020 at 9:15 AM Claudia  wrote:

> 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.


Hmm bit 27 can be influenced by software. Might be an issue where the value
was saved for reference before the OS/hypervisor modified it?
OSXSAVE A value of 1 indicates that the OS has set CR4.OSXSAVE[bit 18] to
enable XSETBV/XGETBV instructions to access XCR0 and to support processor
extended state management using XSAVE/XRSTOR

>

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAOajFedfNAM-wo2k7bD4oSWAOrfWfp3J%2BO4pnVHR7nXg3%2BKOCg%40mail.gmail.com.

Re: [qubes-users] Re: R4 system requirements; AMD compatibility?

[brendan . hoar]

On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote:
>
> I preemptively submitted this PR to see what the Qubes team thinks. 
> https://github.com/QubesOS/qubes-vmm-xen/pull/70
>
> I agree it probably should be fixed upstream, although I've seen the Qubes 
> team make exceptions and apply their own changes. Upstream would probably 
> take a huge amount of time to get merged and tested. I'm not a developer 
> though so I'm sure you could explain the issue better than I. If you do 
> mention it, CC me as well! I like the CLI argument idea, that's probably a 
> much cleaner way of doing it and defaulting it to true. That way users 
> could disable it if needed due to hardware screw-ups.
>

Marek is somewhat active on xen-devel. Submitting the PR to Qubes is 
probably as good a place to start the (github) discussion I suppose.

I expect Claudia is correct that it's really a Xen defect to address, 
either with a flag to disable the check, or security/stability focused 
checks only.

Xen might point upwards again, of course, and tell AMD to fix their 
microcode or manufacturer's their BIOS's...

...but if a disable flag could be added (--yes_i_know_what_im_doing caveat, 
of course) that'd be a good short term workaround for the larger Qubes user 
base that is less likely to be able to figure out how to get a build 
working and rpm applied and keep up to date with upstream.

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/0ee7aa01-5daf-4d71-bc06-2d061994f7ca%40googlegroups.com.

[qubes-users] Re: How to use the USB modem HUAWEI E3372h to connect to the internet in Qubes OS 4.0.3 ?

[brendan . hoar]

On Sunday, February 2, 2020 at 1:06:45 PM UTC, M wrote:
>
> I can’t figure out how I can use the USB modem HUAWEI E3372h to connect to 
> the internet in Qubes OS 4.0.3. 
>

So having watched these threads over the past week, I have some comments:

First, you have a very finicky device. The mode issue needs to be resolved. 
Depending upon the template (fedora/debian) and version (-xx) there is very 
likely an executable you can install via apt or dnf in a template to 
control it. 

Second, *USB-connected* *network* devices are often difficult get working 
in Qubes because of the use of sys-usb to "virtually" connect the device to 
your "network" VM using the "usbip" stack. The issues arise due to defects 
or unsupported functions in the linux usbip stack (not Qubes), which make 
things fail. 

In particular, I have found that a device that can reconfigure itself to 
appear to change type is likely not going to work with usbip.

Therefore: my recommendation is to avoid utilizing usbip at all, which 
means avoiding the usb-attach/usb-detach features of Qubes entirely (that 
is, avoid managing this device using qvm-usb and/or the device widget).

You can either make your current sys-usb into a provides-network VM 
(easier, but not the way I'd go...unless I already devices dependent on 
that config) or use the salt feature to uninstall the entire sys-usb 
feature (removing the sys-usb VM) and instead manually assign the entire 
usb controller to sys-net, utilizing qvm-pci in dom0 to attach the pcie 
device.

That way, you're only dealing with issues in one VM which you can treat as 
a regular fedora or debian install. There are likely existing resources 
that can tell you how to manage the mode switch of that device with that 
version of fedora or debian.

That's all I have.
Brendan

PS - the second approach, removing sys-usb altogether, assumes you don't 
have a USB-based keyboard or mouse (or other important peripherals) that 
you've set up to work through sys-usb.

-- 
You received this message because you are subscribed to the Google Groups 
"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/0472a929-3a41-456c-b073-f5ebd2a4c21c%40googlegroups.com.

Re: [qubes-users] Re: AppVms being killed on resume due to clock skew too large

[brendan . hoar]

Perhaps due to memory balancing being temporarily unable to service all AppVMs 
upon dom0 wake?

-- 
You received this message because you are subscribed to the Google Groups 
"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/79790660-c4d5-4122-b56a-1457087a75aa%40googlegroups.com.

[qubes-users] Re: Anyone using remmina for RDP? (AND able to alt+tab in the RDP session w/o xfce stealing the keystroke)

[brendan . hoar]

On Monday, January 27, 2020 at 8:34:33 PM UTC, Stumpy wrote:
>
> I am using remmina (1.3.10) on a debian (10) appvm to rdp into a win10 
> box and it works fairly well, but there is some sort of issue with 
> remmina grabbing the keystrokes? 
> When i try to alt+tab in my rdp session xfce/qubes grabs it instead of 
> the win10 session alt+tabbing. I have tried changing the alt+tab keys in 
>

 I haven't used the software, but for local Windows HVMs, I'm able to send 
alt-whatever by using windows-alt-whatever.

Kind of a difficult one-hand operation, even with my fat fingers, but 
relatively easy to pull off with two hands.

Might work with this client as well?

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/f96e97f9-5e86-434f-a880-d976a6d4e4cc%40googlegroups.com.

[qubes-users] feature request

[brendan . hoar]

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.

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/fa793038-32f5-4891-bb70-3699f6ba88c8%40googlegroups.com.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

[brendan . hoar]

Try running qvm-start-gui  when the window doesn’t appear.

-- 
You received this message because you are subscribed to the Google Groups 
"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/1b947f08-0957-4f38-ab1f-bd1b418f8534%40googlegroups.com.

Re: [qubes-users] Re: qvm-create-windows-qube 2.0

[brendan . hoar]

On Friday, January 17, 2020 at 11:01:05 PM UTC, Elliot Killick wrote:
>
> On 2020-01-15 01:36, shiftedreality wrote: 
>
> > You pointed me in the right direction. I was using Debian 10 as my 
> default 
> > Qubes template. 
> Debian 10 is supposed to be supported as a template. I didn't realize 
> the Debian 10 template qube didn't come with cURL. Bug fixed, thanks for 
> catching that. 
>

On my nth install of Qubes...and learning the hard way about passing 
informal scripts to others... :)

A reminder if using the standard lvm config : the cloning of VMs/templates 
only ends up using additional storage for the *divergence* of each from the 
other(s). 

So, I'd recommend, if scripting for others: keep a pristine un-updated copy 
of the target template(s) to test scripts against. Even better would be a 
pristine copy and an "up-to-date but not customized" copy. E.g.

debian-10 <- installed by qubes, developer *disables* automatic update 
reminders and does not update (frozen)
debian-10-up-to-date <- cloned by developer, not customized, only ever 
apply updates
debian-10-custom <- cloned by developer, apply customizations (e.g. 
apt-install stuff), apply updates. For day to day use with your VMs.

That way one can (without having to remove and recreate templates via dom0 
salt, dnf invocations, etc) test your scripts against baseline expectations 
of other users.

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/dd9d8548-d1eb-4450-b946-1d4667dbc99d%40googlegroups.com.

[qubes-users] Re: LibreOffice presentation mode with QubesOS

[brendan . hoar]

Alt-space fullscreen doesn’t work?

-- 
You received this message because you are subscribed to the Google Groups 
"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/c9b529be-4eb5-4df1-9ca8-8fb89286a7cc%40googlegroups.com.

[qubes-users] Re: qvm-create-windows-qube 2.0

[brendan . hoar]

Which template are you using?

-- 
You received this message because you are subscribed to the Google Groups 
"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/c9bfbf0b-016f-476b-a5a9-a635dd1a01b9%40googlegroups.com.

[qubes-users] qvm-create-windows-qube 2.0

[brendan . hoar]

Having manually set up windows VMs in  in the pst, I can say that Elliot’s work 
here is quite the time saver.

Just invoke the script, go off and do something for a bit, come back later with 
some windows VM installs completed, including the add on software you wanted.

Haven’t tried the newer version yet as I have to review the 10 windows 7 VMs I 
created under the old version to be sure I can wipe them all first!

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/d125d8e2-5d10-4181-b5ee-27abcd766165%40googlegroups.com.

[qubes-users] Re: Does qubes block usb on thunderbolt port?

[brendan . hoar]

On Wednesday, January 8, 2020 at 4:29:57 PM UTC-5, Ryan Tate wrote:

> (The one thing that I do wonder is if is neccesary for sys-usb to bail 
> out on boot when an assigned device is not present, maybe there could be 
> a system for transient but assigned devices to be allowed to come online 
> post boot? No idea how feasible this is.) 
>

PCIe attach has to happen at startup, and Xen will fail to start it up if 
the named device isn't there.

My suggestion: create a *second* sys-usb style VM (e.g. called "sys-usb-c") 
with the "extra" usb pcie device attached and *remember* to have the USB 
port populated at boot if you want to use devices from that second device 
VM.

The regular sys-usb will always start up for the other ports (regardless of 
whether you have a device plugged in or not).

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/4eb2e9cd-af16-46ef-9b77-d3a6a888f9b8%40googlegroups.com.

[qubes-users] Re: Does qubes block usb on thunderbolt port?

[brendan . hoar]

On Wednesday, January 8, 2020 at 6:19:54 AM UTC-5, Ryan Tate wrote:
>
> Does qubes block USB data on Thunderbolt ports? 
>

So a few things:

1. Qubes has pcie hotplug disabled in the dom0 kernel, which TB uses for 
PCIe-based thunderbolt devices. This is disabled for security reasons.
2. The TB alternate mode that supports USBs might not instantiate the PCIe 
USB controller it connects through *until a USB device is connected to that 
port*.
3. Therefore...depending on BIOS support...you *might* be able to have a 
USB device seen by qubes if the USB device is plugged in at power-on. Even 
if that works, it might be on a USB PCIe controller that is not already 
attached to your sys-usb (if you have one).
4. If it does work, you might want to create a sys-usb-c which you run only 
after connecting a device to the port at boot time, and assign the (usually 
hidden) PCIe USB controller that that VM only.

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/0cbd5089-ce29-4c13-9d9f-d40ff678e95a%40googlegroups.com.

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

[brendan . hoar]

On Friday, January 3, 2020 at 3:48:33 PM UTC-5, Claudia wrote:
>
> January 3, 2020 7:17 PM, brend...@gmail.com  wrote:
>
> > 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:
> ... 
>
> 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.
>

On the W520, lspci -nvvD shows two PCI USB EHCI devices with Debug enabled. 
Probably the same PCI device presenting itself twice. From what I've read 
elsewhere, the USB 2.0 port on the back of the unit is the one wired up for 
debug use. Presumably the X230 units are similarly equipped.
 
Haven't checked the P52 yet.

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!
>

Will do.
 

> 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. 
>

I'm not entirely sure that the XHCI capability is as "low level" friendly 
as the EHCI capability (it might require at least a mini USB stack to be 
utilized). Haven't dived into that fully yet.

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/e2f34648-a0db-44ad-8e81-d5d78acd7323%40googlegroups.com.

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

[brendan . hoar]

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.


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/a3f62e27-517c-4eb3-8f8e-73bde2a0bb56%40googlegroups.com.

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

[brendan . hoar]

On Monday, December 30, 2019 at 1:44:13 PM UTC-5, 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.
>
 

> 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);
>


Interesting. This call to recheck_cpu_features appears to be a check/panic 
that is also in Qubes R4.0, and was backported to Xen 4.8.3 last year:

  
https://github.com/QubesOS/qubes-vmm-xen/commit/c921e46e9e18cd1cfa1347289db4c2f61b8f686a#diff-9ff8c82836adac8412cd8ac4afdf8cae
 
q123 - do you happen to know what the exact two flag bits that changed 
represent in the cpu features? I wonder if the true issue is something not 
being properly preserved during the suspend, or properly re-initialized 
during the resume.

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/26eebc08-a5ca-4786-bc99-0758e26a2fb9%40googlegroups.com.

Re: [qubes-users] Qubes Structure

[brendan . hoar]

On Monday, December 30, 2019 at 6:25:03 AM UTC-5, xao wrote:
>
> Don't know how I missed this link before, but after reading it, things got 
> much clear. Thank you!
>

One important tenet of Qubes is that the security focus is primarily 
protecting you from cross-domain (cross-VM) disclosure or exposure. 
However, anything within a particular VM/domain is about as vulnerable as a 
typical linux system.

Hence, why Qubes requires a certain amount of self-discipline even for 
basic use cases.

In addition some folks extend that a bit and utilize Qubes further to 
separate "personae" from eachother, sometimes routing each through 
different VPNs.

Banking VM only for banking; job1 VM only for day job; ...and superhero 
domain only for your alternate crime-fighting identity, etc. 

In addition, as soon as one starts customizing templates, fingerprinting 
during a breach becomes easier, to the point where a breach in two VMs can 
end up cross-correlating personae in two VMs even if they connect to the 
internet differently.

That's why question #0 is: what are your specific threat concerns? Question 
1 is: how will you mitigate them? Mitigations *begin* with behavior, not 
technology. Technologies just assist with/automate the behavior.

Lastly, one assumption that comes up a lot is that disposable VMs are 
amnesiac. They are not (currently anyway*). The data written to the 
disposable VM is unlinked when the disposable VM volumes are removed but 
they are not explicitly erased from storage (though may be overwritten over 
time). Why? The primary intent of disposable VMs was to prevent propagation 
of malware from dodgy files or dodgy websites or targeted attacks. The 
intent was NOT to prevent forensic recovery of data from shut-down 
disposable VMs.*

B

* though, that would be a nice feature. there are some baby steps happening 
now (e.g. blkdiscard is now run across the volumes before unlinking them, 
which may end up being opportunistically anti-forensic on *some* hardware 
if trim is enabled all the way down through the storage stack).

-- 
You received this message because you are subscribed to the Google Groups 
"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/6e7875c6-0bcb-47c4-8581-c687259ae654%40googlegroups.com.

[qubes-users] Re: Recommended laptop?

[brendan . hoar]

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

[brendan . hoar]

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.

[qubes-users] Notebook with Nvidia Quadro graphics card

[brendan . hoar]

Older laptops w/ Optimus allowed choosing Integrated-only video (vs hybrid or 
vs Discrete). I set up my W520 w/ the Integrated intel cpu and it has been a 
workhorse.

Contemporary laptops w/ Optimus only allow Hybrid or Discrete. No way to choose 
just Integrated. Qubes 4.0 and lower don’t handle this very well w/o a lot of 
boot parameter fiddling and custom X config.

However...

I just tested a test build (20191227) of R4.1 using Fedora 31 dom0 and 5.4 
kernel on a Thinkpad P52 (2018 model w/ Optimus on a Quadra P3200). Other than 
a bit of blind navigation during the first boot part of the install (and some 
strategic Bios settings such as setting discrete graphics), it installed ok. 
Changing screen resolution results in a black screen (fixed via ctrl-alt-f2 
then ctrl-alt-f1). 

Probably would work much better after installing nvidia drivers via 
rpmfusion-nonfree. But not unusable.

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/f28cb7dd-b46c-47e1-8952-4d71ea921258%40googlegroups.com.

[qubes-users] Re: Recommended laptop?

[brendan . hoar]

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.]

Storage: 1 x mSATA (300MB/s) slot; 1 x SATA (600MB/s) main bay; 1 x SATA 
(600MB/s) in media tray replacing optical drive; 1 x eSATAp (300MB/s) external 
port. Additional 1 x eSATA (300MB/s) on some docks.  So plenty of fast-enough 
storage options. Plus an SD card slot.

VGA. DisplayPort. Ethernet. WiFi. Modem.

2 x USB 3.0.

2 x USB 2.0 (1 is part of the eSATAp connector). More on some docks.

FireWire and Expresscard (you’d generally want to disable both in bios for 
security reasons). Though...expresscard can be used to add another usb 
controller if two is not enough (e.g. to work around usb pass through issues 
with usbip).

Core unit generally $250-$300 on eBay in ok shape (sans ram and storage which 
you can add yourself).

Bit heavier than the x230, but I appreciate the additional RAM and cores most 
of the time.

Install in legacy mode, disable discrete GPU.

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/c953df6c-145a-4380-b395-d49b2f4699b8%40googlegroups.com.

Re: [qubes-users] upgrade: latest stable -> latest testing RC

[brendan . hoar]

One additional thing: certain install-related,
VM-creation or volume-creation “fixes” across versions won’t be applied after 
an upgrade.

E.g. there were volume mis-alignment fixes, that lead to better SSD and LVM 
performance, made after 4.0, that aren’t auto-fixed for existing VMs or 
templates. Presumably the template building process means that removing 
templates and redownloading more recently built templates then creating new VMs 
will lead to fixes for 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/fec476e6-e341-4a19-b77e-dfd205799e85%40googlegroups.com.

[qubes-users] Re: One of the configured repositories failed (Fedora 20 - x86_64)

[brendan . hoar]

On Monday, December 23, 2019 at 9:06:09 AM UTC-5, Spleen Productions wrote:
>
> I've setup a machine running R2 since i need audio working on Windows HVM.
>
> I would like to install QWT but when i run sudo-qubes-dom0-update i get 
> the following error:
>
> One of the configured repositories failed (Fedora 20 - x86_64)
> ...
> Cannot retreive metalink for repository: fedora. Please verify it's path 
> and try again.
>
> Do i need to configure qubes-dom0.repo?
>

Fedora 20 is no longer supported.
Qubes R2 is no longer supported.

Generally, I doubt anyone on the list will recommend you continue using 
such older unmaintained security software.

So..if your hardware supports Qubes R4.0, my suggestion would be installing 
that, assigning one of your PCI USB controllers to the Window HVM, and then 
utilize a hardware USB audio device for audio out of the Windows HVM.

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/901abed3-4556-405c-8aea-0825cca54c2a%40googlegroups.com.

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

[Brendan Hoar]

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

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAOajFefPOiX0cixj5BjP5iCE_EyB4ZWcVbrZ56PeafHBUduoHQ%40mail.gmail.com.

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

[Brendan Hoar]

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

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAOajFef-2_HVytQ5Euou8kyvjLOvc%3Dw%3D1hOFO9sPcGa3ZRbYWQ%40mail.gmail.com.

[qubes-users] Startup/Shutdown thin pool trim - where to insert with systemd?

[brendan . hoar]

Hi folks

[ calling @tasket !]

I'd like to have the system perform a thin_trim command across the primary 
thin pool on Qubes startup and shutdown. The purpose would be opportunistic 
erasure of deleted volumes in the pool (say, if they were removed without 
blkdiscard being run against them first). I have already activated passdown 
through the luks layer and enabled discards on the hardware.

As the documentation tells us, thin_trim can only be safely invoked before 
the pool is activated or after the pool is successfully deactivated.

If fedora were still running init, I'm pretty sure I could find the right 
place to do this, but with systemd, I am quite discombobulated.

>From the documentation I know that as part of the automatic lvm scanning 
and activating of autodiscovered lvm VGs/volumes/pools that thin_check is 
automatically run on startup before activating volumes (though that might 
be internal and therefore controlled via lvm.conf).

So...

1. Where/how do I insert a thin_trim of the qubes_00 pool during startup 
when it's available (e.g. after luks volume is mounted) but before the pool 
is activated? How do I do it safely (ensuring that activation only occurs 
on exit of thin_trim)?

2. Where/how do I insert a thin_trim of the qubes_00 pool during shutdown 
after it is deactivated but before the luks volume (the VG) is dismounted?

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/f1ae53ba-d942-4f0c-b6f5-599eee544593%40googlegroups.com.

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

[brendan . hoar]

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.


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/6269800c-11c5-4907-a63e-eca2ca5dfbf2%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

Use this one instead, previous one had a missing newline:

https://pastebin.com/JMtuns8g

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/1356c3ae-dbcf-4c39-8074-0300c1c5a80a%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

On Thursday, December 19, 2019 at 12:09:26 PM UTC-5, Brendan Hoar wrote:
>
> This script shows the approach I take for an ephemerally keyed lvm pool:
>
>   https://pastebin.com/LDKKwsWW
>
>
And of course, since I was in a hurry, I see typos and better possible 
edits in the explanatory text it displays after it runs.

In any case: while you can use the disk space widget to see primary pool 
data usage, I recommend you use lvs to determine your primary pool data 
usage % *and* metadata usage %. Qubes R4.1 will show both.

Also, review the VMs you intend to put in the new pool. Little to no space 
is used until the VMs and associated templates are copied over to it. So in 
addition to copies of the VMs/templates, additional work you do with data 
in the new pool will use storage in the primary pool, until you remove it 
(either by exiting the script correctly or by manually removing via 
lvremove if you did not exit the script correctly).

A full pool is a dead pool.

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/c6c69973-3624-44de-ac28-12a5cf650df9%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

This script shows the approach I take for an ephemerally keyed lvm pool:

  https://pastebin.com/LDKKwsWW

Assuming you want a windows standalone work VM and one or more whonix 
disposable VMs, you just need to change the two variables in the script and 
launch it in dom0.

Be sure you know what you are doing. Review the script first.

It's hacked together, but it's been working well.

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/1118001c-05bb-4fe7-a45e-c7bafc6010c0%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

On Wednesday, December 18, 2019 at 10:04:40 AM UTC-5, steve.coleman wrote:
>
> On 2019-12-15 22:04, brend...@gmail.com  wrote: 
> My suggestion is, rather than the time consuming wiping of bits after 
> the fact would be to instead create an encrypted volume/partiton/pool 
> when launching a DispVM, and upon shutting it down you simply throw away 
> the key to that temporary volume. Without the key any data on that 
> encrypted volume would be unrecoverable, so then all you really need to 
> wipe is just the memory space that stored the runtime key's working 
> memory. If the key is generated before the volume is created then the 
> key would be only available to dom0 where the key's working memory space 
> can be managed properly and Qubes would be able to support any number of 
> guest OS's as a DispVM. 
>

That is what I do via a bash script. LVM vg/pool on top of LUKS (as pv) on 
top of default LVM pool, and the luks layer uses /dev/urandom sourced key. 

However, due to some of the constraints of LVM (which, given the features 
it does provide, I *can* live with), I also need to move the templates to 
the temporary pool for the approach to work, so there's a time consuming 
(~4 minutes) setup time before the VMs are running. 

It's just a script, so execute, perform some other task for a bit and wait 
for windows to appear. When done with the sensitive task (or prepping for 
anti-forensics testing), user performs shutdown VMs, tell script you 
"done", and the script ensures all VMs are closed, then removes the above 
storage layers.

--

There were some discussions in the qubes-issues ticket(s) about adding 
additional driver layers in the mix that might make utilizing a separate 
encrypted pool unnecessary.  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?
 

> If the volume were intentionally stored on an Opal 2.0 SSD device you 
> could then use the built in SSD hardware capabilities of the 'encrypted 
> locking range' (up to four are possible if I remember correctly) for the 
> temporary workspace and when you destroy/reset the MEK (key) this will 
> instantly flip all the bits in the underlying hardware of that disk 
> region and make that range completely unrecoverable. 


OPAL ranges could be useful, but as they are also basically hardware 
managed partitions, I believe they would be difficult to utilize 
effectively, esp. if you want n (instead of a max 4 or 8) different secure 
areas (some permanent, some ephemeral). That being said, I do believe the 
opportunistic anti-forensics of trim/discard on a SED with DZAT might be 
useful (and hence my suggestion of utilizing trim through all layers and 
proposing to the qubes devs to blkdiscard before lvremove, which qubes now 
does).

Also: some business use cases for permanent encrypted VMs have been given, 
e.g. keeping client A resources locked down while client B work is being 
performed or demo'd, etc. I would think LVM, esp. thin LVM, gives quite a 
bit of flexibility in sizing, adding/removing, etc. and would be 
applicable, perhaps with the additional encrypting driver layer discussed 
in the related qubes-issues items in github.
 
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/d77855e6-83d7-4b00-a451-d9c15d83d475%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

On Monday, December 16, 2019 at 5:33:52 PM UTC-5, Claudia wrote:
>
> brend...@gmail.com : 
> > Disposable VMs were not developed with anti-forensics in mind (e.g. no 
> protection in jurisdictions where you can be forced to hand over your drive 
> password 
> Never thought about it, but that makes sense. I can see how it would be 
> easy to confuse "non-persistence of malware" aspect and the 
> "non-persistence (non-remenance) of data" aspect, though. 
>
> But then... What does the checkbox mean, "Keep dispVM in memory", under 
> global settings (R3.2, at least)? Screenshot attached. 
>

See: https://groups.google.com/d/msg/qubes-devel/QwL5PjqPs-4/JwcbdJDbBDwJ

It was meant to be a dispVM speed-up option, not an anti-forensics option.
 

> I sort of like the idea mentioned in bug #904, about doing the crypto 
> inside the dispVM itself, so that 1) the key is scrubbed by Xen when the 
> dispVM is shut down, and 2) data is non-recoverable instantly so you 
> don't have to wait until all dispVMs have been shut down for example. 
> Incidentally this approach actually offers a lot of improvement in 
> scenarios where the machine is seized while it's on and unlocked, too, 
> but that's another topic. 
>

That could work, but depends upon threat model, e.g. if the dispVM hosts 
untrusted content then depending upon the VM to prevent leakage may have 
issues.
 

> Just bouncing around some ideas. Seems like it might be possible to do 
> something like that, and perhaps simpler than the ephemeral pool 
> approach, depending on your situation. Thoughts? 
>

I dunno...the ephemeral approach is simpler to me...in that it's just a 
bash script in dom0.

It's less simple in usuage...in that it takes a while to run to get to a 
usable state. :) But it did help uncover some inefficiencies in the 
qvm-clone implementation that has been patched by the devs.

In any case: the proof is testing data recovery during/after using the 
technique.

e.g. With R4, I found that even after copying the disposable vm template 
and the template it is based off of to a new pool, on startup, at least one 
volatile volume per dispvm is created in the default pool. 

I'm pretty sure that's a defect and it's definitely a forensics gotcha. 
Hence the script currently needs to change the default pool before dispVM 
startup and then, after a time, reverts it back.

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/04f50bfa-c06c-4281-a4f5-f7cdf0702000%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

As to the first question: with qubes 4.0 it is a bit difficult to effectively 
wipe free space in the default thin pool.

One can create a thin volume and write to it until the thin pool reaches some 
saturation level (99.5%), then hit that volume with blkdiscard before invoking 
lvremove. Because you should not go to 100% the user may still be rolling the 
dice.

Lvm doesn’t like hitting 100% and one can permanently corrupt the system if you 
fill the lvm all the way.

It’s possible the lvm tool chain in 4.1 may have more capabilities once dom0 is 
on a much more recent fedora version.

It’d also be nice to have dom0 in a different pool than the templates/VMs...to 
reduce catastrophic failures.

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/6fae11a3-cfb8-4318-908b-76d3f2750387%40googlegroups.com.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

Disposable VMs were not developed with anti-forensics in mind (e.g. no 
protection in jurisdictions where you can be forced to hand over your drive 
password).

That being said...

In 4.0 (updated) qubes now calls blkdiscard on volumes being removed before 
invoking lvremove. If you happen to use a SED SSD and you have manually enabled 
discards through all layers to the physical drive, then, depending on the 
manufacturer implementation, the data from a shutdown disposable VM might not 
be recoverable even with your disk password.

No guarantee but I recommend enabling discards all the way down.

After some forensics experiments, I put together a rough-at-the-edges bash 
script that does a rather good job of ensuring the volumes are not recoverable.

It creates an over-provisioned lvm volume In the current pool, overlays a new 
randomly keyed luks volume on top, makes that into an lvm pv, layers lvm vg and 
finally an lvm thin pool on top.

Adds that new thin pool to qvm-pools, copies templates and VMs there, 
temporarily modifies the global default pool setting (needed to be sure *all* 
volumes related to the VMs were in the ephemeral pool) and starts up some 
sessions. 

I need to make it a bit more flexible but it served my need.

Once all started VMs are shut down, the script unwinds all the storage layers.

Since the luks layer was random keyed, that data is gone once unmounted.

Been meaning to clean it up and share at some point.

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/f6b7c6e3-6f8d-473a-9dc5-5fdf91cbf3b7%40googlegroups.com.

Re: [qubes-users] Making a DispVM permanent

[brendan . hoar]

On Monday, September 23, 2019 at 11:57:22 AM UTC-4, steve.coleman wrote:
>
> On 2019-09-21 07:27, tetrahedra via qubes-users wrote: 
> > Is there a way to turn currently-running DispVM instance into a regular 
> > permanent AppVM, which I can delete later? 
>
> I'm not sure it this helps or not, but you could try pausing the dispvm 
> and restart it when you need it. I don't know what happens if the 
> machine reboots in the mean time, but that paused vm should stop using 
> memory and cpu thus allowing you to use those resources elsewhere. 
>

Just to clarify: while pausing a Qubes VM does relinquish the CPU usage, it 
does not relinquish the memory used. Instead, it just freezes the memory 
allocation to the current amount until you unpause the VM.

An additional caution for VMs that support memory balancing is that if the 
memory pressure has changed significantly from the time that the VM has 
paused, when you unpause it, there's a chance that it may fail the next 
memory request with xen and be terminated immediately.

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/657bb674-665e-4057-b770-97e3f9123a2b%40googlegroups.com.

[qubes-users] Bad/expired certs in qubes repo mirror dgplug.org

[brendan . hoar]

Report below:

[MIRROR] qubes-template-fedora-30-minimal-4.0.1-201907160147.noarch.rpm: 
> Curl error (60): SSL peer certificate or SSH remote key was not OK for 
> https://mirrors.dgplug.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-30-minimal-4.0.1-201907160147.noarch.rpm
>  
> [SSL certificate problem: certificate has expired]
> [MIRROR] qubes-template-debian-10-4.0.1-201907141704.noarch.rpm: Curl 
> error (60): SSL peer certificate or SSH remote key was not OK for 
> https://mirrors.dgplug.org/qubes/repo/yum/r4.0/templates-itl-testing/rpm/qubes-template-debian-10-4.0.1-201907141704.noarch.rpm
>  
> [SSL certificate problem: certificate has expired]
> [MIRROR] qubes-template-debian-9-minimal-4.0.1-201901271906.noarch.rpm: 
> Curl error (60): SSL peer certificate or SSH remote key was not OK for 
> https://mirrors.dgplug.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-debian-9-minimal-4.0.1-201901271906.noarch.rpm
>  
> [SSL certificate problem: certificate has expired]
> (1/6): qubes-template-debian-9-minimal-4.0.1-20 606 kB/s | 196 MB 
> 05:31
> [MIRROR] qubes-template-debian-10-minimal-4.0.1-201907141704.noarch.rpm: 
> Curl error (60): SSL peer certificate or SSH remote key was not OK for 
> https://mirrors.dgplug.org/qubes/repo/yum/r4.0/templates-itl-testing/rpm/qubes-template-debian-10-minimal-4.0.1-201907141704.noarch.rpm
>  
> [SSL certificate problem: certificate has expired]
>

-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/71c8ea74-b541-4c92-aa7b-71fa64e945f1%40googlegroups.com.

Re: [qubes-users] Making a DispVM permanent

[brendan . hoar]

On Sunday, September 22, 2019 at 7:37:40 AM UTC-4, one7...@gmail.com wrote:
>
> Hello,
>
> *Von:* tetrahedra via qubes-users
> *Betreff:* [qubes-users] Making a DispVM permanent
>
> Is there a way to turn currently-running DispVM instance into a regular 
> permanent AppVM, which I can delete later?
>
> 
>
> The way I would do it:
>
> 1) Open a xterm in the same (!) disposable VM
> qvm-run  xterm
>
> 2) close all other windows in this dispvm
> (Make sure that xterm is running in the VM to avoid that the VM gets 
> deleted)
>
>
The one additional caution or clarification I suggest is:
Dom0 is monitoring whatever the first window/process was that it asked the 
dispVM to open. If that window/process exits, the VM will be shutdown.

I typically open a dispVM xterm, open another xterm, and then window-shade 
and/or minimize the original one...just to avoid mistakenly closing it and 
exiting the VM early.

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/56469709-060c-44d9-afb7-1ec0799d8a77%40googlegroups.com.

Re: [qubes-users] "Root File out of memory warning"?

[brendan . hoar]

On Tuesday, September 17, 2019 at 6:15:12 PM UTC-4, awokd wrote:
>
> On a side note, anyone know why "sudo fstrim -av" in dom0 now says 0 
> bytes trimmed for root? I double-checked and have discard specified 
> everywhere it should be. Only thing I don't remember seeing before is 
> stripe=64 in the mount, but I searched issues and qubes-src for "stripe" 
> and didn't find anything related. 
>
> /dev/mapper/qubes_dom0-root on / type ext4 (rw,relatime,discard,stripe=64) 
>

You have discards enabled at all layers (fs and crypt)?

What I think you are seeing is this: Linux keeps tracks of discards in the 
current session and won't re-issue discards if it hasn't subsequently 
written to the already-discarded area. Reboot and try again. The first time 
after reboot, it should issue discards to the non-allocated portion of the 
volume.

This performance-oriented kernel behavior is one reason I am a proponent of 
activating/issuing discards in all the layers. Another is that SSDs consume 
the actual discards very quickly: hundreds of GBs can be discarded in 
seconds utilizing range discard requests supported by the internal queuing 
of the range discard requests.

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/f8d0d123-f5c7-440c-92b0-2651350a543a%40googlegroups.com.

Re: [qubes-users] Re: whonix tor browser customization

[Brendan Hoar]

On Tue, Sep 10, 2019 at 2:40 PM 'awokd' via qubes-users <
qubes-users@googlegroups.com> wrote:

> brendan.h...@gmail.com:
>
> > Under whonix-15, the whonix developers have inserted a presetting
> question
> > on startup allowing you to choose what you want the default on startup
> to
> > be, and the bug where the setting is one way, and the buggy behavior
> above
> > does not seem to be present.
>
> I haven't seen this preset question. Is there a way to trigger it?
>

I dropped all my whonix-14 VMs and templates yesterday and used salt to
install the whonix-15 templates (again: I'm also on the R4 current-testing
repo), and I see the question once every dispvm start.


>
> > You still have to set it again each time a disposable VM starts, but
> it's
> > more straightforward, at least in my opinion.
>
> Might be missing something here, but wouldn't that defeat the purpose?
> I'd like very much to set all my disposables to start on Safest.
>

>From my read, it is possible you could set it in the DVM template (there
are instructions on how to set the startup files in the filesystem to
bypass the question).

Here's the text of the dialog (some of the text hyperlinks elsewhere):



First Start of Tor Browser (AnonDist) - Security vs Usability Trade-off

In the stock Tor Browser configuration, JavaScript is enabled by default
for greater usability. The Tor Project provides a rationale for this
decision.

The producers of Tor Browser decided the security slider setting to be set
to "Standard" by default. Quote Tor Browser Manual:
You can further increase your security by choosing to disable certain web
features that can be used to attack your security and anonymity. You can do
this by increasing Tor Browser's Security Settings in the shield menu.
Increasing Tor Browser's security level will stop some web pages from
functioning properly, so you should weigh your security needs against the
degree of usability you require.
This popup question does not restrict your freedom to change security
slider settings at any time.

Responsible for this popup question is Tor Browser Starter by Whonix
developers. It is an usability feature, which might break in future.
Therefore the user is advised to verify that the security slider has the
expected setting. Please donate!

Preseeding:

It is possible to avoid this popup question by preseeding the answer to it.
For that create a file /etc/torbrowser.d/50_user.conf with the follow
contents, if you want to answer "Yes".
tb_security_slider_safest=true
Or if you want to answer "No".
tb_security_slider_safest=false
Technical Details:

This script is: /usr/bin/torbrowser
Function: tb_security_slider
All this would do is copying file
/usr/share/torbrowser/security-slider-highest.js to
/home/user/.tb/tor-browser/Browser/TorBrowser/Data/Browser/profile.default/user.js.

cp /usr/share/torbrowser/security-slider-highest.js
/home/user/.tb/tor-browser/Browser/TorBrowser/Data/Browser/profile.default/user.js

Set Tor Browser Security Slider to Safest?


[No] [Yes]



My read is that whonix dev(s) do not want to contradict the choices of the
Tor project, even if controversial (I see good arguments on both sides).

Whonix dev(s) are also probably (I am guessing here) tired of getting
questions about these settings every day.

I'll paraphrase: "Here's the shotgun. Use it wisely. Know where your limbs
are at all times."

B

PS - why I continued to see the bug where the setting and behavior were
different in -14 vs. -15 I don't know, but I do have a more recent version
of TB in -15, so maybe that's 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/CAOajFeeXa4c_qgnf1tWJVEmU73G%3DWjbBLMEpAM0GqQg36ybHuw%40mail.gmail.com.

Re: [qubes-users] Re: whonix tor browser customization

[brendan . hoar]

On Tuesday, September 10, 2019 at 2:13:46 PM UTC-4, tetra...@danwin1210.me 
wrote:

> Did upstream (Tor) also change the NoScript settings to block all 
> javascript on all sites by default, even at the lowest Tor Browser 
> security level? 
>

Not exactly. Upstream intended the security slider to be set at Standard 
and the behavior to be Javascript mostly on.

However, some TB versions (I experienced tihs under whonix-14 at least) has 
an issue, where while it defaults to the "Standard" setting as per 
upstream, TB acted as if set to the "Safest" setting. This appears to be a 
TB bug.

Manually adjusting the setting back and forth in firefox preferences fixes 
the issue for that session, but the problem appears again on restart.
 

> This is what seems to be happening for me. It is a pain, since any 
> attempt to fix the settings goes away once the disposable Whonix VM 
> dies. 
>

Under whonix-15, the whonix developers have inserted a presetting question 
on startup allowing you to choose what you want the default on startup to 
be, and the bug where the setting is one way, and the buggy behavior above 
does not seem to be present. 

You still have to set it again each time a disposable VM starts, but it's 
more straightforward, at least in my opinion.

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/ff177f9c-1a91-4893-aacb-cf74b39b0a74%40googlegroups.com.

Re: [qubes-users] Reminder: Please help test new updates and provide feedback!

[brendan . hoar]

FYI, running Thinkpad W520 running R4 w/ current-testing & kernel-latest, 
updated to current-testing's bevy of updates this morning.

Everything is smooth so far.

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/8dd7c99d-04bc-4283-b49d-c6ffa286e50d%40googlegroups.com.

Re: [qubes-users] Cant connect hard drive to appvms?

[Brendan Hoar]

On Sat, Sep 7, 2019 at 3:04 PM Stumpy  wrote:

> ...


Does the template for the VM have the ntfs-3g package installed?

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/CAOajFeefnLynfkZF6%2BD7tcJenntz9D%3DJUM_%2BWPTFaLDatU1t9Q%40mail.gmail.com.

Re: [qubes-users] Re: Cant connect hard drive to appvms?

[brendan . hoar]

On Thursday, September 5, 2019 at 4:33:31 AM UTC-4, awokd wrote:
> b@gmail.com:
> 
> > USB: I generally have not attached USB drives (utilizing the USB IP support
> > via `qvm-usb` aka `qvm-device usb`) to VMs as I find it slow and sometimes
> > buggy.
> 
> I don't do that either, but using qvm-block to attach USB drives has 
> been stable for me. More secure too.

Ah yes. I too use qvm-block for my sata devices. 

What I neglected to mention was that several of my USB devices implement 
hardware  encryption (that replaces a small read-only volume with the main 
read-write volume after unlock).

The strategy choice then was a) unlock via sys-usb and utilize qvm-block or b) 
connect usb chipset to disposable VM and unlock there. I chose the latter.

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/4d57e821-3ee4-4f97-b240-f385047b430a%40googlegroups.com.

[qubes-users] Re: Cant connect hard drive to appvms?

[brendan . hoar]

On Wednesday, September 4, 2019 at 8:12:41 PM UTC-4, Stumpy wrote:
>
> I have a hard drive that i cant seem to connect to any of the appvms yet 
> I can see and access it via dom0 (not good i know). 
> I can attach a usb flash drive to my appvms but not the hard drive? 
>
> This is on my laptop and i do not have a sys-usb (didnt give me the 
> option when installing qubes (v4.0.2) but if i can connect a flash then 
> i cant figure why i cant connect the external hard drive to appvms, esp 
> if i can use/see the drive via dom0?
>

That's odd. Is this a SATA or USB hard drive? 

SATA: On my primary thinkpad, running qubes R4 current-testing (essentially 
at least v4.0.2), while *sda* is not available for attachment to devices 
(as that is the boot disk) all  the other SATA devices are available for 
attaching: sdb, sdc (and, when the eSATAp and/or dock is attached, sdd and 
sde) to VMs. Any valid partitions as well. 

USB: I generally have not attached USB drives (utilizing the USB IP support 
via `qvm-usb` aka `qvm-device usb`) to VMs as I find it slow and sometimes 
buggy.

Instead I attach the PCI device encompassing the USB controller utilizing 
`qvm-device pci` with an HVM, which may be a luxury that other users don't 
always have (this laptop has three USB PCI devices, one of which is via 
expresscard).

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/c7b7be8f-3e99-4602-8f9b-8d0bacfeed39%40googlegroups.com.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

[brendan . hoar]

I would advise against wiping any disks until you are sure the full set of 
restores are complete and tested.

I’ve learned the hard way to never put myself
into a situation where I cannot revert to my original configuration.

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/a8cd7eb9-cb89-4007-a0ce-bde17f3a37cb%40googlegroups.com.

Re: [qubes-users] qvm-create-windows-qube Automatically creates

[Brendan Hoar]

On Fri, Aug 30, 2019 at 2:14 AM 799  wrote:

> Hello Brendan,
>
> Thanks for the improvement list. Some questions:
>
>  schrieb am Do., 29. Aug. 2019, 15:27:
>
>> - Increasing the device-stub VM priority from 256 to 1000 during install
>> utilizing xl sched-credit. This dramatically increases the IO throughput
>> for the installation.
>>
>
> How can this be done? what is the device-stub VM priority? Can this be set
> via qvm-prefs?
>

xl sched-credit -d ${current_name}-dm -w 1000 # execute after sleep nn
seconds after each VM startup. -dm is the stub device VM for HVMs. It is
temporary until next restart.

- Increasing the run-time of the final boot cycle, and possibly overlapping
>> that shutdown with the next creation. Utilize qvm-run shutdown.exe or
>> qvm-run a script instead of qvm-shutdown.
>>
>
> How can this be done?
>

$( sleep 360; qvm-run “${current_name}” “shutdown.exe /s /t 0” )& # I think

- Automate installation of xenvbd 8.2.2 or 8.2.1 after appropriate Windows
>> 7 updates are installed.
>>
>
> xenvbd = Qubes Tools ?
>

It’s in Xen tools, installed by Qubes tools but that module is not
installed by default by Qubes tools as it is buggy with unpatched win 7.
Since the script patches Win 7 it should be ok. I downloaded the 8.2.2
version of the xenvbd driver (don’t use unsigned daily build) from the xen
site and installed that manually. Then you can use qui-devices widget to
attach devices.

It’d be nice to add automating that to the winmgmt VM downloads, iso
mounting and installing steps.

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/CAOajFecXBxgPN1CEUEQXvn_80rthbd83e9z84r9wj0dWWruobg%40mail.gmail.com.

Re: [qubes-users] qvm-create-windows-qube Automatically creates

[Brendan Hoar]

Couple more:

- As windows 7 does not support SCSI unmap, and C and E are on virtual SCSI
devices: install sdelete by default and schedule sdelete.exe -z C:\ and
sdelete -z E:\ ... largish zero writes are caught at the lvm later and
unallocated from storage - plus passed on as discards to physical storage
if you’ve enabled this in Qubes (as per testing).

- Possibly work an initial defrag run into the deployment but before
sdelete as it saved about 1GB of LVM storage per VM (prob related to lvm
chunk size).

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/CAOajFeeBikBT%2B5HJfts5wGrNvYtpZqdy2beDSBCV6s3K%3Dqq%3DqA%40mail.gmail.com.

Re: [qubes-users] qvm-create-windows-qube Automatically creates

[brendan . hoar]

Hi crazyqube,

I've used this to generate 20-30 VMs. 

I've noticed some incomplete installs (50/50). There do seem to be come 
timing dependencies that sometimes cause failures. I'll be investigating 
these further next week.

I have some thoughts on changes I'll work on, if you're not planning to 
work on them, that might address some of these:

- Defaulting to debug=true so that boot problems can be easily diagnosed, 
with instructions on how the user should manually disable it when finished.
- Increasing the device-stub VM priority from 256 to 1000 during install 
utilizing xl sched-credit. This dramatically increases the IO throughput 
for the installation.
- Defaulting to no-network. For the most qubes usage, I think many of us 
won't plan to connect Windows to the internet.
- If network is explicitly set, only set it to the given option 
before/after the final boot cycle, to minimize interference.
- Increasing the run-time of the final boot cycle, and possibly overlapping 
that shutdown with the next creation. Utilize qvm-run shutdown.exe or 
qvm-run a script instead of qvm-shutdown.
- Refactor repeated code into bash functions.
-  Ensure loop devices in windows-mgmt are removed when finished (keep the 
qui-devices menu uncluttered)
- Perhaps restart windows-mgmt between VM creations.
- Automate installation of xenvbd 8.2.2 or 8.2.1 after appropriate Windows 
7 updates are installed.
- Document that xenvbd is needed for attaching block devices from 
qui-devices.
- Utilize double digit counter instead of single digit.
- Option to disable windows update permanantly.
- Option to initiate windows update on last reboot (after QWT is installed).
- Increase qrexec_timeout to 600 by default.

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/aa0b38ae-ec25-40cb-a0c4-0c92b3cd2be7%40googlegroups.com.

Re: [qubes-users] Re: Device showing up in Qubes sys-usb terminal but not devices icon, and attach error in dom0

[Brendan Hoar]

On Thu, Aug 29, 2019 at 3:02 AM rec wins  wrote:

>
> OTP won't ,  if the key does  more than U2F  you may need to  get  a
> configuration application for the key  and  make sure it's  U2F  only
> slot 1  , 2  etc
>

Yubikey OTP works through a keyboard-like HID, which are blacklisted by
default in Qubes. In order to directly attach a keyboard-like device to a
VM you have to override this setting.

See:
https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login

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/CAOajFedSWU1%2BTqk74Y%3DwjeSTV7kDgWnpPJXdr-LHRqQzOA8e_w%40mail.gmail.com.

Re: [qubes-users] qvm-create-windows-qube Automatically creates

[brendan . hoar]

On Tuesday, August 20, 2019 at 6:54:02 PM UTC-4, 799 wrote:
>
> Hello,
> On Tue, 20 Aug 2019 at 21:34, 'awokd' via qubes-users <
> qubes...@googlegroups.com > wrote:
>
>> 'crazyqube' via qubes-users:
>> > I just made my solution for fully automatically creating and installing 
>> new Windows qubes from scratch public! It pre-installs Qubes Windows Tools 
>> and Firefox so now you don't even have to open Internet Explorer to 
>> download a good browser! (lol)
>> > 
>> > If you have any issues or suggestions then by all means create an issue 
>> and I'll look into it.
>> > 
>
> I am trying to run through the process but want to do it by CLI from dom0 
> only.
> This would even allow more automation as we can write a script which will 
> do the last manuell steps like creating the windows-mgmt qube etc.
>

cq appears to have added your dom0 initiation steps, so kudos to both of 
you.

I opened an issue with dom0's $HOME value being passed to windows-mgmt, 
which fails to find the iso (admin vs user account name), but with a quick 
edit it's running now. Will report back.

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/a480c627-179b-4dfb-899f-5b12b411cf3c%40googlegroups.com.

Re: [qubes-users] KDE problems

[brendan . hoar]

On Tuesday, August 20, 2019 at 9:57:51 AM UTC-4, Chris Laprise wrote:
>
> On 8/20/19 8:58 AM, unman wrote: 
> > Otherwise seems fine to me, but I don't think I'm representative user. 
> > Custom mens, Activities, Kwin stuff works fine. 
> > 
> > Can any other KDE users chip in with problems that they still see? 
>
> 1. Qubes widgets (but not others, incl. domU widgets) sometimes require 
> multiple clicks just to activate them. I think this happens more under 
> high system load but not yet sure. Its frequent enough to feel like a 
> constant irritant. 
>

I don't think this issue is KDE-specific. My recollection is that marmarta 
said in one of the qubes-issues threads that the tray widgets are 
triggering a Gtk bug and that workarounds were in progress (or maybe 
already in -testing?).

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/c7731260-d4b9-4042-907e-4479f5b71f1d%40googlegroups.com.

Re: [qubes-users] Data recovery - data loss during cut and paste

[brendan . hoar]

On Monday, August 12, 2019 at 12:25:02 PM UTC-4, Chris Laprise wrote:
>
> On 8/12/19 10:50 AM, ger...@riseup.net  wrote: 
> > Chris Laprise: 
> >> On 8/12/19 9:37 AM, ger...@riseup.net  wrote: 
> >>> Is there a possibility, to recover data after moving it with cut and 
> >>> paste? 
> >>> 
> >>> Description what I did: 
> >>> I have a VM based on a Fedora 28 template (Qubes 4.0) and attached a 
> USB 
> >>> 3.0 SD reader with a SD card to that VM. 
> >>> I moved my complete folder with important offline e-mail data (appr. 
> >>> 500MB) from the VM to the SD card with cut and paste. 
> >>> The connection to the SD card was interrupted during moving, so the 
> data 
> >>> on the VM is lost and there is only a small part of it on the SD card 
> >>> now. 
> >>> There is no backup of that data to restore. 
> >>> I know it was stupid, not to use copy and paste and not to make a 
> backup 
> >>> :-( 
> >>> 
> >>> I didn't make a reboot of the VM and I didn't copy data on that VM 
> yet. 
> >>> Can the deleted data be restored somehow? 
> >>> 
> >>> Many thanks for each kind of help or hint! 
> >>> 
> >> 
> >> There is a chance you can recover the data. 
> >> 
> >> You said "I didn't make a reboot of the VM", and if your system is 
> >> still running and the VM has not been shut down since the incident, 
> >> you can simply clone the VM while it is still running. This will 
> >> create a clone VM in the same state (with the same data!) _before_ you 
> >> started the source VM. 
> >> 
> >> A VM's prior state (pre-startup) isn't removed from the system until 
> >> you shut down the VM. 
> >> 
> > 
> > It worked! Thanks a lot for the answer and thanks a lot for the Qubes 
> > team to develop such a safe working system. All my data could be 
> > restored without loss. 
> > 
>
> Really glad to hear it... kudos to people who ask for help in an 
> emergency and don't panic! :) 
>

Hear, hear! 

Nice one, Chris.

This is a great candidate for something to add to the new users guide for 
the Google Season of Docs effort!

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/864a80cf-02b9-49b7-9198-78be115fb5d2%40googlegroups.com.

Re: [qubes-users] best and less expensive Lenovo think pad

[brendan . hoar]

On Thursday, August 15, 2019 at 8:24:58 AM UTC-4, unman wrote:
>
> On Wed, Aug 14, 2019 at 04:26:18PM -0700, brend...@gmail.com  
> wrote: 
> > 1. That first USB device, which does not state where it can be used is 
> > either: 
> > a) The USB 2.0 interface "available" via the expresscard interface (some 
> > "expresscard" devices are really just USB 2.0 devices). 
> > b) The USB 2.0 interface available via the docking connector. 
>
> It's the dock. 
> I use 3 disposable USBVMs, each allocated 1 controller. 
>

Thanks unman. Thinking about it...that does make the most sense as some of 
the compatible docks can have quite a few USB 2.0 ports (presumably 
implemented as a hub) on them, so it make the most sense to have that 
controller separate.

I won't guarantee this, but I suspect that the "alternate" interface (USB 
2.0) in the expresscard slot is probably attached to the *primary* USB 2.0 
controller on the Thinkpads then.

Therefore the best approach in *most* cases where the user wants either 
best combined throughput or USB controller assignment flexibility is to 
utilize a 1-lane PCIe 1.0-based expresscard (e.g. with a one-or-two port 
USB 3.0 controller) instead of a USB 2.0-based expresscard.

Brendan

PS - The one caveat I will note with the expresscard interface is that it 
is an external PCIe interface, and may provide direct DMA into memory, 
similar to Firewire. You can see there are commercial products that utilize 
the expresscard interface here for memory forensics on running but locked 
machines: 
  https://www.forensicswiki.org/wiki/Tools:Memory_Imaging

I would be curious to see recent experiments showing how well Xen HVM IOMMU 
enforcement works to limit the scope of attacks using Expresscard, which 
Qubes + IOMMU *should* protect against. I just don't have the skills to 
create one or the $7800 it costs to purchase one of these devices (nor 
really the time) to do some testing...

For those overly concerned, they may want to investigate other preventative 
methods (e.g. Does BIOS disabling of the expresscard interface have a 
security impact? Are there physical modifications that would prevent usage 
of acquisition devices? Are there other software mitigation (power-off on 
attach, etc.))

-- 
You received this message because you are subscribed to the Google Groups 
"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/be63f72c-1495-484c-ab32-ed2b82ceb003%40googlegroups.com.

Re: [qubes-users] best and less expensive Lenovo think pad

[brendan . hoar]

On Wednesday, August 14, 2019 at 7:53:38 PM UTC-4, 799 wrote:
>
> Hello Brendan,
> > schrieb am Do., 15. Aug. 2019, 01:26:
>
>> (...)
>>
>> 1. That first USB device, which does not state where it can be used is 
>> either:
>> a) The USB 2.0 interface "available" via the expresscard interface (some 
>> "expresscard" devices are really just USB 2.0 devices).
>> b) The USB 2.0 interface available via the docking connector.
>>
>> ...some experimentation should lead to clarification.
>>
>
> You are very likely right, I have always asked myself why there is an USB 
> Controller which has no internal devices attached and doesn't connect to 
> any of the external USB slots. I have a docking station, so I will test 
> this.
>

Cool, let us know.
 

> 2. On my W520, I typically only attach the USB 2.0 controller to sys-usb 
>> (via PCI). That way, if I have to directly attach a storage device to a VM 
>> for IO-intensive uses, I can utilize a disposable HVM and attach the USB 
>> 3.0 controller directly to it.
>>
>
> The problem is, that the USB 3 Controller on the X230 has also the 
> internal WWAN Card connected, so of I attach it to an AppVM and not the 
> sys-usb Qube I am not able to pass the WWAN Card to my sys-net VM and use 
> LTE, which I need to rely on.
>

Ok, that's unfortunate. I keep an mSATA drive in that slot in my X230 units 
(and in the equivalent slot in the W520 units).

In any case, with the W520, I don't think the built-in USB 3.0 controller 
is connected to anything except for the two left-side ports, but I could be 
wrong. The docking connector on the W520 only supports up to USB 2.0, while 
USB 3.0 via docks is supported in the X230/Tx30/W530 models. All my docks 
have the eSATA port in the spot the later revisions placed the USB 3.0 
port. [Dock storage support may also explain a phantom /dev/sd? device you 
see from time to time in Thinkpads.]

3. Lastly, for those worried about having a flexible USB controller PCI 
>> layout (the ability to assign different controllers to different HVMs), 
>> there's a secret I'll share: the expresscard port on both the X230 and the 
>> W520 is a PCI port! And there are expresscards that provide USB 3.0 ports! 
>> Granted expresscard's maximum signaling rate of 2500Mbps is not quite 
>> 6000Mbps maximum of USB 3.0...but definitely faster than 480Mbps! The W520 
>> puts PCI devices mounted via the expresscard slot in their own grouping 
>> (e.g. a USB 3.0 expresscard)...again, experimentation will show whether the 
>> X230 does as well.
>>
>
> Ok, I'll give the Expresscard Slot a try, need to buy an adapter first...
>
> Any idea how I can test the speed of the interfaces afterwards?
> I would get a Expresscard-to-USB3-Adapter.
>

I would use the poor(-ish) man's throughput tester: 'time dd if=/dev/..." 
reads of a contemporary fast SSD connected via a USB 3->SATA III bridge 
that supports UAS.  Time trial A with the cable connected to the built-in 
USB 3.0 controller attached to an HVM, then trial B with the cable 
connected to the expresscard-USB3 "controller" attached to an HVM. Trial C 
with one of the USB 2.0 ports if you want.

Based on the advertised rates, I'd expect IO up to about 550MBps on the 
internal USB 3.0 ports,  220MBps on the express card USB 3.0 ports (due to 
intervening 1 x lane pcie 1.0) and 40MBps on the internal USB 2.0 ports.

I bought the cheapest expresscard adapter I could find on amazon, now 
currently listed as unavailable: 
https://www.amazon.com/gp/product/B07Q819QTF

It is recognized by dom0 (see below) but I haven't hooked it up yet.. I 
will note that I'll probably need to file down some of the plastic, it 
seems slightly too big for the slot when inserting it (again, it was cheap):

[admin@dom0 ~]$ lspci|grep USB
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #1 (rev 04)
05:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host 
Controller (rev 02)
*** 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host 
Controller (rev 04) ***

Lastly a minor warning: it's really easy to pull out the expresscard when 
removing a USB cable, just FYI.

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/de61d7a1-59d8-4101-a21e-94dd92aee666%40googlegroups.com.

Re: [qubes-users] best and less expensive Lenovo think pad

[brendan . hoar]

On Tuesday, August 13, 2019 at 3:54:58 PM UTC-4, 799 wrote:

> I have documented the Layout of the USB controllers here:
>
> https://github.com/one7two99/my-qubes/blob/master/docs/qubes-x230.md
>
> It shows which USB Controllers connects to which external USB Port and 
> which internal USB Devices like Camera / Bluetooth / LTE-Card belongs to 
> which USB Controller.
>
> Depending on which USB Controller you attach to a VM, you pass along all 
> attached internal USB Devices.
> Therefore I am a using a sys-usb Qube ;-)
>
> Regarding the other questions, I'll try to answer this later.
>
 
799,

1. That first USB device, which does not state where it can be used is 
either:
a) The USB 2.0 interface "available" via the expresscard interface (some 
"expresscard" devices are really just USB 2.0 devices).
b) The USB 2.0 interface available via the docking connector.

...some experimentation should lead to clarification.

2. On my W520, I typically only attach the USB 2.0 controller to sys-usb 
(via PCI). That way, if I have to directly attach a storage device to a VM 
for IO-intensive uses, I can utilize a disposable HVM and attach the USB 
3.0 controller directly to it.

3. Lastly, for those worried about having a flexible USB controller PCI 
layout (the ability to assign different controllers to different HVMs), 
there's a secret I'll share: the expresscard port on both the X230 and the 
W520 is a PCI port! And there are expresscards that provide USB 3.0 ports! 
Granted expresscard's maximum signaling rate of 2500Mbps is not quite 
6000Mbps maximum of USB 3.0...but definitely faster than 480Mbps! The W520 
puts PCI devices mounted via the expresscard slot in their own grouping 
(e.g. a USB 3.0 expresscard)...again, experimentation will show whether the 
X230 does as well.

B

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/39bf1576-f8fc-4720-839c-9c0203d7098c%40googlegroups.com.

Re: [qubes-users] Disk usage warning

[Brendan Hoar]

On Tue, Aug 13, 2019 at 4:52 AM Franz <169...@gmail.com> wrote:

> @brendan, @Chris Many thanks
>
>
>> Also: dom0 VM usage as well as all combined domU VMs usage is allocated
>> from the same shared thinpool pool00 in a default setup.
>>
>
> Now I understand.  Considering that Qubes-settings on Qubes Manager allows
> to set the System storage max size for each VM, I imagined that the alerts
> where connected to that, that is to a problem of a single VM. But now I
> understand that the alerts are connected to a general pool hosting all VMs.
> So it is not a problem of a single VM, rather of the pool.
>
> This way it is much simpler.  Qubes disk space monitor shows that 71% of
> the space is already used, and when I do and verify a backup it uses much
> more space to extract the backup, so this is the reason of the alerts.
>
> Many thanks brothers
>

Ok, that makes sense.

However now I am concerned that qubes backup verification can easily lead
to a pool full situation, which can be a fatal condition* for the pool and
the qubes install.

:(

B

* for typical users to resolve

>

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAOajFeeOAUhCvkR7FqhJOUOND9rh8364njHp%2BxqSYjU4O%3DQCcg%40mail.gmail.com.

Re: [qubes-users] Disk usage warning

[brendan . hoar]

On Monday, August 12, 2019 at 7:41:47 PM UTC-4, Francesco wrote:
>
> @Chris
> On Mon, Aug 12, 2019 at 1:22 PM Chris Laprise  > wrote:
>
>> On 8/12/19 12:03 PM, Franz wrote:
>> > On the upper right corner of the screen a black message alert:
>> > 
>> > Disk usage warning!
>> > You are running out of disk space. 4.8% space left in pool lvm. 
>>
> > So what should I do with that alert?
>>
>> Df is completely inaccurate when Qubes 4 is using the default (lvm).
>>
>> The best overall indicator to use is the disk space widget in the systray.
>>
>
> Thanks, I understand you are referring to a new plugin to add to the 
> panel. if you are using default Xfce. There is one called "Free Space 
> Checker" . 
>

No, there should already be one running in the upper right called "Qubes 
Disk Space Monitor". 
 

> The best way to view individual VM disk usage is from Qube Manager.
>
> Yes this shows disk usage for each VM , but no way to understand which VM 
> may have problems.
>
> In other words, an alert that does not tell which VM is involved have a 
> sort of terror effect. You understand that something can break every 
> moment, but no way to understand  where the problem is.
>

My general recommendation is:

1. Use the following to show the data usage in your thin pool (it should 
give the same percent as the "Qubes Disk Space Monitor":
sudo lvs qubes_dom0/pool00

2. Sort your VMs by size from largest to smallest in Qubes Manager, start 
one up, and execute the following, and repeat as necessary from largest to 
smallest.
sudo fstrim -av ; sudo shutdown -h now

3. Periodically check the pool usage via the "Qubes Disk Space Monitor" or 
the command in #1 above. If my hunch is correct, step #2 may recover some 
data.

If not, then start deleting VMs you don't need.

Also: dom0 VM usage as well as all combined domU VMs usage is allocated 
from the same shared thinpool pool00 in a default setup.

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/8183853f-8753-4c8c-a0f4-7e2c0c857aeb%40googlegroups.com.

[qubes-users] M.2 to PCIe Adapter play nice with qubes?

[brendan . hoar]

M.2 NVME SSD devices are just PCIe devices with a special connector. If your 
main board supports PCIe 3.0 then the adapter should work just like it was an 
onboard M.2 slot, with one possible exception: depending on the BIOS, it might 
not be a bootable device.

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/899e88ae-bd76-4da1-b350-5cbaa8a9f71d%40googlegroups.com.

[qubes-users] Re: Qubes-OS compatible SSD SAMSUNG.

[brendan . hoar]

On Thursday, August 1, 2019 at 7:28:09 AM UTC-4, gerard ribas vicente wrote:
>
> The qubes-os operating system is compatible with the following SSD disk 
> models:
>
> SAMSUNG 860 EVO?
> SAMSUNG860 QVO?
> SAMSUNG860 PRO?
>

Generally all contemporary SSDs are compatible. I have used the 860 EVO 
(both SATA and mSATA) successfully. The other two should work fine, as well.

>From a performance perspective, I currently avoid the QVO line, which 
utilize quad-level cells, as they do not meet performance expectations if 
one plans to move a lot of data in and out of the drive regularly. 

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/15968449-7db4-4dea-a570-cb46d3c3f230%40googlegroups.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Friday, July 26, 2019 at 1:24:57 PM UTC-4, Claudia wrote:

> Just to humor myself, I was going to try testing if I could hear sound 
> from Qubes after resume, but it seems audio isn't working at all. Which 
> is a whole 'nother problem. Aplay says "... unable to open slave; audio 
> open error: no such file or directory." `echo -e '\a'` doesn't work even 
> on a TTY (lsmod shows pcspkr), and `beep` isn't installed. 
>

Notably, Xen does not pass the real PC speaker device to dom0 and while it 
simulates it for dom0, it does not actually invoke the hardware. Something 
something considered dangerous to expose adjacent-to-speaker hardware in 
dom0, apparently.

So terminal beeps, etc. do nothing (except maybe flash the terminal window, 
depending on your config).

I use a snippet I got from google:
function create_beep () {
# create our beep file as xen does not expose the real "bell" device w/i
n the Qubes configuration and a simple echo "\007" does not work.
> /tmp/sinewave.wav
printf "\x52\x49\x46\x46\x64\x1F\x00\x00\x57\x41\x56\x45\x66\x6D\x74\x20
\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1F\x00\x00\x40\x1F\x00\x00\x01\x00\x08\x00
\x64\x61\x74\x61\x40\x1F\x00\x00" >> /tmp/sinewave.wav
for n in {0..999}
do
printf "\x80\x26\x00\x26\x7F\xD9\xFF\xD9" >> /tmp/sinewave.wav
done
}

And then invoke the following when I need a beep (probably should be made a 
function) in scripts dom0: 

  aplay -q /tmp/sinewave.wav --duration=1
 
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/cdc16c4b-a197-48e7-b9aa-6a487cd43383%40googlegroups.com.

Re: [qubes-users] Creating and running VMs on a RAM DISK?

[Brendan Hoar]

On Fri, Jul 26, 2019 at 11:31 AM unman  wrote:

> On Fri, Jul 26, 2019 at 05:57:02AM -0700, brendan wrote:
> > Or, should I just utilize the straightforward approach of adding the
> amount
> > of RAM I wish to use as a RAM disk to the baseline dom0 RAM
> configuration,
> > and then set up the RAM disk in dom0?
>
> Straightforward works fine.
> You can use file driver or create thin pool in /dev/shm and register it
> with Qubes as normal.


Thanks unman. Hmm tmpfs can swap (though unusual). Hmm...thinking LVM on
ramfs if there is plenty of RAM, maybe, as ramfs isn’t supposed to swap.

Of course if a randomly keyed encryption layer is involved, i’d lean
towards LVM on tmpfs.

I’m curious how and when tmpfs knows to release memory. Another rabbit
hole...

For safety I delete qubes, clean up and deregister...
>

I too cleanup for various reasons, including that the disk usage widget
doesn’t like registered but missing pools (it reports divide by zero error
and exits).

Thanks!
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/CAOajFed%3DYF29ceFY7YaqtYWaW2L_ML7t6P9pC03sw-OJ%2BGLbOg%40mail.gmail.com.

[qubes-users] Creating and running VMs on a RAM DISK?

[brendan . hoar]

Hi,

Does XEN expose any sort of configuration-controlled feature or interface 
that would sets aside XEN-owned memory in a way that can be exposed as a 
block device within dom0, for use as a RAM disk?

Or, should I just utilize the straightforward approach of adding the amount 
of RAM I wish to use as a RAM disk to the baseline dom0 RAM configuration, 
and then set up the RAM disk in dom0?

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/ade46719-2d43-4b40-b023-0e4b88b474d4%40googlegroups.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Thursday, July 25, 2019 at 12:16:00 PM UTC-4, Chris Laprise wrote:
>
> On 7/25/19 11:04 AM, brend...@gmail.com  wrote: 
> > I was able to install that particular test build on a Thinkpad X230 for 
> > testing: https://openqa.qubes-os.org/tests/3021 
> > 
> > (note: click on assets tab for link to download the ISO) 
>
> Interesting link! 
>

As a side note, when you opened the ticket asking about back-porting 
"lvm-thin tools" to R4.01 (Fedora 25) for your backup tool work...I was 
wondering if you were aware that some of the (again, very very early test) 
builds of R4.1 were semi usable. 

Not that we should have to wait to do fast, stable backups until R4.1... :)
 
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/0f6a61b5-a5e4-4cc0-a5fa-ec1d55e80df9%40googlegroups.com.

[qubes-users] Re: is it possible to have two sys-net for one firewall vm?

[brendan . hoar]

Use xentop -f to show full names.

Those are likely the stub domains used for device handling, etc.

-- 
You received this message because you are subscribed to the Google Groups 
"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/b33a3364-c696-4489-b209-10f5d8a5fc1c%40googlegroups.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Brendan Hoar]

On Thu, Jul 25, 2019 at 12:15 PM Chris Laprise  wrote:

> If it doesn't work, then the problem is probably entirely in dom0 and
> Fedora 25. Assuming you already have the testing 4.19 kernel, have you
> thought of upgrading it to the even newer 5.x one as 'latest'? The
> latest kernel is installed by specifying the special package named
> 'kernel-latest'.


qubes-dom0-update kernel-latest # will update available dom0 kernels list
and sets most recent as default

qubes-dom0-update kernel-latest-qubes-vm # will update available VM kernels
list and requires manual checking to see if it changed your global defaults
and/or changed a per-VM kernel setting when older ones are removed

I use both and generally pull from current + current-testing repos.
Currently running 5.1.17-1 in dom0 and a mix in VMs under R4.01.

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/CAOajFeeHFK_kngBYcPou%2BQLeqrg1Ef92j05_s7%3DGDUYXAE0iPw%40mail.gmail.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Thursday, July 25, 2019 at 10:18:29 AM UTC-4, awokd wrote:
>
> > Are there any other Xen-based distros out there I could test? 
>
> You can add Xen to your stock Fedora install. That takes it roughly to 
> where Qubes begins, but you might want to use the same version of Fedora 
> dom0 uses. 
>
>
Claudia:

I'm sure the *last* thing you want to do is add additional variables, as 
things are easier to diagnose with fewer, but...

...there are very very early test-builds of Qubes R4.1 out there utilizing 
Xen 4.12 and Fedora 30. This 2019-07-01 build appears semi-stable in light 
testing. It is, at a high level (and Marek can correct me if I am wrong), 
the R4.01 codebase with up-to-date Xen and dom0 Fedora w/ any Qubes-related 
changes to ensure these work with the Qubes code base. 

I was able to install that particular test build on a Thinkpad X230 for 
testing: https://openqa.qubes-os.org/tests/3021

(note: click on assets tab for link to download the ISO)

It might be worth installing one of those as well on another drive to see 
if newer Xen/Fedora combinations resolve sleep issues or get you closer to 
resolution.

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/141ed585-2869-485b-9716-33bb5b2a1c16%40googlegroups.com.

Re: [qubes-users] Using Salt to update TemplateVMs

[brendan . hoar]

On Tuesday, July 16, 2019 at 10:35:11 AM UTC-4, unman wrote:
> I really do recommend using qubesctl for almost all system
> configuration. If only because it makes recovery so much easier.
> I see people saying "keep a list of packages you've installed" - if you
> keep state and use salt you can rebuild your system (almost) completely
> automatically.

Do you happen to have some example "personalized" salt scripts you use (or a 
pointer to where someone has posted some)?

I was planning to put together some bash scripts to push configuration into my 
templates (90% repo adjustments and specific packages to download), but your 
comment above is intriguing.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/46f4a28d-fe95-4ce3-abad-162ccd8d5a4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-ls --fields name,madmen,memory

[brendan . hoar]

On Sunday, July 14, 2019 at 8:04:27 AM UTC-4, unman wrote:
> On Sun, Jul 14, 2019 at 04:34:04AM -0700, bxx...@gmail.com wrote:
> > When I run the above command, the memory column is always set to ???-??? in 
> > the output. Am I using the wrong field name?
> No, right name but doesnt output. maxmem works.

Ok, issue opened. Thanks.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cf3ba04b-8a32-4158-a251-1791005d17d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] qvm-ls --fields name,madmen,memory

[brendan . hoar]

Madmen=maxmem, thank you autocorrect. :/

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

[qubes-users] qvm-ls --fields name,madmen,memory

[brendan . hoar]

When I run the above command, the memory column is always set to “-“ in the 
output. Am I using the wrong field name?

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8f2a03f5-304e-431c-9b71-3f795c8581b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VPN before sys-firewall ?

[brendan . hoar]

I’m currently using:

VMs -> sys-mirage-fw-int -> sys-vpn-tasket-> sys-mirage-fw-ext -> sys-net

Benefit of mirage in this situation is that each one consumes only 32MB of RAM.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/07410923-e42e-4daa-8cbd-506eca9acc5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: whonix workstation 15 browser dropped both noscript and https

[brendan . hoar]

I believe this is an upstream torbrowser decision.

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

Re: [qubes-users] Re: What is the path to the usb drive in sys-usb?

[brendan . hoar]

On my machine I have a sys-usb for only the usb 2.0 controller and a separately 
set up sys-usb-3 for the usb 3.0 controller.

I found the I/O performance of using qvm-usb ok for moving small amounts of 
data on and off the system. For heavier I/O, I ensure the sys-usb-3 VM is shut 
down and connect the USB 3.0 PCI device to the target VM in its Qubes Settings 
before starting the VM up. Effectively, that gives the VM native IO capability 
between the VM and the USB 3 device.

That should work for a Windows VM.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e749a891-1e93-4e0e-95da-8a9c19db0df2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: What is the path to the usb drive in sys-usb?

[brendan . hoar]

On Monday, July 8, 2019 at 3:55:08 PM UTC-4, brend...@gmail.com wrote:
> On Monday, July 8, 2019 at 11:14:41 AM UTC-4, oak...@gmail.com wrote:
> > Easy question, but I'm a noob:  What is the path to the usb drive that is 
> > connecting through sys-usb?  I am trying to get the usb to startup with a 
> > certain vm.  Thanks.
> 
> Since the VMs use /dev/xvd[a-d] as the operational drives, the entire 
> /dev/sd_ list isn't used unless you attach a USB driver.
> 
> Therefore, your first USB drive will be dev/sda (/dev/sda1 for the first 
> partition, etc.).
> 
> If you're feeling lazy like I do, try running gnome-disks and it'll show you.
> 
> Brendan

Oops, my bad. In sys-usb it is /dev/sdX.

In the VM that you pulled it from sys-usb into, it's going to be 
"/dev/xvd[i-z]".

[a-d] are taken by the Qubes-owned LVs. [e,f,g,h] are skipped. [i-z] are 
available for storage pass through.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/63b57f19-7732-47c3-b60a-24794260163a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: What is the path to the usb drive in sys-usb?

[brendan . hoar]

On Monday, July 8, 2019 at 11:14:41 AM UTC-4, oak...@gmail.com wrote:
> Easy question, but I'm a noob:  What is the path to the usb drive that is 
> connecting through sys-usb?  I am trying to get the usb to startup with a 
> certain vm.  Thanks.

Since the VMs use /dev/xvd[a-d] as the operational drives, the entire /dev/sd_ 
list isn't used unless you attach a USB driver.

Therefore, your first USB drive will be dev/sda (/dev/sda1 for the first 
partition, etc.).

If you're feeling lazy like I do, try running gnome-disks and it'll show you.

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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/98089edd-525b-44ab-b518-535805c76e81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] sys-net fails to load ath10k_pci after fedora-29 update

[Brendan Hoar]

I think it was the kernel-latest-qubes-vm package from the -testing repo.

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