From: Penny Zheng <penny.zheng@arm.com>

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.

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@arm.com>
Signed-off-by: Wei Chen <wei.chen@arm.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
Changes from :-

v1 - 1. HARDEN_BRANCH_PREDICTOR is now gated on HAS_VMAP.
2. cpuerrata.c is not gated on HAS_VMAP.

v2 - 1. Introduced CONFIG_VMAP in common/Kconfig.
2. Architectures using MMU select this config.
3. vm_init() now uses CONFIG_VMAP.

v3 - 1. HARDEN_BRANCH_PREDICTOR is now gated on MMU.
2. vmap.c is compiled when CONFIG_HAS_VMAP is enabled.
3. HAS_VMAP is enabled from x86, ppc and riscv architectures. 

 xen/arch/arm/Kconfig   | 4 +++-
 xen/arch/arm/setup.c   | 2 ++
 xen/arch/ppc/Kconfig   | 1 +
 xen/arch/riscv/Kconfig | 1 +
 xen/arch/x86/Kconfig   | 1 +
 xen/common/Kconfig     | 3 +++
 xen/common/Makefile    | 2 +-
 xen/common/vmap.c      | 2 --
 xen/include/xen/vmap.h | 2 ++
 9 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 21d03d9f44..323c967361 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,7 +12,7 @@ config ARM_64
 config ARM
 	def_bool y
 	select FUNCTION_ALIGNMENT_4B
-	select HAS_ALTERNATIVE
+	select HAS_ALTERNATIVE if HAS_VMAP
 	select HAS_DEVICE_TREE
 	select HAS_PASSTHROUGH
 	select HAS_UBSAN
@@ -61,6 +61,7 @@ config PADDR_BITS
 config MMU
 	def_bool y
 	select HAS_PMAP
+	select HAS_VMAP
 
 source "arch/Kconfig"
 
@@ -171,6 +172,7 @@ config ARM_SSBD
 
 config HARDEN_BRANCH_PREDICTOR
 	bool "Harden the branch predictor against aliasing attacks" if EXPERT
+	depends on MMU
 	default y
 	help
 	  Speculation attacks against some high-performance processors rely on
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index cb2c0a16b8..7f686d2cca 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -447,7 +447,9 @@ void asmlinkage __init start_xen(unsigned long boot_phys_offset,
      * It needs to be called after do_initcalls to be able to use
      * stop_machine (tasklets initialized via an initcall).
      */
+#ifdef CONFIG_HAS_ALTERNATIVE
     apply_alternatives_all();
+#endif
     enable_errata_workarounds();
     enable_cpu_features();
 
diff --git a/xen/arch/ppc/Kconfig b/xen/arch/ppc/Kconfig
index f6a77a8200..6db575a48d 100644
--- a/xen/arch/ppc/Kconfig
+++ b/xen/arch/ppc/Kconfig
@@ -2,6 +2,7 @@ config PPC
 	def_bool y
 	select FUNCTION_ALIGNMENT_4B
 	select HAS_DEVICE_TREE
+	select HAS_VMAP
 
 config PPC64
 	def_bool y
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index 259eea8d3b..7a113c7774 100644
--- a/xen/arch/riscv/Kconfig
+++ b/xen/arch/riscv/Kconfig
@@ -3,6 +3,7 @@ config RISCV
 	select FUNCTION_ALIGNMENT_16B
 	select GENERIC_BUG_FRAME
 	select HAS_DEVICE_TREE
+	select HAS_VMAP
 
 config RISCV_64
 	def_bool y
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7ef5c8bc48..1784f01aad 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -29,6 +29,7 @@ config X86
 	select HAS_PIRQ
 	select HAS_SCHED_GRANULARITY
 	select HAS_UBSAN
+	select HAS_VMAP
 	select HAS_VPCI if HVM
 	select NEEDS_LIBELF
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 565ceda741..90268d9249 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -83,6 +83,9 @@ config HAS_SCHED_GRANULARITY
 config HAS_UBSAN
 	bool
 
+config HAS_VMAP
+	bool
+
 config MEM_ACCESS_ALWAYS_ON
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 7e66802a9e..fc52e0857d 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_TRACEBUFFER) += trace.o
 obj-y += version.o
 obj-y += virtual_region.o
 obj-y += vm_event.o
-obj-y += vmap.o
+obj-$(CONFIG_HAS_VMAP) += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
 obj-bin-y += warning.init.o
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index ced9cbf26f..47225fecc0 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -1,4 +1,3 @@
-#ifdef VMAP_VIRT_START
 #include <xen/bitmap.h>
 #include <xen/sections.h>
 #include <xen/init.h>
@@ -427,4 +426,3 @@ void *_xvrealloc(void *va, size_t size, unsigned int align)
 
     return ptr;
 }
-#endif
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index fdae37e950..c1dd7ac22f 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -141,7 +141,9 @@ void *arch_vmap_virt_end(void);
 /* Initialises the VMAP_DEFAULT virtual range */
 static inline void vm_init(void)
 {
+#ifdef CONFIG_HAS_VMAP
     vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
+#endif
 }
 
 #endif /* __XEN_VMAP_H__ */
-- 
2.25.1

Hi Ayan,

On 21/08/2024 13:25, Ayan Kumar Halder wrote:
> From: Penny Zheng <penny.zheng@arm.com>
> 
> 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.

> 
> 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@arm.com>
> Signed-off-by: Wei Chen <wei.chen@arm.com>
> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>

With the typo pointed out by Jan:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall

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@arm.com>
>>
>> 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@arm.com>
>> Signed-off-by: Wei Chen <wei.chen@arm.com>
>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
>
> 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@amazon.com>
>
> Cheers,
>

On 22.08.2024 12:52, Ayan Kumar Halder wrote:
>   I will update the commit message as below. Let me know if this makes 
> sense.

Certainly better. One more question though:

> ```
> 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.

What is "fold HAS_VMAP in MMU"? I see no folding anywhere. My only guess
is that this means to describe the "select HAS_VMAP" being added to MMU.
But then why the word "fold"?

Jan

> 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@amazon.com>
>>
>> Cheers,
>>

Hi Jan,

On 29/08/2024 08:54, Jan Beulich wrote:
> On 22.08.2024 12:52, Ayan Kumar Halder wrote:
>>    I will update the commit message as below. Let me know if this makes
>> sense.
> Certainly better. One more question though:
>
>> ```
>> 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.
> What is "fold HAS_VMAP in MMU"? I see no folding anywhere. My only guess
> is that this means to describe the "select HAS_VMAP" being added to MMU.
> But then why the word "fold"?

Sorry, I used the incorrect word. Rather I should say

"... we choose to make HAS_VMAP selected by MMU. And ALTERNATIVE depends 
..."

- Ayan

On 21.08.2024 14:25, Ayan Kumar Halder wrote:
> From: Penny Zheng <penny.zheng@arm.com>
> 
> 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.

There is a mix of VMAP and HAS_VMAP throughout here. Once that's sorted
I think there'll be redundancy in what is being said, which likely will
want consolidating then, too.

> 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 think that increasingly this wants to be a separate change. It's
entirely unrelated to what the patch's purpose is (or else the
connection isn't clear to me, and also isn't being made in the
description).

Apart from this the code changes look okay to me now.

Jan