From: "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
To: Andy Lutomirski <luto@kernel.org>, Dave Hansen <dave.hansen@intel.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
Rik van Riel <riel@surriel.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: How should we handle illegal task FPU state?
Date: Thu, 8 Oct 2020 11:08:53 -0700 [thread overview]
Message-ID: <8e23f875-3c3c-957d-84db-530d2ece432e@intel.com> (raw)
In-Reply-To: <CALCETrWswWdgXO2J6nRjXW_4JRsK1TzzVZ62EDsF+d_79O+6Sw@mail.gmail.com>
On 10/1/2020 3:04 PM, Andy Lutomirski wrote:
> On Thu, Oct 1, 2020 at 2:50 PM Dave Hansen <dave.hansen@intel.com> wrote:
>>
>> On 10/1/20 1:58 PM, Sean Christopherson wrote:
>>> One thought for a lowish effort approach to pave the way for CET would be to
>>> try XRSTORS multiple times in switch_fpu_return(). If the first try fails,
>>> then WARN, init non-supervisor state and try a second time, and if _that_ fails
>>> then kill the task. I.e. do the minimum effort to play nice with bad FPU
>>> state, but don't let anything "accidentally" turn off CET.
>>
>> I'm not sure we should ever keep running userspace after an XRSTOR*
>> failure. For MPX, this might have provided a nice, additional vector
>> for an attacker to turn off MPX. Same for pkeys if we didn't correctly
>> differentiate between the hardware init state versus the "software init"
>> state that we keep in init_task.
>>
>> What's the advantage of letting userspace keep running after we init its
>> state? That it _might_ be able to recover?
>
> I suppose we can kill userspace and change that behavior only if
> someone complains. I still think it would be polite to try to dump
> core, but that could be tricky with the current code structure. I'll
> try to whip up a patch. Maybe I'll add a debugfs file to trash MXCSR
> for testing.
>
One complication of letting XRSTORS fail is exit_to_user_mode_prepare()
will need to go back to exit_to_user_mode_loop() again (or repeat some
parts of it).
Currently, when exit_to_user_mode_loop() exits, xstates should have been
validated earlier and to be restored shortly. At this stage, XRSTORS
should not fault. If we need to kill the task, we should have done that
earlier.
There are only two sources of invalid xstates: PTRACE and sigreturn.
For user-mode data, both sources have been taken care of.
Supervisor-mode data can be checked/reviewed easily. There are only CET
and PASID supervisor states.
Yu-cheng
next prev parent reply other threads:[~2020-10-08 18:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 17:43 How should we handle illegal task FPU state? Andy Lutomirski
2020-10-01 20:32 ` Yu, Yu-cheng
2020-10-01 20:58 ` Sean Christopherson
2020-10-01 21:42 ` Andrew Cooper
2020-10-01 21:50 ` Dave Hansen
2020-10-01 22:04 ` Andy Lutomirski
2020-10-08 18:08 ` Yu, Yu-cheng [this message]
2020-10-09 0:08 ` Andy Lutomirski
2020-11-02 18:39 ` Borislav Petkov
2020-10-01 21:26 ` Andrew Cooper
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=8e23f875-3c3c-957d-84db-530d2ece432e@intel.com \
--to=yu-cheng.yu@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=riel@surriel.com \
--cc=sean.j.christopherson@intel.com \
--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).