Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

From
Josh Triplett <hidden>
Date
2016-11-09 00:48:16
Also in
lkml
Reply to
Kees Cook, 2016-11-09
On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote:
On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett [off-list ref] wrote:
quoted
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 <redacted>
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.
Thread (12 messages) 12 messages, 6 authors, last reply 2016-11-09
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help