Re: [Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

2016-05-13 Thread Jan Beulich 
>>> On 13.05.16 at 12:55,  wrote:
> Am 18.04.2016 um 15:31 schrieb Xen.org security team:
>> +/*
>> + * Bit 24 of a 24-bit flag mask!  This is not any bit of a real pte,
>> + * and is only used for signalling in variables that contain flags.
>> + */
>> +#define _PAGE_INVALID_BIT (1U<<24)
>> +
>>  #endif /* __X86_64_PAGE_H__ */
> 
> I guess using bit 24 is okay for 32 bit, too.
> 
> Can someone confirm that please?

Yes, that should be fine.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

2016-05-13 Thread Philipp Hahn 
Hi,


Am 18.04.2016 um 15:31 schrieb Xen.org security team:
> Xen Security Advisory CVE-2016-3960 / XSA-173
>   version 3
> 
>  x86 shadow pagetables: address width overflow
...
> ISSUE DESCRIPTION
> =
> In the x86 shadow pagetable code, the guest frame number of a
> superpage mapping is stored in a 32-bit field.  If a shadowed guest
> can cause a superpage mapping of a guest-physical address at or above
> 2^44 to be shadowed, the top bits of the address will be lost, causing
> an assertion failure or NULL dereference later on, in code that
> removes the shadow.
...
> VULNERABLE SYSTEMS
> ==
> Xen versions from 3.4 onwards are affected.
> 
> Only x86 variants of Xen are susceptible.  ARM variants are not
> affected.
...
> RESOLUTION
> ==
> Applying the appropriate attached patch resolves this issue.
...
> xsa173-4.3.patch   Xen 4.3.x

As Xen-4.2 and xen-4.1 are also vulnerable, I'm trying to backport this.
The 4.3 patch applies mostly, but compilation fails as x86-32-bit
support was dropped with Xen-4.3 and  _PAGE_INVALID_BIT remains
undefined for x86-32:
> guest_walk.c: In function 'mandatory_flags':
> guest_walk.c:66:40: error: '_PAGE_INVALID_BIT' undeclared (first use in this 
> function)
> guest_walk.c:66:40: note: each undeclared identifier is reported only once 
> for each function it appears in
> guest_walk.c: In function 'guest_walk_tables_2_levels':
> guest_walk.c:146:30: error: '_PAGE_INVALID_BIT' undeclared (first use in this 
> function)
> guest_walk.c: In function 'mandatory_flags':
> guest_walk.c:67:1: error: control reaches end of non-void function 
> [-Werror=return-type]

It's only defined for x86-64:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
...
> +/*
> + * Bit 24 of a 24-bit flag mask!  This is not any bit of a real pte,
> + * and is only used for signalling in variables that contain flags.
> + */
> +#define _PAGE_INVALID_BIT (1U<<24)
> +
>  #endif /* __X86_64_PAGE_H__ */

I guess using bit 24 is okay for 32 bit, too.

Can someone confirm that please?

Philipp

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow

2016-04-18 Thread Xen . org security team 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2016-3960 / XSA-173
  version 3

 x86 shadow pagetables: address width overflow

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

In the x86 shadow pagetable code, the guest frame number of a
superpage mapping is stored in a 32-bit field.  If a shadowed guest
can cause a superpage mapping of a guest-physical address at or above
2^44 to be shadowed, the top bits of the address will be lost, causing
an assertion failure or NULL dereference later on, in code that
removes the shadow.


IMPACT
==

A HVM guest using shadow pagetables can cause the host to crash.

A PV guest using shadow pagetables (i.e. being migrated) with PV
superpages enabled (which is not the default) can crash the host, or
corrupt hypervisor memory, and so a privilege escalation cannot be
ruled out.


VULNERABLE SYSTEMS
==

Xen versions from 3.4 onwards are affected.

Only x86 variants of Xen are susceptible.  ARM variants are not
affected.

HVM guests using shadow mode paging can expose this vulnerability.  HVM
guests using Hardware Assisted Paging (HAP) are unaffected.

Systems running PV guests with PV superpages enabled are vulnerable if
those guests undergo live migration.  PV superpages are disabled by
default, so systems are not vulnerable in this way unless
"allowsuperpage" is on the Xen command line.

To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q').  This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:

  (XEN) General information for domain 2:
  (XEN) refcnt=1 dying=2 pause_count=2
  (XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0 
dirty_cpus={} max_pages=262400
  (XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
  (XEN) paging assistance: hap refcounts translate external
   ^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain.  For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.


MITIGATION
==

Running only PV guests will avoid this vulnerability, unless PV
superpage support is enabled (see above).

Running HVM guests with Hardware Assisted Paging (HAP) enabled will
also avoid this vulnerability.  This is the default mode on hardware
supporting HAP, but can be overridden by hypervisor command line
option and guest configuration setting.  Such overrides ("hap=0" in
either case, with variants like "no-hap" being possible in the
hypervisor command line case) would need to be removed to avoid this
vulnerability.


CREDITS
===

This issue was discovered by Ling Liu and Yihan Lian of the Cloud
Security Team, Qihoo 360.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa173-unstable.patch  xen-unstable
xsa173-4.6.patch   Xen 4.6.x
xsa173-4.5.patch   Xen 4.5.x
xsa173-4.4.patch   Xen 4.4.x
xsa173-4.3.patch   Xen 4.3.x

$ sha256sum xsa173*
bd4619334351afc9f71bb529e8ac102c63415bb4d13197e3bd24a58de03726cb  
xsa173-unstable.patch
089c07f0c8237da674796f155ee7e3c0305efd11a59df30ef2c3d5f6b423bfea  
xsa173-4.3.patch
35e02b8d4c2841ad951dd967b4f11aa7911fe5d52be2cb605b174e8c2e9214ca  
xsa173-4.4.patch
8cd255416975b5589b85911142b385cc1ed78b8ea5e16ebe9d6c60e2679b23aa  
xsa173-4.5.patch
6dbc34e3e2d4415967c4406e0f8392a9395bff74da115ae20f26bd112b19017c  
xsa173-4.6.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJXFOGhAAoJEIP+FMlX6CvZXUYH/A1ekMpU71/JUK1c53qHmaTY
ZCsJj5hArL9poTYss/AfyumZRATalPrbX/Wt6JaVMutMefgPjphP8OKTzywr/aDJ
vRIim4piOABS15cWtYlfTans6X4yyk1NxmMt182osRW1JSW+OrjXORs6719zoEL7
3hzuf7g6pYiaVqtUmLEx9/U3T246ZaQ98V93YVxGGUyUYRBmFJxEAtA2yf4SlqNX