Wow!!! I was excited about the thermometer support but I did not realise we would be getting toggles for WebView JIT and Dynamic code loading!! This is absolutely incredible! Thanks so so much, GOS team! One of the most exciting updates for a while. This really must have taken a lot of work. I'm so happy I made the decision to switch and persuade other family members to use this OS

First of all, wow and thank you so much for your hard and tireless work! That's an incredible list of changes and new features, I'm really impressed!

I've tried to read up on the following two features:

  • Settings: add per-app memory dynamic code loading restriction toggle (applies to both native code and Android Runtime class loading for Java/Kotlin)

and

  • Settings: add per-app WebView JIT restriction toggle

I found this description helpful:

The vast majority of local and remote code execution vulnerabilities are memory corruption bugs caused by memory unsafe languages or rare low-level unsafe code in an otherwise memory safe language. Most of the remaining issues are caused by dynamic code execution/loading features. Our main focus is on preventing or raising the difficulty of exploiting memory corruption bugs followed by restricting dynamic code execution both to make escalation from a memory corruption bug harder and to directly mitigate bugs caused by dynamic code loading/generation/execution such as a JIT compiler bug or a plugin loading vulnerability.

source: https://grapheneos.org/features

Can I imagine using this toggles similar to the memory tagging and native code debugging toggles (The most secure setting will be on by default as with the settings mentioned above and if an app crashes using these settings, I can then switch memory dynamic code loading restriction and/or WebView JIT restriction on or off)?

By the way: If anyone has an easy to understand explanation of how dynamic code loading and WebView JIT works - would be great if you could share it.

What are the consequences of enabling WebView JIT and dynamic code loading, and what does enabling it do or not do?

@Murcielago @Stewart There's a description under each setting when you click on WebView JIT, Dynamic code loading via memory and Dynamic code loading via storage explaining what each one does. Disabling them makes WebView and DCL less vulnerable to exploitation.

    ErnestThornhill Thanks, what I gain through this toggle is clear to me. What is unclear yet is what I loose.
    EDIT : but I suppose it will become clear when I see that I have lost something ...

    ErnestThornhill

    I haven't installed 2024083100 yet, so I haven't been able to see the descriptions you mentioned - but thanks for the tip and the brief explanation.

    With this update, Shizuku seems to crash too often. I mean, the service stops every now and then even after enabling exploit protection compatibility.

    I know GrapheneOS would give an f about apps that gives users more control. But still, breaking apps like feels more of a sham.

      I don't know if it's because I'm on a P7 but when I enable "hardened memory allocator" or set "dynamic code loading via storage" to restricted, they both are resettled to disabled and allowed when I re-open their settings menu

      Edit: everything works great, only bitwarden doesn't seem to work with DCL via memory disabled
      Error:

      type: memory_DCL
      osVersion: google/panther/panther:14/AP2A.240805.005/2024083100:user/release-keys
      package: com.x8bit.bitwarden:11086
      
      DCL denial type: DENY_EXECMEM

      Is it safe to restrict DCL via memory for Vanadium and webview jit for PDF viewer? I assume some sites won't work / be slower, but is there any other reason to let them be enabled?

      shizukuuser

      I know GrapheneOS would give an f about apps that gives users more control. But still, breaking apps like feels more of a sham.

      That is simply not true. A new user, with that name, making that comment feels like a trolling attempt. You didn't provide details, you didn't provide logs, so how do you expect us to take a look at what you're reporting?

      The implication that this was done on purpose is ridiculous. If that's what your participation in the community is going to consist of, it won't be productive.

        matchboxbananasynergy nice.

        I created an account on the go to tell the issue that i faced multiple times assuming others who use shizuku "might" be facing this.

        So every time an app tries to access DCL, say WhatsApp, Shizuku service gets affected. I re-enabled it a few mins back. I forgot to get logs previously. Will catch the logs when it stops.

        Also, it is reproducible. Enable the service, wait for some time, it stops.

        The implication that this was done on purpose is ridiculous.

        People are free to make assumptions.

          shizukuuser People are free to make assumptions.

          You could have asked if an issue was intentional. You instead opted to say we're breaking apps on purpose, and that it's a "sham". That's bad faith.

          Regardless, I assume from your explanation that you're using the DCL toggles to restrict DCL for an app, i.e. Whatsapp, and then the issue with Shizuku occurs?

          It might have to do with how Shizuku interfaces with apps to do whatever it is you're doing with it.

          If the new features remain in their default state and aren't used, there should be no difference compared to previous updates, are you able to confirm that?

          Yes, I did block DCL to block by default. Some apps crashes and I selectively enabled DCL to them.
          But since I enabled the service yesterday after it stopped, couldn't see it stopping.

          using the DCL toggles to restrict DCL for an app, i.e. Whatsapp, and then the issue with Shizuku occurs?

          previously, yes. Shizuku would crash every time DCL notification occurred for any other app, say Firefox, WhatsApp, etc., These apps have no relation to Shizuku whatsoever.

          Monitoring the activity of when it crashes at present.

            shizukuuser Maybe it's an other app granted Shizuku permission that causes the crash. I suggest you to report the issue to GOS GitHub and clearly states steps to reproduce.

            One of the most exciting updates for a while.

            YES!

            I restricted DCL via Storage for all my apps except of Brave and have no problems so far. Really waiting on the global toggle. Is there a deprecation ETA?

              So, if I understand correctly, the basic default parameter should probably be

              • webview JIT restricted for all apps except pdf,
              • DCF via memory restricted except Google Play and the browser,
              • DCF via storage restricted except Google Play and the browser.

              Then see which apps encounter problems and decide per app.
              Is that the option you generally chose ?

                For your information, my banking app, BanquePostale, require Dynamic Code Loading via memory. Should I report that on the dedicated PrivSec page ?
                EDIT : the same for banking app BoursoBank.