QSB #30: Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)
170 views
Skip to first unread message
Andrew David Wong
May 2, 2017, 8:10:13 AM5/2/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) #30:
Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).
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 #30 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-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/>
```
---===[ Qubes Security Bulletin #30 ]===---
May 2, 2017
Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)
Summary
========
Today the Xen Security Team has disclosed two bugs related to PV memory
handling affecting Qubes OS: XSA-213 [1] and XSA-214 [2].
An attacker who exploits either of these bugs can break Qubes-provided
isolation. This means that if an attacker has already exploited another
vulnerability, e.g. in a Web browser or networking or USB stack, then
the attacker would be able to compromise a whole Qubes system.
Technical details
==================
Xen Security Advisory XSA-213 [1]:
| x86: 64bit PV guest breakout via pagetable use-after-mode-change
|
| 64-bit PV guests typically use separate (root) page tables for their
| kernel and user modes. Hypercalls are accessible to guest kernel
| context only, which certain hypercall handlers make assumptions on.
| The IRET hypercall (replacing the identically name CPU instruction)
| is used by guest kernels to transfer control from kernel mode to user
| mode. If such an IRET hypercall is placed in the middle of a multicall
| batch, subsequent operations invoked by the same multicall batch may
| wrongly assume the guest to still be in kernel mode. If one or more of
| these subsequent operations involve operations on page tables, they may
| be using the wrong root page table, confusing internal accounting. As
| a result the guest may gain writable access to some of its page tables.
Xen Security Advisory XSA-214 [2]:
| grant transfer allows PV guest to elevate privileges
|
| The GNTTABOP_transfer operation allows one guest to transfer a page to
| another guest. The internal processing of this, however, does not
| include zapping the previous type of the page being transferred. This
| makes it possible for a PV guest to transfer a page previously used as
| part of a segment descriptor table to another guest while retaining the
| "contains segment descriptors" property.
|
| If the destination guest is a PV one of different bitness, it may gain
| access to segment descriptors it is not normally allowed to have, like
| 64-bit code segments in a 32-bit PV guest.
|
| If the destination guest is a HVM one, that guest may freely alter the
| page contents and then hand the page back to the same or another PV
| guest.
|
| In either case, if the destination PV guest then inserts that page into
| one of its own descriptor tables, the page still having the designated
| type results in validation of its contents being skipped.
The second bug requires cooperation between two VMs of different types,
which somewhat limits its applicability.
The Xen Security Team also announced a third advisory today: XSA-215
"possible memory corruption via failsafe callback"[3].
| Only x86 systems with physical memory extending to a configuration
| dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are
| actually affected depends on actual physical memory layout.
We believe this bug is extremely unlikely to affect any Qubes users due
to the very high hardware requirements (5Tb or 3.5Tb of physical
memory).
Patching
=========
Patched packages will be built and uploaded to the security-testing
repository shortly after this advisory is published. We have recently
implemented and published the details of a new, transparent build
infrastructure. [4] In this new infrastructure, the source code for
packages is pushed to a public repository, and logs from the build
process are also publicly published. However, the Xen security policy
does not permit us to make this data public until after the embargo has
been lifted. [5] While we have already privately built and tested these
packages, we must wait until the embargo has been lifted before
transparently building the public packages using our new infrastructure.
The specific packages that resolve the problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.5-27
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 will change due to the new xen.gz
binary.
These packages will migrate to the current (stable) repository over the
coming days after being tested by the community.
Commentary
===========
XSA-213 is a fatal, reliably exploitable bug in Xen. In the nearly eight-year
history of the Qubes OS project, we have become aware of four bugs of this
calibre: XSA-148 [12], XSA-182 [13], XSA-212 [14], and now XSA-213.
Coincidentally, all of these fatal bugs have been in Xen mechanisms for handling
memory virtualization for paravirtualized (PV) VMs.
Some might argue that having only four fatal bugs (among other not-that-fatal
ones [15]) in 8 years is a reasonably good result, especially compared to other
desktop systems. We, however, have been deeply upset by each and every of these
bugs. In fact, after we learned of the second of these (XSA-212) 10 months ago,
we immediately began working on a way to move away from using PV-based VMs and
toward using only hardware-based virtualization (HVM) VMs in Qubes 4.x [6].
The switch from PV to HVM has been a major undertaking and has
introduced a delay in the release of Qubes 4.0. This undertaking is now
complete, however [7], and Qubes 4.0-rc1 will be released in the next
1-2 months, after we've finished up with some remaining minor issues.
We originally hoped we could transition to running all Linux VMs in a
so-called PVH mode of virtualization, where the I/O emulator is not
needed at all, but it turned out the Linux kernel is not quite ready for
this. So, in Qubes 4.0, we will use the classic HVM mode, where the I/O
emulator is sandboxed within... a PV VM (which is also the case when one
runs Windows AppVMs on Qubes 3.x). This makes it possible for an
attacker to chain attacks: one for QEMU with another hypothetical for PV
virtualization, to break out of a VM. But the good news is that, with
the work we have done in 4.0 to transition from PV to HVM, the final
step to transition to PVH should be trivial, and we hope to introduce it
in 4.1, once the upstream Linux kernel supports it.
Since we began working on ditching PV virtualization 10 months ago, two
more fatal Xen bugs were published: one last month (XSA 212 [9]) and the
one we discuss today (XSA 213). To provide our users with some means of
addressing these problems, we've recently introduced "Paranoid Backup
Recovery" mode [10], which we believe is a meaningful way for users to
recover from potential compromises on Qubes OS.
Many readers will undoubtedly continue asking, "If Xen is so buggy, why
not ditch it for some other hypervisor?" First, all public hypervisors
have security issues, and it's unclear whether Xen is any buggier than
the other available options. Second, and most importantly, we don't see
any good alternative at this moment. Xen has some unique architectural
features, such as support for running network and storage backends
within _unprivileged_ VMs, which other, popular VMMs do not. Finally,
unlike many research projects, Xen is mature enough to support all sorts
of features that are necessary when running on a laptop, such as power
management and reasonable compatibility with most BIOSes.
In principle, however, Xen is an interchangeable component within the
Qubes OS architecture. One day, we might replace it with something else,
and thanks to the generalized architecture we introduced in Qubes 3.0
[11] and took even further in Qubes 4.0 (e.g. [16]), Qubes users and
admins might not even notice!
Credits
========
See original Xen Security Advisories:
- XSA-213 [1]
- XSA-214 [2]
References
===========
[1] https://xenbits.xen.org/xsa/advisory-213.html
[2] https://xenbits.xen.org/xsa/advisory-214.html
[3] https://xenbits.xen.org/xsa/advisory-215.html
[4] https://github.com/QubesOS/qubes-infrastructure/
[5] https://www.xenproject.org/security-policy.html
[6] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
[7] https://github.com/QubesOS/qubes-issues/issues/2185
[8] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
[9] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt
[10] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
[11] https://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html
[12] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt
[13] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
[14] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt
[15] https://www.qubes-os.org/security/bulletins/
[16] https://www.qubes-os.org/doc/mgmt/
- --
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-----
iQIcBAEBCgAGBQJZCHb3AAoJENtN07w5UDAwGCQP/jBcCWlznoL+c3oPbboQu8w7
xLHpq8ULwb5eI69mdIVqBrnfpeCriVcd8Qa6h0KdIlQVnaBqJ903W6JER+NMaZPq
p6/rbJuUhKA87P8tSUmbdEiJ6SsZ4oMSvHMGvp3px083o8z8ejvF0H3lJRv7TKXt
rQjTo6/X9ezvQlPvgIiE5nGMcgk7VvNDkkM7XrlLsC5J5wcSjHx6YgL5I8MK7+Y4
MJpwBgV4xNmO3WI2oriohCEZ8+55F3KyNe+1rg1BJFIkniT+rti6jgAkWtvR+Odm
mkgEQlyz/Qp8mZcbQGP2w810Ru4KVi6Te0Z1ObylJx+UUFPSoNevvlkgmarTJ+HI
8/D5xlEdZTg2NPuE7aIpJw8C9zR0iA/qC/QWb7PBoBROzYmY89Bxe4M2Ed1g37Hk
mnXqaJ8XwbfZeODn5IzVck2E+IMvR/UKzHTgSw16MOJXuNUsRgYeZPELy8K4OMm0
Y8LKXVgiWwkMsvu7r3Lep6iWb/YC29xhfXJPLPKtQ5H4URyIRH+R0aPf5q6+fZaE
Ru3/n/IfU7ZddM6jDyUvOJbwVTtUgBOkOnR1H8ziIb50KZE7wW7DloyRYfU/YxdL
6yzptCVrxTVFl7fZaB8xvmNyUdL12ewsJ93YHWVM4roMbmqJS6BEtZyFKYBO5E0n
pXfdrKG81M+xK+50ITYS
=eifJ
-----END PGP SIGNATURE-----
Hash: SHA512
Dear Qubes community,
We have just published Qubes Security Bulletin (QSB) #30:
Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).
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 #30 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-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/>
```
---===[ Qubes Security Bulletin #30 ]===---
May 2, 2017
Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214)
Summary
========
Today the Xen Security Team has disclosed two bugs related to PV memory
handling affecting Qubes OS: XSA-213 [1] and XSA-214 [2].
An attacker who exploits either of these bugs can break Qubes-provided
isolation. This means that if an attacker has already exploited another
vulnerability, e.g. in a Web browser or networking or USB stack, then
the attacker would be able to compromise a whole Qubes system.
Technical details
==================
Xen Security Advisory XSA-213 [1]:
| x86: 64bit PV guest breakout via pagetable use-after-mode-change
|
| 64-bit PV guests typically use separate (root) page tables for their
| kernel and user modes. Hypercalls are accessible to guest kernel
| context only, which certain hypercall handlers make assumptions on.
| The IRET hypercall (replacing the identically name CPU instruction)
| is used by guest kernels to transfer control from kernel mode to user
| mode. If such an IRET hypercall is placed in the middle of a multicall
| batch, subsequent operations invoked by the same multicall batch may
| wrongly assume the guest to still be in kernel mode. If one or more of
| these subsequent operations involve operations on page tables, they may
| be using the wrong root page table, confusing internal accounting. As
| a result the guest may gain writable access to some of its page tables.
Xen Security Advisory XSA-214 [2]:
| grant transfer allows PV guest to elevate privileges
|
| The GNTTABOP_transfer operation allows one guest to transfer a page to
| another guest. The internal processing of this, however, does not
| include zapping the previous type of the page being transferred. This
| makes it possible for a PV guest to transfer a page previously used as
| part of a segment descriptor table to another guest while retaining the
| "contains segment descriptors" property.
|
| If the destination guest is a PV one of different bitness, it may gain
| access to segment descriptors it is not normally allowed to have, like
| 64-bit code segments in a 32-bit PV guest.
|
| If the destination guest is a HVM one, that guest may freely alter the
| page contents and then hand the page back to the same or another PV
| guest.
|
| In either case, if the destination PV guest then inserts that page into
| one of its own descriptor tables, the page still having the designated
| type results in validation of its contents being skipped.
The second bug requires cooperation between two VMs of different types,
which somewhat limits its applicability.
The Xen Security Team also announced a third advisory today: XSA-215
"possible memory corruption via failsafe callback"[3].
| Only x86 systems with physical memory extending to a configuration
| dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are
| actually affected depends on actual physical memory layout.
We believe this bug is extremely unlikely to affect any Qubes users due
to the very high hardware requirements (5Tb or 3.5Tb of physical
memory).
Patching
=========
Patched packages will be built and uploaded to the security-testing
repository shortly after this advisory is published. We have recently
implemented and published the details of a new, transparent build
infrastructure. [4] In this new infrastructure, the source code for
packages is pushed to a public repository, and logs from the build
process are also publicly published. However, the Xen security policy
does not permit us to make this data public until after the embargo has
been lifted. [5] While we have already privately built and tested these
packages, we must wait until the embargo has been lifted before
transparently building the public packages using our new infrastructure.
The specific packages that resolve the problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.5-27
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 will change due to the new xen.gz
binary.
These packages will migrate to the current (stable) repository over the
coming days after being tested by the community.
Commentary
===========
XSA-213 is a fatal, reliably exploitable bug in Xen. In the nearly eight-year
history of the Qubes OS project, we have become aware of four bugs of this
calibre: XSA-148 [12], XSA-182 [13], XSA-212 [14], and now XSA-213.
Coincidentally, all of these fatal bugs have been in Xen mechanisms for handling
memory virtualization for paravirtualized (PV) VMs.
Some might argue that having only four fatal bugs (among other not-that-fatal
ones [15]) in 8 years is a reasonably good result, especially compared to other
desktop systems. We, however, have been deeply upset by each and every of these
bugs. In fact, after we learned of the second of these (XSA-212) 10 months ago,
we immediately began working on a way to move away from using PV-based VMs and
toward using only hardware-based virtualization (HVM) VMs in Qubes 4.x [6].
The switch from PV to HVM has been a major undertaking and has
introduced a delay in the release of Qubes 4.0. This undertaking is now
complete, however [7], and Qubes 4.0-rc1 will be released in the next
1-2 months, after we've finished up with some remaining minor issues.
We originally hoped we could transition to running all Linux VMs in a
so-called PVH mode of virtualization, where the I/O emulator is not
needed at all, but it turned out the Linux kernel is not quite ready for
this. So, in Qubes 4.0, we will use the classic HVM mode, where the I/O
emulator is sandboxed within... a PV VM (which is also the case when one
runs Windows AppVMs on Qubes 3.x). This makes it possible for an
attacker to chain attacks: one for QEMU with another hypothetical for PV
virtualization, to break out of a VM. But the good news is that, with
the work we have done in 4.0 to transition from PV to HVM, the final
step to transition to PVH should be trivial, and we hope to introduce it
in 4.1, once the upstream Linux kernel supports it.
Since we began working on ditching PV virtualization 10 months ago, two
more fatal Xen bugs were published: one last month (XSA 212 [9]) and the
one we discuss today (XSA 213). To provide our users with some means of
addressing these problems, we've recently introduced "Paranoid Backup
Recovery" mode [10], which we believe is a meaningful way for users to
recover from potential compromises on Qubes OS.
Many readers will undoubtedly continue asking, "If Xen is so buggy, why
not ditch it for some other hypervisor?" First, all public hypervisors
have security issues, and it's unclear whether Xen is any buggier than
the other available options. Second, and most importantly, we don't see
any good alternative at this moment. Xen has some unique architectural
features, such as support for running network and storage backends
within _unprivileged_ VMs, which other, popular VMMs do not. Finally,
unlike many research projects, Xen is mature enough to support all sorts
of features that are necessary when running on a laptop, such as power
management and reasonable compatibility with most BIOSes.
In principle, however, Xen is an interchangeable component within the
Qubes OS architecture. One day, we might replace it with something else,
and thanks to the generalized architecture we introduced in Qubes 3.0
[11] and took even further in Qubes 4.0 (e.g. [16]), Qubes users and
admins might not even notice!
Credits
========
See original Xen Security Advisories:
- XSA-213 [1]
- XSA-214 [2]
References
===========
[1] https://xenbits.xen.org/xsa/advisory-213.html
[2] https://xenbits.xen.org/xsa/advisory-214.html
[3] https://xenbits.xen.org/xsa/advisory-215.html
[4] https://github.com/QubesOS/qubes-infrastructure/
[5] https://www.xenproject.org/security-policy.html
[6] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
[7] https://github.com/QubesOS/qubes-issues/issues/2185
[8] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
[9] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt
[10] https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
[11] https://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html
[12] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt
[13] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
[14] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt
[15] https://www.qubes-os.org/security/bulletins/
[16] https://www.qubes-os.org/doc/mgmt/
- --
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-----
iQIcBAEBCgAGBQJZCHb3AAoJENtN07w5UDAwGCQP/jBcCWlznoL+c3oPbboQu8w7
xLHpq8ULwb5eI69mdIVqBrnfpeCriVcd8Qa6h0KdIlQVnaBqJ903W6JER+NMaZPq
p6/rbJuUhKA87P8tSUmbdEiJ6SsZ4oMSvHMGvp3px083o8z8ejvF0H3lJRv7TKXt
rQjTo6/X9ezvQlPvgIiE5nGMcgk7VvNDkkM7XrlLsC5J5wcSjHx6YgL5I8MK7+Y4
MJpwBgV4xNmO3WI2oriohCEZ8+55F3KyNe+1rg1BJFIkniT+rti6jgAkWtvR+Odm
mkgEQlyz/Qp8mZcbQGP2w810Ru4KVi6Te0Z1ObylJx+UUFPSoNevvlkgmarTJ+HI
8/D5xlEdZTg2NPuE7aIpJw8C9zR0iA/qC/QWb7PBoBROzYmY89Bxe4M2Ed1g37Hk
mnXqaJ8XwbfZeODn5IzVck2E+IMvR/UKzHTgSw16MOJXuNUsRgYeZPELy8K4OMm0
Y8LKXVgiWwkMsvu7r3Lep6iWb/YC29xhfXJPLPKtQ5H4URyIRH+R0aPf5q6+fZaE
Ru3/n/IfU7ZddM6jDyUvOJbwVTtUgBOkOnR1H8ziIb50KZE7wW7DloyRYfU/YxdL
6yzptCVrxTVFl7fZaB8xvmNyUdL12ewsJ93YHWVM4roMbmqJS6BEtZyFKYBO5E0n
pXfdrKG81M+xK+50ITYS
=eifJ
-----END PGP SIGNATURE-----
Holger Levsen
May 2, 2017, 8:20:00 AM5/2/17
to qubes...@googlegroups.com
On Tue, May 02, 2017 at 07:10:05AM -0500, Andrew David Wong wrote:
> We have just published Qubes Security Bulletin (QSB) #30:
> Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).
sad news, but very well written, thanks a lot for taking the time to do so!
> We have just published Qubes Security Bulletin (QSB) #30:
> Critical Xen bugs related to PV memory virtualization (XSA-213, XSA-214).
> Commentary
> ===========
especially this is a very good read!
--
cheers,
Holger
Message has been deleted
pixel fairy
May 3, 2017, 12:27:46 AM5/3/17
to qubes-devel, qubes-a...@googlegroups.com, qubes...@googlegroups.com
On a more immediate or practical level, i was going to ask about a qubes 3.2.1 release for all the things that have been building up, or perhaps a 3.3 release, with the significant change of moving to hvm by default.
that way, theres less incentive to rush the 4.x releases.
that way, theres less incentive to rush the 4.x releases.
Andrew David Wong
May 3, 2017, 9:24:45 AM5/3/17
to pixel fairy, Marek Marczykowski-Górecki, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
VRLS1tsFAC1lnFnFecrLzWTSD0hanBAeeNhqf0d2Yzpk9tT3CsY03PVFawEEJTEG
uWVorRX5aZMAIo7Y36gOQDSHCzutmRMS/Cgt+fCBUKJqOq+Oazg2pO8I7eUo8Gvf
4w7OqlgQ7VDMxxRz6f+20NtPHkO/FNAGUD9351RD3LTAJqqOhI0uqGS961+ZPdoT
NJwyi9E6hwVJhqtm83+8N7tS3jptvA68uUMX2wSwkcXZv31RwjlWfR+E59wD9vkT
0iZAwvxk8YPOX9TkEmvGrxoHx3JtKiNoc+Wr/NJpryobVxcso3ciDi/5LCBGnJyU
e9/get1l3Qj5hVxt+C4CDkmbVKXeK4ntNgLjoNiZn7vkquxReLh+TzNQ4PKp7ZCv
sg8mii9BW3/WzwmP4YHajurSlsbCDobnxt/yP9aJm+4qtVySPy9P37Hv5JCMM9lf
R0eLf6T1Nd0avM9SWFAcld2+OQvC4t9wMRPdJTPI1z/L1Ga7MiDCO9W7faHJjQ2o
f/nAmHo6nDom84Gh5Q/G66x9mM5W2cqEwlR4t8NJpr1dRlDn3ciS5rYNSZets3lF
ixozeGX+UKc8F5bpqakyZpLi6hgicvGebX5xdZPAo1ui9WBWvb+Eyz8akpkMs9zz
/KDIoHf7KERwU4SqYOaJ
=J8sT
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
May 5, 2017, 3:27:56 PM5/5/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, May 02, 2017 at 09:53:47AM -0600, Reg Tiangha wrote:
> When the QSB says "We originally hoped we could transition to running
Yes.
> If so,
> it's now available in kernel 4.11:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes
Yes, but not for PCI-passthrough. Which is crucial feature for Qubes (or
more specifically: NetVM/USB VM)
> Would jumping straight to the original intended implementation using
> this kernel delay things more to the point where it's not worth it,
Generally yes - this is rather new thing (final 4.11 was released this
week) and we'd rather to focus on stabilizing what we already have in
Qubes 4.0, instead of introducing more bleeding edge new parts.
> or
> is the plan just to stay on course for implementing it in 4.1 for
> various reasons? Or would it be worth it to include PVH support in 4.0
> from the beginning, but maybe leave HVM mode as the default for users?
Generally, from configuration POV, PVHv2 is very similar to PV[*], but
there are multiple architectural differences. The current plan is to
release Qubes 4.0 and then resume work on PVHv2 (which may turn out to
be very minimal needed) and have it in Qubes 4.1. This may mean it will
also work (at least partially) in Qubes 4.0, if we're lucky ;)
[*] basically setting "device_model_version=none"
- --
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
iQEcBAEBCAAGBQJZDNI4AAoJENuP0xzK19csNZ4H/0p2MgSdRPZ5595qN5kbUA5G
h13wLjOuWfNplR0POAsQsC4U68uCaoRO1pixaGlnj8JT+zgEeiaoUDX7AqiuSQs2
3vIgJq3XX1GvMIqzP15gLyLlbklXsBHsOc8R1B+LTdDqXmBsluY14P7u7Iqgb96b
AjJ7kql2lX9ViqpT5p1W13LzFrbs9Axoewm+DHYyK5H9v//Alc82yAZ46zymoIMH
n44x7skZ0Q+4fe0X2/oDCU/5Px5PLUTtEsXOdJblBnpXE0uKvqe5qgZ8CifWo9he
1rSXvbLxGQIiPsEwer40OCZpTklyOZN774nepQzIDrt1qEFt1YzdHDASMEiK+no=
=xS/5
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, May 02, 2017 at 09:53:47AM -0600, Reg Tiangha wrote:
> When the QSB says "We originally hoped we could transition to running
> all Linux VMs in a so-called PVH mode of virtualization, where the I/O
> emulator is not needed at all, but it turned out the Linux kernel is not
> quite ready for this," is it talking about PVHv2/HVMLite support?
> emulator is not needed at all, but it turned out the Linux kernel is not
Yes.
> If so,
> it's now available in kernel 4.11:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Xen-Changes
Yes, but not for PCI-passthrough. Which is crucial feature for Qubes (or
more specifically: NetVM/USB VM)
> Would jumping straight to the original intended implementation using
> this kernel delay things more to the point where it's not worth it,
Generally yes - this is rather new thing (final 4.11 was released this
week) and we'd rather to focus on stabilizing what we already have in
Qubes 4.0, instead of introducing more bleeding edge new parts.
> or
> is the plan just to stay on course for implementing it in 4.1 for
> various reasons? Or would it be worth it to include PVH support in 4.0
> from the beginning, but maybe leave HVM mode as the default for users?
Generally, from configuration POV, PVHv2 is very similar to PV[*], but
there are multiple architectural differences. The current plan is to
release Qubes 4.0 and then resume work on PVHv2 (which may turn out to
be very minimal needed) and have it in Qubes 4.1. This may mean it will
also work (at least partially) in Qubes 4.0, if we're lucky ;)
[*] basically setting "device_model_version=none"
- --
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
iQEcBAEBCAAGBQJZDNI4AAoJENuP0xzK19csNZ4H/0p2MgSdRPZ5595qN5kbUA5G
h13wLjOuWfNplR0POAsQsC4U68uCaoRO1pixaGlnj8JT+zgEeiaoUDX7AqiuSQs2
3vIgJq3XX1GvMIqzP15gLyLlbklXsBHsOc8R1B+LTdDqXmBsluY14P7u7Iqgb96b
AjJ7kql2lX9ViqpT5p1W13LzFrbs9Axoewm+DHYyK5H9v//Alc82yAZ46zymoIMH
n44x7skZ0Q+4fe0X2/oDCU/5Px5PLUTtEsXOdJblBnpXE0uKvqe5qgZ8CifWo9he
1rSXvbLxGQIiPsEwer40OCZpTklyOZN774nepQzIDrt1qEFt1YzdHDASMEiK+no=
=xS/5
-----END PGP SIGNATURE-----
cubit
May 6, 2017, 10:09:02 AM5/6/17
to qubes...@googlegroups.com, qubes...@googlegroups.com, qubes...@googlegroups.com
These packages will migrate to the current (stable) repository over the
coming days after being tested by the community.
Not wanting to push it too much but is there a rough eta as to when these patches will be pushed to 3.2-stable?
Marek Marczykowski-Górecki
May 6, 2017, 1:37:47 PM5/6/17
to cubit, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Normally we push updates to stable repo 7 days after uploading to
testing (or more if update is bigger or potentially more problematic -
but it isn't the case here).
- --
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
iQEcBAEBCAAGBQJZDgnkAAoJENuP0xzK19csGksH/1pl0YOtCd1cxeOItZuFYYgD
mx1KRJ921Fvy2lJyvwXOr7xdjshrQuwu1cJVGi4RicMNwV/2pr2uHIP3EKFiYR7d
ZGT40MeaN5Qm0EmDwzV5P/DfcF08gKGzEMLW55Dl9ey1fGVSfJIOwJsCblTCyCss
DumSNyDZah8Rn/0FOevd/O/BmtIiDtVjTm573UHVrZ4Ru6XR2/q2D2npnPwWDDDs
blk1Szq+IP/875LLn+ZhgZ7w7ARkcwna76AnwedPxNyolopowC5253u75OrfgXHy
ylDDDrmr98bMOtC6nme3LAWTFljETDQM73O4gLxJv5XqleB5lCnFHDc7GKzuGYQ=
=DgWj
-----END PGP SIGNATURE-----
Hash: SHA256
testing (or more if update is bigger or potentially more problematic -
but it isn't the case here).
- --
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
mx1KRJ921Fvy2lJyvwXOr7xdjshrQuwu1cJVGi4RicMNwV/2pr2uHIP3EKFiYR7d
ZGT40MeaN5Qm0EmDwzV5P/DfcF08gKGzEMLW55Dl9ey1fGVSfJIOwJsCblTCyCss
DumSNyDZah8Rn/0FOevd/O/BmtIiDtVjTm573UHVrZ4Ru6XR2/q2D2npnPwWDDDs
blk1Szq+IP/875LLn+ZhgZ7w7ARkcwna76AnwedPxNyolopowC5253u75OrfgXHy
ylDDDrmr98bMOtC6nme3LAWTFljETDQM73O4gLxJv5XqleB5lCnFHDc7GKzuGYQ=
=DgWj
-----END PGP SIGNATURE-----
Andrew David Wong
May 6, 2017, 3:45:40 PM5/6/17
to Marek Marczykowski-Górecki, cubit, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2017-05-06 12:37, Marek Marczykowski-Górecki wrote:
> On Sat, May 06, 2017 at 04:08:57PM +0200, cubit wrote:
>> 2. May 2017 12:10 by a...@qubes-os.org:
>
>>> Patching
>>> =========
>>>
>>> These packages will migrate to the current (stable) repository over the
>>> coming days after being tested by the community.
>>>
>
>> Not wanting to push it too much but is there a rough eta as to when these patches will be pushed to 3.2-stable?
>
> Normally we push updates to stable repo 7 days after uploading to
> testing (or more if update is bigger or potentially more problematic -
> but it isn't the case here).
>
This question is very frequently asked. Perhaps we should change "in the
coming days" to "within the next 10 days." What do you think, Marek?
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZDifXAAoJENtN07w5UDAwMOsQAL5lbL2ub0vWjUpkEZnbaVMf
DyoDsY3sJSy7j4rWWoZwG4Z9JowxnBWcjVorz9g/uzMJ1kDXKsy3Rcs85SAOVR8E
zR34y7rcjNi8r5Ag7Kc8uKbamFH2krK1Uj+yBp544JvzJh4a26cK/Gs4ApPX/qNq
IKpmR0dP42xK7hUI4OfK5uACNnnJNnmP/bpOkvkMPnIY4sfMsaxo7zfJHrb/vWPz
51UaWcDpz6mPaHA6wZEPVclN+hTzEe0JxC7o5D1C5eXz/p73UN9bzEldTALBl1FF
iz0jmS9sNmI4fWQiK0o1uRRnBhDLLCil4ooO73XpcOOE3xdFyuCtavQbawwm9adj
d9BQtythxQiZqezHY7KsaaHCXcgaAvj0avxF++idZuDGvJkohYS+chiHhxORAQrp
RwJwB34IaT1QIWugX5NzB5nKbOi2gEEOQyF6SPXW8USM1QzcDm1bJVAle7HZs8zN
V+l9YhDGkmOu4FL2Vsha+tlK/WgGXvbWLyx4jF3t/sd3iasFkm73OPLpaOGlg9mT
v/CKkMtxQvlu894z+4Dp6ogFiAPHSybkxSWPvFRMwtwcRkBA6ihvrXHGIejx2BwB
7FG9S5h01C2oFt4otLo2EmNQv0a4FtdZm4igdlnYP/ky9PiSOGKJkfKeEXiQwsch
R9tTxkDur+/YU8kdu304
=b5mG
-----END PGP SIGNATURE-----
Hash: SHA512
On 2017-05-06 12:37, Marek Marczykowski-Górecki wrote:
> On Sat, May 06, 2017 at 04:08:57PM +0200, cubit wrote:
>> 2. May 2017 12:10 by a...@qubes-os.org:
>
>>> Patching
>>> =========
>>>
>>> These packages will migrate to the current (stable) repository over the
>>> coming days after being tested by the community.
>>>
>
>> Not wanting to push it too much but is there a rough eta as to when these patches will be pushed to 3.2-stable?
>
> Normally we push updates to stable repo 7 days after uploading to
> testing (or more if update is bigger or potentially more problematic -
> but it isn't the case here).
>
coming days" to "within the next 10 days." What do you think, Marek?
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
DyoDsY3sJSy7j4rWWoZwG4Z9JowxnBWcjVorz9g/uzMJ1kDXKsy3Rcs85SAOVR8E
zR34y7rcjNi8r5Ag7Kc8uKbamFH2krK1Uj+yBp544JvzJh4a26cK/Gs4ApPX/qNq
IKpmR0dP42xK7hUI4OfK5uACNnnJNnmP/bpOkvkMPnIY4sfMsaxo7zfJHrb/vWPz
51UaWcDpz6mPaHA6wZEPVclN+hTzEe0JxC7o5D1C5eXz/p73UN9bzEldTALBl1FF
iz0jmS9sNmI4fWQiK0o1uRRnBhDLLCil4ooO73XpcOOE3xdFyuCtavQbawwm9adj
d9BQtythxQiZqezHY7KsaaHCXcgaAvj0avxF++idZuDGvJkohYS+chiHhxORAQrp
RwJwB34IaT1QIWugX5NzB5nKbOi2gEEOQyF6SPXW8USM1QzcDm1bJVAle7HZs8zN
V+l9YhDGkmOu4FL2Vsha+tlK/WgGXvbWLyx4jF3t/sd3iasFkm73OPLpaOGlg9mT
v/CKkMtxQvlu894z+4Dp6ogFiAPHSybkxSWPvFRMwtwcRkBA6ihvrXHGIejx2BwB
7FG9S5h01C2oFt4otLo2EmNQv0a4FtdZm4igdlnYP/ky9PiSOGKJkfKeEXiQwsch
R9tTxkDur+/YU8kdu304
=b5mG
-----END PGP SIGNATURE-----
Adrian Jeleń
May 7, 2017, 5:48:22 PM5/7/17
to qubes-devel, qubes-a...@googlegroups.com, qubes...@googlegroups.com
W dniu wtorek, 2 maja 2017 14:10:12 UTC+2 użytkownik Andrew David Wong napisał:
For Qubes 3.2:
- Xen packages, version 4.6.5-27
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.
I've just tried to install updates but something doesn't work. It says that package xen-2001:4.6.4-26.fc23.x86_64 is already installed (skipping).
Is it available for repos enabled by default (fedora, updates or qubes-dom0-current)?
Andrew David Wong
May 7, 2017, 7:10:12 PM5/7/17
to Adrian Jeleń, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
o+hGHkX1P+BdsSFrVebq4GpdsKxB/Yfcx2mb7V1VCJpUql78o8BSh0YW5MRIeNsm
FSRZkILf206llRXqNSCP7xRGmcPQUB4HJfgUlokWxN1wUXyu/MwREjv8Pv6tBRvn
NrkJ1eGbxyhYpOMc+7uQxj5uE9CyPHRXhAUJFxfl6Z29VKo1ykdCnBiYrRHE6ZWT
y4jI5kBkLSSE5XRJBVLahSSkf8W1145hZ/K+MAJoQ6Rq7Xy5HV+ZnOz1HKV6ynlD
ZROxquCD8gjX1nAXNsHGKFP18pGbHhM4ufVR8WVh+yrVNIsS6S9hBDJvLsd+wpRx
rMyQLHuvWg9AlDDV7+Pqa5IQZTt1x3wN/miWjmEQPXni2m4y1ALUoPDM8oM9WmaO
OI4nKF5QjJ0GDqErvI9qPr+oIeQn/rQ3bemsVsf8UPMruONmDRDkP7gwSZTjy660
TRb0YxbCKInznOqO9rZVv29eAm/BzuklbCNsnmwHoS5ZfJhCCaH1kEtbkV4gcdR+
/sLA/mo+hgokvm45ch+IQ+CT0CkJ61JAZzKT1Wum3jVfXc00a0BSX8YlNOhkI9Ew
FTJYBuKl8YCwSTvk29olV22umtZQNivLBsWFbVk7wDUNaCay7hpww/uG9AX6Z+2t
QyIctqI4nspLNW2j6aJB
=KxSx
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages