Opened 6 years ago
Last modified 5 years ago
#749 closed defect
Map and eradicate uses of kernel addresses as IDs for userspace — at Version 1
Reported by: | Jakub Jermář | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.8.0 |
Component: | helenos/kernel/generic | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description (last modified by )
The kernel (still) intentionally leaks kernel addresses at various places in order to provide identifiers to userspace.
In the past it used to identify calls this way, but this behavior has been replaced by using capabilities. There are still some other uses in other contexts that this ticket aims to map and eventually eradicate.
Note that using kernel addresses as userspace IDs is bad for two reasons:
- leaking addresses of kernel objects represents a security risk and
- kernel addresses use a global namespace (unlike task-local capability handles), so this precludes some light forms of virtualisation on the namespace-level
The following list enumerates the individual cases:
ipc_forward
sets phone_t *newphone in call→data.phoneipc_forward
sets TASK→taskid (another global ID) in call→data.task_id_ipc_call_actions_internal
sets phone_t *phone in call→data.phone- '_ipc_call_actions_internal` sets caller→task_id in call→data.task_id
sys_ipc_wait_for_call
sets call→priv in call→data.phoneevent_enqueue
sets TASK→taskid in call→data.task_id_ipc_answer_free_call
sets TASK→taskid in call→data.task_id
Change History (1)
comment:1 by , 6 years ago
Description: | modified (diff) |
---|---|
Summary: | Map and eradicate use of kernel addresses as IDs for userspace → Map and eradicate uses of kernel addresses as IDs for userspace |
Note:
See TracTickets
for help on using tickets.