Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 24/05/2018, 10:00, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:

    >>> On 24.05.18 at 15:50, <lars.kurth@xxxxxxxxxx> wrote:
    
    > 
    > On 24/05/2018, 01:48, "Steven Haigh" <netwiz@xxxxxxxxx> wrote:
    > 
    >     On 2018-05-22 20:52, Steven Haigh wrote:
    >     > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
    >     >> >>> On 18.05.18 at 19:53, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
    >     >> > Alternative workaround for this would be more frequent point 
releases 
    > by
    >     >> > default (maybe with ability to delay it very few commits are 
queued).
    >     >> > For example every 3 months. It wouldn't solve all the cases, but 
I 
    > think
    >     >> > will make it easier most of the time.
    >     >> 
    >     >> Is every 3 months so much better than every 4 months? Granted we
    >     >> basically never manage to make it exactly 4 months, but on the 
average
    >     >> I think we're not too far off.
    >     > 
    >     > I think the big thing is reducing the delta between the staging 
branch 
    >     > and the
    >     > release. I can only assume that would reduce the number of issues 
that 
    >     > occur
    >     > with patching vs release tarballs - hopefully making the security 
teams 
    > 
    >     > job a
    >     > little easier.
    >     > 
    >     > That being said, if an approach of releasing a new build when we 
come 
    >     > across
    >     > broken patch sets for XSAs (like the current 4.9.1 vs XSAs, and 
prior 
    >     > 4.10.0
    >     > vs XSAs), then I think this part becomes irrelevant.
    >     
    >     As another example for this, the patches for XSA263 do not apply to 
    >     *any* released tarball version of Xen.
    >     
    >     So far, the patches included with the announcement fail on 4.6, 4.7, 
4.9 
    > 
    >     and 4.10.
    >     
    >     I can only assume that this means all the XSA patches require commits 
    >     that are currently in various staging git trees that have not been 
    >     released in any formal manner via a point release.
    >     
    > Thinking about this, we are essentially exposing ourselves to this, 
because 
    > of backports of issues which happen at any random point in time during a 
    > point release cycle, e.g. 4.8.2. => 4.8.3
    > 
    > In other words, we may get a sequence of backport, XSA, XSA, backport, ...
    > 
    > I am wondering whether time-sequencing may be the answer here. In other 
    > words, let's assume we have a 4-month window: for the first 3 months, we 
    > don't allow bug-fix backports into in this case stable-4.8, we only allow 
    > XSAs. Then we have a 2-week merge window where we handle all backports 
and 
    > prepare the release and cut the release. This means that for most of the 
    > time, XSAs would apply cleanly onto staging and the released tarball.
    
    I'm sincerely against such a model: The larger a batch of commits, the more
    likely that some then-no-longer-easy-to-spot regression may creep in, and
    the less time there is for osstest and people to test. I do appreciate some
    batching, but just like with XSAs I think the batch size should remain 
sensible
    also for commits to stable trees.
    
How many bug-fixes vs. XSAs are typically in a stable branch? I was under the 
impression that historically, the vast majority used to be XSAs with very few 
backports.
However, this year this has really changed because Spectre and Meltdown related 
fixes were developed in public and they look like feature backports
Which is why we see more of these issues

Lars    
    

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel