Porting Chromium to Windows RT

[nbetcher]

No, what's on there is right... Is it possible you're mixing up the Surface RT and Surface 2? I don't think the RT is supposed to have 4.22.500

Yeah, I had them backwards, I do have the Surface 2. I've gotten conflicting information from multiple sources, including Microsoft, and it's been infuriating to say the least. But System Information states it's the Surface 2. So then that's a plus. Thanks for forcing me to resolve that lingering discrepancy.

 

[frylockk19]

Yeah, I had them backwards, I do have the Surface 2. I've gotten conflicting information from multiple sources, including Microsoft, and it's been infuriating to say the least. But System Information states it's the Surface 2. So then that's a plus. Thanks for forcing me to resolve that lingering discrepancy.

No problem

 

[Nicknackpaddywack101]

Sorry to bother...
Why do all that work when you could just install Linux?
It is a lot more configurable than RT or 10 preview and Chromium would be easier to Port.

 

[nbetcher]

Because it's apparently significantly slower than on other Linux-capable devices because it can't be booted directly from the UEFI, and X11/Xorg was never very performant or known for low-latency 2D graphics on lower-end devices like Windows is. The X11 protocol was designed to be versatile, namely for being capable of communicating over sockets (TCP or otherwise).

Anyway, that aside, Linux's power management isn't historically as good as Window's, namely due to the power management drivers (same for the graphics too actually).

I don't know how many distros use Wayland by default now or if there's even a more performant and efficient driver for it for the Surface RT / 2, or even how good Wayland in general is, but somehow I just don't think it's up to par with Windows despite my lack of experience with all of that.

Perhaps most people wouldn't care about such things, or even that I might be forced to go that route myself eventually, but by doing this project I can learn a lot about the Surfaces and their problems. That may help me in the future.

 

[Nicknackpaddywack101]

Because it's apparently significantly slower than on other Linux-capable devices because it can't be booted directly from the UEFI, and X11/Xorg was never very performant or known for low-latency 2D graphics on lower-end devices like Windows is. The X11 protocol was designed to be versatile, namely for being capable of communicating over sockets (TCP or otherwise).

Anyway, that aside, Linux's power management isn't historically as good as Window's, namely due to the power management drivers (same for the graphics too actually).

I don't know how many distros use Wayland by default now or if there's even a more performant and efficient driver for it for the Surface RT / 2, or even how good Wayland in general is, but somehow I just don't think it's up to par with Windows despite my lack of experience with all of that.

Perhaps most people wouldn't care about such things, or even that I might be forced to go that route myself eventually, but by doing this project I can learn a lot about the Surfaces and their problems. That may help me in the future.

Thanks. I never knew how well battery life was because I bought mine as a budget raspberry pi
however I do want to thank you for your work and your love to such a device that was trashedand abandoned by Microsoft because it deserves more attention

 

[nbetcher]

So this needs to be documented publicly if I don't finish the work. Chromium is a bit of a challenge at RUNTIME (not necessarily to compile) because, while the compiler (MSVC or Clang) allows you to compile V8, the Javascript engine, into Chromium, it does use a moderate amount of assembly. While that assembly is available for ARM32 (due to the Linux variety), WINDOWS 8 RT DOES NOT SUPPORT ARM ASSEMBLY OUT OF THE BOX. Yes, you read that right: the basic assembly of the Surface is not supported by Windows 8 RT. I honestly never even considered that could be a possibility, but it's true.

Instead, it only allows execution of THUMB-2 assembly, an instruction extension in the ARM processors. This was apparently to unify the variety of processors that could have (future tense) shipped with the Surface. Not all hope is lost though, "all" that needs to be done is PatcherGuard bypassed and the kernel executable patched to allow it. There's apparently a decision point in the kernel execution of assembly where it ignores ARM and only allows a return from THUMB-2. It's easily patched, but I haven't done something like that before, and I don't think you can simply patch the kernel executable directly: you have to use a loader to load in the changes (which is why PatcherGuard can be a problem) at runtime.


Here's a copy and paste of what I (and jeybee at the beginning) said in the "Open RT" Discord:


