Re: [Xen-devel] On setting clear criteria for declaring a feature acceptable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.03.16 at 17:23, <george.dunlap@xxxxxxxxxx> wrote:
> [Changing the subject and CC'ing more people]
> 
> On 09/03/16 13:39, Jan Beulich wrote:
>>>>> On 08.03.16 at 19:38, <george.dunlap@xxxxxxxxxx> wrote:
>>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>>> about with "Something bad may happen" being difficult to work with.
>>> Rather than you spelling out exactly the situation which you think may
>>> happen, (which I could then either accept or refute on its merits) *I*
>>> am now spending a lot of time and effort trying to imagine what
>>> situations you may be talking about and then refuting them myself.
> [snip]
>> 
>>> If you have concerns, you need to make those concerns concrete, or at
>>> least set clear criteria for how someone could go about addressing your
>>> concerns.  And yes, it is *your* job, as the person doing the objecting
>>> (and even moreso as the x86 maintainer), to make your concerns explicit
>>> and/or set those criteria, and not Feng's job (or even my job) to try to
>>> guess what it is might make you happy.
>> 
>> I'm sorry, George, but no, I don't think this is how things should
>> work. If for a new feature to be enabled by default it is unclear
>> whether that puts the system at risk, it's the party suggesting the
>> default enabling to prove there's no such risk. 
> 
> And it's up to the maintainers to clearly define what kind of "proof"
> would be sufficient. I have no objection to saying that Feng (or someone
> else who cares about the feature) must do some work to demonstrate that
> the feature is in fact safe before it's enabled by default; that's
> perfectly reasonable. I have already suggested something that would shed
> light on the issue and potentially satisfy me. But it's not at all
> reasonable to give them the impossible task of trying to guess what will
> satisfy you.
> 
> I don't know why this is controversial -- this seems obvious to me.

And it is not controversial - as said on the original thread, I
was of the opinion that I had clearly explained which specific
case I want to see taken care of (or to be more precise,
avoided). With that ...

> What do other committers / maintainers think?
> 
>> We just can't allow
>> code in that sets us up for future security issues. If anything
>> that's what we should have learned from the various disasters in
>> the past (XSAVE enabling having been the first and foremost,
>> which by now I count 4 related XSAs for).
> 
> I'm not familiar with the XSAVE feature or its related XSAs, but do you
> think simply saying "I'm not sure; prove to me that it's safe" would

.. this is just an unfair simplification of what I've raised as concerns
so far. That said, ...

> have actually helped matters?  Would it have prompted the authors of
> that code to actually do some sort of testing / analysis that would have
> turned up the subsequent security issues?
> 
> It seems to me that saying "I'm not sure, prove it to me", without
> further guidance about *how* to prove it, would have ended in one of you
> two giving up: either Intel not doing any more work on the feature, or
> you eventually giving up and letting it go in anyway, with the same
> security bugs it had before.

... I agree with you on these points. Just that I don't feel guilty
having acted in this way. Yes, I wasn't anywhere close to precise
in how the questionable state could be reached, but I was (and
continue to be) of the opinion that this doesn't matter, so long as
there are no provisions anywhere in the system that preclude
such a state from being reached (and of that lack of provisions I
am reasonably certain).

And then there's a non-technical aspect to this whole situation:
The set of people introducing features and the set of people
fixing bugs doesn't have a very large overlap. If I could be
certain that it will be those who introduce PI (or any other
feature requiring large or intrusive changes) who are also
going to look into problems with it later on (and in a timely
manner), I might take a more relaxed position. But since history
teaches me that this is not likely going to be the case, my
(submitter dependent) hesitance to accept (even if only
theoretically) risky new features is also some sort of self
defense - not just at the open source project level, but also
from a distro pov.

Jan

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