Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Déar 10 Lún 2017 at 17:36 Michal Hocko [off-list ref] wrote:

On Thu 10-08-17 15:23:05, Colm MacCįrthaigh wrote:

quoted

On Thu, Aug 10, 2017 at 3:05 PM, Michal Hocko [off-list ref] wrote:

quoted

quoted

Too late for that. VM_DONTFORK is already implemented
through MADV_DONTFORK & MADV_DOFORK, in a way that is
very similar to the MADV_WIPEONFORK from these patches.

Yeah, those two seem to be breaking the "madvise as an advise"

semantic as

quoted

quoted

well but that doesn't mean we should follow that pattern any further.

I would imagine that many of the crypto applications using
MADV_WIPEONFORK will also be using MADV_DONTDUMP. In cases where it's
for protecting secret keys, I'd like to use both in my code, for
example. Though that doesn't really help decide this.

There is also at least one case for being able to turn WIPEONFORK
on/off with an existing page; a process that uses privilege separation
often goes through the following flow:

1. [ Access privileged keys as a power user and initialize memory ]
2. [ Fork a child process that actually does the work ]
3. [ Child drops privileges and uses the memory to do work ]
4. [ Parent hangs around to re-spawn a child if it crashes ]

In that mode it would be convenient to be able to mark the memory as
WIPEONFORK in the child, but not the parent.

I am not sure I understand. The child will have an own VMA so chaging
the attribute will not affect parent. Or did I misunderstand your
example?

Typically with privilege separation the parent has to share some minimal
state with the child. In this case that's why the page is left alone.
Though a smart parent could unset and set just immediately around the fork.

The point then of protecting it in the child is to ensure that a grandchild
doesn't inherit the secret data.

-- 
Colm