From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Fwd: Xen-4.1.6.1 backport for XSA156 Date: Fri, 20 Nov 2015 16:03:23 +0100 Message-ID: <564F363B.3010802@canonical.com> References: <564F0603.2080708@canonical.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8892986574244209012==" Return-path: In-Reply-To: <564F0603.2080708@canonical.com> 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@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============8892986574244209012== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1IGivuhXXIFiRAW0WkrSt16Wt0PNFn9bn" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1IGivuhXXIFiRAW0WkrSt16Wt0PNFn9bn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jan, hi Andrew, I am currently trying to backport the changes of XSA156 back to Xen-4.1.x= and I am struggling with the VMX side. I did see the backports made for 4.2 and= 3.4 on the security mailing list but I am not sure the 3.4 backport is not havin= g the same issues (or similar ones). Trying to write down my understanding of the changes: For the 3.4 backpor= t there are only changes to the toggles for debugging and the general trap mask. = So if I understand this right, before the change, TRAP_debug and TRAP_int3 were o= nly handled in vmexit when a debugger was attached to the domain. Now, only TRAP_int3 will be toggled and TRAP_debug is always handled. My testing does (beside other things) involve some verification of ptrace= handling. Which on 4.1.x with the changes, now causes a crash of the HVM = guest in vm_resume (vm_resume_fail error code 7). I think this is caused by TRAP_debug being handled in vmexit. I don't hav= e the 3.4 code so not sure whether there is anything handling it. In the 4.1.x = case and without changing the vmexit code in xen/arch/x86/hvm/vmx/vmx.c it wou= ld be a certain crash as no domain debugging is done. The problem seems to be tha= t I do inject (as the 4.2 patch does) an exception. Though 4.1.x does not, yet, = have the changes from "xen: Define new struct hvm_trap and cleanup vmx excepti= on", so I only have either hvm_inject_exception or vmx_inject_hw_exception. The f= ormer ends up calling the latter. What I think is the problem (which svm does n= ot have) is the debug/int3 handling in the function below. This seems to con= vert the exception unconditionally into a software exception that has an opcod= e associated. Would you also think this is the issue? And if yes, is there = any sane way you can think of to prevent this without having to resort to pul= ling in large hunks of rewrite? Regards, Stefan vmx_inject_hw_exception( ... switch ( trap ) { case TRAP_debug: type =3D X86_EVENTTYPE_SW_EXCEPTION; if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF ) { __restore_debug_registers(curr); write_debugreg(6, read_debugreg(6) | 0x4000); } if ( cpu_has_monitor_trap_flag ) break; case TRAP_int3: if ( curr->domain->debugger_attached ) { /* Debug/Int3: Trap to debugger. */ domain_pause_for_debugger(); return; } type =3D X86_EVENTTYPE_SW_EXCEPTION; __vmwrite(VM_ENTRY_INSTRUCTION_LEN, 1); /* int3 */ ... } --1IGivuhXXIFiRAW0WkrSt16Wt0PNFn9bn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJWTzZMAAoJEOhnXe7L7s6jwjoQAN31vxqpe+nb8bd+mwPQvN51 AmcPL7xFMBmXbW33HGak2o/Ouqqoq/lFQAKZqYpQEV3fKzHbio8hUV7pC6DA7QV5 RCtUHgMjhS73i6oEquWii508aGLCJ8UMzHMV6jPnyGolLXn8Ih/6l35EKKRhjreW 7M+OzqZLW3V/BJh1UsYL8ob/WiX3Og6hnkEJMpnamsPY1lQ8HNEtYd2SDLYAnPy3 YU1zD9+EeJndLYTQx4Hr/4DlE2SAxh9AT8QprWVJ2MI3W0PoRdcLOkLcnon79nhR W3eAVutN9p+faSDk4vT61wNhCig2+6WSpXKJ5+mItIKuDwz8muDaFe2nciIPPLf2 IUN/O/iaohrm5yCwlNxc2ETOliBkCJx4tdxX52D8KuAi1k9TmSUmLd6tve5nZ0mS pyWsnECJ1Zencc91Xwczj6K6F/3d7U5A3kyiV05THxd66qUSl0EXdt5Y6KSN7V/o 4jb+bAQSwGE/RXm8THxwU+yrRINve7ZSf9XarmITLVChHLy7cazr62q8NL2VLeFO hXv3zVE5GkVrb82OgfUKrj5SFqRpq9PZvoxsxxvmRyj3TbaB6mAbhagPa1xhMWHI YH0up+7YnRGA3P2Ht6jnPePjOYAx/AItE8FRx0wOWjKoDk/oKndj4Yomu4D9BIrd 3zDu3w56HBhWJJUgopYx =EdsA -----END PGP SIGNATURE----- --1IGivuhXXIFiRAW0WkrSt16Wt0PNFn9bn-- --===============8892986574244209012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8892986574244209012==--