lkml.org 
[lkml]   [2020]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: general protection fault in perf_misc_flags
On Mon, Sep 21, 2020 at 01:59:43PM -0700, Nick Desaulniers wrote:
> Right, the two sequences above look almost the same, except those 4
> bytes of zeros (the disassembler gets confused about the rest, but
> it's the same byte sequence otherwise). Are the two disassemblies a
> comparison of the code at runtime vs. compile-time?

Yes.

> If so, how did you disassemble the runtime code?

./scripts/decodecode < /tmp/splat

where /tmp/splat contains the line starting with "Code:". Make sure you
have only one "Code:"-line, otherwise you'll see the code of the *last*
Code: line only.

> If runtime and compile time differ, I suspect some kind of runtime
> patching.

If it is, it ain't patching at the right place. :)

But no, that function is pretty simple and looking at its asm, there's
no asm goto() or alternatives in there. But that .config might add them.
It adds a lot of calls to *ASAN helpers and whatnot.

> I wonder if we calculated the address of a static_key wrong
> (asm goto). What function am I looking at the disassembly of?
> perf_misc_flags() in arch/x86/events/core.c?

Yes.

> With this config?
> https://syzkaller.appspot.com/x/.config?x=cd992d74d6c7e62 (though I
> don't see _any_ asm goto in the IR for this file built with this
> config).

Right, there should be none.

> If this is deterministically reproducible, I suppose we
> could set a watchpoint on the address being overwritten?

Sounds like worth a try. I'll go sleep instead, tho. :)

Gnight and good luck.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

\
 
 \ /
  Last update: 2020-09-22 00:14    [W:0.140 / U:1.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site