mystikos
mystikos copied to clipboard
deislabs
Remove the relaxation of badaddr check
The detail of the PR is as follows:
- Remove the relaxation of badaddr check introduced in #1039 given issue with using kstack during the user signal handler was fixed by #1177.
- Ensure the badaddr checks are only enforced in the code path through the syscall interface, avoiding invoking the checks from the kernel.
- Introduce
MYST_INTERNALannotation that helps reasoning whether amyst_function is private or public to the kernel.
Signed-off-by: Ming-Wei Shih [email protected]
Pseudo-fork child processes share the CRT heap with their parent. For such a child process, bad address check will fail for buffers obtained via malloc.
Pseudo-fork child processes share the CRT heap with their parent. For such a child process, bad address check will fail for buffers obtained via malloc.
We only check whether the memory is mapped (with non-zero pid) instead of the ownership of the memory. Will the kernel-allocated memory be used in the scenario you mentioned?
Pseudo-fork child processes share the CRT heap with their parent. For such a child process, bad address check will fail for buffers obtained via malloc.
We only check whether the memory is mapped (with non-zero pid) instead of the ownership of the memory. Will the kernel-allocated memory be used in the scenario you mentioned?
I see that the shared memory PR changes the logic to check the ownership. I can put this PR on hold until your PR is meged, and the scenario you mentioned is addressed.
We only check whether the memory is mapped (with non-zero pid) instead of the ownership of the memory.
Ah I didn't realize that while changing myst_is_bad_addr to ownership.
Will the kernel-allocated memory be used in the scenario you mentioned?
Can't think of any case if NoBrk is specified(which is recommended if program is forking). There is an active PR #1175 to disable SYS_brk by default.
In full disclaimer, I did not encounter such a scenario. This was just reasoning about the consequences of sharing CRT heap in pseudo-fork child processes. Maybe we can detect if the process is a pseudo-fork child and only then relax the check from ownership to additionally check the parent's owned memory.
The shared memory PR does not enable the pids vector based bad address check, so I don't have any empirical data on whether changing to ownership check will fail certain tests.