In a new post to his site Mattias Geniar looks at an old security issue in PHP, opcache information leakage and how to mitigating the issue.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

He starts by talking about the vulnerability itself, that the PHP process doesn't validate the userid when fetching cached bytecode. This could result in information from other operations/scripts being exposed to other processes in a PHP-FPM pool. His solution? Upgrade PHP (the bug is fixed back in PHP 5.6.5) and set a few additional opcache ini settings to enforce the validation. Besides 5.6.29, it was also corrected in the PHP 7 releases (7.0.14 and 7.1.0). The post then talks about the potential exploit - an indirect local privilege escalation to root where the shared memory is read and access to outside information is possible.

In his latest post Juozas Kaziukenas shares a video of his "From PHP to Machine Code" talk he presented at the PHP UK Conference earlier this year (2016).

I recently gave a talk at a few conferences titled “From PHP to Machine Code”. It explains how compilers and interpreters work in general, where are the performance gains to be found and how I applied all of that to build PyHP. PyHP is a little toy project which showcases the basics of taking source code of a programming language and executing it.

As I mention a few times in the talk, it is completely and utterly useless for practical use, but it’s one of the fundamental skill-sets for any programmer. I think knowing how a bunch of text makes a computer do things at the low level is required knowledge for everyone.

The video of the presentation is embedded in the post or you can watch it directly over on YouTube if you'd like. In it he walks you through the entire process that happens from the time the PHP is executed all the way down to opcodes and bytecodes.

Joshua Thjissen has a post to his site looking at a relatively common operation in PHP code - incrementing values - but gets a lot more in-depth than just a simple overview.

Take a variable, increment it with 1. That sounds like a simple enough job right? Well.. from a PHP developer point of view that might seem the case, but is it really? There are bound to be some catches to it (otherwise we wouldn’t write a blogpost about it). So, there are a few different ways to increment a value, and they MIGHT seem similar, they work and behave differently under the hood of PHP, which can lead to – let’s say – interesting results.

He starts with the most basic situations, updating known integer values, but shows the curious things that can happen when the same operations are done on strings. He digs down into the bytecode that's generated from these bits of code, showing the order of operations when the code is actually executed. He then gets into more detail on each kind of operator, starting with the unary increment operator then moving on to the add assignment expression and add operator. For each he describes the behind the scenes bytcode actions happening and where in the PHP source code its being handled (and how).

In the latest post to the HHVM (HipHop VM) blog Sara Golemon recounts the journey of a thousand bytecodes and the process that it takes to decompose a PHP file and optimize it for execution in the HHVM environment.

Compilers are fun. They take nice, human readable languages like PHP or Hack and turn them into lean, mean, CPU executin’ turing machines. Some of these are simple enough a CS student can write one up in a weekend, some are the products of decades of fine tuning and careful architecting. Somewhere in that proud tradition stands HHVM; In fact it’s several compilers stacked in an ever-growing chain of logic manipulation and abstractions. This article will attempt to take the reader through the HHVM compilation process from PHP-script to x86 machine code, one step at a time.

The process is broken down into six different steps, each with a description and some code examples where relevant:

• Lexing the PHP to get its tokens
• Parsing the token results into an AST (and optimizing it along the way)
• Compilation to Bytecode
• HHBBC Optimization
• Intermediate Representation
• Virtual Assembly
• Emitting machine code

On the SitePoint PHP blog there's a new tutorial posted helping you understand OpCache, the caching engine built into PHP versions 5.5 and above. This cache isn't designed to cache data or other content, though. An OpCache caches "opcodes" when a script is executed.

PHP in version 5.5 comes with a caching engine built-in – OpCache – which stores precompiled script bytecode in the memory. If you’re familiar with APC or Xcache, you will already know how such engines work. As each PHP script is being compiled at runtime, a part of the execution time gets used for transforming the human readable code into code that can be understood by the machine. A bytecode cache engine like OpCache, APC or Xcache does it only once – during the first execution of a specific PHP file. Then the precompiled script is being stored in memory, which should lead to performance boosts in your PHP applications.

