New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPC issues #1993
Comments
If we re-implement IPC to use message passing rather than shared memory, we can revisit the MPU implementation (re: #1532). |
I was playing with the IPC API and noticed that applications fault due to memory protection if the shared buffers are not multiple of 64. The buffer's memory region does not seem to be mapped. I cannot figure out the reason for this, all the API calls seem to return success. If this is a requirement, maybe we should add this to the kernel and refuse the buffer? |
While debugging #2906 I've noticed a more intricate issue of app load order and, what appears to me as a racy relationship of the IPC service registering its callback and the client notifying the service. This is in the context of a failing
Now, if the kernel were to execute (3) before (2), the IPC task is converted into a callback ( System call trace:
We currently have no way to tell whether notifying an IPC service (i.e. scheduling a callback in the service process) actually worked. Whereas the source code used to indicate that we might have a method of identifying a null-callback ( |
To add something to point (6) of the current IPC issues: restarting an application resets app_break/kernel_memory_break//allow_high_water_mark . The result is that an application (A) can:
This will result in application B having direct access to kernel data structures. Spicy. This can be leveraged even from safe userspace Rust. |
allow()
call can succeed, and a notify callback can be triggered, even if theexpose_to()
call fails. This may be fixed in 2.0 upgrades.client_notify()
can be used to determine how many other processes are on the board. By iterating through service IDs the error return values leak which apps are present, even if the apps do not setup any IPC services.client_notify()
on a different process causes the callee's process to allocate the grant region, consuming application memory the original app didn't intend to.The text was updated successfully, but these errors were encountered: