[qubes-users] usb keyboard not working on debian 11 template

2021-08-25 Thread 'qtpie' via qubes-users

Hi,

Question: does a template qube need some kind of modification to let a 
sys-usb qube based on that template work with usb keyboards?


Issue: On a debian 10 template, my usb keyboard/mouse combo 'just 
worked'(tm):

1. I have a default sys-usb qube
2. I attach the keyboard device (either before or after startup, tried both)
3. I get the 'Device X is available' notification
4. I can use the device both inside the sys-usb qube and in other qubes 
and in dom0



When I switch the sys-usb to a debian 11 template:
(same)
4. I can use the keyboard inside the sys-usb qube, not in other qubes. 
The mousepointer does not respond at all.


How can I troubleshoot this? thanks for your suggestions.


---

fyi, this is my only problem with debian 11 as the default template, 
multiple applications seem to work smoother when compared to debian 10.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6ab45cb8-2d62-c3fe-fd6a-66e8c5db083a%40disroot.org.


Re: [qubes-users] Qubes-backup verify only verifies dom0, not appVMs

2021-08-25 Thread Andrew David Wong

On 8/25/21 4:03 AM, tetrahedra via qubes-users wrote:

When I verify my backups, it happens ~instantaneously. It used to take
hours, because it would extract every VM backup and verify it. Judging
by the logs, it's only verifying dom0.

Unless something has changed with how Qubes verifies its backups, there
may be a bug that causes verification to only check dom0, rather than
verifying the AppVMs as well.

This is really bad, because what I care about is the data in the
AppVMs... being able to restore the AppVMs is more important than being
able to restore dom0!


Here's how I back up:
```
nice qvm-backup \
 --verbose \
 --passphrase-file $PASSFILE \
 --exclude $IGNORE_VM \
 --dest-vm $DEST_VM \
 --compress \
 --yes \
 $BACKUP_DIR
```

And here's how I restore:
```
qvm-backup-restore \
 --dest-vm $DEST_VM \
 --passphrase-file $PASSFILE \
 --verify-only \
 --verbose \
 $BACKUP_FILE
```

When it starts restoring, it shows that none of my VMs will be restored,
except for dom0:
```
The following VMs are included in the backup:

+--+---+-++ 

    name | type |  template |   
netvm |  label |
+--+---+-++ 

    dom0 |  AdminVM |   n/a |   
(default) |  black |
    myvm | StandaloneVM |   n/a | 
my-net-vm-x | orange | <-- Excluded from restore
     my-other-vm-xxx |    AppVM | debian-10 |   
(default) |   blue | <-- Excluded from restore
   another-vm-xx |    AppVM | fedora-33 |   
(default) |  green | <-- Excluded from restore

   [... continuing for the list of all VMs ...]
```

And in fact only dom0 gets verified, the others seem to be ignored.



I cannot seem to reproduce this. My verify-only attempts also verify 
domUs. I'm using the same qvm-backup-restore command, just without 
`--verbose`.


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/048fc3f8-aa41-bb19-5ca0-77cac43d872b%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] XSAs released on 2021-08-25

2021-08-25 Thread Andrew David Wong

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is affected* by one or more of these XSAs.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)


The following XSAs *do affect* the security of Qubes OS:

  - XSA-378
  - XSA-379
  - XSA-382

Please see *QSB-070* for the actions users must take in order to protect
themselves, as well as further details about these XSAs:




XSAs that do not affect the security of Qubes OS (no user action required)
--

The following XSAs *do not affect* the security of Qubes OS, and no user 
action is necessary:


  - XSA-380 (denial of service only)
  - XSA-383 (affects only Arm systems)


Related links
-

  - Xen Project XSA list: 
  - Qubes XSA tracker: 
  - Qubes security pack (qubes-secpack): 

  - Qubes security bulletins (QSBs): 



This announcement is also available on the Qubes website:


--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a79417f5-bae1-218b-8d0a-79fbca09ba4c%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] QSB-070: Xen issues related to grant tables v2 and IOMMU

2021-08-25 Thread Andrew David Wong

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 070:
Xen issues related to grant tables v2 and IOMMU.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack 
(qubes-secpack).


