From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: [RFC PATCH 0/9] xen: arm: reenable support for 32-bit userspace running in 64-bit guest. Date: Tue, 9 Sep 2014 17:22:10 +0100 Message-ID: <1410279730.8217.238.camel@kazak.uk.xensource.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 , Tim Deegan , Stefano Stabellini 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). I've also successfully booted the VM which originally caused XSA-102 to be discovered (FSO successfully, since the VM image appears to be broken, but it no longer crashes for 32-on-64 reasons...) Ian. [0] http://xenbits.xen.org/xsa/advisory-102.html