xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: security@xenproject.org
Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com,
	Julien Grall <jgrall@amazon.com>,
	Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org,
	Volodymyr_Babchuk@epam.com
Subject: Re: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call
Date: Thu, 18 Jun 2020 18:46:07 +0100	[thread overview]
Message-ID: <0ae27312-f8ab-e3b6-fbaa-a4aba4905405@xen.org> (raw)
In-Reply-To: <20200616175913.7368-3-julien@xen.org>



On 16/06/2020 18:59, Julien Grall wrote:
> From: Julien Grall <jgrall@amazon.com>
> 
> SMC call will update some of registers (typically only x0) depending on
> the arguments provided.
> 
> Some CPUs can speculate past a SMC instruction and potentially perform
> speculative access to emrmoy using the pre-call values before executing
> the SMC.
> 
> There is no known gadget available after the SMC call today. However
> some of the registers may contain values from the guest and are expected
> to be updated by the SMC call.
> 
> In order to harden the code, it would be better to prevent straight-line
> speculation from an SMC. Architecturally executing the speculation
> barrier after every SMC can be rather expensive (particularly on core
> not SB). Therefore we want to mitigate it diferrently:
> 
>      * For arm_smccc_1_0_smc, we can avoid a speculation barrier right
>      after the SMC instruction and instead rely on the one after eret.
>      * For arm_smccc_1_1_smc, we can place a B instruction after the SMC
>      instruction to skip the barrier.
> 
> Note that arm_smccc_1_0_smc version on arm32 is just an alias to
> arm_smccc_1_1_smc.
> 
> Note that no speculation barrier has been added after the SMC
> instruction in arm64/entry.S. This is fine because the call is not
> expected to modify any registers. So straight-line speculation doesn't
> matter.
> 
> Signed-off-by: Julien Grall <jgrall@amazon.com>
> 
> ---
> 
> Note this hasn't been vetted by Arm but they are using the same
> sort of mitigation for blr. So I am quite confident this could do the
> trick.

Actually there is some unknown on whether this may introduce issue on 
other sort of speculation. As there is no known reveal gadge after the 
SMC call and this is only about prevention, I will withdraw this patch 
for the time being.

Patch #1 is still valid though.

Cheers,

-- 
Julien Grall


      parent reply	other threads:[~2020-06-18 17:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 17:59 [PATCH 0/2] xen/arm: Mitigate straight-line speculation Julien Grall
2020-06-16 17:59 ` [PATCH 1/2] xen/arm: entry: Place a speculation barrier following an ret instruction Julien Grall
2020-06-16 21:24   ` Stefano Stabellini
2020-06-17 16:23     ` Julien Grall
2020-07-04 16:07       ` Julien Grall
2020-08-18 16:35         ` Bertrand Marquis
2020-08-18 16:43           ` Julien Grall
2020-08-18 17:06             ` Bertrand Marquis
2020-08-18 17:34               ` Julien Grall
2020-08-19  7:59                 ` Bertrand Marquis
2020-08-19  8:02                   ` Jan Beulich
2020-08-19  8:50                     ` Julien Grall
2020-08-19  8:58                       ` Jan Beulich
2020-08-19  9:56                         ` Julien Grall
2020-06-16 17:59 ` [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call Julien Grall
2020-06-16 21:34   ` Stefano Stabellini
2020-06-16 21:57     ` Julien Grall
2020-06-16 23:16       ` Andrew Cooper
2020-06-16 23:27         ` Stefano Stabellini
2020-06-18 17:46   ` Julien Grall [this message]

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=0ae27312-f8ab-e3b6-fbaa-a4aba4905405@xen.org \
    --to=julien@xen.org \
    --cc=Andre.Przywara@arm.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=jgrall@amazon.com \
    --cc=paul@xen.org \
    --cc=security@xenproject.org \
    --cc=sstabellini@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).