unicorn
unicorn copied to clipboard
unicorn-engine
Test failures on M1 Mac
Hi,
I am trying to use Unicorn on an M1 (arm64) Mac running macOS Monterey 12.5 and am running into some test failures. Unfortunately I'm not yet very familiar with the internals of the project so I can't speculate on why this might be.
No special steps to reproduce afaik. Checked out and built master branch without any special flags other than setting Debug build type (but other build types fail in the same way).
I tried checking the Github Actions to see how this compared to the CI builds but it seems there are only x64 MacOS builds in the CI.
Steps I took and some basic debug info shown below. Let me know if there's any more information you'd like.
Thanks for providing this useful project.
Note: Build/configure output not shown for brevity, but I can provide it if it's relevant.
relapids@Relapids-Mini unicorn % git clone https://github.com/unicorn-engine/unicorn repo
relapids@Relapids-Mini unicorn % mkdir build && cd build
relapids@Relapids-Mini build % cmake -S ../repo -B . -G Ninja -D CMAKE_BUILD_TYPE=Debug && cmake --build .
relapids@Relapids-Mini build % cmake --build . --target test
[0/1] Running tests...
Test project /Users/relapids/dev/unicorn/build
Start 1: test_x86
1/12 Test #1: test_x86 .........................***Failed 1.18 sec
Start 2: test_arm
2/12 Test #2: test_arm ......................... Passed 0.29 sec
Start 3: test_arm64
3/12 Test #3: test_arm64 ....................... Passed 0.14 sec
Start 4: test_m68k
4/12 Test #4: test_m68k ........................ Passed 0.13 sec
Start 5: test_mips
5/12 Test #5: test_mips ........................ Passed 0.13 sec
Start 6: test_sparc
6/12 Test #6: test_sparc ....................... Passed 0.11 sec
Start 7: test_ppc
7/12 Test #7: test_ppc ......................... Passed 0.12 sec
Start 8: test_riscv
8/12 Test #8: test_riscv ....................... Passed 0.14 sec
Start 9: test_s390x
9/12 Test #9: test_s390x ....................... Passed 0.14 sec
Start 10: test_tricore
10/12 Test #10: test_tricore ..................... Passed 0.11 sec
Start 11: test_mem
11/12 Test #11: test_mem .........................***Failed 0.14 sec
Start 12: test_ctl
12/12 Test #12: test_ctl .........................***Failed 0.14 sec
75% tests passed, 3 tests failed out of 12
Total Test time (real) = 2.78 sec
The following tests FAILED:
1 - test_x86 (Failed)
11 - test_mem (Failed)
12 - test_ctl (Failed)
Errors while running CTest
Output from these tests are in: /Users/relapids/dev/unicorn/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
FAILED: CMakeFiles/test.util
cd /Users/relapids/dev/unicorn/build && /opt/homebrew/Cellar/cmake/3.23.3/bin/ctest --force-new-ctest-process
ninja: build stopped: subcommand failed.
relapids@Relapids-Mini build % ./test_x86
Test test_x86_in... [ OK ]
Test test_x86_out... [ OK ]
Test test_x86_mem_hook_all... [ OK ]
Test test_x86_inc_dec_pxor... [ OK ]
Test test_x86_relative_jump... [ OK ]
Test test_x86_loop... [ OK ]
Test test_x86_invalid_mem_read... [ OK ]
Test test_x86_invalid_mem_write... [ OK ]
Test test_x86_invalid_jump... [ OK ]
Test test_x86_64_syscall... [ OK ]
Test test_x86_16_add... [ OK ]
Test test_x86_reg_save... [ OK ]
Test test_x86_invalid_mem_read_stop_in_cb... [ OK ]
Test test_x86_x87_fnstenv... [ OK ]
Test test_x86_mmio... [ OK ]
Test test_x86_missing_code... [ OK ]
Test test_x86_smc_xor... [ OK ]
Test test_x86_mmio_uc_mem_rw... [ OK ]
Test test_x86_sysenter... [ OK ]
Test test_x86_hook_cpuid... [ OK ]
Test test_x86_486_cpuid... [ OK ]
Test test_x86_clear_tb_cache... [ OK ]
Test test_x86_clear_empty_tb... [ OK ]
Test test_x86_hook_tcg_op... [ OK ]
Test test_x86_cmpxchg... [ OK ]
Test test_x86_nested_emu_start... Test interrupted by signal 10.
Test test_x86_nested_emu_stop... Test interrupted by signal 10.
Test test_x86_64_nested_emu_start_error... Test interrupted by signal 10.
Test test_x86_eflags_reserved_bit... [ OK ]
Test test_x86_nested_uc_emu_start_exits... Test interrupted by signal 10.
Test test_x86_clear_count_cache... [ OK ]
Test test_x86_correct_address_in_small_jump_hook... [ OK ]
Test test_x86_correct_address_in_long_jump_hook... [ OK ]
FAILED: 4 of 33 unit tests have failed.
relapids@Relapids-Mini build % ./test_mem
Test test_map_correct... [ OK ]
Test test_map_wrapping... [ OK ]
Test test_mem_protect... [ OK ]
Test test_splitting_mem_unmap... [ OK ]
Test test_splitting_mmio_unmap... [ OK ]
Test test_mem_protect_map_ptr... [ FAILED ]
test_mem.c:142: Check val == mem... failed
Test test_map_at_the_end... [ OK ]
Test test_map_wrap... [ OK ]
Test test_map_big_memory... Assertion failed: (size != 0), function find_ram_offset, file exec.c, line 967.
Test interrupted by SIGABRT.
Test test_mem_protect_remove_exec... [ OK ]
Test test_mem_protect_mmio... [ OK ]
FAILED: 2 of 11 unit tests have failed.
relapids@Relapids-Mini build % ./test_ctl
Test test_uc_ctl_mode... [ OK ]
Test test_uc_ctl_page_size... [ OK ]
Test test_uc_ctl_arch... [ OK ]
Test test_uc_ctl_time_out... [ OK ]
Test test_uc_ctl_exits... [ OK ]
Test test_uc_ctl_tb_cache... [ OK ]
Test test_uc_ctl_change_page_size... [ OK ]
Test test_uc_ctl_arm_cpu... [ OK ]
Test test_uc_hook_cached_uaf... Test interrupted by SIGSEGV.
FAILED: 1 of 9 unit tests has failed.
relapids@Relapids-Mini build % lldb -- ./test_x86
(lldb) target create "./test_x86"
Current executable set to '/Users/relapids/dev/unicorn/build/test_x86' (arm64).
(lldb) r
Process 63056 launched: '/Users/relapids/dev/unicorn/build/test_x86' (arm64)
Test test_x86_in... [ OK ]
Test test_x86_out... [ OK ]
Test test_x86_mem_hook_all... [ OK ]
Test test_x86_inc_dec_pxor... [ OK ]
Test test_x86_relative_jump... [ OK ]
Test test_x86_loop... [ OK ]
Test test_x86_invalid_mem_read... [ OK ]
Test test_x86_invalid_mem_write... [ OK ]
Test test_x86_invalid_jump... [ OK ]
Test test_x86_64_syscall... [ OK ]
Test test_x86_16_add... [ OK ]
Test test_x86_reg_save... [ OK ]
Test test_x86_invalid_mem_read_stop_in_cb... [ OK ]
Test test_x86_x87_fnstenv... [ OK ]
Test test_x86_mmio... [ OK ]
Test test_x86_missing_code... [ OK ]
Test test_x86_smc_xor... [ OK ]
Test test_x86_mmio_uc_mem_rw... [ OK ]
Test test_x86_sysenter... [ OK ]
Test test_x86_hook_cpuid... [ OK ]
Test test_x86_486_cpuid... [ OK ]
Test test_x86_clear_tb_cache... [ OK ]
Test test_x86_clear_empty_tb... [ OK ]
Test test_x86_hook_tcg_op... [ OK ]
Test test_x86_cmpxchg... [ OK ]
Test test_x86_nested_emu_start... Process 63056 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x2800001b0)
frame #0: 0x00000002800001b0
-> 0x2800001b0: ldur w20, [x19, #-0x10]
0x2800001b4: cmp w20, #0x0 ; =0x0
0x2800001b8: b.lt 0x28000020c
0x2800001bc: ldr x20, [x19, #0x8]
Target 0: (test_x86) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x2800001b0)
* frame #0: 0x00000002800001b0
frame #1: 0x0000000101cbc528 libunicorn.2.dylib`cpu_tb_exec(cpu=0x0000000108088000, itb=0x0000000280000080) at cpu-exec.c:60:11
frame #2: 0x0000000101cbbbc0 libunicorn.2.dylib`cpu_loop_exec_tb(cpu=0x0000000108088000, tb=0x0000000280000080, last_tb=0x000000016fdff420, tb_exit=0x000000016fdff41c) at cpu-exec.c:499:11
frame #3: 0x0000000101cbb410 libunicorn.2.dylib`cpu_exec_x86_64(uc=0x0000000103808200, cpu=0x0000000108088000) at cpu-exec.c:598:13
frame #4: 0x0000000101c67f00 libunicorn.2.dylib`tcg_cpu_exec(uc=0x0000000103808200) at cpus.c:96:17
frame #5: 0x0000000101c67e48 libunicorn.2.dylib`resume_all_vcpus_x86_64(uc=0x0000000103808200) at cpus.c:215:13
frame #6: 0x0000000101c680a0 libunicorn.2.dylib`vm_start_x86_64(uc=0x0000000103808200) at cpus.c:234:5
frame #7: 0x0000000101c50a98 libunicorn.2.dylib`uc_emu_start(uc=0x0000000103808200, begin=4096, until=4097, timeout=0, count=0) at uc.c:870:5
frame #8: 0x000000010000b10c test_x86`test_x86_nested_emu_start at test_x86.c:896:5
frame #9: 0x000000010000d100 test_x86`acutest_do_run_(test=0x00000001000104d8, index=25) at acutest.h:1026:9
frame #10: 0x0000000100005798 test_x86`acutest_run_(test=0x00000001000104d8, index=25, master_index=25) at acutest.h:1233:19
frame #11: 0x00000001000044e4 test_x86`main(argc=1, argv=0x000000016fdff8a0) at acutest.h:1831:13
frame #12: 0x000000010002508c dyld`start + 520
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] Y
relapids@Relapids-Mini build % lldb -- ./test_mem
(lldb) target create "./test_mem"
Current executable set to '/Users/relapids/dev/unicorn/build/test_mem' (arm64).
(lldb) r
Process 63061 launched: '/Users/relapids/dev/unicorn/build/test_mem' (arm64)
Test test_map_correct... [ OK ]
Test test_map_wrapping... [ OK ]
Test test_mem_protect... [ OK ]
Test test_splitting_mem_unmap... [ OK ]
Test test_splitting_mmio_unmap... [ OK ]
Test test_mem_protect_map_ptr... [ FAILED ]
test_mem.c:142: Check val == mem... failed
Test test_map_at_the_end... [ OK ]
Test test_map_wrap... [ OK ]
Test test_map_big_memory... Assertion failed: (size != 0), function find_ram_offset, file exec.c, line 967.
Process 63061 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
frame #4: 0x0000000101c5b348 libunicorn.2.dylib`find_ram_offset(uc=0x0000000100809800, size=0) at exec.c:967:5
964 RAMBlock *block, *next_block;
965 ram_addr_t offset = RAM_ADDR_MAX, mingap = RAM_ADDR_MAX;
966
-> 967 assert(size != 0); /* it would hand out same offset multiple times */
968
969 if (QLIST_EMPTY_RCU(&uc->ram_list.blocks)) {
970 return 0;
Target 0: (test_mem) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = hit program assert
frame #0: 0x00000001b0312d98 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001b0347ee0 libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x00000001b0282340 libsystem_c.dylib`abort + 168
frame #3: 0x00000001b0281754 libsystem_c.dylib`__assert_rtn + 272
* frame #4: 0x0000000101c5b348 libunicorn.2.dylib`find_ram_offset(uc=0x0000000100809800, size=0) at exec.c:967:5
frame #5: 0x0000000101c55550 libunicorn.2.dylib`ram_block_add(uc=0x0000000100809800, new_block=0x0000600002100ff0) at exec.c:1040:25
frame #6: 0x0000000101c554f4 libunicorn.2.dylib`qemu_ram_alloc_from_ptr_x86_64(uc=0x0000000100809800, size=0, host=0x0000000000000000, mr=0x0000600003300140) at exec.c:1106:5
frame #7: 0x0000000101c55758 libunicorn.2.dylib`qemu_ram_alloc_x86_64(uc=0x0000000100809800, size=18446744073709547520, mr=0x0000600003300140) at exec.c:1118:12
frame #8: 0x0000000101c5c6f8 libunicorn.2.dylib`memory_region_init_ram_x86_64(uc=0x0000000100809800, mr=0x0000600003300140, size=18446744073709547520, perms=7) at memory.c:1346:21
frame #9: 0x0000000101c5c604 libunicorn.2.dylib`memory_map_x86_64(uc=0x0000000100809800, begin=0, size=18446744073709547520, perms=7) at memory.c:45:5
frame #10: 0x0000000101c45248 libunicorn.2.dylib`uc_mem_map(uc=0x0000000100809800, address=0, size=18446744073709547520, perms=7) at uc.c:1054:20
frame #11: 0x000000010000574c test_mem`test_map_big_memory at test_mem.c:184:5
frame #12: 0x0000000100006880 test_mem`acutest_do_run_(test=0x00000001000083a8, index=8) at acutest.h:1026:9
frame #13: 0x00000001000038fc test_mem`acutest_run_(test=0x00000001000083a8, index=8, master_index=8) at acutest.h:1233:19
frame #14: 0x0000000100002648 test_mem`main(argc=1, argv=0x000000016fdff8a0) at acutest.h:1831:13
frame #15: 0x000000010001908c dyld`start + 520
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] Y
relapids@Relapids-Mini build % lldb -- ./test_ctl
(lldb) target create "./test_ctl"
Current executable set to '/Users/relapids/dev/unicorn/build/test_ctl' (arm64).
(lldb) r
Process 63066 launched: '/Users/relapids/dev/unicorn/build/test_ctl' (arm64)
Test test_uc_ctl_mode... [ OK ]
Test test_uc_ctl_page_size... [ OK ]
Test test_uc_ctl_arch... [ OK ]
Test test_uc_ctl_time_out... [ OK ]
Test test_uc_ctl_exits... [ OK ]
Test test_uc_ctl_tb_cache... [ OK ]
Test test_uc_ctl_change_page_size... [ OK ]
Test test_uc_ctl_arm_cpu... [ OK ]
Test test_uc_hook_cached_uaf... Process 63066 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffff)
frame #0: 0x00000001b035f178 libsystem_platform.dylib`_platform_memmove + 168
libsystem_platform.dylib`_platform_memmove:
-> 0x1b035f178 <+168>: stp q2, q3, [x0]
0x1b035f17c <+172>: subs x2, x2, #0x40 ; =0x40
0x1b035f180 <+176>: b.ls 0x1b035f19c ; <+204>
0x1b035f184 <+180>: stp q0, q1, [x3]
Target 0: (test_ctl) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffff)
* frame #0: 0x00000001b035f178 libsystem_platform.dylib`_platform_memmove + 168
frame #1: 0x0000000100005de4 test_ctl`test_uc_hook_cached_uaf at test_ctl.c:255:5
frame #2: 0x0000000100006960 test_ctl`acutest_do_run_(test=0x00000001000083b8, index=8) at acutest.h:1026:9
frame #3: 0x000000010000442c test_ctl`acutest_run_(test=0x00000001000083b8, index=8, master_index=8) at acutest.h:1233:19
frame #4: 0x0000000100003178 test_ctl`main(argc=1, argv=0x000000016fdff8a0) at acutest.h:1831:13
frame #5: 0x000000010001908c dyld`start + 520
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] Y
relapids@Relapids-Mini build % uname -a
Darwin Relapids-Mini 21.6.0 Darwin Kernel Version 21.6.0: Sat Jun 18 17:05:47 PDT 2022; root:xnu-8020.140.41~1/RELEASE_ARM64_T8101 arm64
relapids@Relapids-Mini build % cc --version
Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: arm64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Unfortunately, I don't have an M1 to test and Github doesn't provide an M1 runner so far.
@wtdcode Understandable. If you have any suggestions for how I can collect better diagnostics or things I can do to debug it I'm open to try. Otherwise I will try to dig into this some more myself, although I've only just started using Unicorn so I can't guarantee how far I'll be able to get on my own. Will try to take some time to understand the internals of the project.
Began debugging these. Started with what looked like the easiest one. For the failure in test_map_big_memory it looks like the problem is that uc->qemu_host_page_size is 0x4000 on Mac M1 but the address passed in is hardcoded to assume a page size of 0x1000. So when it does the HOST_PAGE_ALIGN in qemu_ram_alloc_from_ptr_x86_64 it ends up returning 0.
relapids@Relapids-Mini build % pagesize
16384
(lldb) n
Process 92060 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000101c553e0 libunicorn.2.dylib`qemu_ram_alloc_from_ptr_x86_64(uc=0x0000000103808200, size=18446744073709547520, host=0x0000000000000000, mr=0x0000600003310000) at exec.c:1090:12
1087 RAMBlock *new_block;
1088 ram_addr_t max_size = size;
1089
-> 1090 size = HOST_PAGE_ALIGN(uc, size);
1091 max_size = HOST_PAGE_ALIGN(uc, max_size);
1092 new_block = g_malloc0(sizeof(*new_block));
1093 if (new_block == NULL)
Target 0: (test_mem) stopped.
(lldb) n
Process 92060 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000101c5540c libunicorn.2.dylib`qemu_ram_alloc_from_ptr_x86_64(uc=0x0000000103808200, size=0, host=0x0000000000000000, mr=0x0000600003310000) at exec.c:1091:16
1088 ram_addr_t max_size = size;
1089
1090 size = HOST_PAGE_ALIGN(uc, size);
-> 1091 max_size = HOST_PAGE_ALIGN(uc, max_size);
1092 new_block = g_malloc0(sizeof(*new_block));
1093 if (new_block == NULL)
1094 return NULL;
Target 0: (test_mem) stopped.
(lldb) p uc->qemu_host_page_size
(uint64_t) $2 = 16384
Have a fix for this one locally (it's just a test fix) and will continue on to the next one when I have some more spare time. Will try to send up all the patches in a single PR when I'm done unless you'd prefer individual PRs (or if I get stuck and can't fix them all).
Figured out another one. The test_uc_hook_cached_uaf failure is because Apple Silicon does not allow RWX pages so the mmap call was returning -1. Changing it to map as RW and then mprotect it back and forth between RX/RW as needed works around the issue. Not sure what you're supposed to do if you actually need RWX (e.g. for a JIT that uses self modifying code), but thankfully that's not the case here.
Test test_uc_hook_cached_uaf... Process 15308 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffff)
frame #0: 0x00000001b035f178 libsystem_platform.dylib`_platform_memmove + 168
libsystem_platform.dylib`_platform_memmove:
-> 0x1b035f178 <+168>: stp q2, q3, [x0]
0x1b035f17c <+172>: subs x2, x2, #0x40
0x1b035f180 <+176>: b.ls 0x1b035f19c ; <+204>
0x1b035f184 <+180>: stp q0, q1, [x3]
Target 0: (test_ctl) stopped.
(lldb)
On to the next one...
I think I've nearly figured out another one, but for this one I'm not 100% what the correct fix is so hopefully someone more experienced with the codebase can weigh in. For the failure in test_mem_protect_map_ptr, it appears to be caused by the call to uc_mem_protect. Basically what seems to be happening is that when split_region is called to split the block, it tries to find the correct RAM block to use with the following code:
// Find the correct and large enough (which contains our target mr)
// to create the content backup.
QLIST_FOREACH(block, &uc->ram_list.blocks, next)
{
// block->offset is the offset within ram_addr_t, not GPA
if (block->mr->addr <= mr->addr &&
block->used_length + block->mr->addr >= mr->end) {
break;
}
}
It's this part of the calculation specifically which is causing the issue:
block->used_length + block->mr->addr
Because M1 MacOS has 16KB pages (instead of the typical 4KB), when used_length is set in qemu_ram_alloc_from_ptr, we end up with used_length set to 16KB rather than 4KB, since the size is rounded up to the host page alignment. This means that the loop above ends up choosing the wrong RAM block (i.e. it picks the first block in the list instead of the second).
So, I changed it to this:
// Find the correct and large enough (which contains our target mr)
// to create the content backup.
QLIST_FOREACH(block, &uc->ram_list.blocks, next)
{
// block->offset is the offset within ram_addr_t, not GPA
if (block->mr->addr <= mr->addr &&
int128_get64(block->mr->size) + block->mr->addr >= mr->end) {
break;
}
}
i.e. I replaced block->used_length with block->mr->size.
This passed the tests, but it doesn't feel correct, because if this is valid then I don't understand why we couldn't simply forgo the loop and use mr->ram_block directly, since it already holds a pointer to it. So, clearly there's something I'm not understanding yet.
@wtdcode Is there any chance you'd be able to help with my understanding here? Either a deeper explanation of what's going with that code to help me figure out what I'm missing, or perhaps an example test case which would demonstrate a scenario in which the loop is required (since none of the unit tests ever trigger a case where block != mr->ram_block - I added an assert there to the original version of the code for block == mr->ram_block and that never fails when running the tests, both on my M1 Mac and my x64 Windows machine).
@relapids I can't remember exactly why used_length is used here. For your question, I think the correct way is to round up all memory regions to 16KB internally. I'm afraid I have to check a bit further on how QEMU handles such cases as I only backport the very initial fix for M1.
I find it odd that qemu_ram_alloc_from_ptr always rounds size and max_size up to the host page size, even for pre-allocated RAM. Will this not potentially overflow preallocated memory if the pre-allocated memory block is simply not that large?
@wtdcode The test_map_big_memory failure is resolved after yesterday's changes. Thanks @roehling, your fix is better than the one I hacked together locally to unblock myself.
Here's the list of failures as of today on the latest dev branch for MacOS M1:
The following tests FAILED:
1 - test_x86 (Failed)
12 - test_ctl (Failed)
I have a fix for the test_ctl failure which I have not submitted yet: https://github.com/unicorn-engine/unicorn/commit/51764923a14afca566497016483c5451af87af53
I don't yet have a fix for the test_x86 failures. I'm not sure what's going on there. It's seemingly something specific to nested uc_start calls but I haven't had the time to dig into it deep enough to understand it further yet (spent a bit on it then ended up getting pulled away for a bit due to personal reasons - hopefully will have time to dig into it more in the future if nobody else is able to in the meantime).
EDIT:
Submitted a PR for the test_ctl failure. That should mean only the nested uc_start ones remain after.
@wtdcode The test_map_big_memory failure is resolved after yesterday's changes. Thanks @roehling, your fix is better than the one I hacked together locally to unblock myself.
Here's the list of failures as of today on the latest dev branch for MacOS M1:
The following tests FAILED: 1 - test_x86 (Failed) 12 - test_ctl (Failed)I have a fix for the test_ctl failure which I have not submitted yet: 5176492
I don't yet have a fix for the test_x86 failures. I'm not sure what's going on there. It's seemingly something specific to nested uc_start calls but I haven't had the time to dig into it deep enough to understand it further yet (spent a bit on it then ended up getting pulled away for a bit due to personal reasons - hopefully will have time to dig into it more in the future if nobody else is able to in the meantime).
EDIT:
Submitted a PR for the test_ctl failure. That should mean only the nested uc_start ones remain after.
The nested uc_emu_start use is not that common and might be fine for now until I could grab an M1 for testing. I guess it's mostly due to the pages' W^X protection not being properly set since nested emulation in qemu is not the common use case and we have to be more careful on this.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Had a lot of stuff going on lately and not much time for side-projects. I hope to return to this in the near future though.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.