[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQKmrVGVHM70OT0jc7reRp1LdWTM8dhE1Gde21oxw++jwg@mail.gmail.com>
Date: Fri, 8 Nov 2019 11:32:41 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Alexei Starovoitov <ast@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"daniel@...earbox.net" <daniel@...earbox.net>,
"x86@...nel.org" <x86@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v3 bpf-next 02/18] bpf: Add bpf_arch_text_poke() helper
On Fri, Nov 8, 2019 at 5:42 AM Alexei Starovoitov <ast@...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.
Powered by blists - more mailing lists