(Some of this is out of context, yes, but it doesn't matter... the intent was preserved in each message)

jeybee: devs-might be worth having a read through this http://mamaich-eng.blogspot.com/
jeybee: specifically "No ARM code on Windows on ARM. Period.
Though MS called their new OS "Windows on ARM" (sometimes Windows on Snapdragon, Windows on Tegra and now Windows RT) - you can't see ARM code in it. Everything is THUMB2.
I don't know the reason of such a limitation - but that caused me several days of debugging while I was working on a DosBox dynamic core WinRT port last year. The dynamic code generated by DosBox is ARM, even the original THUMB generator was using small ARM thunks. Original DosBox works fine on ARM Linux, but on Windows RT it behaves differently. The generated code executes once, twice, but on the 100500 time - it crashes.
The reason was simple. If you read the ARM developer's manual, you'll see that OS should determine the previous mode (ARM or THUMB) on kernel mode entrance (via SWI, interrupt, ...). Seems that MS decided to simplify the handler's code - and assume that the user's code is always THUMB. And they always set the T bit on return to the user land.
So if you are running generated ARM code in your program - you may be forced to the THUMB mode any moment by an interrupt or a task switch."
Phorin: "this leaves one thing to be desired: executing ARM code. I already know how we can patch the kernel so that ARM code can execute without the CPU being switched back to Thumb2 all the time." (https://forum.xda-developers.com/t/bypassing-patchguard.2488560/)
Phorin: "it's currently impossible to execute ARM code reliably on Windows RT is a major reason that Firefox hasn't been ported. Fixing that would require patching two context-switch routines in ntoskrnl.exe." (https://forum.xda-developers.com/t/bypassing-patchguard.2488560/#post-46610744)
Phorin: And, narrowing it down specifically:
"Specifically, KeContextFromKframes in the Windows NT kernel (ntoskrnl.exe) is setting the T bit when freezing a thread's state for a task switch.
This annoyed us jailbreakers for RT/WinPhone, because we couldn't directly port Chrome's JITter without breaking Microsoft's PatchGuard."
I'm assuming that in Test Mode PatchGuard is irrelevant -- I'd be shocked if that wasn't the case. If it is irrelevant, then we have the solution: patch KeContextFromKframes in ntoskrnl.exe to return the mode it was requested to be called from user space.
Phorin: (https://stackoverflow.com/a/33427234)
Phorin: Yes, one of those links above talks about it as well as this https://github.com/Mattiwatti/EfiGuard
Phorin: But that link is for x64
Phorin: Disabling PatchGuard on ARM: https://github.com/tandasat/meow haven't tried it yet though
Phorin: If Win10 truly does run ARM assembly (not THUMB2), that would be helpful to know. Then I could just reference the Win10's kernel for the context switching back to user space
Phorin: So then we just need to disable PatchGuard (seemingly trivial) and patch ntoskrnl.exe with the context-switching behavior from Win10's ntoskrnl.exe. Normally I'd say that would be trivial, but my understanding is that you can't physically patch the ntoskrnl.exe file itself but instead need some kind of loader to patch it in-memory... Something to which is not really in my wheelhouse of expertise.
Phorin: But sure as hell of a lot easier than trying to port all of that ARM assembly to THUMB
Phorin: Plus it would solve a whole host of issues pertaining to other apps
Phorin: I think the only reason someone didn't do this before is because the trust zone-level jailbreak wasn't out. All of this I've come up with isn't really my idea, but it sounds like no one went back to the beginning after the jailbreak came out

One thing to clarify: I'm not even sure that PatcherGuard is running/enforced in test mode (jailbroken), so consider that much of what is shown above could be irrelavent.

For those of you considering just porting the V8 engine's (referenced as, "JIT" -- Just-In-Time [compiler]) from ARM to THUMB-2 is easy: even if it is, which requires a very, very specific, and experienced skillset, consider that future changes to Chromium may not merge cleanly on Git checkout (merge conflicts).

Also, by fixing the kernel running ARM assembly directly, you open the door for other developers to more easily port their apps to Windows 8 RT (or even users recompiling existing ones with the Linux ARM-32 assembly copied to the Win32-equivalent directories).