[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1D569B6B-B8C3-497E-8A74-2E1A3D46299E@amacapital.net>
Date: Tue, 16 Jun 2020 14:17:16 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Borislav Petkov <bp@...en8.de>
Cc: x86-ml <x86@...nel.org>, jpa@...nelbug.mail.kapsi.fi,
Dave Hansen <dave.hansen@...el.com>,
"H. Peter Anvin" <hpa@...or.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/fpu: Reset MXCSR to default in kernel_fpu_begin()
> On Jun 16, 2020, at 11:01 AM, Borislav Petkov <bp@...en8.de> wrote:
>
> On Tue, Jun 16, 2020 at 09:53:39AM -0700, Andy Lutomirski wrote:
>>> On Tue, Jun 16, 2020 at 2:53 AM Borislav Petkov <bp@...en8.de> wrote:
>>>
>>> Ok,
>>>
>>> here's the fix first so that it goes in. I'll hammer on the test case later.
>>
>> Does the 32-bit case need FNINIT?
>
> Pasting from IRC:
>
> I'm thinking if you'd need to reinit the FPU, then you need to do it for
> both, not only 32-bit or do you mean something else? Also, if you end up
> doing FNSAVE (old CPU) that one reinits state.
We definitely need to sanitize MXCSR for kernel fpu if kernel fpu means SSE2. If kernel fpu means x87, we need to fix the fpu control word.
On x86_64, I suspect the UEFI ABI technically requires a clean x87 control word too. If we’re willing to declare that the kernel proper won’t use x87, then we could shove that into the UEFI code.
>
> Whatever we decide doing, this should be a separate patch anyway.
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists