[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.