Re: [PATCH] x86/domctl: Reject XEN_DOMCTL_hypercall_init against oneself

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.08.2025 12:17, Andrew Cooper wrote:
> On 07/08/2025 10:30 am, Jan Beulich wrote:
>> On 06.08.2025 18:55, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -372,6 +372,14 @@ long arch_do_domctl(
>>>          struct page_info *page;
>>>          void *hypercall_page;
>>>  
>>> +        /*
>>> +         * Kernels should use the MSR method to get a hypercall page.  The
>>> +         * toolstack should not be using the DOMCTL on itself.
>>> +         */
>>> +        ret = -EINVAL;
>>> +        if ( d == currd )
>>> +            break;
>> Isn't what the comment says more generally true? To act on themselves, most
>> domctl-s are inappropriate to use, I think. There are a few exceptions, where
>> alternatives simply don't exist (and where, if a kernel wanted to use a 
>> domctl
>> [or sysctl], it would need to go through hoops to deal with the interface
>> versioning). Yet there's still the question of whether we shouldn't apply 
>> this
>> restriction in a broader fashion.
> 
> I'd go so far as to say that domctls ought to be restricted against
> oneself, but it's not quite that easy.  The majority of them already are
> restricted because of domain/vcpu_pause(), but this is all ad-hoc.
> 
> In principle, the control domain ought to be able to issue some of the
> getter's on itself, but even that's inconsistent.  get_dominfo is
> permitted, but paging ops are not.

Hmm, right. And as said, there are a few which simply can't be done a non-
domctl way. For the patch here:
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

> This is still a TBD for the stable tools interfaces.  One option I am
> considering was to split the opcode space by whether it was logically a
> getter or setter, but I expect this does not work nicely if we also want
> to retain backwards compatibility.

I didn't expect we'd strive for (binary) backwards compatibility there.
Source compatibility (i.e. merely requiring a re-compile) may be a goal,
yet even there I wouldn't be certain.

Jan