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.
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox