All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Jann Horn <jannh@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH v3 2/4] x86/traps: Print non-canonical address on #GP
Date: Wed, 20 Nov 2019 14:28:30 +0100	[thread overview]
Message-ID: <20191120132830.GB54414@gmail.com> (raw)
In-Reply-To: <20191120123926.GE2634@zn.tnic>


* Borislav Petkov <bp@alien8.de> wrote:

> On Wed, Nov 20, 2019 at 01:30:58PM +0100, Ingo Molnar wrote:
> > 
> > * Jann Horn <jannh@google.com> wrote:
> > 
> > > You mean something like this?
> > > 
> > > ========================
> > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > > index 9b23c4bda243..16a6bdaccb51 100644
> > > --- a/arch/x86/kernel/traps.c
> > > +++ b/arch/x86/kernel/traps.c
> > > @@ -516,32 +516,36 @@ dotraplinkage void do_bounds(struct pt_regs
> > > *regs, long error_code)
> > >   * On 64-bit, if an uncaught #GP occurs while dereferencing a non-canonical
> > >   * address, return that address.
> > >   */
> > > -static unsigned long get_kernel_gp_address(struct pt_regs *regs)
> > > +static bool get_kernel_gp_address(struct pt_regs *regs, unsigned long *addr,
> > > +                                          bool *non_canonical)
> > 
> > Yeah, that's pretty much the perfect end result!
> 
> Why do we need the bool thing? Can't we rely on the assumption that an
> address of 0 is the error case and use that to determine whether the
> resolving succeeded or not?

I'd rather we not trust the decoder and the execution environment so much 
that it never produces a 0 linear address in a #GP:

in get_addr_ref_32() we could get zero:

	linear_addr = (unsigned long)(eff_addr & 0xffffffff) + seg_base;

in get_addr_ref_16() we could get zero too:

	linear_addr = (unsigned long)(eff_addr & 0xffff) + seg_base;

Or in particularly exotic crashes we could get zero in get_addr_ref_64() 
as well:

        linear_addr = (unsigned long)eff_addr + seg_base;

although it's unlikely I suspect.

But the 32-bit case should be plausible enough?

It's also the simplest, most straightforward printout of the decoder 
state: we either see an error, or an (address,canonical) pair of values.

Thanks,

	Ingo

  parent reply	other threads:[~2019-11-20 13:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-20 10:36 [PATCH v3 1/4] x86/insn-eval: Add support for 64-bit kernel mode Jann Horn
2019-11-20 10:36 ` [PATCH v3 2/4] x86/traps: Print non-canonical address on #GP Jann Horn
2019-11-20 11:18   ` Ingo Molnar
2019-11-20 11:24     ` Borislav Petkov
2019-11-20 12:25       ` Jann Horn
2019-11-20 12:41         ` Borislav Petkov
2019-11-20 13:16         ` Ingo Molnar
2019-11-20 13:23           ` Jann Horn
2019-11-20 14:05             ` Ingo Molnar
2019-11-20 12:14     ` Jann Horn
2019-11-20 12:30       ` Ingo Molnar
2019-11-20 12:39         ` Borislav Petkov
2019-11-20 12:42           ` Jann Horn
2019-11-20 13:28           ` Ingo Molnar [this message]
2019-11-20 13:39             ` Borislav Petkov
2019-11-20 16:21               ` Sean Christopherson
2019-11-20 17:37                 ` Borislav Petkov
2019-11-20 10:36 ` [PATCH v3 3/4] x86/dumpstack: Split out header line printing from __die() Jann Horn
2019-11-20 10:36 ` [PATCH v3 4/4] x86/kasan: Print original address on #GP Jann Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191120132830.GB54414@gmail.com \
    --to=mingo@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=andreyknvl@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=bp@alien8.de \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.