Re: [PATCH] xen: make VMAP support in MMU system only

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

On 21/08/2024 22:14, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
> On 21/08/2024 13:25, Ayan Kumar Halder wrote:
> > From: Penny Zheng <penny.zheng@xxxxxxx>
> >
> > Introduce CONFIG_VMAP which is selected by the architectures that use
> > MMU. vm_init() does not do anything if CONFIG_VMAP is not enabled.
> >
> > VMAP is widely used in ALTERNATIVE feature to remap a range of memory
> > with new memory attributes. Since this is highly dependent on virtual
> > address translation, we choose to fold VMAP in MMU system.
> >
> > In this patch, we introduce a new Kconfig CONFIG_HAS_VMAP, and make it
> > only support in MMU system on ARM architecture. And ALTERNATIVE now
> > depends on VMAP.
> >
> > HARDEN_BRANCH_PREDICTOR is now gated on MMU as speculative
> > attacks are not possible on non MMU based systems (ie Cortex-R52, R82).
> > See 
> > https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability.
> I don't have a strong opinion on whether it should be split. But I do 
> agree this deserves a bit more explanation.
> Also, as I mentioned before, speculative attacks may be possible on 
> non-MMU based systems. In fact some the Cortex-R are in the affected 
> list... The R82 and R52 are not listed, but note:
> "For information about any unlisted processors please contact Arm".
>
> So how about the following explanation:
>
> "At the moment, the users of HARDEN_BRANCH_PREDICTOR requires to use 
> the vmap() to update the exceptions vectors. While it might be 
> possible to rework the code, it is believed that speculative attackes 
> would be difficult to exploit on non-MMU because the software is 
> tightly controlled. So for now make HARDEN_PREDICTOR to depend on the 
> !MMU.
This makes sense. However, I think you mean

..... make HARDEN_BRANCH_PREDICTOR to depend on the **MMU**.

> > Also took the opportunity to remove "#ifdef VMAP_VIRT_START .. endif"
> > from vmap.c. Instead vmap.c is compiled when HAS_VMAP is enabled. Thus,
> > HAS_VMAP is now enabled from x86, ppc and riscv architectures as all of
> > them use MMU and has VMAP_VIRT_START defined.
> >
> > Signed-off-by: Penny Zheng <penny.zheng@xxxxxxx>
> > Signed-off-by: Wei Chen <wei.chen@xxxxxxx>
> > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
> With the typo pointed out by Jan:
Yes, I will use HAS_VMAP.

 I will update the commit message as below. Let me know if this makes 
sense.
```
xen: make VMAP support in MMU system only

Introduce CONFIG_HAS_VMAP which is selected by the architectures that
use MMU. vm_init() does not do anything if CONFIG_HAS_VMAP is not
enabled.

HAS_VMAP is widely used in ALTERNATIVE feature to remap a range of
memory with new memory attributes. Since this is highly dependent on
virtual address translation, we choose to fold HAS_VMAP in MMU. And
ALTERNATIVE depends on HAS_VMAP.

At the moment, the users of HARDEN_BRANCH_PREDICTOR requires to use the
vmap() to update the exceptions vectors. While it might be possible to
rework the code, it is believed that speculative attackes would be
difficult to exploit on non-MMU because the software is tightly
controlled. So for now make HARDEN_BRANCH_PREDICTOR to depend on the
MMU.

Also took the opportunity to remove "#ifdef VMAP_VIRT_START .. endif"
from vmap.c. Instead vmap.c is compiled when HAS_VMAP is enabled. Thus,
HAS_VMAP is now enabled from x86, ppc and riscv architectures as all of
them use MMU and has VMAP_VIRT_START defined.

```

- Ayan

> Acked-by: Julien Grall <jgrall@xxxxxxxxxx>
>
> Cheers,