RE: [PATCH v6 09/11] xen/arm64: create boot-time MPU protection regions

[Penny Zheng <Penny.Zheng@xxxxxxx>]

Hi Julien

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: Monday, November 7, 2022 5:30 PM
> To: Penny Zheng <Penny.Zheng@xxxxxxx>; Wei Chen
> <Wei.Chen@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: nd <nd@xxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Bertrand
> Marquis <Bertrand.Marquis@xxxxxxx>; Volodymyr Babchuk
> <Volodymyr_Babchuk@xxxxxxxx>
> Subject: Re: [PATCH v6 09/11] xen/arm64: create boot-time MPU protection
> regions
> 
> On 07/11/2022 06:59, Penny Zheng wrote:
> > Hi Julien
> 
> Hi Penny,
> 
> >>> +
> >>> +/*
> >>> + * In boot stage, we will use 1 MPU region:
> >>> + * Region#0: Normal memory for Xen text + data + bss (2MB)  */
> >>
> >> Are we only going to modify the MPU in head.S? If not, then I would
> >> define the layout in config_mpu.h so there are a single point where
> >> you can read how this works.
> >>
> >
> > We will remap Xen in C codes in setup_mm().
> > The whole strategy is aligned with MMU: a very simple setup(map xen
> > with the maximum size, 2M) at start-of-the-day, and a fit map in
> > setup_mm.
> 
> The strategy we are using for the MMU is completely broken (not compliant
> with the Arm Arm) and unnecessary. My long term goal is to actually remove
> the switch_ttbr() and most of setup_pagetables() for all setup but cache
> coloring. This means the concept of boot pages will not exist anymore.
> 
> For the MPU, we should aim to do better than what was done for the MMU.
> Right now, I see no argument for switching MPUs table. I am only seen
> argument against it because you need to disable the cache and is quite 
> fragile.
> 

> [...]
> 
> >>> +
> >>> +    ldr x2, =XEN_START_ADDRESS
> >>> +    mov x3, #(XEN_START_MEM_SIZE - 1)
> >>
> >> XEN_START_MEM_SIZE is the maximum size of Xen. IOW, Xen may be
> >> smaller and you will map memory that may not be part of Xen.
> >> Therefore, you likely want to compute the real size to avoid mapping
> >> too much.
> >>
> >
> > Later, in setup_mm we will map XEN components by components, such as,
> > one MPU memory region for read-only-executable text section, one MPU
> > memory region for read-only data section, etc, etc.
> > So in there, XEN will be mapped fitly.
> 
> But what prevents you to do this now?
> 
> >
> > IMHO, the mapping in compiler with maximum size of Xen is also what
> > MMU does.
> 
> Which is broken because we don't know what located after Xen binary.
> This could be reserved RAM, device which may requires non-caching
> attribute. Mapping those regions with caching attributes is going to break.
> 

Understood!
Then I will map Xen components by components in the compile time,
then later the first MPU/Cache disabled will be eliminated, I guess.

> 
> Cheers,
> 
> [1] 20221022150422.17707-1-julien@xxxxxxx
> 
> --
> Julien Grall