linux-kernel - Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory

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: <20161104205746.yazddirphm736zpa@linutronix.de>
Date:   Fri, 4 Nov 2016 21:57:46 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     "Charles (Chas) Williams" <ciwillia@...cade.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        "M. Vefa Bicakci" <m.v.b@...box.com>
Subject: Re: [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory

On 2016-11-04 16:42:33 [-0400], Charles (Chas) Williams wrote:
> This comes from here:
> 
>                 unsigned int apicid = apic->cpu_present_to_apicid(cpu);
> 
>                 if (apicid == BAD_APICID || !apic->apic_id_valid(apicid))
>                         continue;
>                 if (!topology_update_package_map(apicid, cpu))

It is late here. Can you check what function apic->cpu_present_to_apicid
is? It should do the right thing for your APIC.
 
> The phys core id from generic_identify() comes from the CPU's EBX register
> so we _know_ this is right.

So you are sure cpuid_level is > 1 here.

> 	       if (c->cpuid_level >= 0x00000001) {
> 			c->initial_apicid = (cpuid_ebx(1) >> 24) & 0xFF;
> 	#ifdef CONFIG_X86_32
> 	# ifdef CONFIG_SMP
> 			c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
> 	# else
> 			c->apicid = c->initial_apicid;
> 	# endif
> 	#endif
> 			c->phys_proc_id = c->initial_apicid;
> 		}
> 
> The intel docs http://x86.renejeschke.de/html/file_module_x86_id_45.html
> claims this is the Local APIC ID.  So it seems likely this is correct
> value.  It's not clear it matter if this is the right value or not
> though.  Even if this is the correct apicid, nothing knows about it.

Need to check that later (and your whole mail) against an official
manual. But as you see in the code, it checks the apicid against
->phys_pkg_id on 32bit so it seems sometimes there are changes required
to what the CPUID returns.

Sebastian