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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.00.1611041736110.13938@tp.orcam.me.uk>
Date:   Fri, 4 Nov 2016 18:06:12 +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:

> >  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.
> > 
> Just for my understanding - so the code is compiled with the kernel and part
> of the kernel source but executed in user mode ?

 Yes, that's correct.

 The idea behind VDSO is to export some kernel data to the userland in a 
way making it possible to avoid the considerable overhead of making a 
syscall, i.e. the whole dance required to switch to the kernel mode, make 
the necessary arrangements there for kernel mode execution such as stack 
switching (see the SAVE_SOME macro), actually retrieve the data requested, 
undo the kernel mode execution arrangements (RESTORE_SOME) and finally 
resume user mode execution.

 So instead a page is mapped by the kernel in the user virtual memory with 
designated entry points comprising the public API and the actual 
implementation which retrieves the data requested in a varying way, 
depending on the kernel configuration, hardware features, etc., so it is 
tightly coupled with the kernel and has to be built along it.  These entry 
points are then used by the C library instead of their corresponding 
syscalls.

 A good use example is a replacement for gettimeofday(2).  This syscall 
retrieves a tiny amount of data which is frequently requested e.g. by X 
servers which want to individually timestamp their events.  So the gain 
from avoiding making this syscall and instead retrieving the data 
requested straight in the user mode is enormous.

> If you ever add real floating point code, doesn't that also mean that you'll
> have to implement the necessary linker helper functions or wrappers (such
> as the wrappers needed for 64-bit integer divide operations in 32 bit code) ?

 No, you could just link the VDSO with `-lgcc' instead and get all the 
necessary bits from there, as usually in user code.  Although if building 
for compat ABIs as well you'd have to ensure you have GCC libraries built 
and installed for all the ABIs required, which in turn depends on the 
configuration chosen for the compiler at its build time.  Not a problem 
right now though as we don't need any of this stuff.

 HTH,

  Maciej