[Cryptography] Swap space (Re: It's all K&R's fault)

[Tom Mitchell]

On Thu, Apr 24, 2014 at 10:50 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> Nemo <nemo at self-evident.org> writes:
>
>>Well, Windows does not use fork()+exec(); it uses spawn() and its variants.
>>Hence it avoids the whole vfork() / "memory overcommit" mess.
>
> Aren't many fork()s now pretty close to vfork(), via COW?

COW (copy on write) is an interesting topic for this forum.

The fork(); exec() pair is mostly safe with the interesting
detail bits about effective user and group ID transitions.
The exec(ed) process only gets args but no data pages,
open files and stuff.

COW does imply a book keeping entry reserving space for
any page that _might_ be written to and thus needing real resources
in RAM (as enabled by the sum of RAM and  swap system shared commons).

However:
Not all programs are exec(ed) in some cases the serious
work of the process is done by the fork(ed) child.   That
child does have ALL the data pages open files etc of the parent and
in the case of security credentials that data persists too.
Some programmers will carefully fiddle with effective UID and GID but
might ignore data that trains along behind especially via lib*  data.

The fork(only) context is valuable because on exit() additional connection
and additional data go poof.   Same for things that might make a process
crash and thus isolate the damage enabling a daemon to be long lived.

There is no notification to the list of library activities on fork() so
the programmer must know about and manage any sensitive data
his libraries might own or need or no longer need.

It is this library vector that may be interesting.

The Windows world is another pile of work.

And, I do not have it all sorted out.
What other common OS models need to be inspected besides Android(s)?











-- 
  T o m    M i t c h e l l
×