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, 30 May 2009 10:25:15 -0700
From:	"Larry H." <research@...reption.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, pageexec@...email.hu,
	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>, linux-mm@...ck.org,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

Done. I just tested with different 'leak' sizes on a kernel patched with
the latest memory sanitization patch and the kfree/kmem_cache_free one:

	10M	- no occurrences with immediate scanmem
	40M	- no occurrences with immediate scanmem
	80M	- no occurrences with immediate scanmem
	160M	- no occurrences with immediate scanmem
	250M	- no occurrences with immediate scanmem
	300M	- no occurrences with immediate scanmem
	500M	- no occurrences with immediate scanmem
	600M	- with immediate zeromem 600 and scanmem afterwards,
		 no occurrences.

The results are satisfactory to me. With the patch applied but
sanitization disabled, a single megabyte test produces 54 occurrences
time after we ran secretleak. With higher amounts of memory, it gets
ridiculous.

I tested out of curiosity how the number of occurrences evolved through
different intervals on a sanitize-disabled system for a 10M leak:

2145
2128
2121
2118
2055
2046
2046
2046
2046
2045

That's under relatively idle work load. Until a larger size allocation
is requested somewhere else, the data is still there. The sad thing
about this, is that a website could be able to force Firefox, for
example, into allocating large amounts of memory (using Javascript, some
plugin, etc) and ensure that any cryptographic secrets previously used
in the browser will remain there even after it has been closed. The
unlikeliness of having such data disappear is directly proportional to
the size of the memory used by the process during its runtime.

This applies to any application (OpenOffice, vim loading large files,
your IRC or silc client, your image editing software, etc).

	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/