<div dir="ltr">Thank you for the reply. I made a slack request.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 1, 2021 at 10:36 AM Andrew Fasano <<a href="mailto:fasano@mit.edu">fasano@mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Kenneth,<div><br></div><div>These are some good questions. We're very interested in both improving PANDA's support for additional architectures and updating PANDA to be based on a newer version of QEMU.</div><div><br></div><div>For additional architectures that were supported in QEMU 2.9 (which PANDA is currently forked from), it's not too bad to get them running with PANDA's callbacks, but adding record and replay support is a fair amount of work. We recently added <a href="https://github.com/panda-re/panda/pull/845" target="_blank">partial AARCH64 support </a>where most callbacks and APIs now work but we skipped record and replay. As you can see from the diff, it wasn't too bad (most of the code changes are related to the OSI and syscalls2 plugins).</div><div><br></div><div>However, there are some architectures only supported in newer QEMU versions as well as a lot of improvements to QEMU since 2.9 was released, so we'd love to get PANDA rebased on top of that. We have a github issue <a href="https://github.com/panda-re/panda/issues/570" target="_blank">here</a> where we've been discussing how to do such an upgrade. The issue has mostly gone stale though since it's a pretty significant undertaking. We (MIT Lincoln Lab) have been exploring ways to dedicate some resources towards tackling the work, but we currently lack the funding for our ideal path forward. Hopefully that will change later this year.</div><div><br></div><div>If you want to discuss with a wider audience, feel free to <a href="https://panda.re/invite.php" target="_blank">request an invite to our slack channel</a> - that's much more active than this mailing list.</div><div><br></div><div>Best,</div><div>Andrew</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 30, 2021 at 12:43 PM Kenneth Adam Miller <<a href="mailto:kennethadammiller@gmail.com" target="_blank">kennethadammiller@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Much later version of *QEMU.<br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 17, 2021 at 11:39 AM Kenneth Adam Miller <<a href="mailto:kennethadammiller@gmail.com" target="_blank">kennethadammiller@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I have a series of questions that relate to trying to satisfy a use case: perform analysis using PANDA but on an architecture that isn't supported directly by PANDA. In this scenario, the architecture is supported by a much later version of PANDA. <br><br>Would there be any way that a later version of QEMU could export LLVM or the TCB for this version to import and use?<br><br>How difficult would it be to take the PANDA extensions to QEMU and apply them to a newer version of QEMU? I don't expect it would be easy, probably would correspond to a new version of PANDA, and I'm sure people are working hard behind the scenes.<br></div></div>
</blockquote></div>
_______________________________________________<br>
panda-users mailing list<br>
<a href="mailto:panda-users@mit.edu" target="_blank">panda-users@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/panda-users" rel="noreferrer" target="_blank">http://mailman.mit.edu/mailman/listinfo/panda-users</a><br>
</blockquote></div>
</blockquote></div>