Reply to post:

No, we're not sorry for Xen security SNAFUs says Ian Jackson


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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon