Re: [PATCH v2] devtmpfs: mount with noexec and nosuid

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> > 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