> There's still something I'm unsure of. I'm not familiar with the mm
> subsystem. Do you know whether vma structs are shared among processes
> with shared mapping ? I'd think the answer is yes, in which case the
> above is the right way, but if it works that way, how come vm_area_struct
> doesn't have a refcount yet ? Who keeps track of it ? Who frees it when
> the last mapper unmaps it ? Is the vma->shared in charge of all that ?
> If so, what lock protects it ?
>
Answering myself here. Sanity-check me :)
According to mm/mmap.c, vma's are indeed shared among processes.
vma->shared is the list, and is maintained by __remove_shared_vm_struct()
and __vma_link_file().
The semaphore we should probably grab when messing with the key of a
shared area is actually its inode's sem, since vma doesn't have one.
inode->i_mapping->i_shared_sem, in the inode pointed by vma->vm_file.
If it doesn't exist, it probably means this vma has only one user.
Invalidating the vma key should probably occur in any place that
calls vma->vm_ops->close(), after this call. We may want to add our own
refcount in vma, in case vm_file isn't available for extracting the
inode.
Just a thought: If we encrypt per-area, it might make more sense to go
down another level, to mm_struct. It already has its refcount and
backpoints its users. The key is valid iff the mm_struct is valid anyway,
so we may not have to track so many things ourselves. Just allocate a
random key whenever mm_struct is allocated, and overwrite the key before
mm_struct is freed. Any mm experts care to comment ?
Yoav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:26 EST