From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJR2d-0003CR-3d for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:48:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJR2S-0008V1-Ob for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:48:22 -0400 Received: from mx2.ll.mit.edu ([129.55.12.46]:47839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJR2S-0008Ug-LN for qemu-devel@nongnu.org; Mon, 18 Aug 2014 13:48:12 -0400 From: "Hulin, Patrick - 0559 - MITLL" Date: Mon, 18 Aug 2014 17:47:08 +0000 Message-ID: References: <5FAD0382C1B6944A908C8A46AB12DA9D03E1EB@LLE2K10-MBX02.mitll.ad.local> <53EE7214.9000603@redhat.com> <9BA52E25-E3BF-42FF-B080-86B7926D8B80@ll.mit.edu> <53F03BCC.705@redhat.com> In-Reply-To: <53F03BCC.705@redhat.com> Content-Language: en-US Content-Type: multipart/mixed; boundary="_002_AB19E7876BCE45FC95F8CFC302B0EFD5llmitedu_" MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU, self-modifying code, and Windows 7 64-bit (no KVM) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "qemu-devel@nongnu.org" --_002_AB19E7876BCE45FC95F8CFC302B0EFD5llmitedu_ Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable On Aug 17, 2014, at 1:21 AM, Paolo Bonzini wrote: > Il 15/08/2014 23:49, Hulin, Patrick - 0559 - MITLL ha scritto: >>>> In this case, the write is 8 bytes and unaligned, so it gets split >>>> into 8 single-byte writes. In stock QEMU, these writes are done in >>>> reverse order (see the loop in softmmu_template.h, line 402). The >>>> third decryption xor from Kernel Patch Protection should hit 4 bytes >>>> that are in the current TB and 4 bytes in the TB afterwards in linear >>>> order. Since this happens in reverse order, and the last 4 bytes of >>>> the write do not intersect the current TB, those writes happen >>>> successfully and QEMU's memory is modified. The 4th byte in linear >>>> order (the 5th in temporal order) then triggers the >>>> current_tb_modified flag and cpu_restore_state, longjmp'ing out. >>>>=20 >>> Would it work to just call tb_invalidate_phys_page_range before the >>> helper_ret_stb loop? >>=20 >> Maybe. I think there=92s another issue, which is that QEMU=92s ending up >> in the I/O read/write code instead of the normal memory RW. This could >> be QEMU messing up, it could be PatchGuard doing something weird, or it >> could be me misunderstanding what=92s going on. I never really figured o= ut >> how the control flow works here. >=20 > That's okay. Everything that's in the slow path goes down > io_mem_read/write (in this case TLB_NOTDIRTY is set for dirty-page > tracking and causes QEMU to choose that path). >=20 > Try making a self-contained test case using the kvm-unit-tests harness > (git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git). >=20 > Paolo Okay. I=92ve attached a test case. Note that since this has to run without = KVM it messes around with the run script. --_002_AB19E7876BCE45FC95F8CFC302B0EFD5llmitedu_ Content-Type: application/octet-stream; name="selfmodify.patch" Content-Description: selfmodify.patch Content-Disposition: attachment; filename="selfmodify.patch"; size=1784; creation-date="Mon, 18 Aug 2014 17:47:08 GMT"; modification-date="Mon, 18 Aug 2014 17:47:08 GMT" Content-ID: <3FA5DDFAAEB4C74D9AB76A8051273492@ll.mit.edu> Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2NvbmZpZy9jb25maWcteDg2LWNvbW1vbi5tYWsgYi9jb25maWcvY29uZmln LXg4Ni1jb21tb24ubWFrDQppbmRleCAwYjBkYTg1Li4wZGRmNWFkIDEwMDY0NA0KLS0tIGEvY29u ZmlnL2NvbmZpZy14ODYtY29tbW9uLm1haw0KKysrIGIvY29uZmlnL2NvbmZpZy14ODYtY29tbW9u Lm1haw0KQEAgLTEwNSw2ICsxMDUsOCBAQCAkKFRFU1RfRElSKS92bXguZWxmOiAkKGNzdGFydC5v KSAkKFRFU1RfRElSKS92bXgubyAkKFRFU1RfRElSKS92bXhfdGVzdHMubw0KIA0KICQoVEVTVF9E SVIpL2RlYnVnLmVsZjogJChjc3RhcnQubykgJChURVNUX0RJUikvZGVidWcubw0KIA0KKyQoVEVT VF9ESVIpL3NlbGZtb2RpZnkuZWxmOiAkKGNzdGFydC5vKSAkKFRFU1RfRElSKS9zZWxmbW9kaWZ5 Lm8NCisNCiBhcmNoX2NsZWFuOg0KIAkkKFJNKSAkKFRFU1RfRElSKS8qLm8gJChURVNUX0RJUikv Ki5mbGF0ICQoVEVTVF9ESVIpLyouZWxmIFwNCiAJJChURVNUX0RJUikvLiouZCBsaWIveDg2Ly4q LmQNCmRpZmYgLS1naXQgYS9jb25maWcvY29uZmlnLXg4Nl82NC5tYWsgYi9jb25maWcvY29uZmln LXg4Nl82NC5tYWsNCmluZGV4IDA2YjI1ODEuLmVkYjIyY2EgMTAwNjQ0DQotLS0gYS9jb25maWcv Y29uZmlnLXg4Nl82NC5tYWsNCisrKyBiL2NvbmZpZy9jb25maWcteDg2XzY0Lm1haw0KQEAgLTks NSArOSw2IEBAIHRlc3RzID0gJChURVNUX0RJUikvYWNjZXNzLmZsYXQgJChURVNUX0RJUikvYXBp Yy5mbGF0IFwNCiAJICAkKFRFU1RfRElSKS9wY2lkLmZsYXQgJChURVNUX0RJUikvZGVidWcuZmxh dA0KIHRlc3RzICs9ICQoVEVTVF9ESVIpL3N2bS5mbGF0DQogdGVzdHMgKz0gJChURVNUX0RJUikv dm14LmZsYXQNCit0ZXN0cyArPSAkKFRFU1RfRElSKS9zZWxmbW9kaWZ5LmZsYXQNCiANCiBpbmNs dWRlIGNvbmZpZy9jb25maWcteDg2LWNvbW1vbi5tYWsNCmRpZmYgLS1naXQgYS94ODYvcnVuIGIv eDg2L3J1bg0KaW5kZXggNjQ2YzU3Ny4uYTM1Njc4ZiAxMDA3NTUNCi0tLSBhL3g4Ni9ydW4NCisr KyBiL3g4Ni9ydW4NCkBAIC0zMyw3ICszMyw3IEBAIGVsc2UNCiAJcGNfdGVzdGRldj0iLWRldmlj ZSB0ZXN0ZGV2LGNoYXJkZXY9dGVzdGxvZyAtY2hhcmRldiBmaWxlLGlkPXRlc3Rsb2cscGF0aD1t c3Iub3V0Ig0KIGZpDQogDQotY29tbWFuZD0iJHtxZW11fSAtZW5hYmxlLWt2bSAkcGNfdGVzdGRl diAtZGlzcGxheSBub25lIC1zZXJpYWwgc3RkaW8gJHBjaV90ZXN0ZGV2IC1rZXJuZWwiDQorY29t bWFuZD0iJHtxZW11fSAkcGNfdGVzdGRldiAtZGlzcGxheSBub25lIC1zZXJpYWwgc3RkaW8gJHBj aV90ZXN0ZGV2IC1rZXJuZWwiDQogZWNobyAke2NvbW1hbmR9ICIkQCINCiAke2NvbW1hbmR9ICIk QCINCiByZXQ9JD8NCmRpZmYgLS1naXQgYS94ODYvdW5pdHRlc3RzLmNmZyBiL3g4Ni91bml0dGVz dHMuY2ZnDQppbmRleCA2ZDNlMjNhLi42NDYxMzBiIDEwMDY0NA0KLS0tIGEveDg2L3VuaXR0ZXN0 cy5jZmcNCisrKyBiL3g4Ni91bml0dGVzdHMuY2ZnDQpAQCAtNiw2ICs2LDEwIEBADQogIyBhcmNo ID0gaTM4Ni94ODZfNjQgIyBPbmx5IGlmIHRoZSB0ZXN0IGNhc2Ugd29ya3Mgb25seSBvbiBvbmUg b2YgdGhlbQ0KICMgZ3JvdXBzID0gZ3JvdXAxIGdyb3VwMiAjIFVzZWQgdG8gaWRlbnRpZnkgdGVz dCBjYXNlcyB3aXRoIHJ1bl90ZXN0cyAtZyAuLi4NCiANCitbc2VsZm1vZGlmeV0NCitmaWxlID0g c2VsZm1vZGlmeS5mbGF0DQorYXJjaCA9IHg4Nl82NA0KKw0KIFthcGljXQ0KIGZpbGUgPSBhcGlj LmZsYXQNCiBzbXAgPSAyDQo= --_002_AB19E7876BCE45FC95F8CFC302B0EFD5llmitedu_--