All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Ayan Kumar Halder <ayankuma@amd.com>,
	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 15:04:21 +0200	[thread overview]
Message-ID: <d68440cd-32b4-4221-a569-ba1b7530781c@suse.com> (raw)
In-Reply-To: <597b358e-3b45-4fba-922d-31208b55d15a@amd.com>

On 14.08.2024 14:33, Ayan Kumar Halder wrote:
> On 14/08/2024 12:35, Jan Beulich wrote:
>> On 14.08.2024 12:55, Ayan Kumar Halder wrote:
>>> On 14/08/2024 07:37, Jan Beulich wrote:
>>>> 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.
>>> AFAIU, to address 'Spectre' like vulnerabilities 'branch hardening' was
>>> added.
>>>
>>> See https://lore.kernel.org/all/E1fNadD-0000fz-9r@rmk-PC.armlinux.org.uk/
>>>
>>> And from
>>> https://lists.linaro.org/archives/list/linux-stable-mirror@lists.linaro.org/message/F4MGL4WT2R7T54NLRDGKFRQNSXF3DZGD/
>>>
>>> Spectre is valid on MMU based systems.
>> Since then various other issues / flavors were found. I've been focusing
>> on the x86 side of things, but I'd be very surprised if some didn't
>> affect other architectures as well.
> 
> We are talking about Arm here as "HARDEN_BRANCH_PREDICTOR" is specific 
> to Arm.
> 
> https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability 
> covers all the flavours and it does not include Cortex-R82 or R52.
> 
> It says the following :-
> 
> "Cortex-R cores typically use a closed software stack. In those 
> environments, applications or processes are strictly controlled, and 
> therefore not exploitable"
> 
>> Plus branch hardening can be a pre-
>> cautionary measure, too, I think.
> 
> The first two Arm non MMU cores that we wish to support in the 
> forthcoming series is Cortex-R82 and R52.
> 
> As seen in https://developer.arm.com/documentation/ka005109/latest/, it 
> explicitly states the following about R82
> 
> The Cortex-R82 implements the faulting feature (FEAT_FPAC) but is not 
> vulnerable. The Cortex-R82 behaves differently than vulnerable A-class 
> CPUs when speculatively executing past an instruction that authenticates 
> PAC, and that behavior does not allow the attack software to create the 
> "oracle".
> 
> We can re-enable branch hardening if we know there is a valid non MMU 
> Arm core which is vulnerable.
> 
> Let me know if you are ok with the rationale.

I'm okay with any rationale. As indicated, I'm likely missing (large) parts
of the picture here. The connection between the two Kconfig settings merely
seemed questionable to me, hence the comment.

Jan


  reply	other threads:[~2024-08-14 13:04 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
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 [this message]
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=d68440cd-32b4-4221-a569-ba1b7530781c@suse.com \
    --to=jbeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=ayan.kumar.halder@amd.com \
    --cc=ayankuma@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.