Re: Proposal for Porting Xen to Armv8-R64 - DraftA

[Julien Grall <julien@xen.org>]

On 02/03/2022 07:21, Penny Zheng wrote:
> Hi julien

Hi Penny,

>>>>
>>>>     So if the unpaused guests start executing the context switch at this
>>>>     point, then its MPU context will base on the boot-time MPU
>>> configuration.
>>>
>>> Can you explain why you want to switch the MPU configuration that late?
>>>
>>
> 
> It is more related to the implementation.
> 
> In the boot stage, we allocate MPU regions in sequence until the max.
> Since a few MPU region will get removed along the way, it leaves hole there.
> Such like when heap is ready, fdt will be reallocated in the heap, which means the
> MPU region for device tree is in no need. And also in free_init_memory, although we
> do not give back init memory to the heap, we will also destroy according MPU
> regions to make them inaccessible.
> Without ordering, we need a bitmap to record such information.
> 
> In context switch, the memory layout is quite different for guest mode and
> hypervisor mode. When switching to guest mode, only guest RAM, emulated/passthrough
> devices, etc could be seen, but in hypervisor mode, all guests RAM and device memory
> shall be seen. And without reordering, we need to iterate all MPU regions to find
> according regions to disable during runtime context switch, that's definitely a overhead.
> 
> So we propose an ordering at the tail of the boot time, to put all fixed MPU region
> in the head, like xen text/data, etc, and put all flexible ones at tail, like device memory,
> guests RAM.
> Then later in context switch,  we could easily just disable ones from tail and inserts new
> ones in the tail.

Thank you for the clarification. This makes sense to me. I would suggest 
to update the proposal to reflect this decision.

>> For PMSA, we still enforce WnX. For your use case, I assume it's alternative.
>> It still may have some possibility to avoid vmap(). But there may be some
>> security issues. We had thought to disable MPU -> update xen text -> enable
>> MPU to copy VMSA alternative's behavior. The problem with this, however,
>> is that at some point, all memory is RWX. There maybe some security risk.
>> But because it's in init stage, it probably doesn't matter as much as I thought.
>>
> 
> In MMU system, we use vmap() to change requested xen text codes(a few lines) temporarily
> to RW to apply the alternative codes, the granularity for it could be 4KB.
> 
> But on MPU system, we give the whole XEN text code a MPU region, so otherwise we disable
> the whole MPU to make it happen, which leads to a little risk for running c codes where MPU
> disabled, or all text memory becoming RWX at this alternative time.

See my answer to Wei. So long the code is compliant with the Arm Arm, it 
would be acceptable to have boot code running with RWX for a short 
period of time.

Cheers,

-- 
Julien Grall