Re: [PATCH v2 10/13] x86/mpx: Map/unmap xsave area in in read_bndcfgu()

["Alejandro Vallejo" <alejandro.vallejo@xxxxxxxxx>]

On Mon Dec 16, 2024 at 2:02 PM GMT, Alejandro Vallejo wrote:
> On Mon Dec 16, 2024 at 12:03 PM GMT, Jan Beulich wrote:
> > On 16.12.2024 13:00, Alejandro Vallejo wrote:
> > > On Mon Dec 9, 2024 at 4:30 PM GMT, Jan Beulich wrote:
> > >> On 05.11.2024 15:33, Alejandro Vallejo wrote:
> > >>> --- a/xen/arch/x86/xstate.c
> > >>> +++ b/xen/arch/x86/xstate.c
> > >>> @@ -1022,9 +1022,10 @@ int handle_xsetbv(u32 index, u64 new_bv)
> > >>>  
> > >>>  uint64_t read_bndcfgu(void)
> > >>>  {
> > >>> +    uint64_t bndcfgu = 0;
> > >>>      unsigned long cr0 = read_cr0();
> > >>> -    struct xsave_struct *xstate
> > >>> -        = idle_vcpu[smp_processor_id()]->arch.xsave_area;
> > >>> +    struct vcpu *v = idle_vcpu[smp_processor_id()];
> > >>
> > >> Can this be pointer-to-const? Certainly right now, so the question is 
> > >> rather
> > >> meant to be forward looking.
> > >>
> > >>> +    struct xsave_struct *xstate = VCPU_MAP_XSAVE_AREA(v);
> > >>
> > >> This certainly can be pointer-to-const, just like ...
> > >>
> > >>>      const struct xstate_bndcsr *bndcsr;
> > >>
> > >> ... this is.
> > > 
> > > Yes, those retained non-const because of the now missing patch to zero-out
> > > bndcfgu.
> >
> > I'm afraid this reply is ambiguous as to what's going to happen in the next
> > version. I can read both "will change" and "needs to stay" into it.
> >
> > Jan
>
> It was an answer to "Can this be pointer to const?". Yes, I'll put the const
> back.
>
> Cheers,
> Alejandro

Actually, xstate is the target of the assembly, so it will be written to
(though not from C). It seems like asking for trouble modifying the target of a
pointer to non-volatile const from inline assembly.

I'll leave it as-is in the interest of safety.

Cheers,
Alejandro