linux-kernel - Re: [patch 0/5] Support for sanitization flag in low-level page allocator

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090530075033.GL29711@oblivion.subreption.com>
Date:	Sat, 30 May 2009 00:50:33 -0700
From:	"Larry H." <research@...reption.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Ingo Molnar <mingo@...e.hu>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>, linux-mm@...ck.org,
	Ingo Molnar <mingo@...hat.com>, pageexec@...email.hu,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

On 10:35 Sat 30 May     , Pekka Enberg wrote:
> The GFP_SENSITIVE flag looks like a big hammer that we don't really
> need IMHO. It seems to me that most of the actual call-sites (crypto
> code, wireless keys, etc.) should probably just use kzfree()
> unconditionally to make sure we don't leak sensitive data. I did not
> look too closely but I don't think any of the sensitive kfree() calls
> are in fastpaths so the performance impact is negligible.

That's hopeless, and kzfree is broken. Like I said in my earlier reply,
please test that yourself to see the results. Whoever wrote that ignored
how SLAB/SLUB work and if kzfree had been used somewhere in the kernel
before, it should have been noticed long time ago.

It's called disregard when you ditch something in favor of something
else you have assumed to be better, when it isn't. That's not polite.

Furthermore, selective clearing doesn't solve the roots of the problem.
It's just adding bandages to a wound which never stops bleeding. I
proposed an initial page flag because we could use it later for
unconditional page clearing doing a one line change in a header file.

I see a lot of speculation on what works and what doesn't, but
there isn't much on the practical side of things, yet. I provided test
results that proved some of the comments wrong, and I've referenced
literature which shows the reasoning behind all this. What else can I do
to make you understand you are missing the point here?

	Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/