Messages in this thread | | | Date | Tue, 22 Sep 2020 00:13:36 +0200 | From | Borislav Petkov <> | Subject | Re: 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
| |