[MODERATED] [patch 0/7] SSB v2.1-jcm

[MODERATED] [patch 0/7] SSB v2.1-jcm

[jcm]

Hi Konrad,

I've taken the liberty of reworking some of the patches with feedback so far.
Please feel free to do whatever you like with these if it helps you, and
you're the owner of the series so review can wait for your next batch.

I didn't include the AMD part. It'll need reworking in any case since you want
to make sure you don't use the X86_FEATURE_MDD like it was. They don't have
that SPEC_CTRL bit. My update adds a synthetic X86_FEATURE_USE_MDD and we
should probably further fix that, and add a similar one for AMD's feature.

The KVM part won't change much so I didn't repost that part either.

Since v2.0:
 - Reworked patches 1-7 with feedback (except for Bosilav's goto comments in #5)

Jon.

[MODERATED] Re: [patch 0/7] SSB v2.1-jcm

[Konrad Rzeszutek Wilk]

On Sun, Apr 22, 2018 at 05:35:23AM -0400, speck for jcm_at_redhat.com wrote:
> Hi Konrad,
> 
> I've taken the liberty of reworking some of the patches with feedback so far.

Thank you. I spent most of the day yesterday and today being outside so
appreciate you doing all the work :-)

In the future - please mangle the subject of the patches in the git tree as
GPG does not encrypt the Subject: header nor the inline GPG
(filename=0006-x86-spec_store_bypass-Provide-boot-parameters-to-sel.patch)
so all the names of the patches are visible.

> Please feel free to do whatever you like with these if it helps you, and
> you're the owner of the series so review can wait for your next batch.

Tomorrow morning. After I enjoy the rocky beach.
> 
> I didn't include the AMD part. It'll need reworking in any case since you want
> to make sure you don't use the X86_FEATURE_MDD like it was. They don't have
> that SPEC_CTRL bit. My update adds a synthetic X86_FEATURE_USE_MDD and we
> should probably further fix that, and add a similar one for AMD's feature.

Borislav wants it to be inline with Intel's MDD so will use the same
name.
> 
> The KVM part won't change much so I didn't repost that part either.
> 
> Since v2.0:
>  - Reworked patches 1-7 with feedback (except for Bosilav's goto comments in #5)
> 
> Jon.

[MODERATED] Re: [patch 0/7] SSB v2.1-jcm

[Borislav Petkov]

On Sun, Apr 22, 2018 at 01:40:44PM -0400, speck for Konrad Rzeszutek Wilk wrote:
> Borislav wants it to be inline with Intel's MDD so will use the same
> name.

Just forget all about MDD and do only two synthetic bits:

X86_FEATURE_STBUF_BYPASS
X86_FEATURE_STBUF_BYPASS_MITIGATE

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[MODERATED] Re: [patch 0/7] SSB v2.1-jcm

[Jon Masters]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

On 04/22/2018 01:40 PM, speck for Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 22, 2018 at 05:35:23AM -0400, speck for jcm_at_redhat.com wrote:
>> Hi Konrad,
>>
>> I've taken the liberty of reworking some of the patches with feedback so far.
> 
> Thank you. I spent most of the day yesterday and today being outside so
> appreciate you doing all the work :-)
> 
> In the future - please mangle the subject of the patches in the git tree as
> GPG does not encrypt the Subject: header nor the inline GPG
> (filename=0006-x86-spec_store_bypass-Provide-boot-parameters-to-sel.patch)
> so all the names of the patches are visible.

Yeah, sorry about that, realized afterward why you'd done "Linux patch",
etc. Will make sure that's changed the next time.

>> Please feel free to do whatever you like with these if it helps you, and
>> you're the owner of the series so review can wait for your next batch.
> 
> Tomorrow morning. After I enjoy the rocky beach.

:)

I'm hoping to have viable patches for IBM POWER and Arm within the next
48 hours as well. I'll be spending today looking at some backports...

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop

[MODERATED] Re: [patch 0/7] SSB v2.1-jcm

[Linus Torvalds]

On Sun, 22 Apr 2018, speck for Jon Masters wrote:
> 
> I'm hoping to have viable patches for IBM POWER and Arm within the next
> 48 hours as well. I'll be spending today looking at some backports...

Is nvidia happy on the arm side? I talked to a distinctly unhappy nvidia 
person the other week.. Not that I know what would work for them.

              Linus

[MODERATED] Re: [patch 0/7] SSB v2.1-jcm

[Jon Masters]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On 04/22/2018 08:13 PM, speck for Linus Torvalds wrote:
> 
> 
> On Sun, 22 Apr 2018, speck for Jon Masters wrote:
>>
>> I'm hoping to have viable patches for IBM POWER and Arm within the next
>> 48 hours as well. I'll be spending today looking at some backports...
> 
> Is nvidia happy on the arm side? I talked to a distinctly unhappy nvidia 
> person the other week.. Not that I know what would work for them.

Yeah, had a lot of conversations with them lately, and we also work
closely together on a few things for future architecture development. A
couple of their folks are in the spectre_meltdown keybase and have been
vocal in drawing attention to the stack attack scenario for SSB (that
being that uarches which won't explicitly match on same base pointer
when comparing a load and store are a lot more susceptible to stack
attack - that's a camp I think Intel are in as well with their uarch,
while AMD will never allow a load from the stack to bypass a store...).

The thing for NVidia (can get you more details elsewhere if useful) is
that their uarch is the closest to Transmeta of any current arches I've
seen. It's all "software to software" as they put it. So they can
implement a store buffer fix, but they can also simply change the
instruction translation layer underneath to have different paths for
userspace (EL0) and kernel (EL1), etc. and they prefer that. This got
confused at some point for "NVidia can't fix it". They can, they just
want to have a more optimized solution than pretty much anyone else is
in a position to implement today. Which is fine. We can fit that into
the Arm CPU errata framework. I've synced with Arm on that bit.

Jon.

P.S. Incidentally, they promised me they would finally upstream their
specific NVidia uarch Spectre-v2 mitigations. On Arm, we added a new SMC
(Secure Monitor Call) for branch predictor invalidation, etc. that is
implemented in the reference Arm Trusted Firmware (ATF). I went around
all of the Arm server companies last fall to make sure they had
implementation plans lined up, and have almost finally gotten done with
the downstream ODM/OEM beatings as well, e.g. HPE are about to finally
ship updated firmware for Cavium-based Apollo 70 servers just in time to
have to rev that again with more mitigations. But c'est la vie.

-- 
Computer Architect | Sent from my Fedora powered laptop