linux-kernel - Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key faults

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:	Mon, 28 Sep 2015 07:59:07 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/26] x86, pkeys: notify userspace about protection key
 faults

* Dave Hansen <dave@...1.net> wrote:

> On 09/25/2015 11:20 PM, Ingo Molnar wrote:
> > * Dave Hansen <dave@...1.net> wrote:
> ...
> >> Since follow_pte() fails for all huge
> >> pages, it just falls back to pulling the protection key out of the VMA,
> >> which _does_ work for huge pages.
> > 
> > That might be true for explicit hugetlb vmas, but what about transparent hugepages 
> > that can show up in regular vmas?
> 
> All PTEs (large or small) established under a given VMA have the same
> protection key. [...]

So a 'pte' is only small. The 'large' thing is called a pmd. So follow_pte() is 
not adequate. But with that removed everything should be fine as the vma 
(protection) flags are size independent.

> So I think it's safe to rely on the VMA entirely.  Well, as least as safe as the 
> PTE.  It's definitely a wee bit racy, which I'll elaborate on when I repost the 
> patches.

So the race I can see is wrt. mprotect(), and we should fix that, because the 
existing method of recovering the 'page fault reason', error_code, is not racy - 
so the extension of it (the protection key) should not be racy either.

By the time user-space processes the signal we might race with other threads, but 
at least the fault-address/error-reason information itself should be coherent.

This can be solved by getting the protection key while still under the down_read() 
of the vma - instead of your current solution of a second find_vma().

Thanks,

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