linux-kernel - Re: [RFC PATCH 0/7] x86/intel_rdt: Restoration of Cache Pseudo-Locked regions

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]

Date:   Fri, 3 Aug 2018 08:40:25 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     fenghua.yu@...el.com, Tony Luck <tony.luck@...el.com>,
        vikas.shivappa@...ux.intel.com, gavin.hindman@...el.com,
        jithu.joseph@...el.com, dave.hansen@...el.com, mingo@...hat.com,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH 0/7] x86/intel_rdt: Restoration of Cache Pseudo-Locked
 regions

Hi Thomas,

On 8/3/2018 4:45 AM, Thomas Gleixner wrote:
> On Tue, 24 Jul 2018, Reinette Chatre wrote:
>> A Cache Pseudo-Locked region is vulnerable to certain instructions (INVD,
>> WBINVD, CLFLUSH) or deeper C-states (that could shrink or power off the
>> cache) evicting the pseudo-locked memory. The current support for
>> pseudo-locked regions already restrict deeper C-states on cores associated
>> with the pseudo-locked regions, but the vulnerability to some instructions
>> remain.
>>
>> This work does not prevent the instructions to which Cache Pseudo-Locked
>> regions are vulnerable, instead, this work support the restoration of
>> Cache Pseudo-Locked regions that can be triggered manually by the user
>> or automatically after the WBINVD instruction has been issued.
>>
>> A new debugfs file "pseudo_lock_restore" is associated with each
>> pseudo-locked region and can be used to manually trigger the memory
>> associated with the region to be pseudo-locked to cache again.
> 
> I'm not seeing how that should be used. What's the indication for an
> operator to write to that file?

Our primary indicator would come from the debugfs mechanism that the
user can use to accurately measure how well the data is pseudo-locked.
If that shows that some cache misses are encountered then the user has
the option to lock the data again.

A user may measure the success of a pseudo-lock region right after its
creation or if any performance issues are experienced by the application
that depends on this region. The latter may hint that there could be as
issue with the integration with power savings, a desctructive
instruction made it to the system, or some other cause that needs to be
investigated.

>> The system-wide "native_wbinvd()" is modified to trigger the restoration of
>> all Cache Pseudo-Locked regions after the WBINVD instruction returns and
>> effort is made to avoid any unnecessary work in this flow.
>>
>> Within the kernel two locations with direct invocations of the WBINVD
>> instruction are coverted to native_wbinvd() and compile tested. Neither
>> location is likely to be used on the platforms supporting Cache Pseudo-Locking.
> 
> Can we just get rid of WBINVD?

While directed at me I am not able to answer this. native_wbinvd() is
used in a few areas that appear important to me.

Reinette