[CP] Make sure FFI works on standalone Mac OS X

[mraleph]

Commit(s) to merge

6c92ce6

Target

stable

Prepared changelist for beta/stable

https://dart-review.googlesource.com/c/sdk/+/335881

Issue Description

Trying to use FFI callbacks on Mac OS X using standalone dart binary causes a crash due to code signing violation. This is a regression caused by bd57548 which changed how callback pages are allocated, but did not accomodate for Mac OS X specific requirements (i.e. that executable memory should be allocated with MAP_JIT flag when hardened runtime is active).

The issue slipped through testing because we did not have coverage for hardened runtime enforced behaviors on CI - but we have now addressed this issue (see 4ce2362 and 906ae3a)

What is the fix

Allocate executable memory for callback pages using MAP_JIT flag on Mac OS X.

Why cherry-pick

Users can't use FFI callbacks on Mac OS X in standalone CLI Dart.

Risk

low

Issue link(s)

#53928

Extra Info

No response

[mraleph]

@athomas it is not clear to me if I should edit CHANGELOG.md or not given that 3.2 is not yet released.

[sortie]

Do you want this to be in 3.2.0? Or 3.2.1?

if you want it in 3.2.0, you don't need the changelog. Add the Changelog-Exempt footer with an explanation and loop in @itsjustkevin who needs to reauthor the 3.2.0 release after you submit it (ideally ~today/~tomorrow since I think we're set to ship 3.2.0 on wednesday)

if you want it in 3.2.1, wait until 3.2.0 is out and then just follow the normal procedure of adding a changelog entry.

[mraleph]

It would be nice to rebuild 3.2.0 if possible and not ship it with a known crasher.

[itsjustkevin]

@mraleph is this a must have or nice to have? We are a bit late in the cycle and I am worried about introducing risk. However if we are okay with it, we can make it happen. I defer to @mit-mit

[mraleph]

@itsjustkevin Given that FFI is effectively broken on 3.2 standalone I would classify it this as must have.

I have also made sure that we actually have test coverage for the fix. We managed to regress with bd57548 because we thought we have coverage, but we did not have it. This is now fixed.

[itsjustkevin]

@mraleph please get a review on the CL so we can get the process started.

[mraleph]

@itsjustkevin done.

[mit-mit]

@mraleph is this only macOS, or also iOS? If only macOS, I think we can consider doing a quick patch release (3.2.1) if it's too late to re-open the 3.2 release?

[mraleph]

@mit-mit I think it should only be affecting standalone dart on Mac OS X. I think nothing else is affected (e.g. Flutter targeting iOS & Mac OS X should work in debug and release).

That being said it is unclear why we would want to release something that is broken if we could still quickly patch it before release.

[mit-mit]

If we have time to patch it, then yes let's do that. But I would not postpone the planned releases if we're not able to patch.

[itsjustkevin]

From the feedback here, it looks like patching in is the path, I’m going to mark this as approved.

@mraleph please submit, I’ll do my part and pass it on to the Flutter release eng team.

[sortie]

Sounds like y'all are on top of this. Just so you know how to react to these situations in general: Our infrastructure and procedures do support even last minute urgent patches prior to publication (which is the point of no return). It will in practice take a couple of hours to land the change and then the release has to be reauthored and rebuilt. It won't delay the release unless we're literally on the release day. There may be additional delays on the Flutter side that I wouldn't know about, which doesn't affect the standalone Dart release.

From a project point of view, those new stable artifacts are largely untested of course, so they introduce a bit of risk that the patch is somehow bad or has unintended consequences. That's the project policy tradeoff you just made, weighing well known breakage against potential unknown breakage, or whether to just postpone the release to do the testing. The systems can handle it all so you can always decide between these options :)