Re: [PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header guard from public API

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.03.2021 15:18, Jan Beulich wrote:
> On 05.03.2021 15:12, Andrew Cooper wrote:
>> On 05/03/2021 13:53, Jan Beulich wrote:
>>> On 05.03.2021 13:49, Andrew Cooper wrote:
>>>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>>>>
>>>> That change actually broke the build with:
>>>>
>>>>   include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t'
>>>>        ioservid_t *id);
>>>>        ^
>>>>
>>>> as libxendevicemodel.h now uses a type it can't see a typedef for.  
>>>> However,
>>>> nothing noticed because the header.chk logic is also broken (fixed
>>>> subsequently).
>>> While I agree up to here, ...
>>>
>>>> Strip the guard from the public header, and remove compensation from
>>>> devicemodel's private.h
>>> ... I'm unconvinced that entirely dropping the guard from the
>>> public header is wanted (or needed): We use these to make clear
>>> that in particular kernels aren't supposed to make use of the
>>> enclosed entities. If a type needs exposing, it (and only it)
>>> wants moving ou of the guarded region imo.
>>
>> DMOP was invented specifically so a kernel module (i915, for Intel
>> gVT-g) was independent of the domctl ABI version.
>>
>> Improving the life of dom0 userspace was an intended consequence, but
>> not the driving force behind the change.
> 
> This is news to me - so far it had been my understanding that it
> was introduced to have a way for the kernel to audit and hand on
> requests to the hypervisor without needing to know all the inner
> details. I wasn't even aware a kernel module was using any of
> these.

And indeed, quote from docs/designs/dmop.markdown:

"The aim of DMOP is to prevent a compromised device model from
 compromising domains other than the one it is providing emulation
 for (which is therefore likely already compromised)."

And it goes on discussing only the purpose that I've been aware
of.

Jan