[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200129180012.jmncqyb7x77gkzwq@treble>
Date: Wed, 29 Jan 2020 12:00:12 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Borislav Petkov <bp@...e.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Luck, Tony" <tony.luck@...el.com>, Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86/asm changes for v5.6
On Tue, Jan 28, 2020 at 11:31:10PM +0100, Borislav Petkov wrote:
> On Tue, Jan 28, 2020 at 01:04:19PM -0800, Linus Torvalds wrote:
> > On Tue, Jan 28, 2020 at 12:41 PM Luck, Tony <tony.luck@...el.com> wrote:
> > >
> > > Is there still some easy way to get gdb to disassemble from /dev/kmem
> > > to see what we ended up with after all the patching?
> >
> > Hmm. No, I think it's all gone.
> >
> > It _used_ to be easy to just do "objdump --disassemble /proc/kcore" as
> > root, but I think we've broken that long ago.
>
> Either booting with "debug-alternative" on baremetal or starting a guest
> and stopping it with gdb and examining the patched memory is what I've
> been using to hack on the alternatives in past years. Guest won't help
> you a whole lot with FSRM but you could "force it", for example.
FWIW, I can still do 'objdump -d' and gdb on /proc/kcore just fine
(though you have to give gdb addresses because no symbols).
--
Josh
Powered by blists - more mailing lists