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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