Re: [Xen-devel] [PATCH for-4.12] passthrough/vtd: Drop the "workaround_bios_bug" logic entirely

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.03.19 at 15:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> There is absolutely nothing *at all* which guarantees that just because
> a number of devices are identified to be behind specific IOMMUs, that
> DMA wont start appearing from elsewhere in the system.

I fully agree here.

> Security of the system when it comes to IOMMUs *is and always will be* a
> mutually cooperative and trusting relationship between Xen and the firmware.
> 
> The notion of "I'm safe because there were no inconsistencies in a piece
> of information I have to trust fully" is security theatre, not security.

Doing our best to sanity check information we're handed is, I think,
not just "security theater".

>>> Disabling the IOMMU prevents the system from booting with a PVH dom0.
>> But doing what you did is not the only way of getting around this.
>> Defaulting to workaround_bios_bug=1 in the PVH case would be
>> another, as would be a mode in which the IOMMU exists for Dom0's
>> purposes only (i.e. still disallowing any pass-through to DomU-s).
> 
> A discussion along these lines might be appropriate in the middle of a
> dev cycle, and might even be valid for a discussion of future improvements.
> 
> It is not appropriate for resolving an issue identified as a 4.12
> blocker by the RM, on a timescale which needs to fit into the 4.12
> release plans.

Okay, I clearly must have missed the mail where this was flagged
as release critical.

Irrespective of this I don't think, though, that a pending release
is sufficient justification to rush in a controversial patch. We're
yet to hear from Kevin, but as you can see I would not have ack-
ed the patch. Emergency ack-s from The Rest maintainers ought
to be given on the assumption that the actual maintainer(s)
would likely not object. I don't think George tried to violate this,
i.e. I think he was assuming that the maintainer(s) would agree,
but as we see this was wrong in this case.

> And if you'd not broken the behaviour back in 4.2, this class of system
> would have been discovered the first time someone tried booting Xen on
> it, not at the point someone is trying to upgrade 4.11 to 4.12.

Correct, and I take the blame for this, but I don't think it helps
the situation. If the problem had been discovered earlier, I
don't think the fix would have been to rip out that code
altogether.

>>> I have made a statement, backed up with specific reference to the code
>>> which, to the best of my ability, demonstrates it to be true.
>>>
>>> If you believe contrary then clearly identify the fault in my reasoning.
>> I did, by pointing out the earlier regression, which you elected to
>> ignore altogether in your reply.
> 
> You identified why Xen 4.11 didn't behave in the way you expected.
> 
> In doing so, you also demonstrated why the commit message was, in fact,
> correct.

Well, we continue to disagree here. It was at best misleading and/or
incomplete.

> Like other parts of this thread, it was deviating sufficiently
> off-topic/relevance that I chose to trim it.  I will continue doing so
> in an effort to reduce the amount of my time that this thread is
> wasting.  I don't know for certain, but I expect you've also got better
> things to do with your time than arguing over off-topic aspects of this
> thread.

Purely from a technical pov the discussion on whether this should
have been rushed in may indeed be considered off topic. But this
doesn't means it's irrelevant. Would you have liked it better if I
had started a separate thread, e.g. by formally requesting a
revert?

I can understand your frustration, but it's not you alone who is
frustrated. Throughout this discussion I've not seen a single
sign that you would be willing to find a compromise. I'm sorry to
repeat myself, but it imo is not reasonable to assume that
your way of thinking is the only possible or reasonable one.
Claiming that anything else is beyond "common sense" is, well,
offending.

And yes, I do have better things to do with my time. But I don't
think I can leave uncommented how things have gone here, if
nothing else then in the hopes that it wouldn't repeat again.

Jan


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