[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 5/6] x86: guard against straight-line speculation past RET


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Thu, 8 Oct 2020 18:28:22 +0200
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 08 Oct 2020 16:28:41 +0000
  • Ironport-sdr: k0o/W4GWV460WRM5Azj6t6ibq/hfQ3CzdGWx7dnMHnQ9lwsnT1bEu4GWac5fG5nBioMjSVQkau bxAO83kJ0RRk5iNyK24iKI14GBQbFHvb6p1ZYNX0oU31yzXTnDflnAOT1JqSuxzKAzU5R6RnNt LWVrGScrZn2wBO4xRGzq1dtN0QBkY6Jf24WivDO9L9a17g1xmPM6MwShunTB6KJt9Xhsf4ttT+ PMPZ6974VCq91rT7128q/wWHFb4ExMwEm6psEWS02nlAAdOIHrQVmTafLl/pn9GVkTvzXBZXZ/ Odk=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Sep 28, 2020 at 02:31:49PM +0200, Jan Beulich wrote:
> Under certain conditions CPUs can speculate into the instruction stream
> past a RET instruction. Guard against this just like 3b7dab93f240
> ("x86/spec-ctrl: Protect against CALL/JMP straight-line speculation")
> did - by inserting an "INT $3" insn. It's merely the mechanics of how to
> achieve this that differ: A set of macros gets introduced to post-
> process RET insns issued by the compiler (or living in assembly files).
> 
> Unfortunately for clang this requires further features their built-in
> assembler doesn't support: We need to be able to override insn mnemonics
> produced by the compiler (which may be impossible, if internally
> assembly mnemonics never get generated), and we want to use \(text)
> escaping / quoting in the auxiliary macro.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Code LGTM.

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

See below for the TBD.

> ---
> TBD: Should this depend on CONFIG_SPECULATIVE_HARDEN_BRANCH?

I don't see the additions done in 3b7dab93f240 being guarded by
CONFIG_SPECULATIVE_HARDEN_BRANCH, so in that regard I would say no.
However those are already guarded by CONFIG_INDIRECT_THUNK so it's
slightly weird that the addition of such protections cannot be turned
off in any way.

I would be fine with having the additions done in 3b7dab93f240
protected by CONFIG_SPECULATIVE_HARDEN_BRANCH, and then the additions
done here also.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.