-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unicorn 2 - looking for sponsors #1217
Comments
are you going to keep in sync with upsream after rewrite? |
That is not easy to keep syncing with the upstream. This means we must
trade off with some sacrifices in features.
Keep posting here if you have any ideas.
|
Support for the next version! |
Related #1190 @@
expression lock, flags;
expression urb;
@@
spin_lock_irqsave(lock, flags);
<...
- usb_submit_urb(urb)
+ usb_submit_urb(urb, GFP_ATOMIC)
...>
spin_unlock_irqrestore(lock, flags);
@@
expression urb;
@@
- usb_submit_urb(urb)
+ usb_submit_urb(urb, GFP_KERNEL) |
@ XVilka Due to how Unicorn is created (ripping out the heart of QEMU and fixing it up to make it nicely embeddable), it unfortunately seems that any new branch of Unicorn is doomed to ultimately fall out of sync with QEMU upstream again. |
Is there any update on Unicorn 2? |
My two cents: I did a bit of "Unicorn 2" prototyping with Qemu 4.2. The two biggests "lifts" I encountered, in terms of source code modifications, were compartmentalizing qemu globals (e.g. when multiple emu instances are used), and dealing with the memory implementation. Like others, I'm cautiously optimistic there is a way to minimize Qemu source code mods to make it easier to keep up with development there, and greatly lessen the burden for updates. A quick hack to get around the issue of qemu globals without source code mods is to load unique instances of the shared library for each "emu" instance. Of course the trade-off is increased memory consumption (however big the qemu lib is, for each instance). I've used Unicorn quite a bit, and in all my use cases (personally) this would be an acceptable trade-off. Regarding memory, there are two options: There are massive downsides to using the host mmu though: emulated code can no longer be securely sandboxed (not that I can tell, at least), and it restricts where regions can be mapped in the emulation (compatibility). Hence, ultimately we'd want the ability to use So I'll put this out there for discussion. The way forward might be to start with pull requests on Qemu towards the goal of adding a "softmmu vs. hostmmu" option for the linux-user build of qemu. I vaguely recall that someone was attempting this years ago and Qemu devs seemed receptive, but it didn't materialize. If we had this option in Qemu, I'd wager that Unicorn-like functionality would be much easier to build out. |
I'm not a typical contributor and not too involved in this project but if QEMU is really that active, why not ask them to publish all the apis and such that you need so we can basically use an unmodified qemu and just plug into it like a dependency? That probably sounds stupid to those who have been working on a unicorn but, what kind of modifications are being made? |
Modifications include (not all of them!):
Qemu code is clean indeed, but not all these modifications can be easily done without some really dirty hack. |
We are redesigning the logo of Unicorn for Unicorn2, with the target of having a more modern logo, that can be used better on Tshirt, mug, etc. If anybody wants to sponsor the new logo design (so your support will be there forever in the project history ;-), please contact. |
towards Unicorn2, we redesigned the logo - for this major version. https://twitter.com/unicorn_engine/status/1400014142098997249 more news is coming soon. |
Refactoring is a very good choice, now unicorn feels devastated. |
Will this allow direct loading and emulation of binary files without modification or wrappers? For an example, a rip from an EPROM that is only machine code without a bootloader or kernel image. |
You would like to have a look at https://github.com/qilingframework/qiling |
super excited to released Unicorn2 to the public. check it out at https://www.unicorn-engine.org/Unicorn2-beta |
Thanks a ton @aquynh for this wonderful release! One question though, does Unicorn 2 incorporate the multi-threaded TCG? I'm so excited for this release as Unicorn is ideal for projects like emulators and adding multi-threading will make it even more powerful. |
No. Unicorn internally is single-threaded. |
Is it possible then to add multi-threading support to the Unicorn APIs? I mean in the features list it states that Unicorn is thread safe by design. And now that QEMU is updated as well it should be easier to do that? But anyways I don't think multi-threading is super important, just something that's nice to have. |
From the top of the view, we are leaving this part for users. We would consider adding the support if it's really the case for example by some benchmark. |
Hello! I created the binding for Nim using nimterod generator at https://github.com/dmknght/unimcorn. But the testing code (converted to Nim from example on unicorn's homepage) in readme gave me error |
Since its born in 2015, Unicorn has been inspiring so many cool research & tools, that we believe it deserves serious upgrade. Based on Qemu 2.1.2, there is a lot to catch up with the latest version of Qemu (Qemu is at v4.2 at the moment). Unfortunately, the code base of Qemu changes so much since 2015, that we believe it is faster to rewrite Unicorn from scratch.
For this reason, next major update of Unicorn (lets call it Unicorn 2) requires huge effort & lots of time. So we call for the support from Unicorn users!
If you are using Unicorn for your work, and wish to sponsor the development of Unicorn 2, please contact us: http://www.unicorn-engine.org/contact/
The text was updated successfully, but these errors were encountered: