[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161109004757.lpbpsdgyzvld7ute@x>
Date: Tue, 8 Nov 2016 16:47:57 -0800
From: Josh Triplett <josh@...htriplett.org>
To: Kees Cook <keescook@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Petr Mladek <pmladek@...e.com>,
Thomas Garnier <thgarnie@...gle.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Zefan Li <lizefan@...wei.com>,
Li Bin <huawei.libin@...wei.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Ralf Baechle <ralf@...ux-mips.org>,
Alex Thorlton <athorlton@....com>,
Michal Hocko <mhocko@...e.com>,
Mateusz Guzik <mguzik@...hat.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
John Stultz <john.stultz@...aro.org>,
Al Viro <viro@...iv.linux.org.uk>, Zach Brown <zab@...hat.com>,
Anna Schumaker <Anna.Schumaker@...app.com>,
Dave Hansen <dave.hansen@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall
On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote:
> On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett <josh@...htriplett.org> wrote:
> > Some embedded systems can do without the prctl syscall, saving some
> > space.
> >
> > This also avoids regular increases in tinyconfig size as people add more
> > non-optional functionality to prctl (observed via the 0-day kernel
> > infrastructure).
> >
> > bloat-o-meter results:
> >
> > add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-2143 (-2143)
> > function old new delta
> > offsets 23 12 -11
> > prctl_set_auxv 97 - -97
> > sys_prctl 794 - -794
> > prctl_set_mm 1241 - -1241
> > Total: Before=1902583, After=1900440, chg -0.11%
> >
> > Signed-off-by: Josh Triplett <josh@...htriplett.org>
>
> I'm absolutely a fan of doing this, but I wonder how this interacts
> with the LSMs that define prctl hooks, etc. I wouldn't expect a system
> that didn't want prctl to want an LSM, but maybe the LSMs all need to
> depend on CONFIG_PRCTL now?
I did think about that (as well as SECCOMP), but I did confirm that the
kernel builds fine with allyesconfig minus CONFIG_PRCTL. An LSM that
wants to restrict access to some prctls should be fine with no process
having any access to prctl. :) Beyond that, anything wanting
configuration via LSM (such as SECCOMP) still exists and functions, even
if you can't access it from outside the kernel.
Powered by blists - more mailing lists