All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Jann Horn <jannh@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	kasan-dev <kasan-dev@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] x86/traps: Print non-canonical address on #GP
Date: Thu, 14 Nov 2019 10:54:20 -0800	[thread overview]
Message-ID: <20191114185420.GJ24045@linux.intel.com> (raw)
In-Reply-To: <CALCETrVOPT5Np9=4ypEipu5YtXyTRZhiYBQ1XZoDd2=_Q4s=yw@mail.gmail.com>

On Thu, Nov 14, 2019 at 10:41:06AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 14, 2019 at 10:20 AM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> >
> > On Thu, Nov 14, 2019 at 10:00:35AM -0800, Andy Lutomirski wrote:
> > > On Thu, Nov 14, 2019 at 9:46 AM Sean Christopherson
> > > <sean.j.christopherson@intel.com> wrote:
> > > > > +     /*
> > > > > +      * For the user half, check against TASK_SIZE_MAX; this way, if the
> > > > > +      * access crosses the canonical address boundary, we don't miss it.
> > > > > +      */
> > > > > +     if (addr_ref <= TASK_SIZE_MAX)
> > > >
> > > > Any objection to open coding the upper bound instead of using
> > > > TASK_SIZE_MASK to make the threshold more obvious?
> > > >
> > > > > +             return;
> > > > > +
> > > > > +     pr_alert("dereferencing non-canonical address 0x%016lx\n", addr_ref);
> > > >
> > > > Printing the raw address will confuse users in the case where the access
> > > > straddles the lower canonical boundary.  Maybe combine this with open
> > > > coding the straddle case?  With a rough heuristic to hedge a bit for
> > > > instructions whose operand size isn't accurately reflected in opnd_bytes.
> > > >
> > > >         if (addr_ref > __VIRTUAL_MASK)
> > > >                 pr_alert("dereferencing non-canonical address 0x%016lx\n", addr_ref);
> > > >         else if ((addr_ref + insn->opnd_bytes - 1) > __VIRTUAL_MASK)
> > > >                 pr_alert("straddling non-canonical boundary 0x%016lx - 0x%016lx\n",
> > > >                          addr_ref, addr_ref + insn->opnd_bytes - 1);
> > > >         else if ((addr_ref + PAGE_SIZE - 1) > __VIRTUAL_MASK)
> > > >                 pr_alert("potentially straddling non-canonical boundary 0x%016lx - 0x%016lx\n",
> > > >                          addr_ref, addr_ref + PAGE_SIZE - 1);
> > >
> > > This is unnecessarily complicated, and I suspect that Jann had the
> > > right idea but just didn't quite explain it enough.  The secret here
> > > is that TASK_SIZE_MAX is a full page below the canonical boundary
> > > (thanks, Intel, for screwing up SYSRET), so, if we get #GP for an
> > > address above TASK_SIZE_MAX,
> >
> > Ya, I followed all that.  My point is that if "addr_ref + insn->opnd_bytes"
> > straddles the boundary then it's extremely likely the #GP is due to a
> > non-canonical access, i.e. the pr_alert() doesn't have to hedge (as much).
> 
> I suppose.  But I don't think we have a real epidemic of failed
> accesses to user memory between TASK_SIZE_MAX and the actual boundary
> that get #GP instead of #PF but fail for a reason other than
> non-canonicality :)

No argument there.

> I think we should just go back in time and fix x86_64 to either give
> #PF or at least give some useful page fault for a non-canonical
> address. The only difficulties I'm aware of is that Intel CPUs would
> either need to be redesigned better or would have slightly odd
> semantics for jumps to non-canonical addresses -- #PF in Intel's model
> of "RIP literally *can't* have a non-canonical value" would be a bit
> strange.  Also, my time machine is out of commission.

If you happen to fix your time machine, just go back a bit further and
change protected mode to push the faulting address onto the stack.

  reply	other threads:[~2019-11-14 18:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 21:10 [PATCH 1/3] x86/insn-eval: Add support for 64-bit kernel mode Jann Horn
2019-11-12 21:10 ` [PATCH 2/3] x86/traps: Print non-canonical address on #GP Jann Horn
2019-11-14 17:46   ` Sean Christopherson
2019-11-14 18:00     ` Andy Lutomirski
2019-11-14 18:08       ` Borislav Petkov
2019-11-14 18:20       ` Sean Christopherson
2019-11-14 18:41         ` Andy Lutomirski
2019-11-14 18:54           ` Sean Christopherson [this message]
2019-11-14 20:03       ` Jann Horn
2019-11-12 21:10 ` [PATCH 3/3] x86/kasan: Print original " Jann Horn
2019-11-13 10:11   ` Dmitry Vyukov
2019-11-13 15:19     ` Andrey Konovalov
2019-11-13 15:43       ` Dmitry Vyukov
2019-11-14 15:09     ` 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=20191114185420.GJ24045@linux.intel.com \
    --to=sean.j.christopherson@intel.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=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.