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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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.

~Andrew