linux-kernel - Re: BPF: failed module verification on linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210526081511.GX30378@techsingularity.net>
Date:   Wed, 26 May 2021 09:15:11 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Michal Such?nek <msuchanek@...e.de>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Networking <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Hritik Vijay <hritikxx8@...il.com>
Subject: Re: BPF: failed module verification on linux-next

> On Tue, May 25, 2021 at 6:51 AM Mel Gorman <mgorman@...hsingularity.net> wrote:
> >
> > On Mon, May 24, 2021 at 03:58:29PM -0700, Andrii Nakryiko wrote:
> > > > It took me a while to reliably bisect this, but it clearly points to
> > > > this commit:
> > > >
> > > > e481fac7d80b ("mm/page_alloc: convert per-cpu list protection to local_lock")
> > > > <SNIP>
> > >
> > > Ok, so nothing weird about them. local_lock_t is designed to be
> > > zero-sized unless CONFIG_DEBUG_LOCK_ALLOC is defined.
> > >
> > > But such zero-sized per-CPU variables are confusing pahole during BTF
> > > generation, as now two different variables "occupy" the same address.
> > >
> > > Given this seems to be the first zero-sized per-CPU variable, I wonder
> > > if it would be ok to make sure it's never zero-sized, while pahole
> > > gets fixed and it's latest version gets widely packaged and
> > > distributed.
> > >
> > > Mel, what do you think about something like below? Or maybe you can
> > > advise some better solution?
> > >
> >
> > Ouch, something like that may never go away. How about just this?
> 
> Yeah, that would work just fine, thanks! Would you like me to send a
> formal patch or you'd like to do it?
> 

Thanks Andrii for bisecting and debugging this, I used your analysis in
the changelog which I hope is ok. For future mailing list searches based
on the same bug, I sent a formal patch

https://lore.kernel.org/r/20210526080741.GW30378@techsingularity.net

> > diff --git a/scripts/rust-version.sh b/scripts/rust-version.sh
> > old mode 100644
> > new mode 100755
> 
> Probably didn't intend to include this?
> 

That was an oversight when applying Andrew's mmotm tree which missed
setting the permissions on rust-version.sh and broke build.

-- 
Mel Gorman
SUSE Labs