[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <97273aa8-9aa4-78ee-21ca-d728835f44a7@intel.com>
Date: Wed, 23 Sep 2020 15:53:46 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Andy Lutomirski <luto@...nel.org>,
"Yu, Yu-cheng" <yu-cheng.yu@...el.com>
Cc: Sean Christopherson <sean.j.christopherson@...el.com>,
X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
linux-arch <linux-arch@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Balbir Singh <bsingharora@...il.com>,
Borislav Petkov <bp@...en8.de>,
Cyrill Gorcunov <gorcunov@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Eugene Syromiatnikov <esyr@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
"H.J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Nadav Amit <nadav.amit@...il.com>,
Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
Peter Zijlstra <peterz@...radead.org>,
Randy Dunlap <rdunlap@...radead.org>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@...el.com>,
Dave Martin <Dave.Martin@....com>,
Weijiang Yang <weijiang.yang@...el.com>
Subject: Re: [PATCH v12 8/8] x86: Disallow vsyscall emulation when CET is
enabled
On 9/23/20 3:47 PM, Andy Lutomirski wrote:
> On Wed, Sep 23, 2020 at 3:20 PM Yu, Yu-cheng <yu-cheng.yu@...el.com> wrote:
>> On 9/23/2020 3:08 PM, Dave Hansen wrote:
>>> On 9/23/20 3:06 PM, Yu, Yu-cheng wrote:
>>>> I think I'll add a check here for (r + 8) >= TASK_SIZE_MAX. It is
>>>> better than getting a fault.
>>> There's also wrmsr_safe().
>>>
>> Yes, thanks.
>>
>> Since I am going to change this to:
>>
>> fpu__prepare_write(), then write to the XSAVES area.
>>
>> The kernel does not expect XRSTORS to fail ("Bad FPU state detected..."
>> message). So maybe still check the address first.
> Surely there are plenty of ways to use ptrace() to poke garbage into
> the FPU state. We should be able to handle this type of failure
> somewhat gracefully.
Yeah, agreed. I'd much rather make XRSTORS able to #GP gracefully than
teach the kernel exhaustively about every possible error condition it
can encounter.
We *might* want to do something like to preserve the warning if the task
hasn't been ptrace'd, or had the memory buffer written to directly or
tainted in another way.
Powered by blists - more mailing lists