diff for duplicates of <20190604134205.757b217a@redhat.com> diff --git a/a/1.txt b/N1/1.txt index ea40189..37869fc 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -31,3 +31,92 @@ Tested-by: Igor Mammedov <imammedo@redhat.com> > unsigned shift; > do_unaligned_access: > addr1 = addr & ~(size - 1); + +-- +You received this bug notification because you are a member of qemu- +devel-ml, which is subscribed to QEMU. +https://bugs.launchpad.net/bugs/1830872 + +Title: + AARCH64 to ARMv7 mistranslation in TCG + +Status in QEMU: + New + +Bug description: + The following guest code: + + https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S + + implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI + Development Kit II) library function. (CopyMem() basically has memmove() + semantics, to provide a standard C analog here.) The relevant functions + are InternalMemCopyMem() and __memcpy(). + + When TCG translates this aarch64 code to x86_64, everything works + fine. + + When TCG translates this aarch64 code to ARMv7, the destination area of + the translated CopyMem() function becomes corrupted -- it differs from + the intended source contents. Namely, in every 4096 byte block, the + 8-byte word at offset 4032 (0xFC0) is zeroed out in the destination, + instead of receiving the intended source value. + + I'm attaching two hexdumps of the same destination area: + + - "good.txt" is a hexdump of the destination area when CopyMem() was + translated to x86_64, + + - "bad.txt" is a hexdump of the destination area when CopyMem() was + translated to ARMv7. + + In order to assist with the analysis of this issue, I disassembled the + aarch64 binary with "objdump". Please find the listing in + "DxeCore.objdump", attached. The InternalMemCopyMem() function starts at + hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180. + + And, I ran the guest on the ARMv7 host with "-d + in_asm,op,op_opt,op_ind,out_asm". Please find the log in + "tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached. + + The TBs that correspond to (parts of) the InternalMemCopyMem() and + __memcpy() functions are scattered over the TCG log file, but the offset + between the "nice" disassembly from "DxeCore.objdump", and the in-RAM + TBs in the TCG log, can be determined from the fact that there is a + single prfm instruction in the entire binary. The instruction's offset + is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy() + function --, and its RAM address is 0x472d2180 in the TCG log. Thus the + difference (= the load address of DxeCore.efi) is 0x472a7000. + + QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch + 'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21). + + The reproducer command line is (on an ARMv7 host): + + qemu-system-aarch64 \ + -display none \ + -machine virt,accel=tcg \ + -nodefaults \ + -nographic \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \ + -cpu cortex-a57 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline \ + -serial chardev:char0 + + The apparent symptom is an assertion failure *in the guest*, such as + + > ASSERT [DxeCore] + > /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090): + > Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength + + but that is only a (distant) consequence of the CopyMem() + mistranslation, and resultant destination area corruption. + + Originally reported in the following two mailing list messages: + - http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com + - http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions diff --git a/a/content_digest b/N1/content_digest index b6db70b..05ae15c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,14 +1,9 @@ + "ref\0155912118291.12579.8926874795813611531.malonedeb@soybean.canonical.com\0" "ref\020190603150120.29255-1-alex.bennee@linaro.org\0" - "From\0Igor Mammedov <imammedo@redhat.com>\0" - "Subject\0Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load\0" - "Date\0Tue, 4 Jun 2019 13:42:05 +0200\0" - "To\0Alex Benn\303\251e <alex.bennee@linaro.org>\0" - "Cc\0qemu-devel@nongnu.org" - 1830872@bugs.launchpad.net - qemu-arm@nongnu.org - Paolo Bonzini <pbonzini@redhat.com> - randrianasulu@gmail.com - " Richard Henderson <rth@twiddle.net>\0" + "From\0Igor <imammedo@redhat.com>\0" + "Subject\0[Qemu-devel] [Bug 1830872] Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load\0" + "Date\0Tue, 04 Jun 2019 11:42:05 -0000\0" + "To\0qemu-devel@nongnu.org\0" "\00:1\0" "b\0" "On Mon, 3 Jun 2019 16:01:20 +0100\n" @@ -43,6 +38,95 @@ "> + uint64_t r1, r2;\n" "> unsigned shift;\n" "> do_unaligned_access:\n" - > addr1 = addr & ~(size - 1); + "> addr1 = addr & ~(size - 1);\n" + "\n" + "-- \n" + "You received this bug notification because you are a member of qemu-\n" + "devel-ml, which is subscribed to QEMU.\n" + "https://bugs.launchpad.net/bugs/1830872\n" + "\n" + "Title:\n" + " AARCH64 to ARMv7 mistranslation in TCG\n" + "\n" + "Status in QEMU:\n" + " New\n" + "\n" + "Bug description:\n" + " The following guest code:\n" + "\n" + " https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S\n" + "\n" + " implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI\n" + " Development Kit II) library function. (CopyMem() basically has memmove()\n" + " semantics, to provide a standard C analog here.) The relevant functions\n" + " are InternalMemCopyMem() and __memcpy().\n" + "\n" + " When TCG translates this aarch64 code to x86_64, everything works\n" + " fine.\n" + "\n" + " When TCG translates this aarch64 code to ARMv7, the destination area of\n" + " the translated CopyMem() function becomes corrupted -- it differs from\n" + " the intended source contents. Namely, in every 4096 byte block, the\n" + " 8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,\n" + " instead of receiving the intended source value.\n" + "\n" + " I'm attaching two hexdumps of the same destination area:\n" + "\n" + " - \"good.txt\" is a hexdump of the destination area when CopyMem() was\n" + " translated to x86_64,\n" + "\n" + " - \"bad.txt\" is a hexdump of the destination area when CopyMem() was\n" + " translated to ARMv7.\n" + "\n" + " In order to assist with the analysis of this issue, I disassembled the\n" + " aarch64 binary with \"objdump\". Please find the listing in\n" + " \"DxeCore.objdump\", attached. The InternalMemCopyMem() function starts at\n" + " hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.\n" + "\n" + " And, I ran the guest on the ARMv7 host with \"-d\n" + " in_asm,op,op_opt,op_ind,out_asm\". Please find the log in\n" + " \"tcg.in_asm.op.op_opt.op_ind.out_asm.log\", attached.\n" + "\n" + " The TBs that correspond to (parts of) the InternalMemCopyMem() and\n" + " __memcpy() functions are scattered over the TCG log file, but the offset\n" + " between the \"nice\" disassembly from \"DxeCore.objdump\", and the in-RAM\n" + " TBs in the TCG log, can be determined from the fact that there is a\n" + " single prfm instruction in the entire binary. The instruction's offset\n" + " is 0x2b180 in \"DxeCore.objdump\" -- at the beginning of the __memcpy()\n" + " function --, and its RAM address is 0x472d2180 in the TCG log. Thus the\n" + " difference (= the load address of DxeCore.efi) is 0x472a7000.\n" + "\n" + " QEMU was built at commit a4f667b67149 (\"Merge remote-tracking branch\n" + " 'remotes/cohuck/tags/s390x-20190521-3' into staging\", 2019-05-21).\n" + "\n" + " The reproducer command line is (on an ARMv7 host):\n" + "\n" + " qemu-system-aarch64 \\\n" + " -display none \\\n" + " -machine virt,accel=tcg \\\n" + " -nodefaults \\\n" + " -nographic \\\n" + " -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \\\n" + " -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \\\n" + " -cpu cortex-a57 \\\n" + " -chardev stdio,signal=off,mux=on,id=char0 \\\n" + " -mon chardev=char0,mode=readline \\\n" + " -serial chardev:char0\n" + "\n" + " The apparent symptom is an assertion failure *in the guest*, such as\n" + "\n" + " > ASSERT [DxeCore]\n" + " > /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):\n" + " > Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength\n" + "\n" + " but that is only a (distant) consequence of the CopyMem()\n" + " mistranslation, and resultant destination area corruption.\n" + "\n" + " Originally reported in the following two mailing list messages:\n" + " - http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com\n" + " - http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com\n" + "\n" + "To manage notifications about this bug go to:\n" + https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions -5f6b93d9b302686a3de7907f2b4ab1d00b145cc8fead37ca936bb8d44fcaa4d5 +2e2307c84d0c2580f66c234217f8a368507558ef5c3b0cdc50c22fe1b75d68f4
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.