From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: [PATCH v2 0/9] xen: arm: reenable support for 32-bit userspace running in 64-bit guest. Date: Tue, 10 Feb 2015 04:35:56 +0000 Message-ID: <1423542956.5851.9.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel Cc: Julien Grall , Stefano Stabellini , Tim Deegan List-Id: xen-devel@lists.xenproject.org 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 redone the v/ptimer emulation to be correct instead of removing it. Actually removing depends on the "xen: arm: context switch vtimer PPI state." patch, which is going to to take a bit longer. I also implemented Julien's review feedback. Ian. [0] http://xenbits.xen.org/xsa/advisory-102.html