QSB #29: Critical Xen bug in PV memory virtualization code (XSA-212)
75 views
Skip to first unread message
Andrew David Wong
Apr 4, 2017, 9:25:49 AM4/4/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) #29:
Critical Xen bug in PV memory virtualization code (XSA-212).
The current text of this QSB is reproduced below. The latest version,
including any future corrections, will always be available in the Qubes
Security Pack (qubes-secpack).
View QSB #29 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt>
Learn about the qubes-secpack, including how to obtain, verify, and
read it:
<https://www.qubes-os.org/doc/security-pack/>
View all past QSBs:
<https://www.qubes-os.org/doc/security-bulletins/>
View XSA-212 in the XSA Tracker:
<https://www.qubes-os.org/security/xsa/#212>
```
---===[ Qubes Security Bulletin #29 ]===---
April 4, 2017
Critical Xen bug in PV memory virtualization code (XSA-212)
Quick Summary
==============
The Xen Security Team has discovered a serious security bug (XSA-212)
in the hypervisor code handling memory virtualization for
paravirtualized (PV) VMs [1]:
| The XSA-29 fix introduced an insufficient check on XENMEM_exchange
| input, allowing the caller to drive hypervisor memory accesses outside
| of the guest provided input/output arrays.
|
| A malicious or buggy 64-bit PV guest may be able to access all of
| system memory, allowing for all of privilege escalation, host crashes,
| and information leaks.
An attacker who exploits this bug 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.
Description of the bug
=======================
Arguments of XENMEM_exchange hypercall contains array of page numbers
to be exchanged and array for exchanged page numbers. Validation of
those arrays (supposedly living in guest memory) assumes a certain
memory layout -- that Xen memory is just above non-canonical addresses.
It also assumes that array accesses are sequential starting from the
beginning of the array. With this assumption, validation code checks
only the address of the first array element and assumes (thanks to
sequential access) that further code will hit a non-canonical address,
resulting in page fault, before reaching Xen memory.
Relevant part of xen/include/asm-x86/x86_64/uaccess.h:
/*
* Valid if in +ve half of 48-bit address space, or above Xen-reserved area.
* This is also valid for range checks (addr, addr+size). As long as the
* start address is outside the Xen-reserved area, sequential accesses
* (starting at addr) will hit a non-canonical address (and thus fault)
* before ever reaching VIRT_START.
*/
#define __addr_ok(addr) \
(((unsigned long)(addr) < (1UL<<47)) || \
((unsigned long)(addr) >= HYPERVISOR_VIRT_END))
#define access_ok(addr, size) \
(__addr_ok(addr) || is_compat_arg_xlat_range(addr, size))
#define array_access_ok(addr, count, size) \
(access_ok(addr, (count)*(size)))
Unfortunately, this assumption is false in XENMEM_exchange. The caller
of this hypercall has full control over the place at which array
processing starts (using the exch.nr_exchanged argument). This means
that the caller can trick the Xen hypervisor into reading input page
numbers from the Xen memory area or write exchanged page numbers into
the Xen memory area. The attacker does not directly control values
written there, but using, for example, balloon driver, can influence
what pages will be available in the system and later chosen for
allocation by XENMEM_exchange.
This means that a sufficiently determined attacker can use this bug to
write arbitrary data into arbitrary places in Xen memory and thereby
take full control of the system.
Discussion
===========
This is another bug resulting from the overly-complex memory
virtualization required for PV in Xen. As we announced last year [5],
the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
switching to HVM-based virtualization:
| One of the most important security improvements that we plan to
| introduce with the release of Qubes 4 is to ditch paravirtualization
| (PV) technology and replace it with hardware-enforced memory
| virtualization, which recent processors have made possible thanks to
| so-called Second Level Address Translation (SLAT), also known as EPT
| in Intel parlance. SLAT (EPT) is an extension to Intel VT-x
| virtualization, which originally was capable of only CPU
| virtualization but not memory virtualization and hence required a
| complex Shadow Page Tables approach (which we believed back then was
| actually less attractive than the PV approach). We hope that embracing
| SLAT-based memory virtualization will allow us to prevent disastrous
| security bugs, such as the infamous XSA 148, publicly disclosed in
| October of last year, which unlike many other major Xen bugs
| regrettably did affect Qubes OS. Consequently, we will be requiring
| SLAT support of all certified hardware for Qubes OS 4 and later.
At the same time, we would like to point out that the security of Qubes
OS has so far been affected by less than 10% of publicly disclosed Xen
bugs, as tracked by the recently created Xen Security Advisory (XSA)
Tracker. [6]
Availability of patches
========================
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. [3] 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 XSA-212
embargo has been lifted. [4] 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.
Thanks to the new infrastructure, it's also much easier for us handle
updates. Because of this, we've decided to release fixed packages
for Qubes OS 3.1, even though it recently reached EOL. Both Qubes OS
3.1 and Qubes OS 3.2 use the same Xen version, so this requires no
additional work.
Patching
=========
The specific packages that resolve the problem discussed in this
bulletin will be uploaded to the security-testing repository:
For Qubes 3.1 and 3.2:
* Xen packages, version 4.6.4-26
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.
Credits
========
This issue was discovered by Jann Horn of Google Project Zero and
reported to the Xen Security Team.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-212.html
[2] https://xenbits.xen.org/xsa/
[3] https://github.com/QubesOS/qubes-infrastructure/
[4] https://www.xenproject.org/security-policy.html
[5] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
[6] https://www.qubes-os.org/security/xsa/
- --
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-----
iQIcBAEBCgAGBQJY457BAAoJENtN07w5UDAwpR4P/Rt9HBD2xUkBiMFJDbVkr2Dm
lKgBWOQy5FcXRBWcsHjc/YI23weG4uAko8w3P2oWxWf7+IU9AIBdzRf25Ignsxda
TLC8waVDAN4OHw1KEWn028ZABOMnir1oOwclCHyblkZC5NLcaikRXf5cTUxCT4Mv
/SstzOndATUTqoLQ0cvbNB/esFzLrlo5S+g8uk7kdJzaLPrb07EgzJMSSCrM5ZQE
LFAgoTKGsjkO3+7t66oJyEAnFc+sXGjjGypvRzHl9rAQtK0/YheU/LEqA/iDnXCt
n5H3QtAmCTUynZxteN0/LKVoj04ObA14Rp50jpb2eEiHBmgEuUNiijWagrYGLM1T
1EKdLUoujc5LvF5Wd28ZOFkyVS14c4Pbp+kD7Ou0MPCGqWhU7jqqrBELL/7ulfYh
O/8lbtu+279Bj5m559jTp3+lB1E50IZ2g8n/41G4VsxLt5lhXL0DdgzbyppC/TWk
rZIcHCHli8HCQoHo4deyeXNBD79WNc6i/ZziOUefCOHzEHUdNijfXqgEpkKql+3b
HvmCcFXK03LLVTKEbMPjK6edkr9g80mi3RF6clDDhQqfae0Bl0hmhuh/gPL5UpMS
7zYwgolxjVjsqKmQEj5sZ48D3jzRuDa1Fim8iAVHamqgCL3pp3HW2WuXcPGBCllE
ieCpBuubJWO8HVsZ1X8v
=yIqA
-----END PGP SIGNATURE-----
Hash: SHA512
Dear Qubes community,
We have just published Qubes Security Bulletin (QSB) #29:
Critical Xen bug in PV memory virtualization code (XSA-212).
The current text of this QSB is reproduced below. The latest version,
including any future corrections, will always be available in the Qubes
Security Pack (qubes-secpack).
View QSB #29 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt>
Learn about the qubes-secpack, including how to obtain, verify, and
read it:
<https://www.qubes-os.org/doc/security-pack/>
View all past QSBs:
<https://www.qubes-os.org/doc/security-bulletins/>
View XSA-212 in the XSA Tracker:
<https://www.qubes-os.org/security/xsa/#212>
```
---===[ Qubes Security Bulletin #29 ]===---
April 4, 2017
Critical Xen bug in PV memory virtualization code (XSA-212)
Quick Summary
==============
The Xen Security Team has discovered a serious security bug (XSA-212)
in the hypervisor code handling memory virtualization for
paravirtualized (PV) VMs [1]:
| The XSA-29 fix introduced an insufficient check on XENMEM_exchange
| input, allowing the caller to drive hypervisor memory accesses outside
| of the guest provided input/output arrays.
|
| A malicious or buggy 64-bit PV guest may be able to access all of
| system memory, allowing for all of privilege escalation, host crashes,
| and information leaks.
An attacker who exploits this bug 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.
Description of the bug
=======================
Arguments of XENMEM_exchange hypercall contains array of page numbers
to be exchanged and array for exchanged page numbers. Validation of
those arrays (supposedly living in guest memory) assumes a certain
memory layout -- that Xen memory is just above non-canonical addresses.
It also assumes that array accesses are sequential starting from the
beginning of the array. With this assumption, validation code checks
only the address of the first array element and assumes (thanks to
sequential access) that further code will hit a non-canonical address,
resulting in page fault, before reaching Xen memory.
Relevant part of xen/include/asm-x86/x86_64/uaccess.h:
/*
* Valid if in +ve half of 48-bit address space, or above Xen-reserved area.
* This is also valid for range checks (addr, addr+size). As long as the
* start address is outside the Xen-reserved area, sequential accesses
* (starting at addr) will hit a non-canonical address (and thus fault)
* before ever reaching VIRT_START.
*/
#define __addr_ok(addr) \
(((unsigned long)(addr) < (1UL<<47)) || \
((unsigned long)(addr) >= HYPERVISOR_VIRT_END))
#define access_ok(addr, size) \
(__addr_ok(addr) || is_compat_arg_xlat_range(addr, size))
#define array_access_ok(addr, count, size) \
(access_ok(addr, (count)*(size)))
Unfortunately, this assumption is false in XENMEM_exchange. The caller
of this hypercall has full control over the place at which array
processing starts (using the exch.nr_exchanged argument). This means
that the caller can trick the Xen hypervisor into reading input page
numbers from the Xen memory area or write exchanged page numbers into
the Xen memory area. The attacker does not directly control values
written there, but using, for example, balloon driver, can influence
what pages will be available in the system and later chosen for
allocation by XENMEM_exchange.
This means that a sufficiently determined attacker can use this bug to
write arbitrary data into arbitrary places in Xen memory and thereby
take full control of the system.
Discussion
===========
This is another bug resulting from the overly-complex memory
virtualization required for PV in Xen. As we announced last year [5],
the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
switching to HVM-based virtualization:
| One of the most important security improvements that we plan to
| introduce with the release of Qubes 4 is to ditch paravirtualization
| (PV) technology and replace it with hardware-enforced memory
| virtualization, which recent processors have made possible thanks to
| so-called Second Level Address Translation (SLAT), also known as EPT
| in Intel parlance. SLAT (EPT) is an extension to Intel VT-x
| virtualization, which originally was capable of only CPU
| virtualization but not memory virtualization and hence required a
| complex Shadow Page Tables approach (which we believed back then was
| actually less attractive than the PV approach). We hope that embracing
| SLAT-based memory virtualization will allow us to prevent disastrous
| security bugs, such as the infamous XSA 148, publicly disclosed in
| October of last year, which unlike many other major Xen bugs
| regrettably did affect Qubes OS. Consequently, we will be requiring
| SLAT support of all certified hardware for Qubes OS 4 and later.
At the same time, we would like to point out that the security of Qubes
OS has so far been affected by less than 10% of publicly disclosed Xen
bugs, as tracked by the recently created Xen Security Advisory (XSA)
Tracker. [6]
Availability of patches
========================
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. [3] 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 XSA-212
embargo has been lifted. [4] 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.
Thanks to the new infrastructure, it's also much easier for us handle
updates. Because of this, we've decided to release fixed packages
for Qubes OS 3.1, even though it recently reached EOL. Both Qubes OS
3.1 and Qubes OS 3.2 use the same Xen version, so this requires no
additional work.
Patching
=========
The specific packages that resolve the problem discussed in this
bulletin will be uploaded to the security-testing repository:
For Qubes 3.1 and 3.2:
* Xen packages, version 4.6.4-26
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.
Credits
========
This issue was discovered by Jann Horn of Google Project Zero and
reported to the Xen Security Team.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-212.html
[2] https://xenbits.xen.org/xsa/
[3] https://github.com/QubesOS/qubes-infrastructure/
[4] https://www.xenproject.org/security-policy.html
[5] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
[6] https://www.qubes-os.org/security/xsa/
- --
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-----
iQIcBAEBCgAGBQJY457BAAoJENtN07w5UDAwpR4P/Rt9HBD2xUkBiMFJDbVkr2Dm
lKgBWOQy5FcXRBWcsHjc/YI23weG4uAko8w3P2oWxWf7+IU9AIBdzRf25Ignsxda
TLC8waVDAN4OHw1KEWn028ZABOMnir1oOwclCHyblkZC5NLcaikRXf5cTUxCT4Mv
/SstzOndATUTqoLQ0cvbNB/esFzLrlo5S+g8uk7kdJzaLPrb07EgzJMSSCrM5ZQE
LFAgoTKGsjkO3+7t66oJyEAnFc+sXGjjGypvRzHl9rAQtK0/YheU/LEqA/iDnXCt
n5H3QtAmCTUynZxteN0/LKVoj04ObA14Rp50jpb2eEiHBmgEuUNiijWagrYGLM1T
1EKdLUoujc5LvF5Wd28ZOFkyVS14c4Pbp+kD7Ou0MPCGqWhU7jqqrBELL/7ulfYh
O/8lbtu+279Bj5m559jTp3+lB1E50IZ2g8n/41G4VsxLt5lhXL0DdgzbyppC/TWk
rZIcHCHli8HCQoHo4deyeXNBD79WNc6i/ZziOUefCOHzEHUdNijfXqgEpkKql+3b
HvmCcFXK03LLVTKEbMPjK6edkr9g80mi3RF6clDDhQqfae0Bl0hmhuh/gPL5UpMS
7zYwgolxjVjsqKmQEj5sZ48D3jzRuDa1Fim8iAVHamqgCL3pp3HW2WuXcPGBCllE
ieCpBuubJWO8HVsZ1X8v
=yIqA
-----END PGP SIGNATURE-----
Salmiakki
Apr 4, 2017, 9:38:34 AM4/4/17
to qubes-users, qubes-a...@googlegroups.com, qubes...@googlegroups.com
*snip*
On Tuesday, April 4, 2017 at 3:25:49 PM UTC+2, Andrew David Wong wrote:
> Discussion
> ===========
>
> This is another bug resulting from the overly-complex memory
> virtualization required for PV in Xen. As we announced last year [5],
> the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
> switching to HVM-based virtualization:
> [5] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
Very interesting move, I had previously missed this. What are the mplications? Will it be much slower and resource intensive?
Marek Marczykowski-Górecki
Apr 4, 2017, 10:14:25 AM4/4/17
to Reg Tiangha, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Apr 04, 2017 at 08:05:20AM -0600, Reg Tiangha wrote:
> and notice that updates are going out to current-testing at the moment.
> The QSB states that they'll make an appearance on security-testing; will
> that come later on or is that an oversight?
Packages by default are uploaded to current-testing repository. Moving
to security-testing require maintainer decision. Done now, you can see
it here:
https://github.com/QubesOS/updates-status/issues/26
- --
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
iQEcBAEBCAAGBQJY46o7AAoJENuP0xzK19csMOMIAIBvguh0BRkZRlP/sqfw9vGB
3RpeRmhPbQfT9zmo1viVn7itPexFCtmhBQ9kFFTjwBBmDewFziPjMD3hUu9BZKoF
rjn3cfVE2xcI1MGnWtg2m6VmYxqxiS4kknOdHepk6DV95t8gM0WFQyfjCbJ0Js4v
uOAk4NCFTyOJ1bJrmXe9NuNt67iPi9c42S5fpMLFPeOc7QGMKjh30DgpnlIOttJb
K77j8vMYR8qR7wdS5gDttnrP+gDA0oWPpdTl2ml3uP6W5nWMzuV9m1XAZ7AKDr1i
pAatb5ccUtSgrDp4HZbo1ACMwlbyIijIm8pgfJ5ra6y+Yze8oaYJvtqd1uH0hXk=
=f9Nh
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Apr 04, 2017 at 08:05:20AM -0600, Reg Tiangha wrote:
> On 04/04/2017 07:25 AM, Andrew David Wong wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Dear Qubes community,
> >
> > We have just published Qubes Security Bulletin (QSB) #29:
> > Critical Xen bug in PV memory virtualization code (XSA-212).
> >
> > The current text of this QSB is reproduced below. The latest version,
> > including any future corrections, will always be available in the Qubes
> > Security Pack (qubes-secpack).
> >
> > View QSB #29 in the qubes-secpack:
> >
> > <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt>
> >
> > Learn about the qubes-secpack, including how to obtain, verify, and
> > read it:
> >
> > <https://www.qubes-os.org/doc/security-pack/>
> >
> > View all past QSBs:
> >
> > <https://www.qubes-os.org/doc/security-bulletins/>
> >
> > View XSA-212 in the XSA Tracker:
> >
> > <https://www.qubes-os.org/security/xsa/#212>
> >
> > ```
> Thanks for this. I'm keeping an eye on the qubesos-bot updates on GitHub
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Dear Qubes community,
> >
> > We have just published Qubes Security Bulletin (QSB) #29:
> > Critical Xen bug in PV memory virtualization code (XSA-212).
> >
> > The current text of this QSB is reproduced below. The latest version,
> > including any future corrections, will always be available in the Qubes
> > Security Pack (qubes-secpack).
> >
> > View QSB #29 in the qubes-secpack:
> >
> > <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-029-2017.txt>
> >
> > Learn about the qubes-secpack, including how to obtain, verify, and
> > read it:
> >
> > <https://www.qubes-os.org/doc/security-pack/>
> >
> > View all past QSBs:
> >
> > <https://www.qubes-os.org/doc/security-bulletins/>
> >
> > View XSA-212 in the XSA Tracker:
> >
> > <https://www.qubes-os.org/security/xsa/#212>
> >
> > ```
> and notice that updates are going out to current-testing at the moment.
> The QSB states that they'll make an appearance on security-testing; will
> that come later on or is that an oversight?
Packages by default are uploaded to current-testing repository. Moving
to security-testing require maintainer decision. Done now, you can see
it here:
https://github.com/QubesOS/updates-status/issues/26
- --
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
iQEcBAEBCAAGBQJY46o7AAoJENuP0xzK19csMOMIAIBvguh0BRkZRlP/sqfw9vGB
3RpeRmhPbQfT9zmo1viVn7itPexFCtmhBQ9kFFTjwBBmDewFziPjMD3hUu9BZKoF
rjn3cfVE2xcI1MGnWtg2m6VmYxqxiS4kknOdHepk6DV95t8gM0WFQyfjCbJ0Js4v
uOAk4NCFTyOJ1bJrmXe9NuNt67iPi9c42S5fpMLFPeOc7QGMKjh30DgpnlIOttJb
K77j8vMYR8qR7wdS5gDttnrP+gDA0oWPpdTl2ml3uP6W5nWMzuV9m1XAZ7AKDr1i
pAatb5ccUtSgrDp4HZbo1ACMwlbyIijIm8pgfJ5ra6y+Yze8oaYJvtqd1uH0hXk=
=f9Nh
-----END PGP SIGNATURE-----
Reg Tiangha
Apr 4, 2017, 10:32:49 AM4/4/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
On 04/04/2017 08:14 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> -----BEGIN PGP SIGNED MESSAGE-----
there, but when I checked, there was nothing there. It doesn't seem like
it gets updated that often, so what I think I'll do is just enable
security-testing on all my VMs and leave it on. I assume that if there
are any issues with the patches that are found during testing, that
higher version numbers will eventually filter their way to current so
it's probably safe for me to just leave it on. Thanks again.
Jean-Philippe Ouellet
Apr 4, 2017, 11:41:10 AM4/4/17
to Hack, qubes-devel, qubes-users
On Tue, Apr 4, 2017 at 11:35 AM, Hack <mister...@outlook.com> wrote:
>> Dear Qubes community,
>>
>> We have just published Qubes Security Bulletin (QSB) #29:
>> Critical Xen bug in PV memory virtualization code (XSA-212).
>>
>> [...]
>> Dear Qubes community,
>>
>> We have just published Qubes Security Bulletin (QSB) #29:
>> Critical Xen bug in PV memory virtualization code (XSA-212).
>>
>>
>> Discussion
>> ===========
>>
>> This is another bug resulting from the overly-complex memory
>> virtualization required for PV in Xen. As we announced last year [5],
>> the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
>> switching to HVM-based virtualization:
>>
>> | One of the most important security improvements that we plan to
>> | introduce with the release of Qubes 4 is to ditch paravirtualization
>> | (PV) technology and replace it with hardware-enforced memory
>> | virtualization, which recent processors have made possible thanks to
>> | so-called Second Level Address Translation (SLAT), also known as EPT
>> | in Intel parlance. SLAT (EPT) is an extension to Intel VT-x
>> | virtualization, which originally was capable of only CPU
>> | virtualization but not memory virtualization and hence required a
>> | complex Shadow Page Tables approach (which we believed back then was
>> | actually less attractive than the PV approach). We hope that embracing
>> | SLAT-based memory virtualization will allow us to prevent disastrous
>> | security bugs, such as the infamous XSA 148, publicly disclosed in
>> | October of last year, which unlike many other major Xen bugs
>> | regrettably did affect Qubes OS. Consequently, we will be requiring
>> | SLAT support of all certified hardware for Qubes OS 4 and later.
>
>
> Does anybody know about Ryzen SLAT support?
>> Discussion
>> ===========
>>
>> This is another bug resulting from the overly-complex memory
>> virtualization required for PV in Xen. As we announced last year [5],
>> the upcoming Qubes OS 4.0 will no longer use PV. Instead, we will be
>> switching to HVM-based virtualization:
>>
>> | One of the most important security improvements that we plan to
>> | introduce with the release of Qubes 4 is to ditch paravirtualization
>> | (PV) technology and replace it with hardware-enforced memory
>> | virtualization, which recent processors have made possible thanks to
>> | so-called Second Level Address Translation (SLAT), also known as EPT
>> | in Intel parlance. SLAT (EPT) is an extension to Intel VT-x
>> | virtualization, which originally was capable of only CPU
>> | virtualization but not memory virtualization and hence required a
>> | complex Shadow Page Tables approach (which we believed back then was
>> | actually less attractive than the PV approach). We hope that embracing
>> | SLAT-based memory virtualization will allow us to prevent disastrous
>> | security bugs, such as the infamous XSA 148, publicly disclosed in
>> | October of last year, which unlike many other major Xen bugs
>> | regrettably did affect Qubes OS. Consequently, we will be requiring
>> | SLAT support of all certified hardware for Qubes OS 4 and later.
>
>
See https://groups.google.com/d/topic/qubes-devel/LRKd_rK2lXc/discussion
Andrew David Wong
Apr 4, 2017, 11:42:41 AM4/4/17
to Hack, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2017-04-04 08:35, Hack wrote:
Hash: SHA512
>> How to enable security-testing repository? I did not find any
>> documentation on the website.
>
https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
crazVntY+VL2dTIj8uVF7aspSNr+L9qd8RE43U1UIfhEmzah74YszYRspwMe3Xh3
fe8SNkadL2EI6abZi2fY77ajboOaEauwSH4zk0cXtLdi6YHF+ARK0JjzRmlj/LJw
su9yruhK89i6IySMMdD6BVZMM4famChzUS18hqsio7G5ZRRrjk2/UvUmNd/6KxYF
usjBt+YT9BQpFDUEhOhFOAMkIiL8NGCGLD1emRoalEIHm7P/Mz96gDRy9eFFoXyv
O43VVQQyuT1afHjiu+rMBXr1VuZRWiXwXYSVhk0pHWLhwLv9unjRp5NDSK3PZq2J
5STh8/oN5fzB5U3/s0VZFrdGmcQzRAMbgvfI3EjF0P91lxMfSvtDIT10rCrN+rv2
UFropt5eR6Xdw36YW9mOl+tDmAWikMYoTDJyIp2hCfTaAFn+xtw+fvaZyeX7R++G
KHWH+H0jOApbaxE5S2N/cZ8wwYnfOGvNzmWWeGCjQp86GWy3cXQYkd1PtJKVBUgv
6dyyIW9x0JZueMf4zNDuD6ua/h39O2MrU7h/gke4fOdXe6iag5tzpCAp5QTNAj13
cyKOJJpe2CUAELjCb4YXDxBXVkdAh3fh+5hF9is1qhUkrKzHckqY4mFMgpaslZ1+
ZjPs1ZlgAmWzoyBzXUjU
=ELiu
-----END PGP SIGNATURE-----
Reg Tiangha
Apr 4, 2017, 11:53:14 AM4/4/17
to qubes...@googlegroups.com, qubes...@googlegroups.com
On 04/04/2017 08:14 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Packages by default are uploaded to current-testing repository. Moving
> to security-testing require maintainer decision. Done now, you can see
> it here:
> https://github.com/QubesOS/updates-status/issues/26
>
> - --
> 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
So I've noticed that qubesos-bot on GitHub says that these Xen packages
> Packages by default are uploaded to current-testing repository. Moving
> to security-testing require maintainer decision. Done now, you can see
> it here:
> https://github.com/QubesOS/updates-status/issues/26
>
> - --
> 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
were uploaded to jessie-securitytesting, but there's still nothing there.
The 'Packages' file for jessie-securitytesting is currently blank:
https://ftp.qubes-os.org/repo/deb/r3.2/vm/dists/jessie-securitytesting/main/binary-amd64/Packages
Contrast with what the Packages file for jessie-testing has, which is a
lot of stuff:
https://ftp.qubes-os.org/repo/deb/r3.2/vm/dists/jessie-testing/main/binary-amd64/Packages
Is there something wrong at the moment with jessie-securitytesting? By
the way, it's also the same behaviour with the Wheezy and Stretch repos too.
Marek Marczykowski-Górecki
Apr 4, 2017, 12:06:26 PM4/4/17
to Reg Tiangha, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
packages are irrelevant here.
Packages are not uploaded to Debian repository because of this:
https://github.com/QubesOS/qubes-issues/issues/2721
- --
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
H81TgQs0gpObBPevhlfeR8N+jF5R7+vGslCklxciDCyzBe4TkTOUyyGvy3H6+2w2
75NYpS9lVSD3E02MrZdvrT92A/t7XeXD3dkoskyxTJeqkxfbpeYmkcs8l5LNXmPZ
YrFMzE9lhfx/xh6p1+EHMOUn10BsYUkjKfHd0L0rMf9L63iPEykYD3oSTQpij8WT
Fq7Ljrf/eBLKls7AlqXSDmFowMQ/31OPPOamhxn5fbisLrMqedOkvQ3T4WtuM4u/
EBTm+s5LAYq/w7yShFSoOepZ5vbtUQ1yT7DK+r0BtJuKJ2C+/HuGapuvV9rwOtE=
=rvcr
-----END PGP SIGNATURE-----
cooloutac
Apr 4, 2017, 3:13:01 PM4/4/17
to qubes-users, r...@reginaldtiangha.com
cooloutac
Apr 4, 2017, 3:15:05 PM4/4/17
to qubes-users, r...@reginaldtiangha.com
sorry if I read further I would of confirmed yes that is the correct version. ty.
Reply all
Reply to author
Forward
0 new messages