All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Cc: xen-devel@lists.xenproject.org, Penny Zheng <penny.zheng@arm.com>,
	Wei Chen <wei.chen@arm.com>,
	sstabellini@kernel.org, bertrand.marquis@arm.com,
	michal.orzel@amd.com, Volodymyr_Babchuk@epam.com, julien@xen.org
Subject: Re: [PATCH v3 2/4] xen: make VMAP only support in MMU system
Date: Wed, 14 Aug 2024 08:37:26 +0200	[thread overview]
Message-ID: <6d333d94-80ad-485c-b024-a45a388b96a4@suse.com> (raw)
In-Reply-To: <20240813171356.46760-3-ayan.kumar.halder@amd.com>

On 13.08.2024 19:13, Ayan Kumar Halder wrote:
> From: Penny Zheng <penny.zheng@arm.com>
> 
> Introduced 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 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.

While I'm not an Arm expert and hence I'm likely missing aspects, I question
the one (Spectre-BHB) vulnerability there to be sufficient to draw a
conclusion towards the usefulness of branch hardening. I would advise
against encoding such a connection in the Kconfig dependencies.

> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -1,6 +1,7 @@
>  config X86_64
>  	def_bool y
>  	select 64BIT
> +	select HAS_VMAP
>  
>  config X86
>  	def_bool y
> @@ -31,6 +32,7 @@ config X86
>  	select HAS_UBSAN
>  	select HAS_VPCI if HVM
>  	select NEEDS_LIBELF
> +	select HAS_VMAP

Why in two places? Also please respect alphabetic sorting here (if this
hunk is kept, which may be the more consistent approach) ...

> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -77,6 +77,9 @@ config HAS_PIRQ
>  config HAS_PMAP
>  	bool
>  
> +config HAS_VMAP
> +	bool
> +
>  config HAS_SCHED_GRANULARITY
>  	bool

... and here.

Jan


  reply	other threads:[~2024-08-14  6:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13 17:13 [PATCH v3 0/4] xen: arm: Split MMU code in preparation for MPU work (part 2) Ayan Kumar Halder
2024-08-13 17:13 ` [PATCH v3 1/4] xen: arm: Add a new helper update_boot_mapping() Ayan Kumar Halder
2024-08-14 12:50   ` Michal Orzel
2024-08-20 11:27     ` Ayan Kumar Halder
2024-08-13 17:13 ` [PATCH v3 2/4] xen: make VMAP only support in MMU system Ayan Kumar Halder
2024-08-14  6:37   ` Jan Beulich [this message]
2024-08-14 10:55     ` Ayan Kumar Halder
2024-08-14 11:35       ` Jan Beulich
2024-08-14 12:33         ` Ayan Kumar Halder
2024-08-14 13:04           ` Jan Beulich
2024-08-16  9:28           ` Michal Orzel
2024-08-16 16:00             ` Ayan Kumar Halder
2024-08-16 16:40           ` Julien Grall
2024-08-19  9:45             ` Ayan Kumar Halder
2024-08-19  9:55               ` Julien Grall
2024-08-19  9:58                 ` Julien Grall
2024-08-20 11:48                   ` Ayan Kumar Halder
2024-08-20 12:51                     ` Jan Beulich
2024-08-19 11:39               ` Jan Beulich
2024-08-19 12:12                 ` Julien Grall
2024-08-19 12:24                   ` Jan Beulich
2024-08-19 13:01                     ` Julien Grall
2024-08-13 17:13 ` [PATCH v3 3/4] xen: arm: Move the functions of domain_page to MMU specific Ayan Kumar Halder
2024-08-14 12:59   ` Michal Orzel
2024-08-13 17:13 ` [PATCH v3 4/4] xen: arm: Enclose access to EL2 MMU specific registers under CONFIG_MMU Ayan Kumar Halder
2024-08-14 13:07   ` Michal Orzel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d333d94-80ad-485c-b024-a45a388b96a4@suse.com \
    --to=jbeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=ayan.kumar.halder@amd.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=penny.zheng@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.chen@arm.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.