lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160130153053.GA4859@amd>
Date:	Sat, 30 Jan 2016 16:30:54 +0100
From:	Pavel Machek <pavel@...x.de>
To:	Laura Abbott <labbott@...hat.com>
Cc:	Laura Abbott <labbott@...oraproject.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Michal Hocko <mhocko@...e.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
	Kees Cook <keescook@...omium.org>, linux-pm@...r.kernel.org
Subject: Re: [PATCHv2 2/2] mm/page_poisoning.c: Allow for zero poisoning

Hi!

> >>By default, page poisoning uses a poison value (0xaa) on free. If this
> >>is changed to 0, the page is not only sanitized but zeroing on alloc
> >>with __GFP_ZERO can be skipped as well. The tradeoff is that detecting
> >>corruption from the poisoning is harder to detect. This feature also
> >>cannot be used with hibernation since pages are not guaranteed to be
> >>zeroed after hibernation.
> >
> >So... this makes kernel harder to debug for performance advantage...?
> >If so.. how big is the performance advantage?

> 
> The performance advantage really depends on the benchmark you are
> running.

You are trying to improve performance, so you should publish at least
one benchmark where it helps.

Alternatively, quote kernel build times with and without the
patch.

If it speeds kernel compile twice, I guess I may even help with
hibernation support. If it makes kernel compile faster by .00000034%
(or slows it down), we should probably simply ignore this patch.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