[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878shuzhcx.fsf@nanos.tec.linutronix.de>
Date: Thu, 14 May 2020 17:06:06 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Alexandre Chartre <alexandre.chartre@...cle.com>,
Frederic Weisbecker <frederic@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Petr Mladek <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
Joel Fernandes <joel@...lfernandes.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Brian Gerst <brgerst@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Will Deacon <will@...nel.org>
Subject: Re: [patch V4 part 4 02/24] x86/int3: Avoid atomic instrumentation
Peter Zijlstra <peterz@...radead.org> writes:
> On Thu, May 14, 2020 at 02:51:32PM +0200, Thomas Gleixner wrote:
>> Peter Zijlstra <peterz@...radead.org> writes:
>> > On Wed, May 13, 2020 at 09:57:52PM -0700, Andy Lutomirski wrote:
>> >> On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>> >> >
>> >> > From: Peter Zijlstra <peterz@...radead.org>
>> >> >
>> >> > Use arch_atomic_*() and READ_ONCE_NOCHECK() to ensure nothing untoward
>> >> > creeps in and ruins things.
>> >> >
>> >> > That is; this is the INT3 text poke handler, strictly limit the code
>> >> > that runs in it, lest it inadvertenly hits yet another INT3.
>> >>
>> >>
>> >> Acked-by: Andy Lutomirski <luto@...nel.org>
>> >>
>> >> Does objtool catch this error?
>> >
>> > It does not. I'll put it on the (endless) todo list..
>>
>> Well, at least it detects when that code calls out into something which
>> is not in the non-instrumentable section.
>
> True, but the more specific problem is that noinstr code can use
> jump_label/static_call just fine.
>
> So a more specific test is validating none of that happens in the INT3
> handler before poke_int3_handler(). Which is what I think Andy was
> after.
Indeed. Forgot about that one.
Hmm, alternatives and jumplabel patch locations in entry.text and
noinstr.text can be valid at least during early boot where we know that
we don't run those code pathes...
Thanks,
tglx
Powered by blists - more mailing lists