Fix EXEC permission of the volume mount when calling mmap with PROT_EXEC #11358
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
@nixprime Hey Jamie! Could you please help us review this pull request when you get time? Thank you! |
test/syscalls/linux/mount.cc
Outdated
| ASSERT_THAT( | ||
| reinterpret_cast<uintptr_t>(mmapRet), | ||
| SyscallSucceeds()); |
There was a problem hiding this comment.
I think the right check here would be EXPECT_NE(mmapRet, MAP_FAILED);
Also, rename mmapRet to addr
There was a problem hiding this comment.
Thanks, I've updated the code now
| @@ -98,6 +98,19 @@ func Mmap(t *kernel.Task, sysno uintptr, args arch.SyscallArguments) (uintptr, * | |||
| opts.MaxPerms.Write = false | |||
| } | |||
|
|
|||
| // mmap requires the volume mount which includes the requested file to have exec capability if given request | |||
There was a problem hiding this comment.
Please wrap these comments to 80 chars as well.
Yhinner
force-pushed
the
xuzhoyin-mmap-fix
branch
from
d163dcb to
3452c7b
Compare
Background
This is Xuzhou (Joe) from
Snowflake Inc. We are currently working on utilizing gVisor internally as our secured sandboxing mechanism. We have met in-person with gVisor team last October sharing our use case and experiences with the gVisor team. As part of the meeting, we (Snowflake team) committed to contribute our internal fixes/improvements back to the upstream.As part of compatibility testing with our previous mechanism, we found some behavior discrepancies between gVisor-emulated kernel and native linux kernel when making
mmapsystem calls. Thus wanted to raise a pull request and see if this makes sense.Issue we observed
On native linux kernel, when calling
mmapsyscall with PROT_EXEC on a file, linux kernel checks if the volume/file system backing the file is executable (ie. HasNOEXECflag or not). If the volume has NOEXEC flag set, the syscall will fail with EPERM.However, this behavior is not observed when running under gVisor. Instead, gvisor allows this system call to be made without any issue.
Thus this pull request aims to bring the same parity to gvisor implemented mmap syscall.