View QSB-070 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```


  ---===[ Qubes Security Bulletin 070 ]===---

  2021-08-25


Xen issues related to grant tables v2 and IOMMU
 (XSA-378, XSA-379, XSA-382)


User action required
=

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

   For Qubes 4.0, in dom0:
   - Xen packages, version 4.8.5-35

   For Qubes 4.1, in dom0:
   - Xen packages, version 4.14.2-2

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.


Summary


The following security advisories were published on 2021-08-25:

XSA-378 [3] "IOMMU page mapping issues on x86":

| Both AMD and Intel allow ACPI tables to specify regions of memory
| which should be left untranslated, which typically means these
| addresses should pass the translation phase unaltered.  While these
| are typically device specific ACPI properties, they can also be
| specified to apply to a range of devices, or even all devices.
|
| On all systems with such regions Xen failed to prevent guests from
| undoing/replacing such mappings (CVE-2021-28694).
|
| On AMD systems, where a discontinuous range is specified by firmware,
| the supposedly-excluded middle range will also be identity-mapped
| (CVE-2021-28695).
|
| Further, on AMD systems, upon de-assigment of a physical device from a
| guest, the identity mappings would be left in place, allowing a guest
| continued access to ranges of memory which it shouldn't have access to
| anymore (CVE-2021-28696).
|

XSA-379 [4] "grant table v2 status pages may remain accessible after
de-allocation":

| Guest get permitted access to certain Xen-owned pages of memory.  The
| majority of such pages remain allocated / associated with a guest for
| its entire lifetime.  Grant table v2 status pages, however, get
| de-allocated when a guest switched (back) from v2 to v1.  The freeing
| of such pages requires that the hypervisor know where in the guest
| these pages were mapped.  The hypervisor tracks only one use within
| guest space, but racing requests from the guest to insert mappings of
| these pages may result in any of them to become mapped in multiple
| locations.  Upon switching back from v2 to v1, the guest would then
| retain access to a page that was freed and perhaps re-used for other
| purposes.
|
| A malicious guest may be able to elevate its privileges to that of the
| host, cause host or guest Denial of Service (DoS), or cause information
| leaks.

XSA-382 [5] "inadequate grant-v2 status frames array bounds check"
| The v2 grant table interface separates grant attributes from grant
| status.  That is, when operating in this mode, a guest has two tables.
| As a result, guests also need to be able to retrieve the addresses that
| the new status tracking table can be accessed through.
|
| For 32-bit guests on x86, translation of requests has to occur because
| the interface structure layouts commonly differ between 32- and 64-bit.
|
| The translation of the request to obtain the frame numbers of the
| grant status table involves translating the resulting array of frame
| numbers.  Since the space used to carry out the translation is limited,
| the translation layer tells the core function the capacity of the array
| within translation space.  Unfortunately the core function then only
| enforces array bounds to be below 8 times the specified value, and would
| write past the available space if enough frame numbers needed storing.
|
| Malicious or buggy guest kernels may be able to mount a Denial of
| Service (DoS) attack affecting the entire system.  Privilege escalation
| and information leaks cannot be ruled out.


Impact
===

XSA-378:

As the Xen Security Team explains, "The precise impact is system
specific, but can - on affected systems - be any or all of privilege
escalation, denial of service, or information leaks." Only 

[qubes-users] Qubes-backup verify only verifies dom0, not appVMs

2021-08-25 Thread tetrahedra via qubes-users

When I verify my backups, it happens ~instantaneously. It used to take
hours, because it would extract every VM backup and verify it. Judging
by the logs, it's only verifying dom0.

Unless something has changed with how Qubes verifies its backups, there
may be a bug that causes verification to only check dom0, rather than
verifying the AppVMs as well.

This is really bad, because what I care about is the data in the
AppVMs... being able to restore the AppVMs is more important than being
able to restore dom0!


Here's how I back up:
```
nice qvm-backup \
--verbose \
--passphrase-file $PASSFILE \
--exclude $IGNORE_VM \
--dest-vm $DEST_VM \
--compress \
--yes \
$BACKUP_DIR
```

And here's how I restore:
```
qvm-backup-restore \
--dest-vm $DEST_VM \
--passphrase-file $PASSFILE \
--verify-only \
--verbose \
$BACKUP_FILE
```

When it starts restoring, it shows that none of my VMs will be restored,
except for dom0:
```
The following VMs are included in the backup:

+--+---+-++
   name | type |  template |   netvm |  
label |
+--+---+-++
   dom0 |  AdminVM |   n/a |   (default) |  
black |
   myvm | StandaloneVM |   n/a | my-net-vm-x | 
orange | <-- Excluded from restore
my-other-vm-xxx |AppVM | debian-10 |   (default) |   
blue | <-- Excluded from restore
  another-vm-xx |AppVM | fedora-33 |   (default) |  
green | <-- Excluded from restore
  [... continuing for the list of all VMs ...]
```

And in fact only dom0 gets verified, the others seem to be ignored.

--
You received this message because you are subscribed to the Google Groups 
"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/YSYjit8%2BhYGbkJrI%40danwin1210.me.