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: <20160615175052.GE30309@pd.tnic>
Date:	Wed, 15 Jun 2016 19:50:52 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Paolo Bonzini <pbonzini@...hat.com>, wfg@...ux.intel.com,
	LKP <lkp@...org>, lkml <linux-kernel@...r.kernel.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Eduardo Habkost <ehabkost@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [x86] 5ac0c41bf3: WARNING: CPU: 0 PID: 0 at
 arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe

On Wed, Jun 15, 2016 at 10:23:39AM -0700, Andy Lutomirski wrote:
> Did the "Call Trace" not show up?

It did, but it is bollocks too:

[    0.020003] ------------[ cut here ]------------
[    0.024009] WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x6f/0x80
[    0.026455] unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f
[    0.028008] Modules linked in:
[    0.032008] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc3+ #26
[    0.035185] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[    0.036000]  0000000000000000 ffffffff81c03d20 ffffffff81298b65 ffffffff81c03d70
[    0.036000]  0000000000000000 ffffffff81c03d60 ffffffff81050fdb 0000003200000001
[    0.036000]  ffffffff81c03e38 ffffffff816691a0 0000000000000000 ffffffff81d662e0
[    0.036000] Call Trace:
[    0.036000]  [<ffffffff81298b65>] dump_stack+0x67/0x92
[    0.036000]  [<ffffffff81050fdb>] __warn+0xcb/0xf0
[    0.036000]  [<ffffffff8105104f>] warn_slowpath_fmt+0x4f/0x60
[    0.036000]  [<ffffffff81026d9f>] ? init_intel_energy_perf.part.3+0xf/0xd0
[    0.036000]  [<ffffffff810448ef>] ex_handler_rdmsr_unsafe+0x6f/0x80
[    0.036000]  [<ffffffff810449c9>] fixup_exception+0x39/0x50
[    0.036000]  [<ffffffff8101658f>] do_general_protection+0x7f/0x150
[    0.036000]  [<ffffffff816649bf>] general_protection+0x1f/0x30
[    0.036000]  [<ffffffff81026d9f>] ? init_intel_energy_perf.part.3+0xf/0xd0
[    0.036000]  [<ffffffff8102731f>] init_intel+0xdf/0x2b0
[    0.036000]  [<ffffffff8102597d>] identify_cpu+0x2ed/0x4f0
[    0.036000]  [<ffffffff81cdc1b8>] identify_boot_cpu+0x10/0x7a
[    0.036000]  [<ffffffff81cdc256>] check_bugs+0x9/0x2d
[    0.036000]  [<ffffffff81cd1ece>] start_kernel+0x3bd/0x3d9
[    0.036000]  [<ffffffff81cd1294>] x86_64_start_reservations+0x2f/0x31
[    0.036000]  [<ffffffff81cd13fe>] x86_64_start_kernel+0x168/0x176
[    0.036007] ---[ end trace df7f3cc4a52dae6d ]---

> I have no fundamental issue adding ip to this, but let's keep it
> WARN_ONCE (so we notice loudly and so we get the call trace)

Bah, I'm sceptical about that.

> and use %pF or whatever it's called instead of %lx.

Ok.

> Also, I want to add a variant of WARN that takes pt_regs as parameters
> at some point.  You'd get much better output.  Even without that, Josh
> Poimboeuf and I (mainly Josh) have some work slowly afoot that will
> greatly improve call trace quality when crossing an exception
> boundary.

Yes, because that call trace is almost worthless to me as the function
which actually causes it - init_intel_energy_perf - is not even on the
current stack frame.

And we don't really need the whole trace - we just need to be able to
say:

unchecked MSR access error: RDMSR from 0x1b0 at rIP: 0xffffffff81026d9f (init_intel_energy_perf.part.3)

and that function name in there could probably be looked up with
kallsyms by doing something like "get me the function name containing
this rIP".

 (I haven't even looked whether that's doable but it should be).

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