Re: [PATCH] x86/domain: restrict context switch hooks for the idle domain

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.10.2026 11:29, Roger Pau Monné wrote:
> On Fri, Oct 02, 2026 at 11:23:17AM +0200, Roger Pau Monné wrote:
>> On Fri, Oct 02, 2026 at 10:09:02AM +0200, Jan Beulich wrote:
>>> On 02.10.2026 10:05, Roger Pau Monné wrote:
>>>> On Fri, Oct 02, 2026 at 09:55:09AM +0200, Jan Beulich wrote:
>>>>> On 02.10.2026 09:48, Roger Pau Monné wrote:
>>>>>> On Fri, Oct 02, 2026 at 07:45:07AM +0200, Jan Beulich wrote:
>>>>>>> On 01.10.2026 16:27, Roger Pau Monne wrote:
>>>>>>>> --- a/xen/arch/x86/domain.c
>>>>>>>> +++ b/xen/arch/x86/domain.c
>>>>>>>> @@ -813,8 +813,6 @@ static bool emulation_flags_ok(const struct domain 
>>>>>>>> *d, uint32_t emflags)
>>>>>>>>  void __init arch_init_idle_domain(struct domain *d)
>>>>>>>>  {
>>>>>>>>      static const struct arch_csw idle_csw = {
>>>>>>>> -        .from = paravirt_ctxt_switch_from,
>>>>>>>> -        .to   = paravirt_ctxt_switch_to,
>>>>>>>>          .tail = idle_loop,
>>>>>>>>      };
>>>>>>>
>>>>>>> Leaving NULL pointers around isn't a good thing, though. May I suggest 
>>>>>>> to
>>>>>>> at least poison the pointers then?
>>>>>>
>>>>>> I don't mind doing so, but I don't think we usually do that for other
>>>>>> hook structures, ie: hvm_function_table for example doesn't poison
>>>>>> unset hooks (and it possibly can't, because there are .hook != NULL
>>>>>> checks).
>>>>>>
>>>>>> TBH I'm missing a benefit of the poisoning here.  Using NULL or a
>>>>>> poisoned value will both trigger a page-fault, and NULL has the
>>>>>> benefit of callers easily checking whether the hook is set.
>>>>>
>>>>> NULL in the context of a HVM vCPU will #PF. NULL in the context of a PV
>>>>> one may not, depending on what the guest may have put there.
>>>>
>>>> It still feels a bit arbitrary to do here but not in other places,
>>>
>>> We should imo resolve this by replacing NULLs wherever hooks could, due
>>> to other issues, end up "in sight" on paths reachable for PV guests. This
>>> would then also cover potential speculation along such paths.
>>
>> FTAOD, I plan to introduce a poison value using a non-canonical
>> address, ie:
>>
>> #define POINTER_POISON ((void *)0xDEAD0000DEAD0000UL)
> 
> s/POINTER_POISON/FUNCTION_POISON/

Sure, if you think none of the present poisoning values we have is good to
reuse here.

Jan