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] [thread-next>] [day] [month] [year] [list]
Message-ID: <03e51c6072d80931a6b532ce1d4d7388a6f84d32.camel@redhat.com>
Date:   Wed, 30 Aug 2023 12:45:22 -0400
From:   Radu Rendec <rrendec@...hat.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
        x86@...nel.org, Andreas Herrmann <aherrmann@...e.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Chen Yu <yu.c.chen@...el.com>, Len Brown <len.brown@...el.com>,
        Pierre Gondois <Pierre.Gondois@....com>,
        Pu Wen <puwen@...on.cn>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Will Deacon <will@...nel.org>, Zhang Rui <rui.zhang@...el.com>,
        stable@...r.kernel.org, Ricardo Neri <ricardo.neri@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 1/3] cacheinfo: Allocate memory for memory if not
 done from the primary CPU

On Wed, 2023-08-30 at 16:47 +0100, Sudeep Holla wrote:
> On Wed, Aug 30, 2023 at 08:13:09AM -0400, Radu Rendec wrote:
> > On Wed, 2023-08-30 at 12:49 +0100, Sudeep Holla wrote:
> > > On Fri, Aug 04, 2023 at 06:24:19PM -0700, Ricardo Neri wrote:
> > > > Commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")
> > > > adds functionality that architectures can use to optionally allocate and
> > > > build cacheinfo early during boot. Commit 6539cffa9495 ("cacheinfo: Add
> > > > arch specific early level initializer") lets secondary CPUs correct (and
> > > > reallocate memory) cacheinfo data if needed.
> > > > 
> > > > If the early build functionality is not used and cacheinfo does not need
> > > > correction, memory for cacheinfo is never allocated. x86 does not use the
> > > > early build functionality. Consequently, during the cacheinfo CPU hotplug
> > > > callback, last_level_cache_is_valid() attempts to dereference a NULL
> > > > pointer:
> > > > 
> > > >      BUG: kernel NULL pointer dereference, address: 0000000000000100
> > > >      #PF: supervisor read access in kernel mode
> > > >      #PF: error_code(0x0000) - not present page
> > > >      PGD 0 P4D 0
> > > >      Oops: 0000 [#1] PREEPMT SMP NOPTI
> > > >      CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1
> > > >      RIP: 0010: last_level_cache_is_valid+0x95/0xe0a
> > > > 
> > > > Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback if
> > > > not done earlier.
> > > > 
> > > > Cc: Andreas Herrmann <aherrmann@...e.com>
> > > > Cc: Catalin Marinas <catalin.marinas@....com>
> > > > Cc: Chen Yu <yu.c.chen@...el.com>
> > > > Cc: Len Brown <len.brown@...el.com>
> > > > Cc: Radu Rendec <rrendec@...hat.com>
> > > > Cc: Pierre Gondois <Pierre.Gondois@....com>
> > > > Cc: Pu Wen <puwen@...on.cn>
> > > > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
> > > > Cc: Sudeep Holla <sudeep.holla@....com>
> > > > Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
> > > > Cc: Will Deacon <will@...nel.org>
> > > > Cc: Zhang Rui <rui.zhang@...el.com>
> > > > Cc: linux-arm-kernel@...ts.infradead.org
> > > > Cc: stable@...r.kernel.org
> > > > Acked-by: Len Brown <len.brown@...el.com>
> > > > Fixes: 6539cffa9495 ("cacheinfo: Add arch specific early level initializer")
> > > 
> > > Not sure if we strictly need this(details below), but I am fine either way.
> > > 
> > > > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
> > > > ---
> > > > The motivation for commit 5944ce092b97 was to prevent a BUG splat in
> > > > PREEMPT_RT kernels during memory allocation. This splat is not observed on
> > > > x86 because the memory allocation for cacheinfo happens in
> > > > detect_cache_attributes() from the cacheinfo CPU hotplug callback.
> > > > 
> > > > The dereference of a NULL pointer is not observed today because
> > > > cache_leaves(cpu) is zero until after init_cache_level() is called (also
> > > > during the CPU hotplug callback). Patch2 will set it earlier and the NULL-
> > > > pointer dereference will be observed.
> > > 
> > > Right, this is the information I have been asking in the previous versions.
> > > This clarifies a lot. The trigger is in the patch 2/3 which is why it didn't
> > > make complete sense to me without it when you posted this patch independently.
> > > Thanks for posting it together and sorry for the delay(both reviewing this
> > > and in understanding the issue).
> > > 
> > > Given the trigger for NULL pointer dereference is in 2/3, I am not sure
> > > if it is really worth applying this to all the stable kernels with the
> > > commit 5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU").
> > > That is the reason why I asked to drop fixes tag if you agree with me.
> > > It is simple fix, so I am OK if you prefer to see that in the stable kernels
> > > as well.
> > 
> > Thanks for reviewing, Sudeep. Since my previous commit 6539cffa9495
> > ("cacheinfo: Add arch specific early level initializer") opens a door
> > for the NULL pointer dereference, I would sleep better at night if the
> > fix was included in the stable kernels :) But seriously, I am concerned
> > that with the fix applied in mainline and not in stable, something else
> > could be backported to the stable in the future, that could trigger the
> > NULL pointer dereference there. Ricardo's patch 2/3 is one way to
> > trigger it, but you never know what other patch lands in mainline in
> > the future that assumes it's safe to set the cache leaves earlier.
> > 
> 
> Fair enough. I agree with you, so please retain the fixes tag as is.
> Please work with x86 maintainers to get it merged along with other patches.
> Let me know if you have other plans.

Thanks, Sudeep. Technically, these are Ricardo's patches, so I will let
him engage with the x86 maintainers and drive the integration work. But
the plan looks good to me, and I will stand by and offer any support
may be needed for the fix patch.

--
Regards,
Radu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