Hi Michael, > On 16 Dec 2025, at 09:15, Orzel, Michal <[email protected]> wrote: > > > > On 28/11/2025 10:58, Harry Ramsey wrote: >> From: Luca Fancellu <[email protected]> >> >> During `init_done`, Xen sets the permissions of all symbols marked with >> __ro_after_init to be read-only. Currently this is achieved by calling >> `modify_xen_mappings` and will shrink the RW mapping on one side and >> extend the RO mapping on the other. > Can you be more specific about the sides you mention? How did you deduce it? > I assume you are talking about MMU part.
You are right, this sentence is a bit misleading. So what was written here was meant to say that on MPU modify_xen_mappings should shrink the RW mapping region and extend the RO mapping region because as of now they are declared like this in xen.lds.S: read only data: +------------------+ | _srodata | | _erodata | +-------------------+ RW data: +---------------------------+ | __ro_after_init_start | | __ro_after_init_end | | __init_begin | +---------------------------+ And in head.S we map like this: /* Xen read-only data section. */ ldr x1, =_srodata ldr x2, =_erodata prepare_xen_region x0, x1, x2, x3, x4, x5, attr_prbar=REGION_RO_PRBAR /* Xen read-only after init and data section. (RW data) */ ldr x1, =__ro_after_init_start ldr x2, =__init_begin prepare_xen_region x0, x1, x2, x3, x4, x5 Now, because (__ro_after_init_start, __ro_after_init_end) needs to become RO, it means that RO section will be extended to (_srodata, __ro_after_init_end) and RW section will be shrinked to (__ro_after_init_end, __init_begin): read only data region: +--------------------------+ | _srodata | | __ro_after_init_end | +--------------------------+ RW data region: +---------------------------+ | __ro_after_init_end | | __init_begin | +---------------------------+ So what we’ve done is taking (__ro_after_init_start, __ro_after_init_end) from the RW region and attach it to the RO region. > >> >> This does not work on MPU systems at present because part-region >> modification is not supported. Therefore introduce the function > What else is in that region? > Wouldn't it be better to have one region for this __ro_after_init so that we > don't need to shrink/extend the mappings? Is it done because of number of > regions limitation? So if we do in this way we waste one region, because we will have 2 region declared RO that are also contiguous, so easily mergeable, like how we are doing above by Extending/shrinking. Cheers, Luca
