lkml.org 
[lkml]   [2000]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mlock behavior across fork, as broken as it looks?
Olaf Titz wrote:
> According to the mlock(2) manpage, "Child processes do not inherit
> page locks across a fork." Even if I call mlock() for the critical
> pages again just after the fork(), in my understanding there is a
> small time window when the pages can, theoretically, be swapped out.
> (Increase this window for a potential exploit with the usual high
> load, high mem pressure attack.)
>
> So is it really impossible to guarantee that locked pages will never
> be swapped out if the process holding them does fork? This would be a
> severe limitation for the case of cryptographic keys, as it in effect
> means "fork() is forbidden for such applications". If so, this is a
> deficiency which should be fixed.

Although the pages aren't be locked by the child process (unless you use
clone or vfork), they will be locked by the parent. As long as they're
not written to by either processes, they shouldn't be paged out.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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