back to article 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 …

  1. a_yank_lurker Silver badge

    Bugs

    Ian is correct all but the most trivial software is riddled with bugs and potential security issues - no exceptions. He is also correct sunlight is the best antidote. As Linus says "All bugs are shallow with enough eyes."

    1. Destroy All Monsters Silver badge
      Coat

      Re: Bugs

      "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..."

      1. This post has been deleted by its author

      2. larsk

        Re: Bugs

        > "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?

      3. Michael Wojcik Silver badge

        Re: Bugs

        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."

  2. Anonymous Coward
    Anonymous Coward

    TL;DR; version of this comments section:

    "Boohoo I told you C is bad, why aren't they using some high level language that would make the code perfect. I don't care that it's practically impossible to write code that runs below the OS in such a language. C IS BAAAAAAD"

    1. Destroy All Monsters Silver badge
      Thumb Down

      > it's practically impossible to write code that runs below the OS in such a language

      Go back to first semester and stay there.

      1. Anonymous Coward
        Anonymous Coward

        >Go back to first semester and stay there.

        Says Mr I don't know what sizeof() does..

        1. Michael Wojcik Silver badge

          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.)

  3. Destroy All Monsters Silver badge
    Paris Hilton

    You mean to say?

    > "assert-like mechanisms perhaps?"

    They don't have this simple "must use to not be considered utter caveman" squeaky-bottoms avoiding tool?

    1. Anonymous Coward
      Anonymous Coward

      Re: You mean to say?

      Is an exception thrown if no one is there to catch it?

  4. Anonymous Coward
    Anonymous Coward

    PR Stunt

    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.

  5. larsk

    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

Other stories you might like

Biting the hand that feeds IT © 1998–2022