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: <20090521184342.GI10756@oblivion.subreption.com>
Date:	Thu, 21 May 2009 11:43:42 -0700
From:	"Larry H." <research@...reption.com>
To:	Robin Holt <holt@....com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	linux-mm@...ck.org, Ingo Molnar <mingo@...hat.com>,
	pageexec@...email.hu
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

On 10:21 Thu 21 May     , Robin Holt wrote:
> I agree with the earlier.  If you know enough to set the flag, then
> you know enough to call a function which does a clear before free.
> Does seem like a waste of a page flag.

Again, place of allocation doesn't necessarily equal place of freeing,
and it's most normally never the same location. And those calls are
unnecessary code duplication and overhead which is suboptimal.

Would you also be willing to oversee the job of watching where these
calls will require placement, who uses them and how? The design decision
of forcing people to write extra code for clearing seems wasteful if you
can simply tell them to use a flag, which brings the same benefits at no
extra cost. Plus any future benefits if it's developed further more.

> That sounds like either a thread group flag or a VMA flag, not a page
> flag.  If you make it a page flag, you would still need to track it
> on the vma or process to handle the event where the page gets migrated
> or swapped out.  Really doesn't feel like a page flag is right, but I
> reserve the right to be wrong.

The patch adds a GFP flag and a slab flag for lookaside caches, both
tied to the lower level page flag. I've implemented a task flag for the
process sensitive marking but that one was kept out of the patchset to
keep it simple for now, and as clean and sane as possible. You are right
that this needs to be tracked down in other interfaces to avoid memory
from being swapped to disk, but I didn't want to include this in the
current patchset until I had positive feedback. Either way, those
changes are trivial.

Also, how would you track what memory is sensitive and what isn't? The
clearing only solves one of the issues here. Deterring data resilience
is far more than just zeroing a buffer.

I would like to request inclusion unless more substantial problems are
found with this patchset.

	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/