Just had a quick look API-wise. I'd prefer different functions for different formats, bool flags are evil. But I don't have good name suggestions right now.

@kelunik thanks for checking. That's microtime() API consistency. There's otherwise no much impact. And naming can get weird, yep, like putting datatype into signature.

Thanks.

@weltling I know, but it's not really consistent. microtime() returns a string by default which must be split.

@kelunik the signature it is and the way it returns some number with true. The stirng return - well, not really sure it should mimic that, too. In terms of functionality - perhaps array is the only thing that makes sense for portability. The number return is good on 64-bit and thus was tempting. Anyway, please suggest another API to discuss. Otherwise could simply only leave the array return and remove the alternative variant. Something for diff/compare would be then unambiguous, too.

Please also document new function in UPGRADING.

Stas, i've addressed the comments where appropriate or left an explanation. The 32-bit part regarding floats is of course not pretty, but the string conversion is most reliable. Indeed, one could simply abandon the get_as_number part, but it would be a pity for 64-bit. It is anyway to see whether 32-bit dies or we'll have to implement 64-bit integer support there :)

Regarding the m4 migration - yep, can be done, then AC_FPM_CLOCK function should be moved into the core m4. Either header or m4 seems ok, so i'd leave it with header for now and see to do this with FPM refactoring. And of course keeping in mind UPGRADING, will document once merged.

Thanks.

You can add UPGRADING part to this very patch, no need to make two separate ones I think?

Of course, just that's often a conflicting part for the merge. I'll add it then, nevertheless.

After some tests and research, i've turned the QPC part back to double arithmetics. It turns out, that QPC is still not 100% reliable when it comes to virtualization. As a reference, here's among others the link like https://www.virtualbox.org/ticket/11951. I was also able to find a machine where QPC was resetting about every 2 hours, that's anything but monotonic. The double arithmetic mitigates it by using the compiler magic with type conversions int64_t -> uint64_t -> double and due to the fact 32-bit VS still has a native 64-bit integer type. I need to have some more tests on machines with uptime over two months yet. I think, the Windows implementation in this patch is the most PITA, tests on Linux and FreeBSD show good results.

Thanks.

Merged as 8349732.

Thanks everyone!

Firefox/Chrome recently removed high-performance timers because they can be abused for Spectre exploits in multitenant environments. It's a very strange time to be introducing a new high-performance timer API.

Is there any potential security impact of having a high-performance timer API available? e.g. shared hosting environments?

@mappu could you give more info on that, please?

Thanks.

@weltling "Spectre" attacks can read information from other processes on the machine, by biasing the CPU branch predictor and then timing how long some operations take.

It's a major vulnerability for web applications because the vulnerability can be exploited from Javascript. In that case, a website running malicious javascript could read sensitive data from other tabs, or from other OS processes.

Firefox [1], Edge [2], and Chrome [3] all issued emergency security patches this week, to reduce the accuracy of their high-resolution timer API (performance.now()).

It's not clear whether a better mitigation will be available in the future, or if this is going to be permanent on current CPUs.

I suspect the same attack, or a similar attack, would also apply to PHP in shared hosting environments.

Maybe it's not possible, but in a post-Spectre world, high-resolution timers must be treated as a security-sensitive issue.

@mappu thanks for more info. Basically, anytime one comes from the holiday, something horrible has happened :) Talking seriously - the real mitigation seems unavoidable in first place by hardware and OSes, that's where the focus is. The mitigation in browsers is of course the necessary immediate step to solve the issue right now in the released software. This patch is master only and has time to see what happens further.

Today, 5 day after the disclosure, solutions are being worked on, in kernels and compilers. Some distros already provide kernel patches, see for example SUSE, also gcc and clang already have patches. So it is clear a mitigation stands already. But in general, this kind of vulnerability is likely only to solve at the very low level, not by the applications. In the end, there is no reason for panic, but of course a good reason to stay tuned as there are other time sources based on gettimeofday(), etc. and modules in many other scripting languages, etc.

Thanks.

Shared hosting providers may still disable this function, just like they currently disable functions that they consider dangerous for shared hosting use.

That said, the reason why this functionality was originally requested, was because AMP needed a monotonic (but not high-resolution) clock source. Maybe it would be better to separate this into two features, so one will not be affected if the other has to be disabled for security reasons.

I thought about that, too. At the start it was also about high resolution and no Spectre issue known ofc. Basically it doesn't hurt to revert this patch and reintroduce it in another form. Fun enough - same APIs would be used for just monotonic+milliseconds. Probably should introduce just monotonic_time, same as it is, only delivering milliseconds. I would suggest to do so and see the further happenings with the HW and OS mitigations. What do you think?

