Qubes Security Bulletin #32: Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
52 views
Skip to first unread message
Andrew David Wong
Aug 15, 2017, 9:31:41 AM8/15/17
to qubes-a...@googlegroups.com, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #32:
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230).
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 #32 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-032-2017.txt>
Learn about the qubes-secpack, including how to obtain, verify, and read it:
<https://www.qubes-os.org/security/pack/>
View all past QSBs:
<https://www.qubes-os.org/security/bulletins/>
View XSA-226 through XSA-230 in the XSA Tracker:
<https://www.qubes-os.org/security/xsa/>
```
---===[ Qubes Security Bulletin #32 ]===---
August 15, 2017
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
Summary
========
The Xen Security Team released several Xen Security Advisories today (XSA-226
through XSA-230) related to the grant tables mechanism used to share memory
between domains. The impact of these advisories ranges from data leaks to
system crashes and privilege escalations. See our commentary below for details.
Technical details
==================
Xen Security Advisory 226 [1]:
| Code to handle copy operations on transitive grants has built in retry
| logic, involving a function reinvoking itself with unchanged
| parameters. Such use assumes that the compiler would also translate
| this to a so called "tail call" when generating machine code.
| Empirically, this is not commonly the case, allowing for theoretically
| unbounded nesting of such function calls.
| | A malicious or buggy guest may be able to crash Xen. Privilege
| escalation and information leaks cannot be ruled out.
Xen Security Advisory 227 [2]:
| When mapping a grant reference, a guest must inform Xen of where it
| would like the grant mapped. For PV guests, this is done by nominating
| an existing linear address, or an L1 pagetable entry, to be altered.
| | Neither of these PV paths check for alignment of the passed parameter.
| The linear address path suitably truncates the linear address when
| calculating the L1 entry to use, but the path which uses a directly
| nominated L1 entry performs no checks.
| | This causes Xen to make an incorrectly-aligned update to a pagetable,
| which corrupts both the intended entry and the subsequent entry with
| values which are largely guest controlled. If the misaligned value
| crosses a page boundary, then an arbitrary other heap page is
| corrupted.
| | A PV guest can elevate its privilege to that of the host.
Xen Security Advisory 228 [3]:
| The grant table code in Xen has a bespoke semi-lockfree allocator for
| recording grant mappings ("maptrack" entries). This allocator has a
| race which allows the free list to be corrupted.
| | Specifically: the code for removing an entry from the free list, prior
| to use, assumes (without locking) that if inspecting head item shows
| that it is not the tail, it will continue to not be the tail of the
| list if it is later found to be still the head and removed with
| cmpxchg. But the entry might have been removed and replaced, with the
| result that it might be the tail by then. (The invariants for the
| semi-lockfree data structure were never formally documented.)
| | Additionally, a stolen entry is put on the free list with an incorrect
| link field, which will very likely corrupt the list.
| | A malicious guest administrator can crash the host, and can probably
| escalate their privilege to that of the host.
Xen Security Advisory 229 [4]:
| The block layer in Linux may choose to merge adjacent block IO requests.
| When Linux is running as a Xen guest, the default merging algorithm is
| replaced with a Xen-specific one. When Linux is running as an x86 PV
| guest, some BIO's are erroneously merged, corrupting the data stream
| to/from the block device.
| | This can result in incorrect access to an uncontrolled adjacent frame.
| | A buggy or malicious guest can cause Linux to read or write incorrect
| memory when processing a block stream. This could leak information from
| other guests in the system or from Xen itself, or be used to DoS or
| escalate privilege within the system.
Xen Security Advisory 230 [5]:
| Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
| guest that a grant is in use. A guest is expected not to modify the
| grant details while it is in use, whereas the guest is free to
| modify/reuse the grant entry when it is not in use.
| | Under some circumstances, Xen will clear the status bits too early,
| incorrectly informing the guest that the grant is no longer in use.
| | A guest may prematurely believe that a granted frame is safely private
| again, and reuse it in a way which contains sensitive information, while
| the domain on the far end of the grant is still using the grant.
Commentary from the Qubes Security Team
========================================
It looks like the most severe of the vulnerabilities published today is
XSA-227, which is another example of a bug in memory management code for
para-virtualized (PV) VMs. As discussed before, in Qubes 4.0 [6], we've decided
to retire the use of PV virtualization mode in favour of fully virtualized VMs,
precisely in order to to prevent this class of vulnerabilities from affecting
the security of Qubes OS. We note however, that Qubes 3.2 uses PV for all VMs
by default.
XSA-228 seems to be another potentially serious vulnerability. While this does
not seem to be limited only to PV virtualization, we should note that it is a
race condition type of bug. Such types of vulnerabilities are typically
significantly more difficult to reliably exploit in practice.
The remaining vulnerabilities (XSA-229 and XSA-230) look even more theoretical.
We should also note that XSA-229 is a vulnerability in the Linux kernel's
implementation of the Xen PV block (disk) backend, not in the Xen hypervisor.
The Qubes architecture partly mitigates potential successful attacks exploiting
this vulnerability thanks to offloading some of the storage backend to USB and
(optionally) other VMs. The main system block backend still runs in dom0,
however, hence the inclusion of this bug in the bulletin.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which was
designed specifically to aid in the recovery of a (potentially) compromised
Qubes OS system. Thus, if you believe your system might have been compromised
(perhaps because of the bugs discussed in this bulletin), then you should read
and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-29
- Kernel packages, version 4.9.35-20
For Qubes 4.0:
- Xen packages, version 4.8.1-5
- Kernel packages, version 4.9.35-20
The packages are to be installed in dom0 via the qubes-dom0-update command or
via the Qubes VM Manager. A system restart will be required afterwards.
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 and kernel binaries,
and because of the regenerated initramfs.
These packages will migrate to the current (stable) repository over the next
two weeks after being tested by the community.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-226.html
[2] https://xenbits.xen.org/xsa/advisory-227.html
[3] https://xenbits.xen.org/xsa/advisory-228.html
[4] https://xenbits.xen.org/xsa/advisory-229.html
[5] https://xenbits.xen.org/xsa/advisory-230.html
[6] https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/
- --
The Qubes Security Team
https://www.qubes-os.org/security/
```
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZkvepAAoJENtN07w5UDAwQbsP/iIKgpqMmqDka7CS7kzXTVce
D2z+zQnXqnomB7Y6zGyw57zJXSSrU/W00oGNtUddxoBITE8P8FpYEpbhP/cYAA4+
bpxUVN1vSQjuAf4XUUol3296+Vg7sOb3MYGDDV1cxf6ps2Gr82piQWfGf5pqHtxj
jMzCi7FBDdeXxFegLpM2ApoGSrS8Z5BCzZymfwnlMsRtSbn0n59sbc348sxFU9mq
CFQIcM/7wLNrY7Pw7pjSYmK7sC+QeK641t6KYLNjM43LkSQH3If+mq48f3LXNAkl
dicTztuvChEGkBhq2iTccxXOSObNjDS0YoqMxncf0twIw3ZmudEwxWq9IYv3GTy/
+AeMYfuvCGRpCIEg1oEF+4/6GqEHEtzFfVgT6s7xQrGDPx2jx5oBec+zqSX4UkSP
Ygaic5vuty+4Q6cBb49vaDfsJ8pyFaZNKlP+lqgIO/CS8yp2O0RyU1QoZsyndPFR
qDtjumaqiWVEz6c70idQB7+S+vBBePPsKJxwK9N+pPb+F1qi2SGIpj22sR0TWsbQ
I8I8URMmuEmLcFa+JFNJu4+809kBs/uQ2br8pArid/B1n1u9i46bZUOnlE1tlvJ3
hSYIyoag+6v/ivzPFpy1mbl0Djhfx2WVHedmn/wFl58PZ8tuffAMXAjiAz0lTzEL
icxDG4dP5Se1hbaGxD9o
=2txO
-----END PGP SIGNATURE-----
Hash: SHA512
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #32:
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230).
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 #32 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-032-2017.txt>
Learn about the qubes-secpack, including how to obtain, verify, and read it:
<https://www.qubes-os.org/security/pack/>
View all past QSBs:
<https://www.qubes-os.org/security/bulletins/>
View XSA-226 through XSA-230 in the XSA Tracker:
<https://www.qubes-os.org/security/xsa/>
```
---===[ Qubes Security Bulletin #32 ]===---
August 15, 2017
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
Summary
========
The Xen Security Team released several Xen Security Advisories today (XSA-226
through XSA-230) related to the grant tables mechanism used to share memory
between domains. The impact of these advisories ranges from data leaks to
system crashes and privilege escalations. See our commentary below for details.
Technical details
==================
Xen Security Advisory 226 [1]:
| Code to handle copy operations on transitive grants has built in retry
| logic, involving a function reinvoking itself with unchanged
| parameters. Such use assumes that the compiler would also translate
| this to a so called "tail call" when generating machine code.
| Empirically, this is not commonly the case, allowing for theoretically
| unbounded nesting of such function calls.
| | A malicious or buggy guest may be able to crash Xen. Privilege
| escalation and information leaks cannot be ruled out.
Xen Security Advisory 227 [2]:
| When mapping a grant reference, a guest must inform Xen of where it
| would like the grant mapped. For PV guests, this is done by nominating
| an existing linear address, or an L1 pagetable entry, to be altered.
| | Neither of these PV paths check for alignment of the passed parameter.
| The linear address path suitably truncates the linear address when
| calculating the L1 entry to use, but the path which uses a directly
| nominated L1 entry performs no checks.
| | This causes Xen to make an incorrectly-aligned update to a pagetable,
| which corrupts both the intended entry and the subsequent entry with
| values which are largely guest controlled. If the misaligned value
| crosses a page boundary, then an arbitrary other heap page is
| corrupted.
| | A PV guest can elevate its privilege to that of the host.
Xen Security Advisory 228 [3]:
| The grant table code in Xen has a bespoke semi-lockfree allocator for
| recording grant mappings ("maptrack" entries). This allocator has a
| race which allows the free list to be corrupted.
| | Specifically: the code for removing an entry from the free list, prior
| to use, assumes (without locking) that if inspecting head item shows
| that it is not the tail, it will continue to not be the tail of the
| list if it is later found to be still the head and removed with
| cmpxchg. But the entry might have been removed and replaced, with the
| result that it might be the tail by then. (The invariants for the
| semi-lockfree data structure were never formally documented.)
| | Additionally, a stolen entry is put on the free list with an incorrect
| link field, which will very likely corrupt the list.
| | A malicious guest administrator can crash the host, and can probably
| escalate their privilege to that of the host.
Xen Security Advisory 229 [4]:
| The block layer in Linux may choose to merge adjacent block IO requests.
| When Linux is running as a Xen guest, the default merging algorithm is
| replaced with a Xen-specific one. When Linux is running as an x86 PV
| guest, some BIO's are erroneously merged, corrupting the data stream
| to/from the block device.
| | This can result in incorrect access to an uncontrolled adjacent frame.
| | A buggy or malicious guest can cause Linux to read or write incorrect
| memory when processing a block stream. This could leak information from
| other guests in the system or from Xen itself, or be used to DoS or
| escalate privilege within the system.
Xen Security Advisory 230 [5]:
| Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
| guest that a grant is in use. A guest is expected not to modify the
| grant details while it is in use, whereas the guest is free to
| modify/reuse the grant entry when it is not in use.
| | Under some circumstances, Xen will clear the status bits too early,
| incorrectly informing the guest that the grant is no longer in use.
| | A guest may prematurely believe that a granted frame is safely private
| again, and reuse it in a way which contains sensitive information, while
| the domain on the far end of the grant is still using the grant.
Commentary from the Qubes Security Team
========================================
It looks like the most severe of the vulnerabilities published today is
XSA-227, which is another example of a bug in memory management code for
para-virtualized (PV) VMs. As discussed before, in Qubes 4.0 [6], we've decided
to retire the use of PV virtualization mode in favour of fully virtualized VMs,
precisely in order to to prevent this class of vulnerabilities from affecting
the security of Qubes OS. We note however, that Qubes 3.2 uses PV for all VMs
by default.
XSA-228 seems to be another potentially serious vulnerability. While this does
not seem to be limited only to PV virtualization, we should note that it is a
race condition type of bug. Such types of vulnerabilities are typically
significantly more difficult to reliably exploit in practice.
The remaining vulnerabilities (XSA-229 and XSA-230) look even more theoretical.
We should also note that XSA-229 is a vulnerability in the Linux kernel's
implementation of the Xen PV block (disk) backend, not in the Xen hypervisor.
The Qubes architecture partly mitigates potential successful attacks exploiting
this vulnerability thanks to offloading some of the storage backend to USB and
(optionally) other VMs. The main system block backend still runs in dom0,
however, hence the inclusion of this bug in the bulletin.
Compromise Recovery
====================
Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which was
designed specifically to aid in the recovery of a (potentially) compromised
Qubes OS system. Thus, if you believe your system might have been compromised
(perhaps because of the bugs discussed in this bulletin), then you should read
and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-29
- Kernel packages, version 4.9.35-20
For Qubes 4.0:
- Xen packages, version 4.8.1-5
- Kernel packages, version 4.9.35-20
The packages are to be installed in dom0 via the qubes-dom0-update command or
via the Qubes VM Manager. A system restart will be required afterwards.
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 and kernel binaries,
and because of the regenerated initramfs.
These packages will migrate to the current (stable) repository over the next
two weeks after being tested by the community.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-226.html
[2] https://xenbits.xen.org/xsa/advisory-227.html
[3] https://xenbits.xen.org/xsa/advisory-228.html
[4] https://xenbits.xen.org/xsa/advisory-229.html
[5] https://xenbits.xen.org/xsa/advisory-230.html
[6] https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/
- --
The Qubes Security Team
https://www.qubes-os.org/security/
```
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZkvepAAoJENtN07w5UDAwQbsP/iIKgpqMmqDka7CS7kzXTVce
D2z+zQnXqnomB7Y6zGyw57zJXSSrU/W00oGNtUddxoBITE8P8FpYEpbhP/cYAA4+
bpxUVN1vSQjuAf4XUUol3296+Vg7sOb3MYGDDV1cxf6ps2Gr82piQWfGf5pqHtxj
jMzCi7FBDdeXxFegLpM2ApoGSrS8Z5BCzZymfwnlMsRtSbn0n59sbc348sxFU9mq
CFQIcM/7wLNrY7Pw7pjSYmK7sC+QeK641t6KYLNjM43LkSQH3If+mq48f3LXNAkl
dicTztuvChEGkBhq2iTccxXOSObNjDS0YoqMxncf0twIw3ZmudEwxWq9IYv3GTy/
+AeMYfuvCGRpCIEg1oEF+4/6GqEHEtzFfVgT6s7xQrGDPx2jx5oBec+zqSX4UkSP
Ygaic5vuty+4Q6cBb49vaDfsJ8pyFaZNKlP+lqgIO/CS8yp2O0RyU1QoZsyndPFR
qDtjumaqiWVEz6c70idQB7+S+vBBePPsKJxwK9N+pPb+F1qi2SGIpj22sR0TWsbQ
I8I8URMmuEmLcFa+JFNJu4+809kBs/uQ2br8pArid/B1n1u9i46bZUOnlE1tlvJ3
hSYIyoag+6v/ivzPFpy1mbl0Djhfx2WVHedmn/wFl58PZ8tuffAMXAjiAz0lTzEL
icxDG4dP5Se1hbaGxD9o
=2txO
-----END PGP SIGNATURE-----
Holger Levsen
Aug 15, 2017, 10:00:07 AM8/15/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
Hi,
first of all: thanks for this handling this update!
On Tue, Aug 15, 2017 at 08:31:31AM -0500, Andrew David Wong wrote:
> Patching
> =========
[...]
paragraphs seems to imply one can simply upgrade packages as usual, while the
second quoted paragraphs implies that this doesnt work, but that one has to use
some other, unspecified (here) repository (for the next two weeks).
Please include those two commands needed instead, with the full options needed.
So, "sudo qubes-dom0-update" for the first paragraph, and
"sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 2nd…
(IIRC!)
Else people have to guess or simply wont know etc…
--
cheers,
Holger
first of all: thanks for this handling this update!
On Tue, Aug 15, 2017 at 08:31:31AM -0500, Andrew David Wong wrote:
> Patching
> =========
[...]
> The packages are to be installed in dom0 via the qubes-dom0-update command or
> via the Qubes VM Manager. A system restart will be required afterwards.
[...]
> via the Qubes VM Manager. A system restart will be required afterwards.
> These packages will migrate to the current (stable) repository over the next
> two weeks after being tested by the community.
I think it would be good to include the *exact* commands here. The first quoted
> two weeks after being tested by the community.
paragraphs seems to imply one can simply upgrade packages as usual, while the
second quoted paragraphs implies that this doesnt work, but that one has to use
some other, unspecified (here) repository (for the next two weeks).
Please include those two commands needed instead, with the full options needed.
So, "sudo qubes-dom0-update" for the first paragraph, and
"sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 2nd…
(IIRC!)
Else people have to guess or simply wont know etc…
--
cheers,
Holger
Marek Marczykowski-Górecki
Aug 15, 2017, 10:05:33 AM8/15/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Actually:
sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
...
> Else people have to guess or simply wont know etc…
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJZkv+oAAoJENuP0xzK19cs5T8IAI1BHctT5hAkFd0COt1sTv40
bDYhOv29zZRXPm9VOetwT73FDwpAwoHqKP/Vc3+mjMdJZPUD5oWH+CHn/gwogRy8
QWXWjkMuAqgRaJDFSMeob75OG1eQPL3XW9qlSQeY9ByIOZ4CqFkBJcHkC9/OHTiv
c7Rp5yXq9TrR7/F+qo0W6EqkL891y5pBa2rSiNi+FX2Y77pDPYfvkQb4oz9fUDCt
CfNzR0lzhT7woTUeBl/IVJTDOybuicdpSIyGaS6lWbERBeTgnU95dc0dHl7HzRcn
lbCZ/hgQF5yz8FwrhcEAZlPHEEyPL8FjP2hL9JHQDEpz0LECcoMAOytHCMaS6aA=
=wQIq
-----END PGP SIGNATURE-----
Hash: SHA256
sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
...
> Else people have to guess or simply wont know etc…
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJZkv+oAAoJENuP0xzK19cs5T8IAI1BHctT5hAkFd0COt1sTv40
bDYhOv29zZRXPm9VOetwT73FDwpAwoHqKP/Vc3+mjMdJZPUD5oWH+CHn/gwogRy8
QWXWjkMuAqgRaJDFSMeob75OG1eQPL3XW9qlSQeY9ByIOZ4CqFkBJcHkC9/OHTiv
c7Rp5yXq9TrR7/F+qo0W6EqkL891y5pBa2rSiNi+FX2Y77pDPYfvkQb4oz9fUDCt
CfNzR0lzhT7woTUeBl/IVJTDOybuicdpSIyGaS6lWbERBeTgnU95dc0dHl7HzRcn
lbCZ/hgQF5yz8FwrhcEAZlPHEEyPL8FjP2hL9JHQDEpz0LECcoMAOytHCMaS6aA=
=wQIq
-----END PGP SIGNATURE-----
Holger Levsen
Aug 15, 2017, 10:41:33 AM8/15/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
On Tue, Aug 15, 2017 at 04:05:27PM +0200, Marek Marczykowski-Górecki wrote:
> Actually:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
q.e.d. & thanks!
--
cheers,
Holger
> Actually:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
q.e.d. & thanks!
--
cheers,
Holger
Rusty Bird
Aug 15, 2017, 10:44:04 AM8/15/17
to Marek Marczykowski-Górecki, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marek Marczykowski-Górecki:
- - r3.2 Xen packages: current-testing
- - r3.2 kernel packages: security-testing
- - r4.0 packages: not built yet?
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJZkwieXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk3QP/2eKJPrh03TcfQjtlTnm7lVk
ZxNKOfhO0rwuWZ/oE5GXjKhhfbBY/LfrmGZl8X3Cm2elyiqh2vP7l6x2CevR7qRo
v8WBBYh3ALImosDVI1Eo3XB/asrmxSo/q3espnp8UmLFaus9ZChV+2E16cQcuWOu
m25r1wWTr4PiH7AFsBEibW37orgPPEhrP+umUj+QYjfvyPXFXw/MUvbsdoGTcwSi
jUyqC552F/zSz1om5M7QpvzLXQ5dxqE0/T8zwv0On4n5tzdVX0QFpt7n0ylWj8vY
9/5vQY9/7luHh4MJnMTB4FpBvilSSMBPhRcN9YpZPolEPBtHpQ41Cj9p0TscgNP0
Wd2lGKFYaEtpPzN4XUmKRxNKku8nZDFezLvzJe4VXxsUZCw4OM+932YFFZkBwant
cf6oVd6z1pPnf1lfpnBsA5lZkHp7VURhQrRZ1yEwJ1o8ZGODptLgq5LGVxpMPDeL
5UulQFE9TZtmyBcuI9v2ArT3mS07coFFJyNToMDsHTZ0GspwthLd75SZ/A7CKGuy
6Cfa86wtizjGyDqjOpDhhSDOciFwrtxWzAh1pnSPD1U3d/ac3W17Bvi029y45Euh
uwzJoQ240FUcVw11PuifrRJzrpsYTKZAvzTCBqr5vqZ9JRvsfGc2gn2RKPCR0alt
OQ6Rtz6AtcVQ1pkFEdM8
=hFi/
-----END PGP SIGNATURE-----
Hash: SHA512
Marek Marczykowski-Górecki:
> On Tue, Aug 15, 2017 at 01:59:59PM +0000, Holger Levsen wrote:
> > So, "sudo qubes-dom0-update" for the first paragraph, and
> > "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 2nd…
> > (IIRC!)
>
> Actually:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
Looks like they ended up in the wrong place:
> > So, "sudo qubes-dom0-update" for the first paragraph, and
> > "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 2nd…
> > (IIRC!)
>
> Actually:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
- - r3.2 Xen packages: current-testing
- - r3.2 kernel packages: security-testing
- - r4.0 packages: not built yet?
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJZkwieXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk3QP/2eKJPrh03TcfQjtlTnm7lVk
ZxNKOfhO0rwuWZ/oE5GXjKhhfbBY/LfrmGZl8X3Cm2elyiqh2vP7l6x2CevR7qRo
v8WBBYh3ALImosDVI1Eo3XB/asrmxSo/q3espnp8UmLFaus9ZChV+2E16cQcuWOu
m25r1wWTr4PiH7AFsBEibW37orgPPEhrP+umUj+QYjfvyPXFXw/MUvbsdoGTcwSi
jUyqC552F/zSz1om5M7QpvzLXQ5dxqE0/T8zwv0On4n5tzdVX0QFpt7n0ylWj8vY
9/5vQY9/7luHh4MJnMTB4FpBvilSSMBPhRcN9YpZPolEPBtHpQ41Cj9p0TscgNP0
Wd2lGKFYaEtpPzN4XUmKRxNKku8nZDFezLvzJe4VXxsUZCw4OM+932YFFZkBwant
cf6oVd6z1pPnf1lfpnBsA5lZkHp7VURhQrRZ1yEwJ1o8ZGODptLgq5LGVxpMPDeL
5UulQFE9TZtmyBcuI9v2ArT3mS07coFFJyNToMDsHTZ0GspwthLd75SZ/A7CKGuy
6Cfa86wtizjGyDqjOpDhhSDOciFwrtxWzAh1pnSPD1U3d/ac3W17Bvi029y45Euh
uwzJoQ240FUcVw11PuifrRJzrpsYTKZAvzTCBqr5vqZ9JRvsfGc2gn2RKPCR0alt
OQ6Rtz6AtcVQ1pkFEdM8
=hFi/
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Aug 15, 2017, 2:05:48 PM8/15/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Aug 15, 2017 at 02:43:42PM +0000, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
> > On Tue, Aug 15, 2017 at 01:59:59PM +0000, Holger Levsen wrote:
> > > So, "sudo qubes-dom0-update" for the first paragraph, and
> > > "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 2nd…
> > > (IIRC!)
> >
> > Actually:
> > sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
>
> Looks like they ended up in the wrong place:
>
> - r3.2 Xen packages: current-testing
> - r3.2 kernel packages: security-testing
> - r4.0 packages: not built yet?
Building took significantly more time than anticipated (especially
kernel). Now all packages are built and updated to security-testing (and
current-testing).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJZkzf1AAoJENuP0xzK19csgswIAJSVX0nDUdVwZdM2F6j/4S+q
ZFfqqmCaiYCUT3KQOsAFoevRbrXAnz5u+YTrOLtbKHZw1+0Ia8DgEhKxRj3Uyh58
krIZI70yGEtLT/glwlZIVuJ5+6T5mkeK1T7hr+1QBWPncm5EhPcCuJ4vANQ5Oc9G
i6pt7rlPZjPYTJTt+GIN0Cm+39uxcwrcppc+yQ+TzuS08vf+RdT3BWPMNgprh1J9
mfjgpJyBccHUpRX3V8YkRpjfk+iva+UBtK68aFKRz5K5dCnK8DCHYJ/aM8fQxiK4
i1q18qFnpuaoj9CVwhSQRTz/kzGajHZBDzNtpBG3oD5c2AO5oR4FKbpI6bYC5y8=
=GY3p
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Aug 15, 2017 at 02:43:42PM +0000, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
> > On Tue, Aug 15, 2017 at 01:59:59PM +0000, Holger Levsen wrote:
> > > So, "sudo qubes-dom0-update" for the first paragraph, and
> > > "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 2nd…
> > > (IIRC!)
> >
> > Actually:
> > sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
>
> Looks like they ended up in the wrong place:
>
> - r3.2 Xen packages: current-testing
> - r3.2 kernel packages: security-testing
> - r4.0 packages: not built yet?
kernel). Now all packages are built and updated to security-testing (and
current-testing).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
ZFfqqmCaiYCUT3KQOsAFoevRbrXAnz5u+YTrOLtbKHZw1+0Ia8DgEhKxRj3Uyh58
krIZI70yGEtLT/glwlZIVuJ5+6T5mkeK1T7hr+1QBWPncm5EhPcCuJ4vANQ5Oc9G
i6pt7rlPZjPYTJTt+GIN0Cm+39uxcwrcppc+yQ+TzuS08vf+RdT3BWPMNgprh1J9
mfjgpJyBccHUpRX3V8YkRpjfk+iva+UBtK68aFKRz5K5dCnK8DCHYJ/aM8fQxiK4
i1q18qFnpuaoj9CVwhSQRTz/kzGajHZBDzNtpBG3oD5c2AO5oR4FKbpI6bYC5y8=
=GY3p
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages