This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: removing slow paths in various dbl-64 libm functions
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Anton Blanchard <anton at au1 dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Thu, 3 Dec 2015 12:22:27 +0100
- Subject: Re: RFC: removing slow paths in various dbl-64 libm functions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511261736421 dot 10502 at digraph dot polyomino dot org dot uk> <5657D3A5 dot 5090005 at redhat dot com> <20151130230324 dot 3dd0c293 at kryten> <565D24D0 dot 70804 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1512020034100 dot 12604 at digraph dot polyomino dot org dot uk> <565FB08D dot 9010407 at redhat dot com>
On 12/03/2015 04:01 AM, Carlos O'Donell wrote:
> On 12/01/2015 07:41 PM, Joseph Myers wrote:
>> I don't think timing oracle avoidance is a goal for libm functions (or for
>> glibc functions in general, e.g. memcmp).
>
> I agree that at present there are no goals regarding timing oracle avoidance.
>
> Any discussions about timing oracle issues would be had in a new thread and
> with clear guidelines discussed in order to attain community consensus.
I don't think it's reasonable to avoid timing oracles for math
functions. I would expect data-dependent timing for quite a few
floating point instructions (notably division, we don't even have to go
into NaN territory).
Non-polynomial functions (such as trigonometric functions) are used in
cryptography, but only to generate constant tables which are not
data-dependent at all, and those tables usually are precomputed, to
avoid issues with platforms where these floating-point operations have
errors so large that the computed tables are not correct.
Here's an example which uses |sin n|:
<https://tools.ietf.org/html/rfc1321#section-3.4>
> The particular case of memcmp is certainly the most interesting, and Florian
> and I have discussed it privately. A public discussion is welcome if someone
> wants to start it.
There has been some public discussion as well:
<https://sourceware.org/ml/libc-alpha/2014-01/msg00763.html>
Florian