[RFCv2 4/7] bpf/kexec: Introduce three bpf kfunc for kexec
Pingfan Liu
piliu at redhat.com
Mon May 5 17:37:50 PDT 2025
Hi Alexei,
Sorry to reply late since I just got back from holiday.
On Thu, May 1, 2025 at 12:16 AM Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
>
> On Wed, Apr 30, 2025 at 3:47 AM Pingfan Liu <piliu at redhat.com> wrote:
> >
> > On Wed, Apr 30, 2025 at 8:04 AM Alexei Starovoitov
> > <alexei.starovoitov at gmail.com> wrote:
> > >
[...]
> >
> > Thanks for your suggestion. I originally considered using these kfuncs
> > only in kexec context (Later, introducing a dedicated BPF_PROG_TYPE
> > for kexec).
>
> We do not add new prog types anymore.
> They're frozen just like the list of helpers.
>
Got it.
> > They are placed under a lock so that a malice attack can
> > not exhaust the memory through repeatedly calling to the decompress
> > kfunc.
>
> attack? This is all root only anyway and all memory is counted
> towards memcg.
> Make sure to use GFP_KERNEL_ACCOUNT and something similar
> to bpf_map_get_memcg.
>
Your clarification makes sense. I will follow that guide.
> > To generalize these kfunc, I think I can add some boundary control of
> > the memory usage to prevent such attacks.
>
> Don't reinvent the wheel. memcg is the mechanism.
>
Sure. Thanks for your insight. It is helpful.
Best Regards,
Pingfan
> > > They also must be KF_SLEEPABLE.
> > > Please test your patches with all kernel debugs enabled.
> > > Otherwise you would have seen all these "sleeping while atomic"
> > > issues yourself.
> > >
> >
> > See, I will have all these debug options for the V3 test.
> >
> > Appreciate your insight.
> >
> > Regards,
> >
> > Pingfan
> >
>
More information about the kexec
mailing list