Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Jun 2019 08:15:34 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Qian Cai <cai@....pw>, Catalin Marinas <catalin.marinas@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Alexander Potapenko <glider@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Sandeep Patil <sspatil@...roid.com>,
	Laura Abbott <labbott@...hat.com>,
	Randy Dunlap <rdunlap@...radead.org>, Jann Horn <jannh@...gle.com>,
	Mark Rutland <mark.rutland@....com>, Marco Elver <elver@...gle.com>,
	linux-mm@...ck.org, linux-security-module@...r.kernel.org,
	kernel-hardening@...ts.openwall.com,
	clang-built-linux@...glegroups.com
Subject: Re: [PATCH v8 1/2] mm: security: introduce init_on_alloc=1 and
 init_on_free=1 boot options

On Wed 26-06-19 13:23:34, Kees Cook wrote:
> On Wed, Jun 26, 2019 at 02:15:49PM -0400, Qian Cai wrote:
> > On Wed, 2019-06-26 at 14:19 +0200, Alexander Potapenko wrote:
> > > 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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.