[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180316165239.GA28462@redhat.com>
Date: Fri, 16 Mar 2018 17:52:39 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Erica Bugden <ebugden@...icios.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: uprobes misses breakpoint insertion into VM_WRITE mappings
On 03/15, Mathieu Desnoyers wrote:
>
> Hi,
>
> Erica has been working on extending test-cases for uprobes, and found
> something unexpected:
>
> Since commit e40cfce626a5 "uprobes: Restrict valid_vma(false) to skip VM_SHARED vmas"
> uprobes does not insert breakpoints into mappings mprotect'd as writeable.
Not really, VM_WRITE was illegal from the very beginning, this commit only
affects the "is_register == false" case.
> This issue can be reproduced by compiling a library without PIC (not using GOT),
> and then concurrently:
>
> A) Load the library (dynamic loader mprotect the code as writeable to do
> the relocations, and then mprotect as executable),
>
> B) Enable a uprobe through perf.
>
> (it is a race window between the two mprotect syscalls)
>
> It appears that the following restriction in valid_vma() is responsible
> for this behavior:
>
> if (is_register)
> flags |= VM_WRITE;
>
> I don't figure a clear explanation for this flag based on the function
> comment nor the commit changelog. Any idea on whether this is really
> needed ?
Because we do not want to modify the writable area. If nothing else, this
can break the application which writes to the page we are going to replace.
> Note that on uprobes unregister, it allows removing a breakpoint event
> on a writeable mapping,
Yes. Because a probed apllication can do mprotect() after the kernel installs
the breakpoint. And we have to remove this breakpoint in any case, even if
this is unsafe too.
Oleg.
Powered by blists - more mailing lists