Re: [Xen-devel] Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.08.17 at 17:28, <george.dunlap@xxxxxxxxxx> wrote:
> So your argument seems to be:
> 
> 1. We can only provide security support in situations where we can test
> all possible combinations in the support matrix.
> 
> 2. We cannot test the entire matrix of combinations for Xen x livepatch
> tools x compilers
> 
> 3. Therefore, we cannot provide security support for livepatching tools.
> 
> Put this way, I hope you can see what the flaw in the argument is: #1 is
> false.  Xen has {Xen version} x {Linux version} x {Compiler} x
> {Hardware}.  Hardware of course includes not only the chip itself, but
> the BIOS / firmware, and the particular devices (and device firmware).
> If we wanted we could add in {Python version} for people using pygrub,
> and {Ocaml compiler version} for people running Ocaml, versions of
> systemd -- I'm sure with effort I could find more dimensions to add to
> the matrix.
> 
> We do not, and never have, *tested* the entire matrix of possible
> combinations considered "security supported" to make sure they work.
> Such a matrix is completely impossible to even consider, and even if we
> did some sort of testing, that could not guarantee that they are bug free.
> 
> What we do for security support is:
> 
> 1. Test a *representative sample* of combinations (via osstest, product
> testing, user testing, &c)
> 
> 2. Promise to issue XSAs if anyone *happens to discover* a combination
> in the rest of the support matrix that has a security issue
> 
> That is the requirment for normal Xen, and it would be the same
> requirement for livepatch-tools: That between osstest, product, and the
> community, we get regular testing of *a representative sample* of {Xen,
> livepatch-tools, compiler}, and (what primarily concerns me) issue an
> XSA if anyone discovers a security issue somewhere in that matrix.
> 
> I'm not frustrated, but I am baffled by the fact that this "support
> matrix" objection is so persistent.  Nearly everyone has brought it up,
> as though "test every combination" was a necessary requirement, in spite
> of the fact that 1) there is *no* piece of software for which we test
> the entire matrix of possible combinations 2) I have said over and over
> again (in fact, I specifically said a few replies ago -- it's there at
> the top of this email) that we do not test all possible combinations.

Well, part of it may be that the other components involved in the
test matrix you suggest are external, i.e. we're just their consumers.
If we consider just our own portions, the matrix is - as said - one
dimensional. With the livepatching tools, a dimension is being added.
Even us issuing Linux XSAs is, with the current upstream status of
the Xen pieces in there, questionable imo. This is also considering
the fact that iirc we've never issued an XSA for another Xen guest
OS, yet it is hard to believe that only Linux would ever had any
vulnerability.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel