Skip to content
This repository has been archived by the owner on Apr 14, 2023. It is now read-only.

Support loading kernel, device tree, trust cache from im4p files #9

Merged
merged 5 commits into from
Mar 11, 2021
Merged

Support loading kernel, device tree, trust cache from im4p files #9

merged 5 commits into from
Mar 11, 2021

Conversation

qmfrederik
Copy link
Contributor

@qmfrederik qmfrederik commented Mar 10, 2021

This adds support for extracting the kernel, device tree and trust cache from im4p files.

It turns out qemu doesn't link with OpenSSL after all, but does use GnuTLS which uses libtasn1, which supports parsing ASN.1 files as well.

It does require you to define a schema for the ASN.1 structure which you're parsing (hence the img4.asn1 file), which is then converted into a "definitions array" using asn1Parser -o img4.c -n img4_definitions_array img4.asn1.

The code assumes:

  • The file is an IM4P file if asn1_der_decoding can successfully parse the file.
  • The payload is LZFSE-compressed if it starts with the string bvx.

@qmfrederik
Copy link
Contributor Author

@TrungNguyen1909 For some reason this doesn't work with the trust cache; so I disabled IM4P support for the trust cache for now.

@TrungNguyen1909
Copy link
Owner

trust caches use "rtsc" as payload type AFAIK, can you verify if it works or not?

@TrungNguyen1909
Copy link
Owner

Also, you wouldnt want qemu exits if im4p parser failed because there are cases where you want qemu to load the unpacked data as it.

For instance, ramdisk: its filesystem need to be decompressed. In that case, you wouldnt want to repack it into im4p format, right?

@qmfrederik
Copy link
Contributor Author

@TrungNguyen1909 , correct, let me rephrase that a bit:

The code assumes:

  • The file is an IM4P file if asn1_der_decoding can successfully parse the file. If it is not an IM4P file, the file is loaded as is.
  • The payload is LZFSE-compressed if it starts with the string bvx. If the payload does nto start with bvx, the payload is loaded as is.

@qmfrederik qmfrederik changed the title Support loading kernel, device tree from im4p files Support loading kernel, device tree, trust cache from im4p files Mar 11, 2021
@qmfrederik
Copy link
Contributor Author

@TrungNguyen1909 I added support for the trustcache and a couple of sanity checks (to make sure the data which is being loaded is a valid MACH object or a valid trust cache).

I didn't implement the ram disk since it needs to be decompressed anyway.

@TrungNguyen1909
Copy link
Owner

Errors in extract_im4p_payload should be returned to the caller instead of exit(EXIT_FAILURE).

And when it fails, we should fallback to load the file as it.

@qmfrederik
Copy link
Contributor Author

Errors in extract_im4p_payload should be returned to the caller instead of exit(EXIT_FAILURE).
And when it fails, we should fallback to load the file as it.

Thanks, in that case, I'd suggest to change the semantics of extract_im4p_payload to be closer to those of g_file_get_contents. That would mean returning TRUE/FALSE depending on whether the operation succeeds.

If the file is not an DER-encoded ASN.1 file which conforms to the IM4P payload specification, the raw content is always returned (as is the case in the current implementation).

But I'm not sure that falling back to the raw payload is always the right thing to do.

For example, when asn1_der_decoding succeeds, the file is a DER-encoded ASN.1 file which conforms to the IM4P payload specification. This means the raw content can never be a valid kernel, trust cache, device tree or ram disk file. Returning the raw content will only result in a failure later down, right?

In that case, I'd suggest to print an error message (for example: "expeting a krnl file but we got a dtre file") and just return FALSE, so that the calling code can clean up and exit.

What about we change the semantics like this:

  • Change extract_im4p_payload to return a gboolean just like g_file_get_contents does, and have it return FALSE if g_file_get_contents fails.
  • Failures in asn1_array2tree and asn1_create_element are some corner cases, since this code is not operating on user input and not supposed to fail. If they fail, you probably hit an out of memory situation or something similar. So we could probably just assert instead`.
  • If asn1_der_decoding fails, the file is returned "as is" (this is already the case)
  • If asn1_der_decoding succeeds, but any of the ASN.1-manipulating functions fail, the file is very probably invalid (e.g. the wrong type, wrong magic,...). So call error_report but return FALSE instead of calling exit(EXIT_FAILURE)?

Though in the end, all calls to extract_im4p_payload will probably just abort if extract_im4p_payload returns FALSE (just like they abort now if g_file_get_contents returns false)?

@TrungNguyen1909
Copy link
Owner

Ah, I got it.

Sorry I missed that earlier.

Thanks.

hw/arm/xnu.c Outdated Show resolved Hide resolved
@TrungNguyen1909 TrungNguyen1909 merged commit 28f31ea into TrungNguyen1909:master Mar 11, 2021
@dom-lgtm dom-lgtm mentioned this pull request Jul 12, 2022
shannon2893 pushed a commit to shannon2893/qemu-t8030 that referenced this pull request Jul 25, 2022
In commit 00f05c0 we gave the TYPE_XLNX_CSU_DMA object its
own class struct, but forgot to update the TypeInfo::class_size
accordingly.  This meant that not enough memory was allocated for the
class struct, and the initialization of xcdc->read in the class init
function wrote off the end of the memory. Add the missing line.

Found by running 'check-qtest-aarch64' with a clang
address-sanitizer build, which complains:

==2542634==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61000000ab00 at pc 0x559a20aebc29 bp 0x7fff97df74d0 sp 0x7fff97df74c8
WRITE of size 8 at 0x61000000ab00 thread T0
    #0 0x559a20aebc28 in xlnx_csu_dma_class_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../hw/dma/xlnx_csu_dma.c:722:16
    TrungNguyen1909#1 0x559a21bf297c in type_initialize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:365:9
    TrungNguyen1909#2 0x559a21bf3442 in object_class_foreach_tramp /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1070:5
    TrungNguyen1909#3 0x7f09bcb641b7 in g_hash_table_foreach (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x401b7)
    TrungNguyen1909#4 0x559a21bf3c27 in object_class_foreach /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1092:5
    TrungNguyen1909#5 0x559a21bf3c27 in object_class_get_list /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1149:5
    TrungNguyen1909#6 0x559a2081a2fd in select_machine /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:1661:24
    TrungNguyen1909#7 0x559a2081a2fd in qemu_create_machine /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:2146:35
    TrungNguyen1909#8 0x559a2081a2fd in qemu_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/vl.c:3706:5
    TrungNguyen1909#9 0x559a20720ed5 in main /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../softmmu/main.c:49:5
    TrungNguyen1909#10 0x7f09baec00b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
    TrungNguyen1909#11 0x559a2067673d in _start (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/qemu-system-aarch64+0xf4b73d)

0x61000000ab00 is located 0 bytes to the right of 192-byte region [0x61000000aa40,0x61000000ab00)
allocated by thread T0 here:
    #0 0x559a206eeff2 in calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/qemu-system-aarch64+0xfc3ff2)
    TrungNguyen1909#1 0x7f09bcb7bef0 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ef0)
    TrungNguyen1909#2 0x559a21bf3442 in object_class_foreach_tramp /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/san/../../qom/object.c:1070:5

Fixes: 00f05c0 ("hw/dma/xlnx_csu_dma: Support starting a read transfer through a class method")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Francisco Iglesias <francisco.iglesias@xilinx.com>
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-id: 20220308150207.2546272-1-peter.maydell@linaro.org
shannon2893 pushed a commit to shannon2893/qemu-t8030 that referenced this pull request Jul 25, 2022
Include the qtest reproducer provided by Alexander Bulekov
in https://gitlab.com/qemu-project/qemu/-/issues/542.
Without the previous commit, we get:

  $ make check-qtest-i386
  ...
  Running test tests/qtest/intel-hda-test
  AddressSanitizer:DEADLYSIGNAL
  =================================================================
  ==1580408==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc3d566fe0
      #0 0x63d297cf in address_space_translate_internal softmmu/physmem.c:356
      TrungNguyen1909#1 0x63d27260 in flatview_do_translate softmmu/physmem.c:499:15
      TrungNguyen1909#2 0x63d27af5 in flatview_translate softmmu/physmem.c:565:15
      TrungNguyen1909#3 0x63d4ce84 in flatview_write softmmu/physmem.c:2850:10
      TrungNguyen1909#4 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18
      TrungNguyen1909#5 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16
      TrungNguyen1909#6 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      TrungNguyen1909#7 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12
      TrungNguyen1909#8 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12
      TrungNguyen1909#9 0x62ae5ec0 in stl_le_dma include/sysemu/dma.h:275:1
      TrungNguyen1909#10 0x62ae5ba2 in stl_le_pci_dma include/hw/pci/pci.h:871:1
      TrungNguyen1909#11 0x62ad59a6 in intel_hda_response hw/audio/intel-hda.c:372:12
      TrungNguyen1909#12 0x62ad2afb in hda_codec_response hw/audio/intel-hda.c:107:5
      TrungNguyen1909#13 0x62aec4e1 in hda_audio_command hw/audio/hda-codec.c:655:5
      TrungNguyen1909#14 0x62ae05d9 in intel_hda_send_command hw/audio/intel-hda.c:307:5
      TrungNguyen1909#15 0x62adff54 in intel_hda_corb_run hw/audio/intel-hda.c:342:9
      TrungNguyen1909#16 0x62adc13b in intel_hda_set_corb_wp hw/audio/intel-hda.c:548:5
      TrungNguyen1909#17 0x62ae5942 in intel_hda_reg_write hw/audio/intel-hda.c:977:9
      TrungNguyen1909#18 0x62ada10a in intel_hda_mmio_write hw/audio/intel-hda.c:1054:5
      TrungNguyen1909#19 0x63d8f383 in memory_region_write_accessor softmmu/memory.c:492:5
      TrungNguyen1909#20 0x63d8ecc1 in access_with_adjusted_size softmmu/memory.c:554:18
      TrungNguyen1909#21 0x63d8d5d6 in memory_region_dispatch_write softmmu/memory.c:1504:16
      TrungNguyen1909#22 0x63d5e85e in flatview_write_continue softmmu/physmem.c:2812:23
      TrungNguyen1909#23 0x63d4d05b in flatview_write softmmu/physmem.c:2854:12
      TrungNguyen1909#24 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18
      TrungNguyen1909#25 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16
      TrungNguyen1909#26 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      #27 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12
      TrungNguyen1909#28 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12
      TrungNguyen1909#29 0x62ae5ec0 in stl_le_dma include/sysemu/dma.h:275:1
      TrungNguyen1909#30 0x62ae5ba2 in stl_le_pci_dma include/hw/pci/pci.h:871:1
      TrungNguyen1909#31 0x62ad59a6 in intel_hda_response hw/audio/intel-hda.c:372:12
      TrungNguyen1909#32 0x62ad2afb in hda_codec_response hw/audio/intel-hda.c:107:5
      TrungNguyen1909#33 0x62aec4e1 in hda_audio_command hw/audio/hda-codec.c:655:5
      TrungNguyen1909#34 0x62ae05d9 in intel_hda_send_command hw/audio/intel-hda.c:307:5
      TrungNguyen1909#35 0x62adff54 in intel_hda_corb_run hw/audio/intel-hda.c:342:9
      TrungNguyen1909#36 0x62adc13b in intel_hda_set_corb_wp hw/audio/intel-hda.c:548:5
      TrungNguyen1909#37 0x62ae5942 in intel_hda_reg_write hw/audio/intel-hda.c:977:9
      TrungNguyen1909#38 0x62ada10a in intel_hda_mmio_write hw/audio/intel-hda.c:1054:5
      TrungNguyen1909#39 0x63d8f383 in memory_region_write_accessor softmmu/memory.c:492:5
      TrungNguyen1909#40 0x63d8ecc1 in access_with_adjusted_size softmmu/memory.c:554:18
      TrungNguyen1909#41 0x63d8d5d6 in memory_region_dispatch_write softmmu/memory.c:1504:16
      TrungNguyen1909#42 0x63d5e85e in flatview_write_continue softmmu/physmem.c:2812:23
      TrungNguyen1909#43 0x63d4d05b in flatview_write softmmu/physmem.c:2854:12
      TrungNguyen1909#44 0x63d4cb18 in address_space_write softmmu/physmem.c:2950:18
      TrungNguyen1909#45 0x63d4d387 in address_space_rw softmmu/physmem.c:2960:16
      TrungNguyen1909#46 0x62ae12f2 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      TrungNguyen1909#47 0x62ae104a in dma_memory_rw include/sysemu/dma.h:132:12
      TrungNguyen1909#48 0x62ae6157 in dma_memory_write include/sysemu/dma.h:173:12
      ...
  SUMMARY: AddressSanitizer: stack-overflow softmmu/physmem.c:356 in address_space_translate_internal
  ==1580408==ABORTING
  Broken pipe
  Aborted (core dumped)

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211218160912.1591633-4-philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
shannon2893 pushed a commit to shannon2893/qemu-t8030 that referenced this pull request Jul 25, 2022
The issue reported by OSS-Fuzz produces the following backtrace:

  ==447470==ERROR: AddressSanitizer: heap-buffer-overflow
  READ of size 1 at 0x61500002a080 thread T0
      #0 0x71766d47 in sdhci_read_dataport hw/sd/sdhci.c:474:18
      TrungNguyen1909#1 0x7175f139 in sdhci_read hw/sd/sdhci.c:1022:19
      TrungNguyen1909#2 0x721b937b in memory_region_read_accessor softmmu/memory.c:440:11
      TrungNguyen1909#3 0x72171e51 in access_with_adjusted_size softmmu/memory.c:554:18
      TrungNguyen1909#4 0x7216f47c in memory_region_dispatch_read1 softmmu/memory.c:1424:16
      TrungNguyen1909#5 0x7216ebb9 in memory_region_dispatch_read softmmu/memory.c:1452:9
      TrungNguyen1909#6 0x7212db5d in flatview_read_continue softmmu/physmem.c:2879:23
      TrungNguyen1909#7 0x7212f958 in flatview_read softmmu/physmem.c:2921:12
      TrungNguyen1909#8 0x7212f418 in address_space_read_full softmmu/physmem.c:2934:18
      TrungNguyen1909#9 0x721305a9 in address_space_rw softmmu/physmem.c:2962:16
      TrungNguyen1909#10 0x7175a392 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      TrungNguyen1909#11 0x7175a0ea in dma_memory_rw include/sysemu/dma.h:132:12
      TrungNguyen1909#12 0x71759684 in dma_memory_read include/sysemu/dma.h:152:12
      TrungNguyen1909#13 0x7175518c in sdhci_do_adma hw/sd/sdhci.c:823:27
      TrungNguyen1909#14 0x7174bf69 in sdhci_data_transfer hw/sd/sdhci.c:935:13
      TrungNguyen1909#15 0x7176aaa7 in sdhci_send_command hw/sd/sdhci.c:376:9
      TrungNguyen1909#16 0x717629ee in sdhci_write hw/sd/sdhci.c:1212:9
      TrungNguyen1909#17 0x72172513 in memory_region_write_accessor softmmu/memory.c:492:5
      TrungNguyen1909#18 0x72171e51 in access_with_adjusted_size softmmu/memory.c:554:18
      TrungNguyen1909#19 0x72170766 in memory_region_dispatch_write softmmu/memory.c:1504:16
      TrungNguyen1909#20 0x721419ee in flatview_write_continue softmmu/physmem.c:2812:23
      TrungNguyen1909#21 0x721301eb in flatview_write softmmu/physmem.c:2854:12
      TrungNguyen1909#22 0x7212fca8 in address_space_write softmmu/physmem.c:2950:18
      TrungNguyen1909#23 0x721d9a53 in qtest_process_command softmmu/qtest.c:727:9

A DMA descriptor is previously filled in RAM. An I/O access to the
device (frames TrungNguyen1909#22 to TrungNguyen1909#16) start the DMA engine (frame TrungNguyen1909#13). The
engine fetch the descriptor and execute the request, which itself
accesses the SDHCI I/O registers (frame TrungNguyen1909#1 and #0), triggering a
re-entrancy issue.

Fix by prohibit transactions from the DMA to devices. The DMA engine
is thus restricted to memories.

Reported-by: OSS-Fuzz (Issue 36391)
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/451
Message-Id: <20211215205656.488940-3-philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
shannon2893 pushed a commit to shannon2893/qemu-t8030 that referenced this pull request Jul 25, 2022
Include the qtest reproducer provided by Alexander Bulekov
in https://gitlab.com/qemu-project/qemu/-/issues/451. Without
the previous commit, we get:

  $ make check-qtest-i386
  ...
  Running test qtest-i386/fuzz-sdcard-test
  ==447470==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61500002a080 at pc 0x564c71766d48 bp 0x7ffc126c62b0 sp 0x7ffc126c62a8
  READ of size 1 at 0x61500002a080 thread T0
      #0 0x564c71766d47 in sdhci_read_dataport hw/sd/sdhci.c:474:18
      TrungNguyen1909#1 0x564c7175f139 in sdhci_read hw/sd/sdhci.c:1022:19
      TrungNguyen1909#2 0x564c721b937b in memory_region_read_accessor softmmu/memory.c:440:11
      TrungNguyen1909#3 0x564c72171e51 in access_with_adjusted_size softmmu/memory.c:554:18
      TrungNguyen1909#4 0x564c7216f47c in memory_region_dispatch_read1 softmmu/memory.c:1424:16
      TrungNguyen1909#5 0x564c7216ebb9 in memory_region_dispatch_read softmmu/memory.c:1452:9
      TrungNguyen1909#6 0x564c7212db5d in flatview_read_continue softmmu/physmem.c:2879:23
      TrungNguyen1909#7 0x564c7212f958 in flatview_read softmmu/physmem.c:2921:12
      TrungNguyen1909#8 0x564c7212f418 in address_space_read_full softmmu/physmem.c:2934:18
      TrungNguyen1909#9 0x564c721305a9 in address_space_rw softmmu/physmem.c:2962:16
      TrungNguyen1909#10 0x564c7175a392 in dma_memory_rw_relaxed include/sysemu/dma.h:89:12
      TrungNguyen1909#11 0x564c7175a0ea in dma_memory_rw include/sysemu/dma.h:132:12
      TrungNguyen1909#12 0x564c71759684 in dma_memory_read include/sysemu/dma.h:152:12
      TrungNguyen1909#13 0x564c7175518c in sdhci_do_adma hw/sd/sdhci.c:823:27
      TrungNguyen1909#14 0x564c7174bf69 in sdhci_data_transfer hw/sd/sdhci.c:935:13
      TrungNguyen1909#15 0x564c7176aaa7 in sdhci_send_command hw/sd/sdhci.c:376:9
      TrungNguyen1909#16 0x564c717629ee in sdhci_write hw/sd/sdhci.c:1212:9
      TrungNguyen1909#17 0x564c72172513 in memory_region_write_accessor softmmu/memory.c:492:5
      TrungNguyen1909#18 0x564c72171e51 in access_with_adjusted_size softmmu/memory.c:554:18
      TrungNguyen1909#19 0x564c72170766 in memory_region_dispatch_write softmmu/memory.c:1504:16
      TrungNguyen1909#20 0x564c721419ee in flatview_write_continue softmmu/physmem.c:2812:23
      TrungNguyen1909#21 0x564c721301eb in flatview_write softmmu/physmem.c:2854:12
      TrungNguyen1909#22 0x564c7212fca8 in address_space_write softmmu/physmem.c:2950:18
      TrungNguyen1909#23 0x564c721d9a53 in qtest_process_command softmmu/qtest.c:727:9

  0x61500002a080 is located 0 bytes to the right of 512-byte region [0x615000029e80,0x61500002a080)
  allocated by thread T0 here:
      #0 0x564c708e1737 in __interceptor_calloc (qemu-system-i386+0x1e6a737)
      TrungNguyen1909#1 0x7ff05567b5e0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x5a5e0)
      TrungNguyen1909#2 0x564c71774adb in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5

  SUMMARY: AddressSanitizer: heap-buffer-overflow hw/sd/sdhci.c:474:18 in sdhci_read_dataport
  Shadow bytes around the buggy address:
    0x0c2a7fffd3c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c2a7fffd3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c2a7fffd3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c2a7fffd3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c2a7fffd400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  =>0x0c2a7fffd410:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c2a7fffd420: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c2a7fffd430: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c2a7fffd440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c2a7fffd450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c2a7fffd460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  Shadow byte legend (one shadow byte represents 8 application bytes):
    Addressable:           00
    Heap left redzone:       fa
    Freed heap region:       fd
  ==447470==ABORTING
  Broken pipe
  ERROR qtest-i386/fuzz-sdcard-test - too few tests run (expected 3, got 2)

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20211215205656.488940-4-philmd@redhat.com>
[thuth: Replaced "-m 4G" with "-m 512M"]
Signed-off-by: Thomas Huth <thuth@redhat.com>
shannon2893 pushed a commit to shannon2893/qemu-t8030 that referenced this pull request Jul 25, 2022
Since commit 0439c5a ("block/block-backend.c: assertions for
block-backend") QEMU crashes when using Cocoa on Darwin hosts.

Example on macOS:

  $ qemu-system-i386
  Assertion failed: (qemu_in_main_thread()), function blk_all_next, file block-backend.c, line 552.
  Abort trap: 6

Looking with lldb:

  Assertion failed: (qemu_in_main_thread()), function blk_all_next, file block-backend.c, line 552.
  Process 76914 stopped
  * thread TrungNguyen1909#1, queue = 'com.apple.main-thread', stop reason = hit program assert
     frame TrungNguyen1909#4: 0x000000010057c2d4 qemu-system-i386`blk_all_next.cold.1
  at block-backend.c:552:5 [opt]
      549    */
      550   BlockBackend *blk_all_next(BlockBackend *blk)
      551   {
  --> 552       GLOBAL_STATE_CODE();
      553       return blk ? QTAILQ_NEXT(blk, link)
      554                  : QTAILQ_FIRST(&block_backends);
      555   }
  Target 1: (qemu-system-i386) stopped.

  (lldb) bt
  * thread TrungNguyen1909#1, queue = 'com.apple.main-thread', stop reason = hit program assert
     frame #0: 0x00000001908c99b8 libsystem_kernel.dylib`__pthread_kill + 8
     frame TrungNguyen1909#1: 0x00000001908fceb0 libsystem_pthread.dylib`pthread_kill + 288
     frame TrungNguyen1909#2: 0x000000019083a314 libsystem_c.dylib`abort + 164
     frame TrungNguyen1909#3: 0x000000019083972c libsystem_c.dylib`__assert_rtn + 300
   * frame TrungNguyen1909#4: 0x000000010057c2d4 qemu-system-i386`blk_all_next.cold.1 at block-backend.c:552:5 [opt]
     frame TrungNguyen1909#5: 0x00000001003c00b4 qemu-system-i386`blk_all_next(blk=<unavailable>) at block-backend.c:552:5 [opt]
     frame TrungNguyen1909#6: 0x00000001003d8f04 qemu-system-i386`qmp_query_block(errp=0x0000000000000000) at qapi.c:591:16 [opt]
     frame TrungNguyen1909#7: 0x000000010003ab0c qemu-system-i386`main [inlined] addRemovableDevicesMenuItems at cocoa.m:1756:21 [opt]
     frame TrungNguyen1909#8: 0x000000010003ab04 qemu-system-i386`main(argc=<unavailable>, argv=<unavailable>) at cocoa.m:1980:5 [opt]
     frame TrungNguyen1909#9: 0x00000001012690f4 dyld`start + 520

As we are in passed release 7.0 hard freeze, disable the block
backend assertion which, while being valuable during development,
is not helpful to users. We'll restore this assertion immediately
once 7.0 is released and work on a fix.

Suggested-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20220325183707.85733-1-philippe.mathieu.daude@gmail.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants