No, we're not sorry for Xen security SNAFUs says Ian Jackson Open source luminary Ian Jackson has hit back at criticism of the Xen Project's security. The project last week nixed nine nasties, including a seven-year-old guest-host escape, and has patched a string of bugs this year including some that threatened to disrupt cloud services. The many bug squashed of late has seen some …
"All bugs are shallow with enough eyes."
But that doesn't help. You still need to recruit enough eyes and make what the code does visible in the first place. And this includes shipping a large testing base btw.
Otherwise it's just a reformulation of "all NP-hard problems are easy given enough time..."
This post has been deleted by its author
> "And this includes shipping a large testing base btw."
And that code is indeed available. The code which is used to test Xen is available and the code which is used to test XenServer is available. Of course there are other testing code bases from other vendors that use Xen which are not. Unfortunately, you will need a rather large HW installation with many different machine types to set it up.
However, I did want to point out, that traditional unit and functional testing, does not normally pick up security issues. To do this, you do need run fuzzing and other tools designed to find security issues. And in fact such tools are run regularly on the Xen codebase. But understandably, such code cannot be published without giving blackhats the tools to run them themselves.
> You still need to recruit enough eyes and make what the code does visible in the first place.
I guess that's an argument for open source?
Otherwise it's just a reformulation of "all NP-hard problems are easy given enough time..."
Oh, I like this game.
"All impossible problems are easy given enough unicorns."
"All matter is iron given enough time."
"All answers are accurate, given enough margin for error."
"All songs are good, given enough cowbell."
"All interlocutors are like Hitler, given enough posts."
Says Mr I don't know what sizeof() does..
Says Mr I don't know that sizeof is an operator, not a function, and thus does not require parentheses.
(The argument to sizeof is unary-expression or a parenthesized type-name. In the latter case, the parentheses are part of the argument, not part of sizeof as such.)
On thing which has not really been covered in this whole story is how the criticism by Invisible Things Lab has been made. They chose to include the criticism on the Xen Project in their own security advisory, which was clearly designed for maximum PR impact to give Invisible Things Lab free press coverage. And hey, it has worked.
What they could have done instead, is to start a constructive dialog with the Xen community to actually address their concerns. They did not do this (yet). If you look at this tweet https://twitter.com/rootkovska/status/660154918465110017 it appears that they were maybe not intending to do so.
Ian Jackson said in the original post:
> ... over the last few years the Xen Project’s code review process has become a
> lot more rigorous. As a result, the quality of code being newly introduced into
> Xen has improved a lot.
This is certainly true. In fact, we have had complaints from various vendors that it is now too hard to contribute to the Xen Project (compared to Linux and KVM). To look into this, the project commissioned a study by Bitergia to model and data mine our review process. Phase 1 of that study completed a few weeks ago and it shows that the primary reasons for the increased elapsed time it takes to get code into Xen, are significantly higher quality expectations.
If you look at some of the data, in 2008 when the bug behind XSA 148 was introduced, the average number of sets of review comments per patch was 4. Sets of review comments are emails that comment on a submitted patch (not patch series) piece by piece and contain several review comments (typically between 1-15 depending on the size of patch). This number has steadily grown to around 13.5 sets of review comments per patch and has increased the time it takes to get a patch into Xen noticeably. We do not know how this compares to Linux, KVM or even proprietary software. But given the complaints by vendors who contribute to Linux, KVM and Xen, it appears that Xen is more rigorous than most other projects.
To say, that the project does not care about quality and thus security, is simply unfair. We do care, which is also why a) we run a rigorous security vulnerability process and b) we resist the temptation to sacrifice transparency, even if this sometimes leads to negative press coverage.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
