Bug 2130009

Hi Linus, I've created upstream bug https://bugs.webkit.org/show_bug.cgi?id=245697 and will ask around to see if the upstream developers who understand this code might be interested in investigating it.

Some context: llint_program_prologue() is an assembly language function implemented in LowLevelInterpreter.asm. This is a custom assembly language implemented by Source/JavaScriptCore/llint, so it is not ARM assembly. Unfortunately, everything under Source/JavaScriptCore is gobbledygook to me. There's really no chance of making any serious progress here on Red Hat Bugzilla because I'm the only WebKit developer here, so I will close this with UPSTREAM resolution to indicate that is where work will need to happen. But if patches are eventually posted upstream, then I can build test RPMs for you to try to see if they actually work, and handle backports if something lands.

It's *probably* possible to work around this issue by using a custom build of WebKitGTK with the JIT disabled and the low level interpreter forced to use a slower C implementation rather than asm. That would not be good to do in Fedora proper, but I can provide an unofficial build if you want one. If you're content with using Firefox and don't use other applications that require WebKitGTK, Firefox is certainly the easier workaround.

Heh. Thanks. I didn't even know what the real upstream project for that particular code was, so going by the package I have installed was the easiest way.

CC: Jeremy as change owner of https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication

(In reply to Linus Torvalds from comment #2)
> Heh. Thanks. I didn't even know what the real upstream project for that
> particular code was, so going by the package I have installed was the
> easiest way.

It's WebKit. Unfortunately Apple is telling me that the implementation of BTI is going to be somehow Linux-specific, so that's not great news. The intersection of JSC developers with M2 Macbooks and JSC developers using Linux is probably zero.

Instead of a custom package, a potential work-around is to run with JavaScriptCoreUseJIT=0 in the environment, I believe?

(In reply to Gustavo Noronha Silva from comment #4)
> Instead of a custom package, a potential work-around is to run with
> JavaScriptCoreUseJIT=0 in the environment, I believe?

Not if my understanding is correct. Doesn't hurt to try, but based on the backtrace, I don't think it's trying to use JIT yet, but rather the baseline interpreter tier. To make this work, we would need to disable that at build time and use the llint cloop instead of the asm interpreter, which we already do in RHEL. There's actually a RHEL-specific condition for this in our spec file already. This is not a desirable way to go as the performance will not be satisfactory, but I believe that would be enough to make this work today without requiring anybody to dive into JavaScriptCore and figure out how to make BTI work.

I've posted some more comments in the upstream bug.

A package with a workaround is being prepared here: https://github.com/leifliddy/asahi-fedora-builder/issues/10

Apparently it's possible to resolve this by changing build flags. Eric Curtin has a pull request incoming so you won't need to use a special package from the Asahi repo anymore.

Oops, I forgot to close this bug. This should be fixed in both Fedora 38 and 37.

Fixed by https://src.fedoraproject.org/rpms/webkitgtk/c/fac6852e5695051ade276ed08835d7baa487bf32?branch=rawhide (thanks Eric!)

It is fixed (well worked around) in Fedora, we built without BTI basically, although I'd like to see it fixed properly, I do not want users to suffer because it's unfixed though. Upstream bug should remain open as it needs to be fixed properly by someone who cares and has the cycles to do it.

Hopefully we can turn on BTI protection for this package again when it is fixed upstream.