Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230619100121.27534-1-puranjay12@gmail.com> <20230619100121.27534-4-puranjay12@gmail.com>
 <ZJMXqTffB22LSOkd@FVFF77S0Q05N> <CANk7y0h5ucxmMz4K8sGx7qogFyx6PRxYxmFtwTRO7=0Y=B4ugw@mail.gmail.com>
 <ZJQE9PIjxuA3Q8Sm@FVFF77S0Q05N>
In-Reply-To: <ZJQE9PIjxuA3Q8Sm@FVFF77S0Q05N>
From:   Puranjay Mohan <puranjay12@gmail.com>
Date:   Thu, 22 Jun 2023 10:47:08 +0200
Message-ID: <CANk7y0jtm9yYobPLsMEHAem+R-wKjVOLWo=EeU-bojYks9tetQ@mail.gmail.com>
Subject: Re: [PATCH bpf-next v3 3/3] bpf, arm64: use bpf_jit_binary_pack_alloc
To:     Mark Rutland <mark.rutland@arm.com>
Cc:     ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
        martin.lau@linux.dev, song@kernel.org, catalin.marinas@arm.com,
        bpf@vger.kernel.org, kpsingh@kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Mark,

On Thu, Jun 22, 2023 at 10:23=E2=80=AFAM Mark Rutland <mark.rutland@arm.com=
> wrote:
>
> On Wed, Jun 21, 2023 at 10:57:20PM +0200, Puranjay Mohan wrote:
> > On Wed, Jun 21, 2023 at 5:31=E2=80=AFPM Mark Rutland <mark.rutland@arm.=
com> wrote:
> > > On Mon, Jun 19, 2023 at 10:01:21AM +0000, Puranjay Mohan wrote:
> > > > @@ -1562,34 +1610,39 @@ struct bpf_prog *bpf_int_jit_compile(struct=
 bpf_prog *prog)
> > > >
> > > >       /* 3. Extra pass to validate JITed code. */
> > > >       if (validate_ctx(&ctx)) {
> > > > -             bpf_jit_binary_free(header);
> > > >               prog =3D orig_prog;
> > > > -             goto out_off;
> > > > +             goto out_free_hdr;
> > > >       }
> > > >
> > > >       /* And we're done. */
> > > >       if (bpf_jit_enable > 1)
> > > >               bpf_jit_dump(prog->len, prog_size, 2, ctx.image);
> > > >
> > > > -     bpf_flush_icache(header, ctx.image + ctx.idx);
> > > > +     bpf_flush_icache(ro_header, ctx.ro_image + ctx.idx);
> > >
> > > I think this is too early; we haven't copied the instructions into th=
e
> > > ro_header yet, so that still contains stale instructions.
> > >
> > > IIUC at the whole point of this is to pack multiple programs into sha=
red ROX
> > > pages, and so there can be an executable mapping of the RO page at th=
is point,
> > > and the CPU can fetch stale instructions throught that.
> > >
> > > Note that *regardless* of whether there is an executeable mapping at =
this point
> > > (and even if no executable mapping exists until after the copy), we a=
t least
> > > need a data cache clean to the PoU *after* the copy (so fetches don't=
 get a
> > > stale value from the PoU), and the I-cache maintenance has to happeon=
 the VA
> > > the instrutions will be executed from (or VIPT I-caches can still con=
tain stale
> > > instructions).
> >
> > Thanks for catching this, It is a big miss from my side.
> >
> > I was able to reproduce the boot issue in the other thread on my
> > raspberry pi. I think it is connected to the
> > wrong I-cache handling done by me.
> >
> > As you rightly pointed out: We need to do bpf_flush_icache() after
> > copying the instructions to the ro_header or the CPU can run
> > incorrect instructions.
> >
> > When I move the call to bpf_flush_icache() after
> > bpf_jit_binary_pack_finalize() (this does the copy to ro_header), the
> > boot issue
> > is fixed. Would this change be enough to make this work or I would
> > need to do more with the data cache as well to catch other
> > edge cases?
>
> AFAICT, bpf_flush_icache() calls flush_icache_range(). Despite its name,
> flush_icache_range() has d-cache maintenance, i-cache maintenance, and co=
ntext
> synchronization (i.e. it does everything necessary).
>
> As long as you call that with the VAs the code will be executed from, tha=
t
> should be sufficient, and you don't need to do any other work.

Thanks for explaining this.
After reading your explanation, I feel this should work.

bpf_jit_binary_pack_finalize() will copy the instructions from
rw_header to ro_header.
After the copy, calling bpf_flush_icache(ro_header, ctx.ro_image +
ctx.idx); will invalidate the caches
for the VAs in the ro_header, this is where the code will be executed from.

I will send the v4 patchset with this change.

Thanks,
Puranjay