{"action":"created","issue":{"url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/issues/6972","repository_url":"https://api.github.com/repos/zephyrproject-rtos/zephyr","labels_url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/issues/6972/labels{/name}","comments_url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/issues/6972/comments","events_url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/issues/6972/events","html_url":"https://github.com/zephyrproject-rtos/zephyr/issues/6972","id":312076460,"number":6972,"title":"RFC: kernel heap requests on behalf of syscalls","user":{"login":"andrewboie","id":3387369,"avatar_url":"https://avatars1.githubusercontent.com/u/3387369?v=4","gravatar_id":"","url":"https://api.github.com/users/andrewboie","html_url":"https://github.com/andrewboie","followers_url":"https://api.github.com/users/andrewboie/followers","following_url":"https://api.github.com/users/andrewboie/following{/other_user}","gists_url":"https://api.github.com/users/andrewboie/gists{/gist_id}","starred_url":"https://api.github.com/users/andrewboie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andrewboie/subscriptions","organizations_url":"https://api.github.com/users/andrewboie/orgs","repos_url":"https://api.github.com/users/andrewboie/repos","events_url":"https://api.github.com/users/andrewboie/events{/privacy}","received_events_url":"https://api.github.com/users/andrewboie/received_events","type":"User","site_admin":false},"labels":[{"id":724796876,"url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/labels/RFC","name":"RFC","color":"d8af5d","default":false},{"id":717161529,"url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/labels/area:%20Memory%20Protection","name":"area: Memory Protection","color":"0d50a8","default":false},{"id":604498101,"url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/labels/feature","name":"feature","color":"e99695","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-04-06T18:39:17Z","updated_at":"2018-04-09T17:43:46Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"We've found some situations where we are going to need to allow the kernel side of system calls to reserve memory on some private kernel heap, for short or long-lived purposes, because user mode cannot be trusted to provide this memory itself. However, if we allow this, we must have some means to prevent user mode threads from DoS the kernel heap by requesting all of its memory.\r\n\r\nLet's go through some examples where this is needed:\r\n\r\n1. Dynamic allocation of kernel objects, an RFC patch which exists in #6876. We want to allow for kernel objects to be allocated dynamically, not just statically as we have now. It would be very desirable to allow user mode threads to also request kernel objects.\r\n2. We have some system calls which would like to do some deferred processing. A good example is the k_delayed_work APIs. In order to properly do deferred processing, you need to instantiate a struct _timeout which gets added to system timeout lists. Once the timeout expires, the _timeout can be deleted. The _timeout cannot be in user-accessible memory, so any deferred workqueue requests will need a transient heap allocation to handle the timeout.\r\n3. Using the workqueue example again, there's a larger struct k_work which is queued when work is requested and de-queued by the worker thread. A user mode compatible workqueue would need temporary allocation of k_work objects until the worker thread consumes them.\r\n4. In a more general case, we could introduce the notion of unbounded k_queues by allocating the linked list behind the scenes, right now the only IPC data exchange mechanism we allow user mode to use are pipes which are fixed size.\r\n5. k_pipes are themselves currently problematic. We really can't trust user mode to provide the buffer where the pipe data gets queued. If user mode wants to initialize a pipe object we need the pipe's buffer to be allocated on a heap instead.\r\n\r\nSo given all this, we still don't want threads to spam syscalls and eat up the entire kernel heap. There needs to be some limits on how much kernel heap data a user thread can indirectly consume on behalf of these calls. I can think of 3 methods for doing this:\r\n\r\n1. Limit number of heap requests. Simpler per-thread counter, any given thread cannot make more than N requests before the request fails, where N defaults to some Kconfig and can be adjusted by supervisor mode at runtime. Freeing memory will credit the thread that made the request (even if freed by some other thread or an ISR)\r\n2. Limit number of bytes of heap requests. Just like #1, but account for actual number of bytes requested. Any given thread can only reserve N bytes.\r\n3. Don't do numerical accounting, instead there can be a supervisor mode to assign a k_mem_pool to a thread. Any requests made by that thread will draw from that memory pool. Defaults to NULL, so no requests allowed. Supervisor mode API to assign a pool to a thread. Multiple threads can all be using the same pool, child threads will inherit the pool assigned to the parent. If DoS is not a concern, just make this be the kernel heap.\r\n\r\nI feel Option 1 doesn't account for divergent sizes of object requests, it would only work well if all requests were generally on the same order of magnitude in size, and I won't discuss Option 1 further.\r\n\r\nOption 2 is simple and easy and doesn't require the creation of additional pools. However it means that child threads would again be able to reserve as much stuff as the parent; it doesn't impose any kind of cap on a group of threads. We don't (yet) have a *process* model in Zephyr, with multiple threads running in one process. Something like option 2 would be ideal later if when introduce processes, even if it's only an abstraction layer for non-MMU systems.\r\n\r\nOption 3 is a bit more cumbersome since additional memory pools will have to be defined. But it does offer the ability to have threads that form some logical \"application\" on the device to all draw from a single pool. One of the more popular use-cases of Zephyr is to have multiple, more or less independent applications all running on the same MCU, APIs like Memory Domains and so forth are intended for this. So if each application has its own pool for syscall requests, then they can't DoS each other. The downside is that since these are separate pools, they all have to be set up, a proper size determined, threads assigned to them, etc.\r\n\r\nI'm looking for input on approach:\r\n\r\n- Pursue Option 2 by introducing a Zephyr \"process\" abstraction layer and have the heap limits shared by all threads that belong to that process. This is what I am trending towards. The same process-level APIs will then tie into future work to introduce virtual memory.\r\n- Pursue Option 2 but disregard potential DoS scenarios where a ton of user threads are created and eat up the heap in concert\r\n- Pursue Option 3 as it would be fastest to implement even though not particularly easy to use.\r\n"},"comment":{"url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/issues/comments/379835014","html_url":"https://github.com/zephyrproject-rtos/zephyr/issues/6972#issuecomment-379835014","issue_url":"https://api.github.com/repos/zephyrproject-rtos/zephyr/issues/6972","id":379835014,"user":{"login":"andrewboie","id":3387369,"avatar_url":"https://avatars1.githubusercontent.com/u/3387369?v=4","gravatar_id":"","url":"https://api.github.com/users/andrewboie","html_url":"https://github.com/andrewboie","followers_url":"https://api.github.com/users/andrewboie/followers","following_url":"https://api.github.com/users/andrewboie/following{/other_user}","gists_url":"https://api.github.com/users/andrewboie/gists{/gist_id}","starred_url":"https://api.github.com/users/andrewboie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andrewboie/subscriptions","organizations_url":"https://api.github.com/users/andrewboie/orgs","repos_url":"https://api.github.com/users/andrewboie/repos","events_url":"https://api.github.com/users/andrewboie/events{/privacy}","received_events_url":"https://api.github.com/users/andrewboie/received_events","type":"User","site_admin":false},"created_at":"2018-04-09T17:43:46Z","updated_at":"2018-04-09T17:43:46Z","author_association":"CONTRIBUTOR","body":"> FWIW: I'd argue you don't even need the per-object byte counts. All that is really required for security is that the kernel object's allocation be bounded to some predictable level and not drivable to arbitrary sizes by userspace requests.\r\n\r\nI'm not 100% sure about this. There are some use-cases where the memory allocation might be somewhat large. Or at least, the way that objects make allocations are not necessarily on the same order of magnitude per object type.\r\n\r\nI did sketch out use-cases in the original RFC but I'm going to take another pass at this and really drill down to the specifics for each API that might involve allocations on behalf of syscalls. It will help knowing exactly what we are dealing with, and in further contemplation we may want to say for some of them \"no this is not the right way to go about this\" and omit those."}}
{"actor":{"display_login":"andrewboie"}}