From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Cc: Julien Grall <julien.grall@citrix.com>, Tim Deegan <tim@xen.org>,
Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: [PATCH v3 0/12] xen: arm: reenable support for 32-bit userspace running in 64-bit guest.
Date: Wed, 25 Mar 2015 14:22:19 +0000 [thread overview]
Message-ID: <1427293339.10784.83.camel@citrix.com> (raw)
XSA-102/CVE-2014-5147[0] concerned a crash when trapping from 32-bit
userspace in a 64-bit guest. Part of that security patch was c0020e09970
"xen: arm: Handle traps from 32-bit userspace on 64-bit kernel as undef
fix" which turned the exploitable crash into a #undef to the guest (so
as to kill the process but not the host) as a workaround for the issue.
However while this prevented the exploit it did not make 32-bit
userspaces which were prone to triggering the issue actually work.
This series consists of some patches which I originally wrote for
XSA-102 to fix the issue properly before it was determined that those
fixes were too invasive by far for a security update. At the end of the
series is a new patch which removes the XSA-102 workaround since all
problematic traps should now be handled.
Since these were originally intended to be the security fix they have
had a fair bit of scrutiny already in private . However since there is
now a risk of reintroducing XSA-102 I would appreciate a pretty thorough
second pair of eyes on it this time around.
I've tested this with a local utility which tries to access the various
cp and system registers from both 32- and 64-bit processes and checks
that they either work or give the expected traps. Since this tool is
effectively an exploit for XSA-102 I'm not sharing here but if you ask
nicely and appear to be wearing the correct colour hat I might share it
with you (it's not terribly impressive, so don't get too excited).
Since last time I've implemented Julien's review feedback including:
* added the GUEST_BUG_ON patch to the end to replace the BUG_ONs
due to invalid h/w state, which gets more useful debug if that
occurs.
* handled CNTP_CVAL_EL0.
Ian.
[0] http://xenbits.xen.org/xsa/advisory-102.html
next reply other threads:[~2015-03-25 14:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 14:22 Ian Campbell [this message]
2015-03-25 14:22 ` [PATCH 01/12] xen: arm: Correct PMXEV cp register definitions Ian Campbell
2015-03-25 14:22 ` [PATCH 02/12] xen: arm: handle accesses to CNTP_CVAL_EL0 Ian Campbell
2015-03-25 18:23 ` Julien Grall
2015-03-25 18:32 ` Julien Grall
2015-03-26 10:59 ` Ian Campbell
2015-03-26 16:07 ` Ian Campbell
2015-03-25 14:22 ` [PATCH 03/12] xen: arm: Use ARMv8 names for CNTHCTL_EL2 bits Ian Campbell
2015-03-25 18:25 ` Julien Grall
2015-03-25 14:22 ` [PATCH 04/12] xen: arm: Factor out psr_mode_is_user Ian Campbell
2015-03-25 14:22 ` [PATCH 05/12] xen: arm: Handle 32-bit EL0 on 64-bit EL1 when advancing PC after trap Ian Campbell
2015-03-25 14:22 ` [PATCH 06/12] xen: arm: correctly handle vtimer traps from userspace Ian Campbell
2015-03-25 18:41 ` Julien Grall
2015-03-26 11:09 ` Ian Campbell
2015-03-25 14:22 ` [PATCH 07/12] xen: arm: Handle CP15 register " Ian Campbell
2015-03-25 18:59 ` Julien Grall
2015-03-26 11:19 ` Ian Campbell
2015-03-25 14:22 ` [PATCH 08/12] xen: arm: Handle CP14 32-bit register accesses " Ian Campbell
2015-03-25 19:05 ` Julien Grall
2015-03-25 14:22 ` [PATCH 09/12] xen: arm: correctly handle sysreg " Ian Campbell
2015-03-25 19:22 ` Julien Grall
2015-03-26 11:32 ` Ian Campbell
2015-03-25 14:22 ` [PATCH 10/12] xen: arm: handle remaining traps " Ian Campbell
2015-03-25 19:29 ` Julien Grall
2015-03-25 14:22 ` [PATCH 11/12] xen: arm: Allow traps from 32 bit userspace on 64 bit hypervisors again Ian Campbell
2015-03-25 14:22 ` [PATCH 12/12] xen: arm: Dump guest state when invalid trap state is detected Ian Campbell
2015-03-25 19:35 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1427293339.10784.83.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.