<p><pre><code> | The code to validate level 2 page table entries is bypassed when
| certain conditions are satisfied. This means that a PV guest can
| create writeable mappings using super page mappings.
|
| Such writeable mappings can violate Xen intended invariants for pages
| which Xen is supposed to keep read-only.
</code></pre>
Xen is used by security-focused Qubes, which published an analysis of XSA-148, <a href="https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt" rel="nofollow">https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs...</a>:<p><i>"The above is a political way of stating the bug is a very critical one. Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly.<p>Admittedly this is subtle bug, because there is no buggy code that could be spotted immediately ... On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our
opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again (assert-like
mechanisms perhaps?). Otherwise the whole project makes no sense, at least to those who would like to use Xen for security-sensitive work.<p>Specifically, it worries us that, in the last 7 years (i.e. all the time when the bug was sitting there having a good time) so much engineering and development effort has been put into adding all sorts of new features and whatnots, yet no serious effort to improve Xen security effectively. Because there have been, of course, many more security bugs found in Xen over the last years (as the numbering of this XSA suggests)... the bugs in Xen are being found regularly, and
this is no good news. For a type-1 hypervisor of the age and maturity of Xen, this simply should not be happening. If it does, it suggests the development process is not prioritizing security."</i>