>
>
> On Fri, 5 Mar 2010, [email protected] wrote:
> >
> > This patch makes it possible for userspace to implement setproctitle()
> > cleanly. It adds a new PR_SET_PROCTITLE_AREA option for prctl(), which
> > updates task's mm_struct->arg_start and arg_end to the given area.
>
> This looks overly complicated. Why do you change the whole locking rules,
> instead of protecting _only_ the "arg_start/arg_end" case?
>
> The thing is, there's no reason to hold the mmap_sem over the whole thing,
> and I don't think this is important enough to be a valid reason for
> exposing a whole new "locked" access variant, when a simple "protect just
> the arg_start/end" would handle it.
Hmm..
I did it at several previous iteration. but Alan and Oleg don't like such
approach. After small discussion, we concluded that this reusing mmap_sem
doesn't
have unignorable downside.
We discussed this patch need to conder following two performance worrieness.
Q1) The system doesn't have badboy process, it shouldn't have system
performance degression.
A1) In writer side, setproctitle() is not frequently called function.
then, performance damage is nothing. In reader side, this patch doesn't
add to take any new lock.
Q2) The attacker's process use setproctitle() for attack. The system
should have enough DoS tolerability.
A2) a lot of /proc file takes mmap_sem. then, this feature doesn't introduce
new attack way. plus, fork-bomb provide very efficient attack way rather
than mmap_sem flood. then, we concluded the attackers don't use mmap_sem
flood in practice.
However, reusing mmap_sem is not my strong mention. if you really dislike it,
I can change it soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
