Re: [PATCH 28/36] xen/arm: introduce xen_map_text_rw

[Julien Grall <julien@xxxxxxx>]

Hi,

On 07/03/2022 07:39, Jan Beulich wrote:
> On 04.03.2022 18:46, Marco Solieri wrote:
> > From: Luca Miccio <lucmiccio@xxxxxxxxx>
> >
> > Introduce two new arm specific functions to temporarily map/unmap the
> > Xen text read-write (the Xen text is mapped read-only by default by
> > setup_pagetables): xen_map_text_rw and xen_unmap_text_rw.
> >
> > There is only one caller in the alternative framework.
> >
> > The non-colored implementation simply uses __vmap to do the mapping. In
> > other words, there are no changes to the non-colored case.
> >
> > The colored implementation calculates Xen text physical addresses
> > appropriately, according to the coloring configuration.
> >
> > Export vm_alloc because it is needed by the colored implementation of
> > xen_map_text_rw.
> I'm afraid I view vm_alloc() as strictly an internal function to
> vmap.c. Even livepatching infrastructure has got away without making
> it non-static.
I think we can get away from using vmap() here. We were using it because 
Xen text mappings are RX and this is enforced by the processor via 
SCTLR_EL1.WXN.
The bit is cached in the TLB. Back then it wasn't very clear what would 
happen if we clear the bit. Looking at the latest Arm Arm (ARM DDI 
0487H.a D5.10), there is now a section "TLB invalidation and System 
register control fields" providing more details.
Reading the section, it should be safe to temporary disable WXN on every 
CPUs and make Xen text writable.
@Marco, would you be able to have a look?

Cheers,

--
Julien Grall