On setting clear criteria for declaring a feature acceptable (was "vmx: VT-d posted-interrupt core logic handling")

[George Dunlap <george.dunlap@citrix.com>]

[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@citrix.com> 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.
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
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.

Again, without knowing much about the XSAVE feature or the XSAs, a
couple of responses which might have led to better outcomes:

* "I'd like to see an analysis of the XSAVE code -- what are all the
possible ways in can be loaded and stored?  How can we be sure that
nothing is leaked? See
marc.info/?i=<1371746007-19073-1-git-send-email-george.dunlap@eu.citrix.com>
for an example of the kind of analysis I'm talking about."

* "I'd like to see a framework that tests a lot of the corner cases to
make sure nothing leaks"

Those are both a fair amount of work, but they're also fairly concrete,
and actually move people towards a helpful conclusion.

 -George


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