linux-kernel - Re: [PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo infrastructure

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: <20150311133647.GB4464@pd.tnic>
Date:	Wed, 11 Mar 2015 14:36:47 +0100
From:	Borislav Petkov <bp@...e.de>
To:	Sudeep Holla <sudeep.holla@....com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andre Przywara <Andre.Przywara@....com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v3] x86: move cacheinfo sysfs to generic cacheinfo
 infrastructure

On Tue, Mar 10, 2015 at 02:35:12PM +0000, Sudeep Holla wrote:
> My initial assumption was that it will be NULL for Intel processors
> and hence I assigned cacheinfo->priv to nb pointer unconditionally. So
> I don't have any strong opinion here.

Right, we need the NB descriptor on AMD to do L3-specific operations,
see amd_l3_disable_index() for an example.

IOW, I ended up committing this:

---
From: Sudeep Holla <sudeep.holla@....com>
Date: Wed, 11 Mar 2015 11:54:29 +0100
Subject: [PATCH] x86/cacheinfo: Fix cache_get_priv_group() for Intel
 processors

The private pointer provided by the cacheinfo code is used to implement
the AMD L3 cache-specific attributes using a pointer to the northbridge
descriptor. It is needed for performing L3-specific operations and for
that we need a couple of PCI devices and other service information, all
contained in the northbridge descriptor.

However, it's populated even on Intel processors for an L3 cache.
This results in failure of cacheinfo setup as shown below as
cache_get_priv_group() returns the unintialised private attributes which
are not valid for Intel processors.

------------[ cut here ]------------
WARNING: CPU: 3 PID: 1 at fs/sysfs/group.c:102
internal_create_group+0x151/0x280()
sysfs: (bin_)attrs not set by subsystem for group: index3/
Modules linked in:
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc3+ #1
Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
...
Call Trace:
  dump_stack
  warn_slowpath_common
  warn_slowpath_fmt
  internal_create_group
  sysfs_create_groups
  device_add
  cpu_device_create
  ? __kmalloc
  cache_add_dev
  cacheinfo_sysfs_init
  ? container_dev_init
  do_one_initcall
  kernel_init_freeable
  ? rest_init
  kernel_init
  ret_from_fork
  ? rest_init

This patch fixes the issue by checking if the l3 cache indices are
populated correctly (AMD-specific) before initializing the private
attributes.

Reported-by: Borislav Petkov <bp@...e.de>
Signed-off-by: Sudeep Holla <sudeep.holla@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: x86@...nel.org
Signed-off-by: 
---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 8008bc2dd2d0..edcb0e28c336 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -556,7 +556,7 @@ cache_get_priv_group(struct cacheinfo *this_leaf)
 {
 	struct amd_northbridge *nb = this_leaf->priv;
 
-	if (this_leaf->level < 3)
+	if (this_leaf->level < 3 || !nb)
 		return NULL;
 
 	if (nb && nb->l3_cache.indices)
-- 
2.2.0.33.gc18b867

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/