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

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 10 Nov 2020 15:08:56 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8IOmeltT7hFatd+i1U39dua0XWlKFgIOmapkPc/V650=; b=Z/WP+oZthT3YgxyXjvwAwrsDo6R3KmynGzJfh1v335q1y4pSMtyA9q71DzlZRqfEfuPcLkdei1cwjvn9JIbf8dRJAtm1bOrG99ft1ZcKMIUkbGXi9oLfqiHIwiZ212tWr1KK87PLbmP5McWReQJZ2x8t+3zt4RiGy0ID22XQIseRFQ6rz2yxjYqh1ZcIUd9sn9ucsKrlL3VROsDu4sSzU/128gL5pGv12jupJJsJZDWjH9lD99fv2N+7hQCJJ16ir02gJo/SCIygJ5Rp3ko6kGXJ0Kk1MRZTzsf53dC5F3HgXcyLVufLtU0/iZok6BaXUT6OBLDwDEQAWY0d5W1qrw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BciKau0nzy4nz0z6qMVZLBIwWYc+iqAQ/LsWVONVzM5/CrvCnYBFGzAVgyWli5+7+Uva2HuXort5mtL3u9k7d/oSJ9Kn/QExMwDO0KXE32cJS+T/+zAs2qtyJYFxlj8Q+nv3RbC3EWwe9il8yHz+8hU13d9yJ3Hr8rWiWRLN/gQEIrKOZkUs9CjPkYUg7dbMB6xt/xIJdmHt6b6kvkHPkakfalv0+PmQ8dtxPQKKPTo6IT5oyxlgabradJoacOCXKTZw2nwdGVa8URYNMCvT6XJATl50aBQGQRXgbdXvdoHr5F8crdNmyb1x0OiPNgpEqDMe6XD2U/yQLExYjmNkZA==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 10 Nov 2020 14:10:22 +0000
  • Ironport-sdr: G7VR7kDP5V3iIPLn0XsrBiu3nbzshPs6kHk5H3eeTo6pZ5YQ3rdaROV24AnaEo6HqppRULRd1c NnS7USd+dypmyWQxqaEUXBOcB8UV3QgjswUmCFBq96PtoAst5p8c5uSkceuQIfgMEonIqvWqHe PezWCCX05E93u1oUOksIE8GDBNx+GWp+TySVXR92XO76cIjf7doBwULX31hmwMp1VZ9zR8xH0P uZHfpsGnlBNX3pt32CVslSxT0pozyzB5aFD7etHmAyHTmiHpA4QUIowNDWle7i6lNqdEMVL1/L vTQ=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Nov 10, 2020 at 02:19:40PM +0100, Jan Beulich wrote:
> On 10.11.2020 12:16, Roger Pau Monné wrote:
> > On Tue, Nov 10, 2020 at 11:06:46AM +0100, Jan Beulich wrote:
> >> On 10.11.2020 10:31, Roger Pau Monné wrote:
> >>> On Fri, Oct 23, 2020 at 10:38:04AM +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.
> >>>
> >>> Could this have an option to enable/disable at build time?
> >>
> >> Well, a subsequent patch adds a config option for this, which in
> >> the worst case could be turned off. I'm afraid though I'm not
> >> clear about the question, because ...
> >>
> >>> FreeBSD will drop GNU as quite soon from base, and albeit it can be
> >>> installed as a package I would like to be able to build Xen using a
> >>> toolchain based on LLVM exclusively.
> >>
> >> ... it's not clear to me what the implications here are: Are you
> >> saying -no-integrated-as is not going to function anymore, unless
> >> people explicitly install gas? If that's not what you meant to
> >> indicate, then I don't see how building would become impossible.
> > 
> > I'm still inquiring about this, but I would say that when gas is
> > removed from FreeBSD then the 'as' command would be mapped to llvm-as,
> > and thus -no-integrated-as would hit the same issues as the integrated
> > as. So far in Xen we have assumed that -no-integrated-as would
> > fallback to an as capable of doing what the integrated clang as
> > doesn't support, but that might not be the case.
> 
> At which point Xen couldn't be built anyway, I expect. If llvm-as
> isn't sufficiently gas-compatible, we've lost (right now at least).
> 
> > Ideally we would have to re-run the tests with -no-integrated-as, in
> > order to assert that the external as is really capable of what the
> > internal one is not.
> 
> And if it doesn't, what would we do other than failing the build
> (which it would also if we didn't do the 2nd round of checks)?

I would always prefer a clear message (ie: your toolstack is not
capable of building Xen) rather than a weird build time failure.

Also we could maybe disable certain options by default if the
toolstack doesn't have the required support to build them?

Has anyone reported this shortcoming to upstream llvm, so they are
aware and can work on this or maybe provide an alternative way to
achieve the same result?

Thanks, Roger.



 


Rackspace

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