linux-kernel - Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

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: <20190205182651.GB70667@romley-ivt3.sc.intel.com>
Date:   Tue, 5 Feb 2019 10:26:51 -0800
From:   Fenghua Yu <fenghua.yu@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Ricardo Neri <ricardo.neri@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

On Tue, Feb 05, 2019 at 04:43:09PM +0100, Borislav Petkov wrote:
> On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote:
> > This is one of the few times that we're pretty confident that folks will
> > use this.  The reason we're going to this trouble is that the split lock
> > detection is wanted by actual customers, and they want it before it's
> > implemented on a processor with real enumeration.
> >
> > This isn't something we want everybody and their grandma to turn on;
> > it's a rather specialized feature.  It's really only for folks that care
> > about the latency incurred across the entire system on split lock
> > operations.
> 
> ...
> 
> > It's not for developers.  This really is for (somewhat niche) end users
> > that want split lock detection in production.  This is all really an
> > effort to get them running mainline or real distro kernels.
> 
> This all sounds to me like it shouldn't even be mainline but in a
> special, evaluation kernel. If anything, it should be default off and be
> opted-in by a cmdline switch. None of that *cpuid=* toggling dance

In the cover patch, we gave three real usage cases for this feature:

This capability is critical for real time system designers who build
consolidated real time systems. These systems run hard real time
code on some cores and run "untrusted" user processes on some
other cores. The hard real time cannot afford to have any bus lock from
the untrusted processes to hurt real time performance. To date the
designers have been unable to deploy these solutions as they have no
way to prevent the "untrusted" user code from generating split lock and
bus lock to block the hard real time code to access memory during bus
locking.

This capability may also find usage in cloud. A user process with split
lock running in one guest can block other cores from accessing shared
memory during its split locked memory access. That may cause overall
system performance degradation.

Split lock may open a security hole where malicious user code may slow
down overall system by executing instructions with split lock.

In the usage cases, end users (not developers) want to turn on the
feature in their production lines (not evaluation) to detect split lock
issues which can come not only from legacy apps but also from
malicious code or newly started apps any time during run time.

Thanks.

-Fenghua