[Bug 21232] Chromium-based browser engines (Chrome, Opera, Comodo Dragon, SRWare Iron) crash on startup unless '--no-sandbox' is used ( native API sandboxing/hooking scheme incompatible with Wine)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=21232

--- Comment #37 from Fabian Maurer <dark.shadow4 at web.de> ---
Created attachment 61770
  --> https://bugs.winehq.org/attachment.cgi?id=61770
Proof of Concept

(In reply to Zebediah Figura from comment #36)
> 32-bit and WOW64 is doable as far as Chromium is concerned, but is there any
> way to make this actually work on 64-bit?

I didn't see a method mentioned here, but I made a Proof of Concept. It's the
only method I found that's viable at least - we can't intercept syscalls in
userland.

According to
https://chromium.googlesource.com/chromium/src/sandbox/+/master/win/src/service_resolver_64.cc#71
new win10 has a fallback to "int 2e" for interrupts. Don't ask me why, but my
tests confirm this true, and this opens an opportunity for us to provide
patchability.

Running "int 2e" results under Linux x64 to a segfault (not sure how certain
this is though) and we can catch and handle this. It might not be a pretty
solution, but it should do the job.

Of course, running this many SIGSEVs could impact the performance (need to test
that), but it could be made conditional.
AFAIK most people shouldn't depend on native APIs, so maybe we could only
enable that hooking feature when needed.
I thought of the lines of making the stub a simple jump to the actual function,
 and when GetProcAddress for an hookable Nt-function is called, the jumps are
converted into "int 2e; ret" resulting in the slower, patchable code..


Attached a small demo on how I think it could work.
I plan to make patches for actual wine to try it out this weekend.
What do you think about that?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.