What would McSema mean for ReactOS?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
ameerjaiswal
Posts: 1
Joined: Tue Aug 14, 2018 3:59 pm

What would McSema mean for ReactOS?

Post by ameerjaiswal »

https://blog.trailofbits.com/2018/01/23 ... csema-2-0/

It converts binaries to LLVM Byte Code and from there, you can re-compile it to another architecture. So could you fix the XP 64-bit driver problem of there not being drivers and the few drivers that exist for it being horrible (thus making ROS 64-bit worthwhile) and add more supported devices for Server2k3/ROS Itanium? Like recompile the XP Driver for the Titan Black (Fastest Card with XP Drivers) for the Itanic and Crysis and the Itanic could run Crysis? Or would this mostly be helpful for people running Wine on Arm and PowerPC and want to get their Unreal Gold Fix on those platforms? (Maybe run legacy Apps on Jailbroke Windows RT?) Would it make ROS PowerPC viable?

I'm also curious of what McSema's optimizations would do with efficiency. There's 32 and 64-bit Crysis binaries and I'm curious of how the 32-bit binary converted to 64-bit compares to the native 64-bit binary.
cb88
Posts: 73
Joined: Fri Oct 06, 2017 3:26 pm

Re: What would McSema mean for ReactOS?

Post by cb88 »

It probably wouldn't work for drivers. What it would let you do is run x86 applications on ARM ReactOS etc...

It's mainly for userland applications, drivers tend to require intimate information about the hardware that isn't easy for translators like this to translate. Drivers should generally always be written natively otherwise it's going to be slow and glitchy if it runs at all.
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: What would McSema mean for ReactOS?

Post by PurpleGurl »

I don't know, I find the Termite project a tad more interesting, and they claimed to have created drivers that work better than the originals, with better CPU utilization. Of course, compared to McSema, that was designed for drivers. However, I have my doubts about automating drivers. In the past, a dev here said they'd never use machine-produced code, and I guess mainly, licensing issues aside, it will be unreadable as heck and hard to troubleshoot.
PeterGoodman
Posts: 1
Joined: Wed Aug 15, 2018 5:18 pm

Re: What would McSema mean for ReactOS?

Post by PeterGoodman »

Hello, McSema team member here. McSema *may* in one form or another be applicable, but some important caveats apply. Most likely, to achieve your goals, you would need to modify McSema in some interesting ways. If anyone here is actually up to the task, then Trail of Bits may be interested in funding this as a short project.

I will try to address the issues in turn.
It's mainly for userland applications, drivers tend to require intimate information about the hardware that isn't easy for translators like this to translate. Drivers should generally always be written natively otherwise it's going to be slow and glitchy if it runs at all.
This is mostly true; McSema is primarily for userland code, and modelling system instructions is challenging. McSema uses the https://github.com/trailofbits/remill library for instruction semantics, and it provides an escape hatch (called hyper calls) for handling things like system instructions whose effects are beyond the scope of what can be represented in LLVM IR.
It converts binaries to LLVM Byte Code and from there, you can re-compile it to another architecture.
In general, you want the source architecture address size to match the destination architecture address size. So, we could go back and forth between amd64 and aarch64, for example, but in general, bitcode produced from x86 machine code will likely not work if compiled for 64-bit, due to the things like 64-bit memory addresses being truncated.

McSema generally tries to lift both code and data, and maintain all interrelationships there-between. An interesting project would be one where we only lift all code, and then create a kind of fake 32-bit address space in memory (4 GiB allocated chunk of memory) on which the code operates. This would be a path toward achieving 32-to-64 bit.
I don't know, I find the Termite project a tad more interesting, and they claimed to have created drivers that work better than the originals, with better CPU utilization. Of course, compared to McSema, that was designed for drivers.
Can you provide a link to the Termite project and their results?
Zombiedeth
Posts: 119
Joined: Fri Jun 27, 2014 9:01 am

Re: What would McSema mean for ReactOS?

Post by Zombiedeth »

PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: What would McSema mean for ReactOS?

Post by PurpleGurl »

Zombiedeth wrote: Thu Aug 16, 2018 11:21 pm I think this is it.

https://ts.data61.csiro.au/projects/TS/ ... synthesis/
Yes, thanks. That link also includes a link to their Github repository. However, ROS devs have stated that they would not use dynamic code generation, for the reasons I stated before.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 46 guests