Extending MADV_PROTECT
Julian Elischer
julian at freebsd.org
Tue May 7 18:39:30 UTC 2013
On 5/7/13 11:33 AM, John Baldwin wrote:
> One of the issues I have with our current MADV_PROTECT is that it isn't very
> administrative-friendly. That is, as a sysadmin I can't easily protect
> arbitrary processes from the OOM killer. Instead, the binary has to be
> changed to invoke madvise(). Furthermore, once the protection is granted it
> can't be revoked. Also, any binaries that want this have to be run as root.
> Instead, I would like to be able to both set and revoke this for existing
> processes and possibly even allow it to be inherited (so I can tag a top-level
> daemon that forks and have all its future children be protected for example).
> To that end I've whipped up a simple patch (against 8, but should port to HEAD
> easily if folks think it is a good idea) to add a new pprotect() system call
> and userland program (protect) that can be used similar to ktrace(1) either as
> a modifier when running a new program or as a tool for setting or clearing
> protection for existing processes.
>
> The inherit feature isn't implemented yet, but it should be simple to do. One
> would simply need a new flag that PPROT_INHERIT sets that is checked on fork
> and propagates P_PROTECTED if it is set. Also, one other thought I had is
> that at some point we might want to make P_PROTECTED more fine-grained, e.g.
> by allowing for OOM "priorities". To that end, it may make sense to add a new
> argument to protect, though you could also reserve part of the 'op' parameter
> to encode a priority.
>
> The manpage for the proposed protect command is below, then the source of the
> command, then the patch to add pprotect():
>
> PROTECT(1) FreeBSD General Commands Manual PROTECT(1)
>
> NAME
> protect -- protect processes from being killed when swap space is
> exhausted
>
> SYNOPSIS
> protect [-i] command
> protect [-cdi] -g pgrp | -p pid
>
>
I like it but it does make it very easy to abuse.. (try protect
everything)
what kinds of limits can there be?
More information about the freebsd-arch
mailing list