RE: [PHP-DEV] RE: High resolution timer function
| From: | Anatol Belski | Date: | Mon, 08 Jan 2018 16:48:28 +0000 |
| Subject: | RE: [PHP-DEV] RE: High resolution timer function | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-101567@lists.php.net to get a copy of this message | ||
Hi,
> -----Original Message-----
> From: Anatol Belski [mailto:weltling@outlook.de] On Behalf Of Anatol Belski
> Sent: Saturday, January 6, 2018 12:31 AM
> To: Rasmus Lerdorf <rasmus@lerdorf.com>; Rowan Collins
> <rowan.collins@gmail.com>
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] RE: High resolution timer function
>
> Hi Rasmus,
>
> > -----Original Message-----
> > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
> > Sent: Friday, January 5, 2018 5:42 PM
> > To: Rowan Collins <rowan.collins@gmail.com>
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] RE: High resolution timer function
> >
> > Definitely. Small, uncontroversial changes have never required an RFC.
> > Let's not add process just for the sake of process.
> >
> That was my premise, too, similar to what Rowan's second mail expressed. I
> myself didn't think it would be something big to vote, just to make lists aware.
> The PHP interface might be a subject to nitpick, but otherwise it's a long
> requested feature. I'm still to the QA of the patch, the PHP interface is still
> choosable of course, the functionality itself is to the big part ready.
>
This patch was merged a short while ago. Since then, a concern was raised on the PR page https://github.com/php/php-src/pull/2976#issuecomment-355882740
, that providing a high resolution timer could have impacts to shared hostings with regard to the
Spectre vulnerability. The paper https://spectreattack.com/spectre.pdf describes a
reproduce way in Javascript, which is why current browsers already issued a patch to reduce the
timer resolutions as a part of mitigation. In further in the PR, it was suggested to provide a
separate function that only cares about the monotony, but delivers time as milliseconds.
Now, as one can see in the paper, Javascript can provide an attack vector, because it compiles to
JIT and because browsers provide certain features. Neither of those are currently available in PHP.
Furthermore, PHP itself as any other program is vulnerable to Meltdown/Spectre and a proper fix is
only available on the OS and hardware levels. Both features, high resolution and monotonic timer was
requested earlier also not only those that led to this PR.
As it is now a few days after the disclosure, it is not quite clear how much impact high resolution
timers might have on the PHP side in the future. At least, it doesn't seem obvious these issues
are something to be fixed on the PHP side. For now, my suggestion were to keep hrtime() in the core
and to implement monotonictime() that provides millisecond resolution. I'm working on that
right now. If later on it turns out, that high resolution timers are a general security impact,
parts regarding gettimeofday and microtime would have to be touched, too. But the monotonic low
resolution timer would still have no impact, at least by today's knowledge. The
Meltdown/Spectre issue is definitely something, that needs to be monitored with the regard to
impacts to PHP.
Regards
Anatol
>
>
> > -Rasmus
> >
> > On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins
> > <rowan.collins@gmail.com>
> > wrote:
> >
> > > On 5 January 2018 at 10:38, Dan Ackroyd <danack@basereality.com> wrote:
> > >
> > > > On 2 January 2018 at 13:55, Peter Cowburn <petercowburn@gmail.com>
> > > wrote:
> > > > >
> > > > >
> > > > > Why is this bypassing the RFC process?
> > > >
> > > > That's a very good question.
> > > >
> > > > Although I'm pretty sure an RFC for this would pass unanimously,
> > > > stuff should have to go through voting rather than relying on
> > > > no-one shouting loudly enough.
> > > >
> > >
> > >
> > > Just as a counter-point to this, I understand that many (Westminster
> > > style?) parliaments have mechanisms to skip uncontroversial votes by
> > > first requiring a show of hands or voices, and only "dividing the
> > > house" (making everyone get up and register their formal votes) if there is
> dissent.
> > >
> > > I think Anatol's intent here is similar: if anyone says "Nay", we
> > > can proceed with an RFC and vote; but if it's already unanimous, why
> > > spend the time, when we could be moving onto other business?
> > >
> > > Regards,
> > > --
> > > Rowan Collins
> > > [IMSoP]
> > >