The remainder of the article is a series of answers to some common questions about using the cache, what it will do for your applications and some tools to use for tuning and status updates:

• Is OpCache worth installing at all? What speed boost can I expect?
• I already use APC cache. Should I migrate to OpCache?
• How to check if OpCache is actually caching my files?
• Is there any framework-specific config that I should set?
• I keep my app config in a PHP file. Can I prevent it from being cached?
• How can I run both a development and a production environment on a single server where OpCache is enabled?

Allan MacGregor has posted a (high level) introduction to the HipHop Virtual Machine (HHVM) that was created by Facebook to address some of their PHP-related needs inside their platform. It sacrifices some things in the name of speed and less resource consumption.

In early 2008 Facebook began working on HipHop(now HPHP), a PHP execution engine; its original motivation was to convert Facebook massive PHP code base into C++ in order to save resources and increase the application performance. [...] At it’s peak, HipHop PHP code showed up to 6x times better performance than its ZEND counterpart. However, there where several drawbacks to this first iteration of HipHop. [...] At the same time Facebook started the development of the modern version of HipHop, known as HHVM (HipHop Virtual Machine), HHVM improves the strengths of HPHPc and corrects many of the critical problems.

He talks some about Facebook's efforts to open source the platform and what the HipHop VM does to make your PHP code execute that much faster. It's all about bytecode, machine code and a JIT (just in time) compiler where the bytecode is parsed during execution instead of before.

Currently HHVM supports PHP 5.4 almost on its entirety, however there are still numerous bugs that prevent some applications from running, for that reason Facebook has set as goal to have the top 20 open source PHP applications running on HHVM. The first popular application to achieve this was Wordpress.

In a new post to their site, the PHP.cc (well, Sebastian Bergmann) takes a look at the bytecode caching feature that's included in the latest release of PHP, version 5.5.

PHP is an interpreted language. The default PHP runtime, the one that can be obtained from php.net, compiles PHP sourcecode to an intermediate representation called PHP bytecode which is then executed. A bytecode cache stores this compiled representation of PHP sourcecode in shared memory. This eliminates the need to load and compile sourcecode on each request which leads to a significant increase in performance (up to 70% more requests per second).

He looks some at "the past" of PHP and how it made it up from the world of PHP 4.x to PHP 5.4 and the de-facto bytecode cache before now, APC. With the introduction of PHP 5.5, though, developers have access to an integrated version of the ZendOptimizer+ cache built right into the language. They include a little bit of documentation about how to enable it and how to install it via PECL if it's not already built in.

Improving on his last post about creating a bytecode compiler in PHP, the Sankuru blog has a new post in the series looking at extending the basic compiler to add support for if/while and do while logic.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

On the Sankuru blog there's a recent post looking at the construction of a simple bytecode compiler with a virtual machine as written in PHP (for Expression Language).

In my previous blog posts, I demonstrated how we can use the builtin PCRE library, to create a lexer in Php. I also showed how to use Bison-generated LALR1 parser tables in Php. In this blog post, I will re-use these lexing and parsing facilities to compile EL programs from within Php.

He uses his lexer/parser (available for download) in an example program that outputs some values and does some simple mathematical operations. There's sections detailing the Bison grammar used, execution stacks, callbacks and the bytecode it produces.

Brandon Savage has posted a response to a recent set of benchmarks as run comparing ASP.NET and PHP's processing speeds.

But benchmarks, for all their decision-making aid, fail under the best of circumstances for one simple reason: they’re not real life. Never more is this true than in Joe Stagner's blog post on whether Windows or Linux, and PHP or ASP was faster. [...] Benchmarks come loaded with all sorts of problems. It doesn’t matter if it’s Microsoft doing them or Apple doing them; they don’t mimic real-world conditions, and any number of factors affect how the benchmarks are rendered.

Keeping these things in mind, Brandon looks at some of the issues he found with how the benchamrks were run, the largest of which was comparing the ASP.NET results (with byte code caching) to a PHP install without APC enabled.