linux-kernel - Re: [Qemu-devel] [PATCH 00/17] RFC: userfault v2

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: <20141121201415.GK4569@redhat.com>
Date:	Fri, 21 Nov 2014 21:14:15 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Peter Maydell <peter.maydell@...aro.org>
Cc:	zhanghailiang <zhang.zhanghailiang@...wei.com>,
	Robert Love <rlove@...gle.com>, Dave Hansen <dave@...1.net>,
	Jan Kara <jack@...e.cz>, kvm-devel <kvm@...r.kernel.org>,
	Neil Brown <neilb@...e.de>,
	Stefan Hajnoczi <stefanha@...il.com>,
	QEMU Developers <qemu-devel@...gnu.org>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Michel Lespinasse <walken@...gle.com>,
	Taras Glek <tglek@...illa.com>,
	Andrew Jones <drjones@...hat.com>,
	Juan Quintela <quintela@...hat.com>,
	Hugh Dickins <hughd@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	Android Kernel Team <kernel-team@...roid.com>,
	"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
	"Huangpeng (Peter)" <peter.huangpeng@...wei.com>,
	Andres Lagar-Cavilla <andreslc@...gle.com>,
	Christopher Covington <cov@...eaurora.org>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Keith Packard <keithp@...thp.com>,
	Wenchao Xia <wenchaoqemu@...il.com>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Minchan Kim <minchan@...nel.org>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Mike Hommey <mh@...ndium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Feiner <pfeiner@...gle.com>
Subject: Re: [Qemu-devel] [PATCH 00/17] RFC: userfault v2

Hi Peter,

On Wed, Oct 29, 2014 at 05:56:59PM +0000, Peter Maydell wrote:
> On 29 October 2014 17:46, Andrea Arcangeli <aarcange@...hat.com> wrote:
> > After some chat during the KVMForum I've been already thinking it
> > could be beneficial for some usage to give userland the information
> > about the fault being read or write
> 
> ...I wonder if that would let us replace the current nasty
> mess we use in linux-user to detect read vs write faults
> (which uses a bunch of architecture-specific hacks including
> in some cases "look at the insn that triggered this SEGV and
> decode it to see if it was a load or a store"; see the
> various cpu_signal_handler() implementations in user-exec.c).

There's currently no plan to deliver to userland read access
notifications of a present page, simply because the task of the
userfaultfd is to handle the page fault in userland, but if the page
is mapped and readable it won't fault in the first place :). I just
mean it's not like gdb read watch.

Even if the region would be set to PROT_NONE it would still SEGV
without triggering an userfault (after all pte_present would still
true because the page is still mapped despite not being readable, so
in any case it wouldn't be considered a not-present page fault).

If you temporarily remove the page (which requires an unavoidable TLB
flush also considering if the page was previously mapped the TLB could
still resolve it for reads) it would work then, because the plan is to
provide read/write fault information through the userfaultfd.

In theory it would be possible to deliver PROT_NONE faults through
userfault too but it doesn't make much sense because PROT_NONE still
requires a TLB flush, in addition to the vma
modifications/splitting/rbtree-rebalance and the mmap_sem for writing
as well.

Temporarily removing/moving the page with remap_anon_pages shall be
much better than using PROT_NONE for this (or alternative syscall name
to differentiate it further from remap_file_pages, or equivalent
userfaultfd command if we decide to hide the pte/pmd mangling as
userfaultfd commands instead of adding new standalone syscalls). It
would have the only constraint that you must mark the region
MADV_DONTFORK if you intend linux-user to ever fork or it won't work
reliably (that constraint is to eliminate the need of additional rmap
complexity, precisely so that it doesn't turn into something more
intrusive like remap_file_pages). I assume that would be a fine
constraint for linux-user.

Thanks,
Andrea
--
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/