linux-kernel - Re: [PATCH] MIPS: VDSO: Always select -msoft-float

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: <alpine.DEB.2.00.1611041558460.13938@tp.orcam.me.uk>
Date:   Fri, 4 Nov 2016 16:09:37 +0000
From:   "Maciej W. Rozycki" <macro@...tec.com>
To:     Guenter Roeck <linux@...ck-us.net>
CC:     Matthew Fortune <Matthew.Fortune@...tec.com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        "linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        James Hogan <James.Hogan@...tec.com>
Subject: Re: [PATCH] MIPS: VDSO: Always select -msoft-float

On Fri, 4 Nov 2016, Guenter Roeck wrote:

> > As above, unless absolutely critical to have floating point code then
> > the vDSO should just avoid all FP related issues and build soft-float.
> 
> FWIW, my logic was quite simple: The rest of the kernel builds with
> -msoft-float, thus vDSO should do the same. Of course, I don't know the
> entire context, so there may well be a reason to handle it differently
> than the rest of the kernel.

 VDSO is not a part of the kernel, it's user mode code, made visible in 
the user virtual memory, and implicitly loaded along the rest of the DSOs 
on program startup by the dynamic loader (ld.so).  It has to be PIC for 
that reason, too, causing all the hassle we had with making it such that 
it does not need a GOT.

> Anyway, isn't the kernel supposed to not use floating point operations
> in the first place ? Is this different for vDSO ?

 This code is executed in the user mode so while floating-point code may 
not be needed there, not at least right now, there's actually nothing 
which should stop us from from adding some should such a need arise.

  Maciej