On Fri, 16 May 2003, Yoav Weiss wrote:
> Hi,
>
> I got the below from some guy, off the list.
> He may has a point, at least when writable pages are shared between
> processes.
>
> What do you think ?
>
> Yoav
>
> My apologies; I was unclear.
>
> I think that you need to associate swap encryption keys with memory
> spaces, not with processes, precisely because you need to be able to
> swap out and swap in from any process using that memory space. And
> correspondingly the key can't die on a per-process basis, it has to
> die if and only if the associated memory space is torn down (which
> may be long after the PID that originally creates it goes away).
Hi Yoav,
After sort of thinking about it at this early friday hour (well late
thursday for me), it occurs to me that we may want to maintain keys
either in the vm_area_struct (vma) or for a vma group.
We want to decrypt mostlikely after a page-fault, which triggers a vma
nopage (code here?), has loaded the page so vma key, and swapping out of
course is still in vma domain.
Since we can always go from process to vma to page and back again i think
it is not going to cause any tracking issues.
Further, we have different vma's for shared and other interesting pages
so various optimizations are also doable on a case to case basis.
Does this make any sense? or am I off the cuckoo train at this hour :)
Please comment.
Cheers,
Ahmed.
> Hi Yoav,
>
> After sort of thinking about it at this early friday hour (well late
> thursday for me), it occurs to me that we may want to maintain keys
> either in the vm_area_struct (vma) or for a vma group.
>
> We want to decrypt mostlikely after a page-fault, which triggers a vma
> nopage (code here?), has loaded the page so vma key, and swapping out of
> course is still in vma domain.
>
> Since we can always go from process to vma to page and back again i think
> it is not going to cause any tracking issues.
Right. The only drawback is that we have another level of indirection for
some operations, but its negligible because it'll only be used on swap
operations or core dumps, both of which rely on disk access times anyway.
I guess a refcount and a key can be added to vm_area_struct, to provide
that. As long as this vma is in use, key remains valid.
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 ?
>
> Further, we have different vma's for shared and other interesting pages
> so various optimizations are also doable on a case to case basis.
>
Yes, I seems so, but we need to dig into mm and find some answers to be
sure about all cases.
> Does this make any sense? or am I off the cuckoo train at this hour :)
It does, unless I'm also off the cuckoo train at this hour. Time to get
some sleep, I guess :)
Yoav
> 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
On Sat, 17 May 2003, Yoav Weiss wrote:
>
> 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 ?
A page of swap may belong to different mms (see fork's copy_page_range
calling swap_duplicate). That's a difficulty for your approaches,
and one reason why cryptoloop of block device is used instead.
Hugh