linux-kernel - Re: [PATCH] x86: Fix /proc/cpuinfo cpumask warning

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: <20221012065154.p6mn35sy7fynkwdi@kamzik>
Date:   Wed, 12 Oct 2022 08:51:54 +0200
From:   Andrew Jones <ajones@...tanamicro.com>
To:     Yury Norov <yury.norov@...il.com>
Cc:     Borislav Petkov <bp@...en8.de>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH] x86: Fix /proc/cpuinfo cpumask warning

On Tue, Oct 11, 2022 at 12:02:26PM -0700, Yury Norov wrote:
> On Tue, Oct 11, 2022 at 11:17 AM Andrew Jones <ajones@...tanamicro.com> wrote:
> >
> > On Tue, Oct 11, 2022 at 08:01:03PM +0200, Borislav Petkov wrote:
> > > On Tue, Oct 11, 2022 at 07:50:31PM +0200, Andrew Jones wrote:
> > > > Upcoming cpumask changes will start issuing warnings[*] when cpu
> > >
> > > What upcoming changes?
> > >
> > > This needs a concrete pointer to a commit or so.
> >
> > Hi Boris,
> >
> > Sorry, I should have pointed this out. The upcoming change is
> >
> > linux-next/master commit a314123c8bdb ("cpumask: fix checking valid cpu
> > range")
> >
> > And also an ongoing discussion here
> > https://lore.kernel.org/lkml/20221011170949.upxk3tcfcwnkytwm@kamzik/
> >
> > I'm hoping that Yury will pick these patches up and integrate
> > them at the front of his series when introducing the warnings.
> > I wasn't sure how to call that out other than with the generic
> > "upcoming change".
> >
> > >
> > > > indices equal to nr_cpu_ids are passed to cpumask_next* functions.
> > >
> > > How do those indices get passed here? I think you need to explain how
> > > exactly this happens.
> 
> The cpumask_check() fix is already in master. Because of some mess in

Ah, it's already in master. I should have checked that...

> cpumask, cpumask_check() was broken for quite a long time, and didn't
> bark when passed with an out-of-range CPU.
> 
> I fixed some false-positives and sent those fixes together with a314123c8bdb.
> Now, I expect that people will see warnings generated by correct
> cpumask_check().
> This is actually the first sign.
> 
> Andrew, can you please answer Borislav's question:

I answered in the discussion[1], but I'll send a v2 of this patch,
properly based on master, with a proper pointer to commit 78e5a3399421
("cpumask: fix checking valid cpu range"), and also with a condensed
analysis for justification in the commit message.

Thanks,
drew

> 
> > > How do those indices get passed here? I think you need to explain how
> > > exactly this happens.
> 
> It might be either an expected behaviour, and then there should be a great
> explanation on how and why things work in the subsystem.
> 
> Or it might be an error in the caller. In that case, the caller must be fixed.
> 
> Thanks,
> Yury