linux-kernel - Re: [PATCH v3] Documentation: Add section about CPU vulnerabilities for Spectre

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <95881c0e-5849-9062-a0c5-eb55081a06aa@linux.intel.com>
Date:   Tue, 18 Jun 2019 13:05:43 -0700
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Jon Masters <jcm@...hat.com>, Thomas Gleixner <tglx@...utronix.de>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jonathan Corbet <corbet@....net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ben Greear <greearb@...delatech.com>, stable@...r.kernel.org,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Jiri Kosina <jikos@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Waiman Long <longman9394@...il.com>,
        Borislav Petkov <bp@...en8.de>,
        Mark Gross <mgross@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: [PATCH v3] Documentation: Add section about CPU vulnerabilities
 for Spectre

On 6/17/19 1:30 PM, Jon Masters wrote:
> On 6/17/19 4:22 PM, Jon Masters wrote:
> 
>>> +   For kernel code that has been identified where data pointers could
>>> +   potentially be influenced for Spectre attacks, new "nospec" accessor
>>> +   macros are used to prevent speculative loading of data.
>>
>> Maybe explain that nospec (speculative clamping) relies on the absence
>> of value prediction in the masking (in current hardware). It may NOT
>> always be a safe approach in future hardware, where Spectre-v1 attacks
>> are likely to persist but hardware may speculate about the mask value.
> 
> Something like the Arm CSDB barrier would seem to be potentially useful
> for $FUTURE_X86 as a fence with lighter-weight semantics than an *fence.
> 

Is it necessary to go into such level of implementation details on nospec?
These seem to be appropriate as code comments in nospec for kernel developer.
But for an admin-guide doc, it may confuse sys admin to think that nospec
could not be ineffective.

When new hardware appears that need new implementations of nospec, we should
tweak nospec and not need the admin to worry about such implementation details.

Tim