From: Andy Lutomirski <luto@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
Waiman Long <longman@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
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>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp
Date: Mon, 5 Nov 2018 11:21:24 -0800 [thread overview]
Message-ID: <CALCETrX7NU02=kMED--p_TXkRPrm4_Bntc6W13tdtS4GJspLKw@mail.gmail.com> (raw)
In-Reply-To: <08752b15-8771-266f-0155-3b721203e721@intel.com>
On Mon, Nov 5, 2018 at 9:20 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
>
> On 11/4/18 9:14 PM, Andy Lutomirski wrote:
> > I should add: if this patch is *not* applied, then I think we'll
> > need to replace the sw_error_code check with user_mode(regs) to avoid
> > an info leak if CET is enabled. Because, with CET, WRUSS will allow
> > a *kernel* mode access (where regs->sp is the kernel stack pointer)
> > with user permissions.
>
> Are you saying that WRUSS, if it faults will set the "user" page fault
> error code bit? I seem to have some rough recollection about it being
> that way, and the shadow-stack spec does say:
>
> paging access control checks will be treated as a user-mode
> shadow stack store
>
I believe so, and it would make sense for it to work this way. I
would love some instructions for directly accessing normal user
memory, too. Maybe a prefix?
> But the SDM says:
>
> For all instruction fetches and most data accesses, this
> distinction is determined by the current privilege level (CPL):
> accesses made while CPL < 3 are supervisor-mode accesses, while
> accesses made while CPL = 3 are user-mode accesses.
>
> It would certainly be ideal if things affecting the core architecture
> like this were in the SDM itself before we merged them. It makes things
> like this a lot easier to figure out.
Agreed. The current documentation situation is not so good.
next prev parent reply other threads:[~2018-11-05 19:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-02 19:40 [RFC PATCH] x86/mm/fault: Allow stack access below %rsp Waiman Long
2018-11-02 19:44 ` Dave Hansen
2018-11-02 19:50 ` Waiman Long
2018-11-02 20:11 ` Andy Lutomirski
2018-11-02 20:34 ` Waiman Long
2018-11-02 22:28 ` Dave Hansen
2018-11-05 5:11 ` Andy Lutomirski
2018-11-05 5:14 ` Andy Lutomirski
2018-11-05 17:20 ` Dave Hansen
2018-11-05 19:21 ` Andy Lutomirski [this message]
2018-11-05 16:27 ` Waiman Long
2018-11-05 17:51 ` Dave Hansen
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='CALCETrX7NU02=kMED--p_TXkRPrm4_Bntc6W13tdtS4GJspLKw@mail.gmail.com' \
--to=luto@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).