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]

Date:	Sat, 23 May 2009 15:28:13 -0700
From:	"Larry H." <research@...reption.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	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>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, pageexec@...email.hu
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

On 14:49 Sat 23 May     , Ingo Molnar wrote:
> You need to address my specific concerns instead of referring back 
> to an earlier discussion. The patches touch code i maintain and i 
> find them (and your latest resend) unacceptable.

Meaning the latest boot option-based unconditional sanitization which
doesn't touch anything else and doesn't duplicate clearing (it only
performs such during release)?

> Naming _is_ a technical issue. Especially here.

True, that's no more of an issue since the page flag approach has been
left out of the patch (albeit it mutilates our possibilities to do
fine-grained clearing and track status across the different higher level
interfaces through the gfp flag). Do you still have a problem with
something related to naming?

If any of the variable names still don't catch your fancy, please let me
know.

> What you are missing is that your patch makes _no technical sense_ 
> if you allow the same information to leak over the kernel stack. 
> Kernel stacks can be freed and reused, swapped out and thus 
> 'exposed'.

Do you have technical evidence to back up that claim? Perhaps an
analysis and testcase that demonstrates true resilience of the kernel
stack information? Something that can convince me I'm mistaken by
showing that it isn't extremely volatile? That it doesn't get
overwritten to smithereens?

I have a simple testcase for vmalloc/kmalloc/page allocator
sanitization. The current patch covers both vmalloc and page allocators
well, since the former is basically dependent on the latter. kmalloc
still won't get sanitized until the slab is returned to the page
allocator (during cache shrink/reaping or when it becomes empty).

Also, a political question, are you the only current maintainer of the
affected code, or there are more people who might not necessarily share
your opinion on this?

	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/