Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754313AbeAGSBm (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Sun, 7 Jan 2018 13:01:42 -0500
Received: from mail-lf0-f66.google.com ([209.85.215.66]:46259 "EHLO
        mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754216AbeAGSBk (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 7 Jan 2018 13:01:40 -0500
X-Google-Smtp-Source: ACJfBou2xQXKox3APfP3QhXJzHI3mQoX/HwUO0LvwqcW9AefzxK1/FyesfgDRh2Ap+6Ma8fmLuPLkqIalfcxNrwPQlU=
MIME-Version: 1.0
In-Reply-To: <20180107174714.GE9772@1wt.eu>
References: <e64025e6-9c4f-703d-cb69-29eeb9cc16bd@redhat.com>
 <20180104015920.1ad7b9d3@alans-desktop> <e3a0fa73-1328-aa42-13ea-c670c8d4ac87@redhat.com>
 <1515054014.12987.75.camel@amazon.co.uk> <403e65be-cfd1-fd08-0401-2e26470b63d4@redhat.com>
 <4dde456c-fd15-e768-8876-5844c8b7c455@redhat.com> <alpine.DEB.2.20.1801050153290.2127@nanos>
 <CAL9bgJ8XNJgCtxR6+M+Vm9eDBVZ4Dyi_-Lt-Q1ei9N=TE2c6cg@mail.gmail.com>
 <CAL9bgJ942ekzyCrposr-xPeTNyh==d2JMO5LvvwuSOKQ38BgBw@mail.gmail.com>
 <20180107140138.08a7e8e3@alans-desktop> <20180107174714.GE9772@1wt.eu>
From: Ivan Ivanov <qmastery16@gmail.com>
Date: Sun, 7 Jan 2018 21:01:38 +0300
Message-ID: <CAAaskFB=zLqQxu=Pptdr97WX4TiqNFNPhO7Pc1o6C1aULy5swg@mail.gmail.com>
Subject: Re: Avoid speculative indirect calls in kernel
To: kah.listaddress@gmail.com, Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jon Masters <jcm@redhat.com>,
        "Woodhouse, David" <dwmw@amazon.co.uk>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andi Kleen <andi@firstfloor.org>,
        Greg Kroah-Hartman <gregkh@linux-foundation.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jeff Law <law@redhat.com>, Nick Clifton <nickc@redhat.com>,
        bp@alien8.de
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

Make sure that your patches do not affect AMD CPU,
because they are unaffected by Meltdown vulnerability
for which this "30% slowdown Intel patch" is required

All your security patches regarding Meltdown should be like:
*) if its Intel, it is " cpu_insecure " ==> take a safe and slow route
*) if its AMD, it is " secure cpu " ==> take a normal route

AMD users should not suffer because of Intel screwups.
if Intel is responsible they should accept the CPU returns

Best regards
Ivan Ivanov,
coreboot developer and
open source enthusiast
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table
style="border-top: 1px solid #D3D4DE;">
	<tr>
      <td style="width: 55px; padding-top: 18px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/></a></td>
		<td style="width: 470px; padding-top: 17px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Без вирусов. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
target="_blank" style="color: #4453ea;">www.avast.ru</a> 		</td>
	</tr>
</table>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>

2018-01-07 20:47 GMT+03:00 Willy Tarreau <w@1wt.eu>:
> On Sun, Jan 07, 2018 at 02:01:38PM +0000, Alan Cox wrote:
>> > I disagree. When there are patches that slow execution down up to 30%,
>> > I want to be able to mark a binary as "trusted" so that I can run it
>>
>> It's not a binary that is trusted - it's a binary in a given use case.
>> You could easily have the same binary being run in two situations on the
>> same box at the same time and run just one of them 'trusted'.
>
> That's what I like with the prctl approach. This can end up as a config
> option in the application itself. At least I'd see it like this in
> haproxy. Basically :
>   - start it with enough privileges (always the case to warrant chroot()
>     then setuid())
>
>   - if config option "disable-kpti" is set, run prctl() to disable it.
>
>
> It is sufficiently inconvenient to ensure that it's only done where
> relevant and regardless of the executable itself (ie it should not be
> an xattr on the FS for example).
>
> Willy