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:	Thu, 21 May 2009 20:26:28 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Rik van Riel <riel@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"Larry H." <research@...reption.com>, 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

> You don't always know this at page free time.

You do at buffer free time.

> I could see the PG_sensitive flag being used from
> userspace through mmap or madvise flags.  This way
> the sensitive memory from a program like gpg would
> be cleaned, even if gpg died in a segfault accident.

Still doesn't need a page flag - that is a vma flag which is far cheaper.
Also means you can get rid of the stupid mlock() misuse by things like
GPG to work around OS weaknesses by crypting the page if it hits
disk/swap/whatever.

> I could also imagine the suspend-to-disk code skipping
> PG_sensitive pages when storing data to disk, and
> replacing it with some magic signature so programs
> that use special PG_sensitive buffers can know that
> their crypto key disappeared after a restore.

Its irrelevant in the simple S2D case. I just patch other bits of the
suspend image to mail me the new key later. The right answer is crypted
swap combined with a hard disk password and thus a crypted and locked
suspend image. Playing the "I must not miss any page which might be
sensitive even compiler stack copies and library buffers I don't know
about" game is not going to build you a secure system - its simply
*lousy* engineering and design.

Basically though - loss of physical control means you have to assue the
recovered system is compromised. I doubt even TC is going to manage to
spot firmware compromises on your CD-ROM drive, which thanks to the film
industry creating a demand for altered firmware is a well understood
field...

The cost of doing crypto on suspend to disk relative to media speed is
basically irrelevant on a PC today. In the S2R case you might want to
crypt those pages against an electronic pure read of RAM type attack but
this is getting into serious spook territory.

--
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/