In worst case - yes, hosters can disable these functions. Note that microtime() is already exposed, if disabled - it would likely break some apps. But it really stands in the dark right now - if a program can deliver high resolution times, it's not automatically suspicious. Also it'd still require proof it's possible with PHP, or say another language like Python, etc. Node's hrtime() function uses similar APIs. Without a global fix to OSes and hardware, not only shared hostings but also containers and cloud are vulnerable. There are tons of software, that could potentially be called suspicious otherwise.

Thanks.

One solution on linux could be to fall back down to clock_monotonic_coarse if you compile php in a different way. This is of course a bit dangerous depending on what people rely on.

Probably that doesn't help much. As far i understood, the concern of @mappu is, that PHP could potentially provide an attack possibility. PHP itself, as any other program, would be vulnerable to an attack by a third party software. The poc in Javascript is based firstly on the fact, that the code is compiled to JIT, and secondly - that it relies on a certain browser feature. PHP doesn't compile to JIT yet, for one.

From what i also could read today in many sources, a fix to this issue is only possible on the system and HW level, fe https://de.wikipedia.org/wiki/Spectre_(Sicherheitsl%C3%BCcke)#Gegenma%C3%9Fnahmen. Otherwise no process can be sure. Also, while containers are important today, there are still not only them. The functions can be disabled by admins, if needed. To compare, as the mitigations can introduce performance impacts, RedHat tells it'll be possible to enable them selectively. Clear, it's probably the worst issue the industry ever seen, but the head should still be cold.

I'm nevertheless working on monotonictime() now, reusing the existing code but shrinking the return value to milliseconds, as suggested. If it later turns out the world wants get rid of high resolution timers for some reason, so the existing hrtime() can be deleted before 7.3.

Thanks.

We could also introduce INI_SYSTEM setting with maximum accuracy and have the code here that limits the accuracy of the timer. This way people running single-user but needing good accuracy can set it to high accuracy, and shared system admins could limit the potential for abusing timing oracles with restricting the accuracy while still keeping the monotonity. What do you think?

A separate function could have less overhead, that's true. IMHO the idea with the ini sounds better as it gives more flexibility.

As i'd see it, there'd be hrtime.precision setting that would take a value in ns. If the value is zero, no adjustment is done. Otherwise, the value is used to reduce the actual timer. Say, one wants to reduce the timer to 20us precision, so the setting were 20000. Internally we still read the full precision, but do something like (php_hrtime_t)(time / 20000) * 20000 and then proceed further as before.

For the furture, this ini setting could be reused for the others like microtime(), if we ever need to do it. Also not sure about the ini setting name, please suggest. Also need to check for possible cast issues, etc.

Thanks.

I was doing some checks now, and seems the calculation is a bit more complicated. Actually for an INI it needs two settings - one is for precision and the other for unit. Say one could deliver nanosecond accuracy still, but the precision would be 20us. Alternatively, the INI could be just like "hrtime.low_resolution" which we could still set to something like 20us or 1ms, etc. In that case, perhaps a separate function would be more clear.

Thanks.

I think it should be something like hrtime.resolution which provides resolution unit in ns - so if it's set to 20000, the measurement is always rounded up to 20us grid. If it's 0, then the measurement is reported as is.

Ok, this seems the simplest variant. I probably went too complicated way of thought. To think, like in the 20000 example - one could first reduce to an arbitrary unit, and then round to a given interval. Fe what is done at Mozilla is first reducing to ms, then again to nearest 20us. But that's actually a specification JS has to follow.

I'm now working straight to this simple solution then - hrtime.resolution is expressed in ns, the function delivers ns and optionally reduces to the given interval. The setting is PHP_INI_SYSTEM and set default to zero. Thus admins have the full control. Later on the INI can be reused if needed. The flexibility to not to shrink down to ms is also a big plus, imo.

Thanks.

OK, i've pushed c3717d9 and reverted it. We're too short in time after the discovery, there should be a better discussion after some time where the world have seen fixes to Meltdown/Spectre. I think it's sufficient to put this topic on hold and resurrect it anyway in time so a mitigation, if needed, lands in 7.3.

Thanks.

For even higher precision, it would be great to add hrtime() to zend_try_compile_special_func() in zend_compile.c!

(see https://bugs.php.net/76241)

Please add to $_SERVER array:
key: REQUEST_HRTIME_FLOAT
value: hrtime(true)

<?php
 // PHP 7.2

 // ... page
 // ... code

 $elapsed=$_SERVER['REQUEST_TIME_FLOAT']-microtime(true);

?>

<?php
 // PHP 7.3

 // ... page
 // ... code

 $elapsed=$_SERVER['REQUEST_HRTIME_FLOAT']-hrtime(true);

?>

$_SERVER['REQUEST_HRTIME_FLOAT'] returns hrtime(true) of script start

what about just the monotonic part for getting time?