Re: [PATCH v9 01/20] xen: introduce CONFIG_HAS_SHARED_INFO for archs without a shared page

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 09-Sep-26 17:07, Oleksii Kurochko wrote:
> On architectures that run guests in dom0less mode without the PV ABI
> (currently RISC-V), no shared_info page is allocated and d->shared_info
> remains NULL throughout the domain lifetime.  Several places in common
> code access d->shared_info through the shared_info() macro or directly,
> causing UBSAN null-pointer errors on such architectures.
> 
> Rather than adding runtime NULL guards that are logically unreachable
> on x86 and Arm (where shared_info is always allocated), introduce a new
> Kconfig symbol CONFIG_HAS_SHARED_INFO selected by x86 and Arm.
> 
> On !HAS_SHARED_INFO the shared_info() macro expands to a dereference
> of shared_info_absent, an extern pointer that is declared but
> intentionally never defined.  Any use of shared_info() that is not
> dead-code-eliminated will therefore cause a link-time failure, making
> missed guards impossible to overlook.
> 
> The 2L event-channel ops call shared_info() and must not be compiled on
> architectures without a shared_info page, so event_2l.o is gated on
> CONFIG_HAS_SHARED_INFO.  On such architectures evtchn_init() installs the
> FIFO ops as a placeholder instead, so that a later guest opt-in to the
> FIFO ABI via EVTCHNOP_init_control has no special-casing to do; if FIFO
> support itself is also unavailable (!CONFIG_EVTCHN_FIFO), a dedicated
> no-op evtchn_port_ops_none table is installed instead, so that
> d->evtchn_port_ops is never NULL.  evtchn_fifo_word_from_port() is
> guarded against uninitialised d->evtchn_fifo so the FIFO ops are safe
> before evtchn_fifo_init_control() is called by the guest.
> 
> With CONFIG_HAS_SHARED_INFO=n all vCPUs fall back to the global
> dummy_vcpu_info, so writes through vcpu_info() could leak data between
> vCPUs. Reviewing the write paths in common code: the write in
> map_guest_area() stores the constant ~0 so nothing serious would happen
> if it were leaked; the event_2l.c paths are not compiled on
> !HAS_SHARED_INFO, as event_2l.o is gated on CONFIG_HAS_SHARED_INFO; the
> write in vcpu_info_populate() targets the new mapping buffer, not
> dummy_vcpu_info.
> 
> Outside common code, the remaining writes are x86 PV-specific, for which
> CONFIG_HAS_SHARED_INFO=y. No code changes are needed.
> 
> Finally, struct domain's shared_info field itself is gated on
> CONFIG_HAS_SHARED_INFO, as it would otherwise be a permanently NULL
> pointer: every user of it is either arch code for an architecture that
> selects HAS_SHARED_INFO, or common code already guarded by the same
> Kconfig symbol.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
Acked-by: Michal Orzel <michal.orzel@xxxxxxx> #Arm

~Michal