Re: [PATCH v3 bpf-next 02/18] bpf: Add bpf_arch_text_poke() helper

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"x86@kernel.org" <x86@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v3 bpf-next 02/18] bpf: Add bpf_arch_text_poke() helper
Date: Fri, 8 Nov 2019 11:32:41 -0800	[thread overview]
Message-ID: <CAADnVQKmrVGVHM70OT0jc7reRp1LdWTM8dhE1Gde21oxw++jwg@mail.gmail.com> (raw)
In-Reply-To: <59d3af80-a781-9765-4d01-4c8006cd574f@fb.com>

On Fri, Nov 8, 2019 at 5:42 AM Alexei Starovoitov <ast@fb.com> wrote:
>
> On 11/8/19 1:36 AM, Peter Zijlstra wrote:
> > On Fri, Nov 08, 2019 at 10:11:56AM +0100, Peter Zijlstra wrote:
> >> On Thu, Nov 07, 2019 at 10:40:23PM -0800, Alexei Starovoitov wrote:
> >>> Add bpf_arch_text_poke() helper that is used by BPF trampoline logic to patch
> >>> nops/calls in kernel text into calls into BPF trampoline and to patch
> >>> calls/nops inside BPF programs too.
> >>
> >> This thing assumes the text is unused, right? That isn't spelled out
> >> anywhere. The implementation is very much unsafe vs concurrent execution
> >> of the text.
> >
> > Also, what NOP/CALL instructions will you be hijacking? If you're
> > planning on using the fentry nops, then what ensures this and ftrace
> > don't trample on one another? Similar for kprobes.
> >
> > In general, what ensures every instruction only has a single modifier?
>
> Looks like you didn't bother reading cover letter and missed a month
> of discussions between my and Steven regarding exactly this topic
> though you were directly cc-ed in all threads :(
> tldr for kernel fentry nops it will be converted to use
> register_ftrace_direct() whenever it's available.
> For all other nops, calls, jumps that are inside BPF programs BPF infra
> will continue modifying them through this helper.
> Daniel's upcoming bpf_tail_call() optimization will use text_poke as well.
>
>  > I'm very uncomfortable letting random bpf proglets poke around in the
> kernel text.
>
> 1. There is no such thing as 'proglet'. Please don't invent meaningless
> names.
> 2. BPF programs have no ability to modify kernel text.
> 3. BPF infra taking all necessary measures to make sure that poking
> kernel's and BPF generated text is safe.
> If you see specific issue please say so. We'll be happy to address
> all issues. Being 'uncomfortable' is not constructive.
>

I was thinking more about this.
Peter,
do you mind we apply your first patch:
https://lore.kernel.org/lkml/20191007081944.88332264.2@infradead.org/
to both tip and bpf-next trees?
Then I can use text_poke_bp() as-is without any additional ugliness
on my side that would need to be removed in few weeks.
Do you have it in tip already?
I can cherry-pick from there to make sure it's exactly the same commit log
then there will be no merge issues during merge window.