lkml.org 
[lkml]   [2003]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: encrypted swap [was: The disappearing sys_call_table export.]
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.044 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site