linux-kernel - Re: AMD DC graphics display code enables -mhard-float, -msse, -msse2 without any visible FPU state protection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4c5fe55d-9db9-2f61-59b2-1fb2e1b45ed0@amd.com>
Date:   Thu, 2 Apr 2020 09:33:54 +0200
From:   Christian König <christian.koenig@....com>
To:     Jann Horn <jannh@...gle.com>,
        Harry Wentland <harry.wentland@....com>,
        Leo Li <sunpeng.li@....com>, amd-gfx@...ts.freedesktop.org,
        Alex Deucher <alexander.deucher@....com>,
        "David (ChunMing) Zhou" <David1.Zhou@....com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: AMD DC graphics display code enables -mhard-float, -msse, -msse2
 without any visible FPU state protection

Hi Jann,

Am 02.04.20 um 04:34 schrieb Jann Horn:
> [x86 folks in CC so that they can chime in on the precise rules for this stuff]
>
> Hi!
>
> I noticed that several makefiles under drivers/gpu/drm/amd/display/dc/
> turn on floating-point instructions in the compiler flags
> (-mhard-float, -msse and -msse2) in order to make the "float" and
> "double" types usable from C code without requiring helper functions.
>
> However, as far as I know, code running in normal kernel context isn't
> allowed to use floating-point registers without special protection
> using helpers like kernel_fpu_begin() and kernel_fpu_end() (which also
> require that the protected code never blocks). If you violate that
> rule, that can lead to various issues - among other things, I think
> the kernel will clobber userspace FPU register state, and I think the
> kernel code can blow up if a context switch happens at the wrong time,
> since in-kernel task switches don't preserve FPU state.
>
> Is there some hidden trick I'm missing that makes it okay to use FPU
> registers here?
>
> I would try testing this, but unfortunately none of the AMD devices I
> have here have the appropriate graphics hardware...

yes, using the floating point calculations in the display code has been 
a source of numerous problems and confusion in the past.

The calls to kernel_fpu_begin() and kernel_fpu_end() are hidden behind 
the DC_FP_START() and DC_FP_END() macros which are supposed to hide the 
architecture depend handling for x86 and PPC64.

This originated from the graphics block integrated into AMD CPU (where 
we knew which fp unit we had), but as far as I know is now also used for 
dedicated AMD GPUs as well.

I'm not really a fan of this either, but so far we weren't able to 
convince the hardware engineers to not use floating point calculations 
for the display stuff.

Regards,
Christian.