On November 8, 2016 4:56:54 PM PST, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >On Tue, Nov 8, 2016 at 4:47 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> >wrote: >> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> >>> >>> 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. > >Okay, testing that is good, thanks. > >Seccomp can use the seccomp() syscall, so missing prctl isn't a big >deal there. > >Things like Yama, though, are almost useless in the !PRCTL case. I >think a "depends on PRCTL" should be added at least to Yama. All the >other LSMs are configured in other ways, and they'll just have some >dead code around their prctl hooks; no big deal. OK, I'll add that dependency to Yama in v2. >This does also beg the question about how to configure some process >behaviors by default if PRCTL is disabled, but if people want those >things, they can write patches, I would think. :) Agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html