Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 May 2019 12:02:39 -0700
From: Kees Cook <>
To: Alexander Potapenko <>
Cc: Andrew Morton <>, Christoph Lameter <>, 
	Kees Cook <>, Laura Abbott <>, 
	Linux-MM <>, 
	linux-security-module <>, 
	Kernel Hardening <>, 
	Masahiro Yamada <>, James Morris <>, 
	"Serge E. Hallyn" <>, Nick Desaulniers <>, 
	Kostya Serebryany <>, Dmitry Vyukov <>, Sandeep Patil <>, 
	Randy Dunlap <>, Jann Horn <>, 
	Mark Rutland <>
Subject: Re: [PATCH 1/4] mm: security: introduce init_on_alloc=1 and
 init_on_free=1 boot options

On Wed, May 8, 2019 at 8:38 AM Alexander Potapenko <> wrote:
> The new options are needed to prevent possible information leaks and
> make control-flow bugs that depend on uninitialized values more
> deterministic.

I like having this available on both alloc and free. This makes it
much more configurable for the end users who can adapt to their work
loads, etc.

> Linux build with -j12, init_on_free=1:  +24.42% sys time (st.err 0.52%)
> [...]
> Linux build with -j12, init_on_alloc=1: +0.57% sys time (st.err 0.40%)

Any idea why there is such a massive difference here? This seems to
high just for cache-locality effects of touching all the freed pages.

Kees Cook

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.