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
> 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 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
> > 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]
> > >