[MODERATED] ...

[MODERATED] ...

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 21 bytes --]

Subject: Signing off

[-- Attachment #2: Type: text/plain, Size: 1460 bytes --]

Hello everyone,

Today is my last day at Red Hat after 13.5 years. It's been absolutely
the best time of my life, and I'm going to miss it terribly. There are
many great companies, but I've always thought Red Hat was the best place
to work. It's full of wonderful, imaginative, creative people who do
amazing things every day, not just for revenue, but for the greater
good. That's what enticed me to join and kept me there for so long.

But then came Spectre and Meltdown. I realized over the past couple of
years what I think I'd come to know all along. One of my truest passions
is in computer architecture, and I want to build machines. There is much
I have to learn, and to do that completely I must now follow a different
path for a time. It's bittersweet. I'm happy for the choices I have
made, but I am so sad to leave so many great things behind today.

Leaving Red Hat is very, very hard. I agonized over this for so many
months. I will miss all of you, and I will miss the collaboration on
mitigating vulnerabilities to protect users from harm. Most of all, I
will miss the sense of common purpose I see here among so many great
engineers from across the industry. I wish you good luck. Keep fighting
the good fight, and please keep these efforts alive for as long as they
are necessary. Thomas, Greg, Linus, others: thank you so much.

Until later,

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] ...

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 38 bytes --]

Subject: Re: [PATCH v7 04/10] TAAv7 4

[-- Attachment #2: Type: text/plain, Size: 1216 bytes --]

On 10/22/19 4:02 PM, speck for Luck, Tony wrote:
> On Tue, Oct 22, 2019 at 09:28:20PM +0200, speck for Borislav Petkov wrote:
>> Or, a completely different idea: I wonder if we could merge the two
>> options like we do for l1tf= for example where we have
>>
>> 	l1tf=<opt1>,<opt2>
>>
>> and then do:
>>
>> 	tsx=on,async_abort_full
>> 	tsx=on,async_abort_full,nosmt
>> 	tsx=off
>>
>> That should even diminish the number of combinations because once you've
>> supplied "tsx=off" for example, async_abort doesn't matter.
> 
> At first glance I find that more confusing that helpful.
> 
> Perspective: TAA is an issue that affects ~3 CPU models. It will be
> a non-issue on future models.

This should have been the very first thing mentioned, on the first day.
It's taken a very long time for us to all get on this same page.

> TSX control is a new CPU feature control that happens to begin
> with those three models, but will continue to be present on future
> CPU models.

So this answers my other question. The MSR will be there forevermore.
Meaning that tsx=off has meaning provided you're on a MDS_NO+ part.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] ...

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 38 bytes --]

Subject: Re: [PATCH v7 01/10] TAAv7 1

[-- Attachment #2: Type: text/plain, Size: 1527 bytes --]

On 10/22/19 1:26 PM, speck for Josh Poimboeuf wrote:
> On Mon, Oct 21, 2019 at 01:23:02PM -0700, speck for Pawan Gupta wrote:
>> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>> Subject: [PATCH v7 01/10] x86/tsx: Add enumeration support for IA32_TSX_CTRL
>>  MSR
>>
>> Transactional Synchronization Extensions (TSX) may be used on certain
>> processors as part of a speculative side channel attack.  A microcode
>> update for existing processors that are vulnerable to this attack will
>> add a new MSR, IA32_TSX_CTRL to allow the system administrator the
>> option to disable TSX as one of the possible mitigations.  [Note that
>> future processors that are not vulnerable will also support the
>> IA32_TSX_CTRL MSR].
> 
> This should clarify that not *all* TAA-vulnerable CPUs will get
> IA32_TSX_CTRL, instead only the ones which aren't vulnerable to MDS.

And FYI this is a change from what Intel had originally said. I think
we're all on the same page now that IA32_TSX_CTRL is only going to exist
on a small number of processors (those with MDS_NO=1 vulnerable to TAA).
We need a comprehensive list of designs in flight shared at some point
(privately) too, so that vendors can prepare documentation ahead.

I believe IA32_TSX_CTRL will be implemented going forward, even on next
generation processors without TAA. Please document that this control
interface is going to persist if that is indeed still the plan.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop

[MODERATED] ...

[Jon Masters]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 38 bytes --]

Subject: Re: [PATCH v7 07/10] TAAv7 7

[-- Attachment #2: Type: text/plain, Size: 1614 bytes --]

On 10/21/19 4:29 PM, speck for Pawan Gupta wrote:
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Subject: [PATCH v7 07/10] x86/tsx: Add "auto" option to TSX cmdline parameter
> 
> Platforms which are not affected by X86_BUG_TAA may want the TSX feature
> enabled. Add "auto" option to the TSX cmdline parameter. When tsx=auto
> disable TSX when X86_BUG_TAA is present, otherwise enable TSX.

Earlier, you do this:

+	if (!(ia32_cap & ARCH_CAP_TAA_NO) &&
+	    (boot_cpu_has(X86_FEATURE_RTM) ||
+	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
+		setup_force_cpu_bug(X86_BUG_TAA);

Per the other discussion, I think you want to double check if tsx=auto
is doing what folks want it to do, because currently I think auto still
has the semantics of turning off TSX on everything, rather than just
those cases where a VERW mitigation won't suffice/is in use.

(see Thomas's update to the "Re: [PATCH v5 08/11] TAAv5 8" diagram)

It seems that it's a good time to double check if that's what everyone
on the distro side is expecting, namely "tsx=auto will disable TSX
automatically on those parts impacted by TAA for which VERW mitigation
is not available". This seems to reduce the set where we end up
disabling TSX essentially to a few very recent processors (e.g.
CascadeLake some second gen, Bx stepping?). If that's what we are all
expecting/are planning to do, I suspect Red Hat would go with tsx=auto
as a default since the set of impacted processors can be documented.

Anyway, auto isn't right yet.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop