a1xndr

On most builds of QEMU, that command will start a VM with an e1000 card networked through SLIRP. It's the equivalent of something like:

  -netdev user,id=net0 -device e1000,netdev=net0

Doing this is a huge amount of engineering work. Things like the usb controller, modem, audio, touch sensor, and many many more are often custom hardware without any specs available that you somehow need to simulate. That's not even getting into the display tech. And these things change with each new hardware iteration. In the OP repo, there appear to be 25 of these things that the author had to reverse engineer an emulate. And that's for 15 year old hardware. Things like usb controllers require thousands of lines of dense C code. Then you have all of the CPU extensions leveraged by iPhones that generally have poor/nonexistent emulation support. This type of emulation/rehosting is a notoriously hard problem even for simpler devices like routers. Modern game emulators typically move up the stack and intercept high-level graphics etc APIs because emulating all of the hardware would be a ton of work (and doing so in performantly would be impossible). The simulator that comes with xcode works in a similar way. But by doing this, you lose a lot of the capabilities that you might want from an emulated device (kernel/driver debugging, etc).

There is a reason that Corellium can charge so much for SASS access to recent-model emulated iPhones.

> VM escapes are pretty difficult, especially with modern, patched microcode processors

Most VM escapes happen through buggy virtual-devices written in C/C++/.. code. Virtual-device bugs that are exploitable by attackers with root access in the VM are found frequently.

I wasn't involved in the work mentioned in the post, but I worked on integrating QEMU into oss-fuzz. Here's an example of a report from oss-fuzz, that we get by email: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29225 This lets us download the test-case and reproduce the bug, locally.

Internally, we convert this test-case into something that can be used with an unmodified build of qemu, for developers unfamiliar with oss-fuzz, and post it to our own issue tracker: https://gitlab.com/qemu-project/qemu/-/issues/450

The English ones are probably most easily found since design guidelines are usually written in the local language. https://design.gov.ru/design-system/#principles

on phones, ads are not limited to your web browser

.local is perfectly fine according to the IETF https://tools.ietf.org/html/rfc6762

I don't see how Spectre and meltdown were blown way out of proportion? Google and Amazon seem to have treated them quite seriously.. Maybe they should have just closed their eyes. The solution to Spectre right now is "Don't do speculative execution". Meltdown exploits a pretty embarrassing bug in the hardware. One has to wonder how it got through all of the testing/review that must happen before a new design is sent off to a fab($$$). Don't forget that there are 30+ class action lawsuits filed against Intel due solely to these bugs.