Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
flat view
From: Michal Hocko <mhocko@kernel.org>
Date: 2019-06-27 06:15:40
Also in:
linux-mm
On Wed 26-06-19 13:23:34, Kees Cook wrote:
On Wed, Jun 26, 2019 at 02:15:49PM -0400, Qian Cai wrote:quoted
On Wed, 2019-06-26 at 14:19 +0200, Alexander Potapenko wrote:quoted
Both init_on_alloc and init_on_free default to zero, but those defaults can be overridden with CONFIG_INIT_ON_ALLOC_DEFAULT_ON and CONFIG_INIT_ON_FREE_DEFAULT_ON. [...] +static int __init early_init_on_alloc(char *buf) +{ + int ret; + bool bool_result; + + if (!buf) + return -EINVAL; + ret = kstrtobool(buf, &bool_result); + if (bool_result) + static_branch_enable(&init_on_alloc); + else + static_branch_disable(&init_on_alloc); + return ret; +} +early_param("init_on_alloc", early_init_on_alloc);Do those really necessary need to be static keys? Adding either init_on_free=0 or init_on_alloc=0 to the kernel cmdline will generate a warning with kernels built with clang. [ 0.000000] static_key_disable(): static key 'init_on_free+0x0/0x4' used before call to jump_label_init() [ 0.000000] WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:317 early_init_on_free+0x1c0/0x200 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.0-rc6-next-20190626+ #9 [ 0.000000] pstate: 60000089 (nZCv daIf -PAN -UAO)I think the issue here is that arm64 doesn't initialize static keys early enough.
This sounds familiar: http://lkml.kernel.org/r/CABXOdTd-cqHM_feAO1tvwn4Z=kM6WHKYAbDJ7LGfMvRPRPG7GA@mail.gmail.com -- Michal Hocko SUSE Labs