Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753917Ab2KUAS4 (ORCPT ); Tue, 20 Nov 2012 19:18:56 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:33421 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753264Ab2KUASz (ORCPT ); Tue, 20 Nov 2012 19:18:55 -0500 Date: Wed, 21 Nov 2012 00:24:12 +0000 From: Alan Cox To: Kees Cook Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , ellyjones@chromium.org, Kay Sievers , Roland Eggner Subject: Re: [PATCH v2] devtmpfs: mount with noexec and nosuid Message-ID: <20121121002412.1c957ad2@pyramind.ukuu.org.uk> In-Reply-To: References: <20121120204238.GA19554@www.outflux.net> <20121120211312.57f1b63d@pyramind.ukuu.org.uk> <20121120235353.3092c8d2@pyramind.ukuu.org.uk> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII= Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2292 Lines: 56 > > You just broke my bullshitometer > > > > It's a single syscall from your init binary, its microseconds. > > Whatever, I still see it as a needless inefficiency. As opposed to adding permanent kernel code and having to change the setting by recompilation, and not being able to deploy this with older kernels. Right now you can add one call to your user space and it just works, with old kernels, with new kernels, with Android etc. You think its *more efficient* to add permanently loaded kernel hacks. Wrong. Big time wrong. A page is 4096 bytes, your change is probably about 8. So 1 in 512 builds will see an extra page of kernel space used assuming an even distribution. For each of those users the moment they've had a few page faults your solution is *less* efficient, and the moment they've paged one page because of having less memory your solution has become vastly less efficient. So can we put the crap about efficiency away please. This basically reads like "Mummy, the mount syscall looks complicated let me hack everyones kernel with a crass extra Kconfig option because I'm crap" > > You don't want to stop mmap with PROT_EXEC on /dev/mem as that breaks a > > load of stuff, you want to stop people adding stuff to that file system > > and executing it. > > Well, initially the latter, yes. But as it turns out, setting noexec > also stops PROT_EXEC on /dev/mem. Since the systems I'm building for > all use KMS, there's no need to execute regions of /dev/mem (e.g. VESA > BIOS init, etc). I have news for you: this is the upstream kernel, you specific personal needs should not define what is good design - this isn't GNOME. If you block exec on anything but devices then all is happy. You could even block it on anything but specific devices. At that point you could get rid of the config option and make it more useful. We don't need extra confusion Kconfig options, we don't need extra kernel code combinations to fail to maintain. Your patch offers *NO* feature advantages over the existing kernel. NAK Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/