linux-kernel - Re: [PATCH]: exec: avoid propagating PF_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131128145115.GF3925@htj.dyndns.org>
Date:	Thu, 28 Nov 2013 09:51:15 -0500
From:	Tejun Heo <htejun@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, zhang.yi20@....com.cn,
	lkml <linux-kernel@...r.kernel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into
 userspace child

On Thu, Nov 28, 2013 at 03:47:14PM +0100, Peter Zijlstra wrote:
> Bah, windows mentality of we know better.
> 
> If they do stupid they get stupid; the only thing we should be concerned
> about is correctness, they shouldn't be able to crash the system.

It isn't about that we know better but more that we do not want to
leak implementation details to userland.  "Whatever isn't crashing is
okay" doesn't work because we aren't supposed to change behaviors
which are depended upon from userland.  Unless what's exposed is
actively managed, we end up being locked into specific unintended
characteristics of the current implementation.  It hurts both the
kernel and userland.  We end up having to hack around silly
constraints in the future and userland gets surprised when such hacks
inevitably falls apart in corner cases.

So, no, it's not about which part knows better or windows mentaility.
It's about having proper separation between implementation details and
exposed interface.

Thanks.

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