You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DESCRIPTION
For each thread, the kernel maintains two attributes (addresses) called set_child_tid and clear_child_tid.
These two attributes contain the value NULL by default.
set_child_tid
If a thread is started using clone(2) with the CLONE_CHILD_SETTID flag, set_child_tid is set to the
value passed in the ctid argument of that system call.
When set_child_tid is set, the very first thing the new thread does is to write its thread ID at
this address.
My concern is that if a hostile compartment A starts a thread with clone() passing the address of memory owned by victim compartment B as the set_child_tid address, the write to this address may succeed even though the clone() syscall was issued by compartment A. I believe this write is performed by the kernel inside the implementation of clone(), which means that it may or may not respect pkeys depending on how it is implemented.
We should test this; if the write does ignore pkeys, we need to filter calls to clone() to either ensure that the set_child_tid and clear_child_tid addresses are owned by the compartment (and ensure that the latter address stays thusly owned until thread ends) or simply forbid the relevant CLONE_CHILD_SETTID/CLONE_CHILD_CLEARTID) flags.
The text was updated successfully, but these errors were encountered:
Anyone know whether put_user respects pkeys? I think given that it's not doing a complex dance to circumvent the MMU like /proc/self/mem does (described here) that it likely does respect them.
Looks like we're safe; these writes silently fail. Comment out the pkey_mprotect call and see the program fail its assertions due to the writes succeeding.
Split out of #233.
My concern is that if a hostile compartment A starts a thread with clone() passing the address of memory owned by victim compartment B as the
set_child_tid
address, the write to this address may succeed even though the clone() syscall was issued by compartment A. I believe this write is performed by the kernel inside the implementation of clone(), which means that it may or may not respect pkeys depending on how it is implemented.We should test this; if the write does ignore pkeys, we need to filter calls to clone() to either ensure that the
set_child_tid
andclear_child_tid
addresses are owned by the compartment (and ensure that the latter address stays thusly owned until thread ends) or simply forbid the relevantCLONE_CHILD_SETTID
/CLONE_CHILD_CLEARTID
) flags.The text was updated successfully, but these errors were encountered: