1902244 - [meta] Make the JIT compatible with CET Shadow Stacks

Status: NEW

(Core :: JavaScript Engine: JIT, enhancement, P3)

Description

[Gian-Carlo Pascutto [:gcp]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1899830#c8

"Is the problem only the fact that when we have a JIT we cannot encode the jump into JIT-ed pages with CET? I know Safari has CFI implemented for their JIT, could we implement CFI as part of the JIT in both the parent and client process?"

"I wonder if we can have the JIT emit CET control information, whether we'd be able to enable CET for content processes. That'd potentially be a big security win (even though it's probably a separate discussion from this one due to the above)."

Yannis pointed out Windows doesn't do the IBT part of CET, so for Windows it would be support for CET Shadow Stacks only, but I'm not sure how that interacts with JIT-ing.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

When we talked about this feature with Intel and Microsoft, I think Intel was specifically saying they think it's possible. Jan de Mooij was in those meetings, so maybe he remembers.

Comment 2

[Jan de Mooij [:jandem]]

This has come up a few times over the years. We think it's possible to support both IBT and Shadow Stack, but especially supporting the shadow stack will require non-trivial JIT work. The bailout code for example can push multiple frames onto the stack so this will need to be rewritten somehow to also adjust the shadow stack. There might be other problems elsewhere.

I'd suggest disabling the JITs completely as a first step (--disable-jit configure flag) to see what other problems show up in the browser.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Given that we already have a bug about CET IBT, let's make this specific about CET SS.

Comment 4

[Iain Ireland [:iain]]

This V8 design doc describes one approach to handling shadow stacks on bailout.

Comment 5

[Nicolas B. Pierron [:nbp — off until 29-09]]

The balance of call/return of Inline frame return path can be worked around by having a jump-on-return path that we use prior to resume in all the restored frames.
When a bailout would generate N inline frames, we can fallback to a path which can restore these call/return balance, where the return addresses would serve as a trampoline to resume the execution at the previously registered returned location.

restoreInlineFrame:
  <restore stack>
  depth--;
  if (depth) {
    call restoreInlineFrame;
  }
  jump *<resume location>

Having these generic return might cause additional issues when walking the stack, but given that we should have a resume location to jump back to, we can handle it.

However this solution is not perfect as this implies that we either have a jump to a dereferenced location, or a call to a dereferenced location (if we were to hard-code the resume locations) These might go against the work on X-only, as leaking pointer to useful attack surface.