From: Penny Zheng <penny.zheng@arm.com>
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
depend on VMAP.
HARDEN_BRANCH_PREDICTOR is now gated on HAS_VMAP 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.
Split "https://patchwork.kernel.org/project/xen-devel/patch/20230626033443.2943270-16-Penny.Zheng@arm.com/"
into Arm specific
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.
xen/arch/arm/Kconfig | 7 ++++++-
xen/arch/arm/setup.c | 2 ++
xen/include/xen/vmap.h | 2 ++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 21d03d9f44..7d1dde89d7 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
@@ -58,9 +58,13 @@ config PADDR_BITS
default 40 if ARM_PA_BITS_40
default 48 if ARM_64
+config HAS_VMAP
+ def_bool y
+
config MMU
def_bool y
select HAS_PMAP
+ select HAS_VMAP
source "arch/Kconfig"
@@ -171,6 +175,7 @@ config ARM_SSBD
config HARDEN_BRANCH_PREDICTOR
bool "Harden the branch predictor against aliasing attacks" if EXPERT
+ depends on HAS_VMAP
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/include/xen/vmap.h b/xen/include/xen/vmap.h
index fdae37e950..4c7dfe58ba 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_MMU
vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
+#endif
}
#endif /* __XEN_VMAP_H__ */
--
2.25.1On 08.08.2024 14:09, Ayan Kumar Halder wrote:
> @@ -58,9 +58,13 @@ config PADDR_BITS
> default 40 if ARM_PA_BITS_40
> default 48 if ARM_64
>
> +config HAS_VMAP
> + def_bool y
With this being always enabled, ...
> config MMU
> def_bool y
> select HAS_PMAP
> + select HAS_VMAP
.. what use is this?
> --- 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_MMU
> vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
> +#endif
> }
What about non-Arm, which all have MMUs but no corresponding Kconfig
setting? And why is this not CONFIG_HAS_VMAP anyway (with HAS_VMAP
properly moved to common/Kconfig, where e.g. HAS_PMAP also lives,
and then unconditionally selected by all other architectures)?
Jan
Hi Jan,
On 08/08/2024 13:49, Jan Beulich wrote:
> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>> @@ -58,9 +58,13 @@ config PADDR_BITS
>> default 40 if ARM_PA_BITS_40
>> default 48 if ARM_64
>>
>> +config HAS_VMAP
>> + def_bool y
> With this being always enabled, ...
I had to define the config somewhere. It seemed this is the correct
place to define as HAS_VMAP will be turned off when MPU is introduced.
So, it will be
config HAS_VMAP
def_bool n
At that time, only MMU will select HAS_VMAP.
>
>> config MMU
>> def_bool y
>> select HAS_PMAP
>> + select HAS_VMAP
> .. what use is this?
>
>> --- 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_MMU
>> vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>> +#endif
>> }
> What about non-Arm, which all have MMUs but no corresponding Kconfig
> setting?
AFAICS , the only file that is of our concern xen/common/vmap.c It is
enclosed with VMAP_VIRT_START which is defined in mmu specific file
(xen/arch/arm/include/asm/mmu/layout.h).
So, it will not be compiled for Arm MPU arch.
> And why is this not CONFIG_HAS_VMAP anyway (with HAS_VMAP
> properly moved to common/Kconfig, where e.g. HAS_PMAP also lives,
> and then unconditionally selected by all other architectures)?
I am not sure why CONFIG_HAS_VMAP should be moved to common/Kconfig when
it will be selected/deselected only for Arm architecture.
- Ayan
>
> Jan
On 08.08.2024 17:50, Ayan Kumar Halder wrote:
> On 08/08/2024 13:49, Jan Beulich wrote:
>> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>> default 40 if ARM_PA_BITS_40
>>> default 48 if ARM_64
>>>
>>> +config HAS_VMAP
>>> + def_bool y
>> With this being always enabled, ...
>
> I had to define the config somewhere. It seemed this is the correct
> place to define as HAS_VMAP will be turned off when MPU is introduced.
>
> So, it will be
>
> config HAS_VMAP
>
> def_bool n
>
> At that time, only MMU will select HAS_VMAP.
Well, but why is it not simply
config HAS_VMAP
bool
from the very beginning? (There should never be "def_bool n" imo, btw.)
>>> --- 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_MMU
>>> vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>>> +#endif
>>> }
>> What about non-Arm, which all have MMUs but no corresponding Kconfig
>> setting?
>
> AFAICS , the only file that is of our concern xen/common/vmap.c It is
> enclosed with VMAP_VIRT_START which is defined in mmu specific file
> (xen/arch/arm/include/asm/mmu/layout.h).
>
> So, it will not be compiled for Arm MPU arch.
Yet that wasn't my question. I asked about non-Arm, for all of which it
looks like you're changing behavior of vm_init() (by suddenly making it
do nothing).
>> And why is this not CONFIG_HAS_VMAP anyway (with HAS_VMAP
>> properly moved to common/Kconfig, where e.g. HAS_PMAP also lives,
>> and then unconditionally selected by all other architectures)?
>
> I am not sure why CONFIG_HAS_VMAP should be moved to common/Kconfig when
> it will be selected/deselected only for Arm architecture.
Because you will want to use that (not MMU) in vm_init().
Jan
Hi Jan,
On 09/08/2024 10:34, Jan Beulich wrote:
> On 08.08.2024 17:50, Ayan Kumar Halder wrote:
>> On 08/08/2024 13:49, Jan Beulich wrote:
>>> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>>>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>>> default 40 if ARM_PA_BITS_40
>>>> default 48 if ARM_64
>>>>
>>>> +config HAS_VMAP
>>>> + def_bool y
>>> With this being always enabled, ...
>> I had to define the config somewhere. It seemed this is the correct
>> place to define as HAS_VMAP will be turned off when MPU is introduced.
>>
>> So, it will be
>>
>> config HAS_VMAP
>>
>> def_bool n
>>
>> At that time, only MMU will select HAS_VMAP.
> Well, but why is it not simply
>
> config HAS_VMAP
> bool
>
> from the very beginning? (There should never be "def_bool n" imo, btw.)
>
>>>> --- 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_MMU
>>>> vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>>>> +#endif
>>>> }
>>> What about non-Arm, which all have MMUs but no corresponding Kconfig
>>> setting?
>> AFAICS , the only file that is of our concern xen/common/vmap.c It is
>> enclosed with VMAP_VIRT_START which is defined in mmu specific file
>> (xen/arch/arm/include/asm/mmu/layout.h).
>>
>> So, it will not be compiled for Arm MPU arch.
> Yet that wasn't my question. I asked about non-Arm, for all of which it
> looks like you're changing behavior of vm_init() (by suddenly making it
> do nothing).
Oh now I see what you mean. There is no CONFIG_MMU is x86 , yet it is
used to enclose a common code which is a mistake.
So, we should introduce HAS_VMAP in xen/common/Kconfig and select it
from X86, X86_64 and Arm.
Is my understanding correct ?
- Ayan
On 12.08.2024 18:02, Ayan Kumar Halder wrote:
> Hi Jan,
>
> On 09/08/2024 10:34, Jan Beulich wrote:
>> On 08.08.2024 17:50, Ayan Kumar Halder wrote:
>>> On 08/08/2024 13:49, Jan Beulich wrote:
>>>> On 08.08.2024 14:09, Ayan Kumar Halder wrote:
>>>>> @@ -58,9 +58,13 @@ config PADDR_BITS
>>>>> default 40 if ARM_PA_BITS_40
>>>>> default 48 if ARM_64
>>>>>
>>>>> +config HAS_VMAP
>>>>> + def_bool y
>>>> With this being always enabled, ...
>>> I had to define the config somewhere. It seemed this is the correct
>>> place to define as HAS_VMAP will be turned off when MPU is introduced.
>>>
>>> So, it will be
>>>
>>> config HAS_VMAP
>>>
>>> def_bool n
>>>
>>> At that time, only MMU will select HAS_VMAP.
>> Well, but why is it not simply
>>
>> config HAS_VMAP
>> bool
>>
>> from the very beginning? (There should never be "def_bool n" imo, btw.)
>>
>>>>> --- 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_MMU
>>>>> vm_init_type(VMAP_DEFAULT, (void *)VMAP_VIRT_START, arch_vmap_virt_end());
>>>>> +#endif
>>>>> }
>>>> What about non-Arm, which all have MMUs but no corresponding Kconfig
>>>> setting?
>>> AFAICS , the only file that is of our concern xen/common/vmap.c It is
>>> enclosed with VMAP_VIRT_START which is defined in mmu specific file
>>> (xen/arch/arm/include/asm/mmu/layout.h).
>>>
>>> So, it will not be compiled for Arm MPU arch.
>> Yet that wasn't my question. I asked about non-Arm, for all of which it
>> looks like you're changing behavior of vm_init() (by suddenly making it
>> do nothing).
>
> Oh now I see what you mean. There is no CONFIG_MMU is x86 , yet it is
> used to enclose a common code which is a mistake.
>
> So, we should introduce HAS_VMAP in xen/common/Kconfig and select it
> from X86, X86_64 and Arm.
>
> Is my understanding correct ?
Almost. On Arm the select would be conditional, depending on (or simply
from) MMU.
Jan
© 2016 - 2024 Red Hat, Inc.