cannon: Noop mprotect syscall

[Inphi]

No-ops the mprotect(2) syscall for go1.23 compatibility. The go1.23 runtime may use mprotect in certain situations. A no-op approach is sufficient for two reasons:

• memory protection is explicitly not a supported feature of the VM. Cannon expects userspace to track its page mappings and not access protected pages.
• the mmap page bump allocator ensures that protected pages will never be yielded back to userspace in the future.

Closes #13447

[codecov]

Codecov Report

Attention: Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 46.81%. Comparing base (f890f71) to head (ad08885).
Report is 6 commits behind head on develop.

Files with missing lines	Patch %	Lines
cannon/mipsevm/multithreaded/mips.go	25.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #15792      +/-   ##
===========================================
- Coverage    46.82%   46.81%   -0.01%     
===========================================
  Files         1336     1336              
  Lines       107733   107738       +5     
===========================================
- Hits         50446    50438       -8     
- Misses       53683    53695      +12     
- Partials      3604     3605       +1     

Flag	Coverage Δ
cannon-go-tests-64	67.33% <40.00%> (-0.04%)	⬇️
contracts-bedrock-tests	96.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
cannon/mipsevm/arch/arch64.go	100.00% <ø> (ø)
cannon/mipsevm/versions/state.go	54.23% <100.00%> (+0.78%)	⬆️
cannon/mipsevm/multithreaded/mips.go	90.42% <25.00%> (-0.75%)	⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ajsutton]

LGTM.

Would be interesting to know what access level go is actually setting. From https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html:

An implementation may permit accesses other than those specified by prot; however, no implementation shall permit a write to succeed where PROT_WRITE has not been set or shall permit any access where PROT_NONE alone has been set.

As no-op may be in compliance. But also:

The behavior of this function is unspecified if the mapping was not established by a call to mmap().

Not sure what would be getting mmaped in cannon so that alone may justify the no-op implementation.

[Inphi]

LGTM.

Would be interesting to know what access level go is actually setting. From https://pubs.opengroup.org/onlinepubs/9699919799/functions/mprotect.html:

An implementation may permit accesses other than those specified by prot; however, no implementation shall permit a write to succeed where PROT_WRITE has not been set or shall permit any access where PROT_NONE alone has been set.

The only mprotect flag used by the runtime is PROT_NONE - https://github.com/golang/go/blob/go1.23.9/src/runtime/mem_linux.go#L152. The runtime marks previously mmap'd pages as unused when it's about to free the memory regions that are contained within.
Even if this were to change in the future and other rwx mprotect flags are used, I think no-op would still be appropriate.