From: Andrew Cooper <andrew.cooper3@citrix.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 3/9] TAA 3
Date: Thu, 24 Oct 2019 23:38:21 +0100 [thread overview]
Message-ID: <832cb284-9852-5cfe-b71c-c3a23b85adc5@citrix.com> (raw)
In-Reply-To: <20191024201748.GL14115@zn.tnic>
[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]
On 24/10/2019 21:17, speck for Borislav Petkov wrote:
> On Thu, Oct 24, 2019 at 09:07:27PM +0100, speck for Andrew Cooper wrote:
>> On Xen, I've juggled things such that we load microcode, then interpret
>> tsx= if the user has provided it (taking care to always write
>> MSR_TSX_CTRL if it is available, to discard whatever settings firmware
>> or kexec left), before querying CPUID.
> Yap, wanna try the same thing, in that exact order.
>
>> Later, the spec-ctrl= interpretation happens, which might choose to turn
>> off TSX due to TAA, which then has to modify MSR_TSX_CTRL and force
>> clear the bits in the policy.
> Well, the kernel doesn't reeval CPUID feature bits in that case because
> it has gone on booting and enabled all kinds of feature supporting code.
> This is the reason why the whole late microcode loading is such a bad
> thing to do.
:)
I don't necessarily disagree, but the customers (who ultimately pay my
salary) want late microcode loading and livepatching, so we've delivered.
>
>> On Haswell and Broadwell, the microcode which turned HLE/RTM off in the
>> pipeline left the LBR MSRs in a state where you can't context switch the
>> value, because they would yield a value via RDMSR which WRMSR faulted
>> on, because the two operations had an asymmetric view of how the top
>> bits of metadata should be interpreted, given some TSX-related metadata
>> and a sign extended linear address.
>>
>> On Skylake where you can't actually turn RTM off, but we may hide
>> FEATURE_RTM/HLE, the above quirk is probably not true.
> Huh? How is that possible? TSX_CTRL has defined only bit 1 there, the CPUID
> enumeration bit, and bit 0 doesn't do any RTM disabling? Srsly?!
Skylake CPUs aren't getting TSX_CTRL, but force setting/clearing bits at
boot will affect later logic. (Unless I'm being blind while reading the
patches, which is a distinct possibility).
>
>> On Cascadelake, who knows? RTM is being turned off in the pipeline, but
>> maybe the HSX/BWX bug has been fixed, or maybe it is being turned off in
>> a different way, or ...
> Right, I guess we'll deal with any perfcounters fallout in public, when
> the stuff releases...
So, I remembered that I had already written a test case for this bug.
Initial experimentation shows that using TSX_CTRL to secure Cascade Lake
doesn't result in Haswell/Broadwell style GP faults, which is good
news. I will be adjusting Xen's logic not to invoke the quirk on more
modern parts.
~Andrew
next prev parent reply other threads:[~2019-10-24 22:38 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 8:20 [MODERATED] [PATCH 0/9] TAA 0 Borislav Petkov
2019-10-23 8:45 ` [MODERATED] [PATCH 1/9] TAA 1 Pawan Gupta
2019-10-24 15:22 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:23 ` Borislav Petkov
2019-10-24 16:42 ` Josh Poimboeuf
2019-10-23 8:52 ` [MODERATED] [PATCH 2/9] TAA 2 Pawan Gupta
2019-10-23 9:01 ` [MODERATED] [PATCH 3/9] TAA 3 Pawan Gupta
2019-10-24 15:30 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:33 ` Borislav Petkov
2019-10-24 16:43 ` Josh Poimboeuf
2019-10-24 17:39 ` Andrew Cooper
2019-10-24 19:45 ` Borislav Petkov
2019-10-24 19:59 ` Josh Poimboeuf
2019-10-24 20:05 ` Borislav Petkov
2019-10-24 20:14 ` Josh Poimboeuf
2019-10-24 20:36 ` Borislav Petkov
2019-10-24 20:43 ` Andrew Cooper
2019-10-24 20:55 ` Borislav Petkov
2019-10-24 20:44 ` Josh Poimboeuf
2019-10-24 20:07 ` Andrew Cooper
2019-10-24 20:17 ` Borislav Petkov
2019-10-24 22:38 ` Andrew Cooper [this message]
2019-10-25 6:03 ` Pawan Gupta
2019-10-25 7:25 ` Borislav Petkov
2019-10-25 7:17 ` Borislav Petkov
2019-10-25 9:08 ` Andrew Cooper
2019-10-27 7:48 ` Borislav Petkov
2019-10-27 7:49 ` [MODERATED] [AUTOREPLY] [MODERATED] [AUTOREPLY] Automatic reply: " James, Hengameh M
2019-10-24 19:47 ` [MODERATED] " Pawan Gupta
2019-10-30 13:28 ` Greg KH
2019-10-30 14:48 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-30 17:24 ` [MODERATED] " Pawan Gupta
2019-10-30 19:27 ` Greg KH
2019-10-30 19:44 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-11-01 9:35 ` Greg KH
2019-11-01 13:15 ` [MODERATED] " Borislav Petkov
2019-11-01 14:33 ` Greg KH
2019-11-01 18:42 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-23 9:30 ` [MODERATED] [PATCH 4/9] TAA 4 Pawan Gupta
2019-10-24 15:32 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:43 ` Borislav Petkov
2019-10-24 17:15 ` Josh Poimboeuf
2019-10-24 17:23 ` Pawan Gupta
2019-10-24 17:27 ` Pawan Gupta
2019-10-24 17:34 ` Josh Poimboeuf
2019-10-24 18:23 ` Andrew Cooper
2019-10-24 18:56 ` Josh Poimboeuf
2019-10-24 18:59 ` Josh Poimboeuf
2019-10-24 19:13 ` Andrew Cooper
2019-10-24 19:49 ` Josh Poimboeuf
2019-10-24 20:48 ` Andrew Cooper
2019-10-25 9:12 ` Andrew Cooper
2019-10-25 0:49 ` Pawan Gupta
2019-10-25 7:36 ` Borislav Petkov
2019-10-23 10:19 ` [MODERATED] [PATCH 5/9] TAA 5 Pawan Gupta
2019-10-24 18:30 ` [MODERATED] " Greg KH
2019-10-23 10:23 ` [MODERATED] [PATCH 6/9] TAA 6 Pawan Gupta
2019-10-23 10:28 ` [MODERATED] [PATCH 7/9] TAA 7 Pawan Gupta
2019-10-24 15:35 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:42 ` Borislav Petkov
2019-10-24 18:20 ` Jiri Kosina
2019-10-24 19:53 ` Borislav Petkov
2019-10-24 20:02 ` Josh Poimboeuf
2019-10-24 20:08 ` Borislav Petkov
2019-10-23 10:32 ` [MODERATED] [PATCH 8/9] TAA 8 Pawan Gupta
2019-10-24 16:03 ` [MODERATED] " Josh Poimboeuf
2019-10-24 17:35 ` Borislav Petkov
2019-10-24 18:11 ` Josh Poimboeuf
2019-10-24 18:55 ` Pawan Gupta
2019-10-25 8:04 ` Borislav Petkov
2019-10-23 10:35 ` [MODERATED] [PATCH 9/9] TAA 9 Michal Hocko
2019-10-24 16:10 ` [MODERATED] " Josh Poimboeuf
2019-10-24 16:58 ` Borislav Petkov
2019-10-25 10:47 ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-25 13:05 ` [MODERATED] " Josh Poimboeuf
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=832cb284-9852-5cfe-b71c-c3a23b85adc5@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=speck@linutronix.de \
/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).