App crashes while creating instance of WebView in Apple silicon macs

If you run the app from outside of Xcode, does it generate a crash report? If so, please post it here. Use the text attachment feature (the paperclip icon) to avoid clogging up the timeline.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

@eskimo

Interestingly I'm in the process of finishing up getting an app compiling for Apple Silicon. When I first got it compiling yesterday I ran it in debug mode with a debugger attached. When a view that uses the deprecated WebView class attempted to come on screen during the initialization of the window it crashed immediately with an EXC_BAD_ADDRESS. The function at the top of the crashed stack is:
void JSC::LinkBuffer::copyCompactAndLinkCode<unsigned int>(JSC::MacroAssembler&, JSC::JITCompilationEffort).
At this point the WebView hasn't been given a URL or any content. It is simply trying to come on screen during the initialization of the window from a nib. I tried replacing the view in the nib with a custom view and class set to WebView but that didn't help.

I decided to try a debug build compiled for using Rosetta (Intel) in debug mode with the debugger attached. No crash.
I then tried a debug build compiled for Apple Silicon (arm) without the debugger attached. No crash.

This is strange. 🤔

I then compiled in release mode and properly code signed instead of ad hoc in debug. No crash.

A teammate suggested I turn off the JIT and so in my scheme for debug build I put JSC_useJIT=false as an environment variable did a debug build compiled for Apple Silicon. No crash.

Still very strange. But clearly by not using the JIT we avoid the crash in this situation.

So I tried to reproduce the problem by creating a new app that just throws up a WebView in a window. Tried to create as best a representation as I could with all the settings. Disappointingly no crash.

I discovered JSC_useLLInt=false and thought maybe that would force the use of the JIT in release mode or without the debugger attached and cause the crash but it didn't.

After a lot of Googling I found something about JIT and the hardened runtime. So I went and looked and saw the Allow Execution of JIT-compiled Code and decided to give it a whirl. With allowing that exception (I also have Disable Library Validation enabled for debug builds) I did a debug build compiled for Apple Silicon with the debugger attached. This time there was NO crash.

So this brings up lots of questions for me. I can possibly understand why this exception is required. However, the results appear to be all over the place with little reason between them. Where it is working in some situations and in other not as described above. I would expect if this truly was the problem I should be hitting it in more situations especially when disabling JSC_useLLInt. Also, I talked with someone else who has the old WebView in their app and they have never seen this behavior. Given all that...

Does using the old style WebView require that we include the Allow Execution of JIT-compiled Code?
If not, why might I be hitting these different results?

Thank you for any insight you might have!

Does using the old style WebView require that we include the Allow
Execution of JIT-compiled Code?

The legacy web views (WebView and UIWebView) run all of their code within your process. Thus, if their code needs some privilege then the privilege must be available to your entire app.

If you have the hardened runtime enabled then you need the com.apple.security.cs.allow-jit entitlement in order to JIT. This applies to all code running in your process, including the JavaScript context being used by your WebView.

This, incidentally, is one of the main reasons that the legacy web views are deprecated. WWDC 2018 Session 207 Strategies for Securing Web Content discusses this concept in some depth.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

So is the answer "yes" or "no"? If an app can potentially use legacy WebKit (or JavaScriptCore directly?) and it has enabled the hardened runtime, does it need to have the JIT entitlement to avoid crashes? Or is it expected that WebKit will automatically disable JIT if the entitlement isn't present?

Does -[NSAttributedString initWithHTML:...] (macOS) still use legacy WebKit? If so, would use of that API mean it's a good idea to enable the JIT entitlement to avoid crashes?

Thanks!

Specific advice:

• Stop using the legacy web views. They’ve been deprecated for a long time, and for a good reason.

• If you need to run a JavaScriptCore context inside a hardened runtime app — and that includes via the legacy WebView — set the com.apple.security.cs.allow-jit entitlement.

• Don’t run -[NSAttributedString initWithHTML:…] within an input that might contain JavaScript; that’s not what it was designed for.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"