
Accelerating iOS on QEMU with hardware virtualization (KVM) - mdelias
https://alephsecurity.com/2020/07/19/xnu-qemu-kvm/
======
londons_explore
> The ARM servers we were working on, however, ignored a higher different
> number of LSBs. Therefore, when dc zva was called inside bzero, more bytes
> than expected were set to 0

Let that sink in... ARM has an instruction which zeros out an implementation
defined amount of memory...

How can ARM ever hope to become the new-x86 with things like that? It's pretty
rare a programmer wants a randomly sized bit of memory zeroed...

~~~
dmitrygr
Nope, the writers are just wrong. It is not a random value, and it is not
arbitrary

"DC ZVA" always zeroes exactly one data cache line. That is the size. And you
can easily get that size from an appropriate userspace-readable register. See
for yourself: [https://developer.arm.com/docs/ddi0595/h/aarch64-system-
inst...](https://developer.arm.com/docs/ddi0595/h/aarch64-system-
instructions/dc-zva) and
[https://developer.arm.com/docs/ddi0595/h/aarch64-system-
regi...](https://developer.arm.com/docs/ddi0595/h/aarch64-system-
registers/dczid_el0)

You are not expected to use it anyways. Your libc is, in its implementation of
memset(), and it will properly query and use it.

Not only that, but since ARMv8.6 this instr, _AND_ the reg you can read to get
its size are both trappable by hypervisors (using HFGITR_EL2 and HFGRTR_EL2
fine-grained-trap regs respectively). See
[https://developer.arm.com/docs/ddi0595/h/aarch64-system-
regi...](https://developer.arm.com/docs/ddi0595/h/aarch64-system-
registers/hfgitr_el2) and
[https://developer.arm.com/docs/ddi0595/h/aarch64-system-
regi...](https://developer.arm.com/docs/ddi0595/h/aarch64-system-
registers/hfgrtr_el2)

------
vaxman
Wow, they succeeded in getting iOS to boot on a cloud ARM processor inside
QEMU. They can use that enviro to develop custom layers to eventually run on
modded hardware to do realtime analysis at full execution speed.

------
coolspot
Great writeup!

