Linked by Thom Holwerda on Tue 8th Jan 2013 23:27 UTC
Windows So, a rudimentary jailbreak for Windows RT made its way onto the web these past few days. Open source applications were ported right away, and it was confirmed that Windows RT is the full Windows - it's exactly the same as regular Windows, except that it runs on ARM. Microsoft responded to the jailbreak as well.
Thread beginning with comment 548063
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: x86
by WereCatf on Thu 10th Jan 2013 02:50 UTC in reply to "RE[5]: x86"
WereCatf
Member since:
2006-02-15

Most code doesn't self modify


I think you mean most simple applications don't self-modify. Most multimedia-related applications do make use of heavy optimizations where straight-up static translation doesn't work. On a similar note, straight-up translation wouldn't work for 64-bit applications at all.

But sure, I would love to see you prove me wrong, it'd be a very nice tool in the toolbox! Go ahead and explain more in detail of how you'd actually implement such a thing if you feel like it, as off-topic as it may be.

Reply Parent Score: 3

RE[7]: x86
by Alfman on Thu 10th Jan 2013 07:29 in reply to "RE[6]: x86"
Alfman Member since:
2011-01-28

WereCatf,

"I think you mean most simple applications don't self-modify. Most multimedia-related applications do make use of heavy optimizations where straight-up static translation doesn't work."

I don't really know what you are referring to here? Most games/multimedia apps would use SSE and the like, but they are still static as far as I know. Skype uses dynamic code extensively to obscure itself even to the point of incurring significant overhead during normal use, which is ridiculous. However that's an exception and not the norm. I'd be surprised to see many cases where the code in memory is not a mirror image of the executable/dlls.


"On a similar note, straight-up translation wouldn't work for 64-bit applications at all."

Why not? Are you talking about handling 64bit calculations? Can't ARM platforms handle uint64_t today just like 32bit x86 can? Aren't ints usually 32bit even on x86-64? It's mainly in the case of longs that 64bit arithmatic needs to be split up into multiple 32bit operations.

An observation is that 64bit longs are often used to store values that would fit in 32bits anyways, so we don't always need to touch the high bytes anyways. Take a look at 64bit pointers, they'll never point beyond 4GB on a 32bit ARM, so there's no need to handle it. The 32bit translated code would only need to detect overflow, and only then would it have to handle a 64bit variable and compile a 64bit code path.


"But sure, I would love to see you prove me wrong, it'd be a very nice tool in the toolbox! Go ahead and explain more in detail of how you'd actually implement such a thing if you feel like it, as off-topic as it may be."

That's kind of a vague request.
At a high level, every x86 code segment would have a corresponding ARM recompiled one that's generated either on the fly or maybe up front. In principal it's probably not much different from Java's JIT compiler w/bytecode, though x86 is obviously much less structured.

Having used decompilers (yay turbo debugger!), code alignment is tricky to get right - dumping code with the wrong offset produces garbage. But since we are actually running the code, we don't have to guess. Dynamic modifications to code pages would trigger faults such that we could invalidate/recompile the corresponding ARM translated code, however I really think we're talking about an edge case there. The ARM code could be cached between executions to avoid constant recompilation.

In order to save a lot of work on the ARM compiler/optimizer I would try to hook into GCC's optimizer directly or if I feel particularly hacky maybe even convert the x86 opcodes into C code and call the compiler that way.

Ideally the end result would be ARM code that would be very close to what we would have had if the original source were compiled for ARM instead of x86.

Reply Parent Score: 3

RE[8]: x86
by viton on Thu 10th Jan 2013 22:11 in reply to "RE[7]: x86"
viton Member since:
2005-08-09

if I feel particularly hacky maybe even convert the x86 opcodes into C code and call the compiler that way.

It is safe to assume that code in question is already optimized.
So it should be enough to just move ARM instructions (according to target CPU issue possibilities) up to nearest branch entry point.
Modern OoO ARMs will do the rest for you.

Reply Parent Score: 2