Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp59803ybb; Tue, 7 Apr 2020 16:51:34 -0700 (PDT) X-Google-Smtp-Source: APiQypJz90sqNz0L2xAN1/3xt7x/xFsiRf5rT+z9ukA185S5RBddKG9p0R5fttLBnRutI7rx9nJg X-Received: by 2002:a9d:548:: with SMTP id 66mr3380833otw.227.1586303494749; Tue, 07 Apr 2020 16:51:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586303494; cv=none; d=google.com; s=arc-20160816; b=eXM3+k8bflE2gKpOWaWfNU97yuMaX6ThU9XYKE38jj7Gl82k5h2/UyUlBHcfBRGlNW 7v9M3/kXQwslHLqWhp+r74uBLtrEG66QQz0RwRKhoEeqZWw4S3ReFZ/lFTJo6N53p2U1 Hy5QQTJRm+UxEhjN0VtN23VmxpWUtWxbepv20Rx4hidB2aQaMqNBnxMJ4S0ygg+nOiu3 N5+Lua6jJnitD8u8z5scgCOdeN5dHK7A0MQtAXvsnp1OfjC1HA6geq3O5wiHi+xYeabp 7gukj6ba0Ushd1VMuvTHJldb3fT59NM+JCWsKwT8JDoQvuSL0/FSU3UBcHfP1XJrEIDR BGGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=zNQsPofakdKV1XM1FmlyU6V+swWJrmCTexeWMiRf3ec=; b=kANU2/ZKKXaemr5GfQdX+Uxg7B54isavPRsMmvq5SLkx84t9SOyxgP+rkWvRicRqTZ 2INQfcxU50RviS+e6HgHKRgepwMziAGblxfG8lQiuTlCsvRFX3ktosWRnyjN4S2y6m2B aZsBA1ZEnrlOP3+alpmCtjSg5tDsuNiqhb9KT3+vhw7gfyPRA2VvFWW7ZebPofEy645f jM8eqJHlDwDrs485xlRlKf+TpHeqYux94Zg16uGCT1HJrg/DvP8sMzFdeJ+lN802DuLX ww1mgbWC7kZHsQ3zMjzdDFv9IT/TXIdCoZHulKSwugfmvh4tEephNal+AAaUPLkVZC27 Rh6A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r184si1205422oie.79.2020.04.07.16.50.56; Tue, 07 Apr 2020 16:51:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726428AbgDGXtu (ORCPT + 99 others); Tue, 7 Apr 2020 19:49:50 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:48679 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726407AbgDGXtu (ORCPT ); Tue, 7 Apr 2020 19:49:50 -0400 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jLxyO-00074q-SG; Wed, 08 Apr 2020 01:49:41 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 1032010069D; Wed, 8 Apr 2020 01:49:40 +0200 (CEST) From: Thomas Gleixner To: "Singh\, Balbir" , "keescook\@chromium.org" Cc: "linux-kernel\@vger.kernel.org" , "tony.luck\@intel.com" , "benh\@kernel.crashing.org" , "jpoimboe\@redhat.com" , "x86\@kernel.org" , "dave.hansen\@intel.com" Subject: Re: [PATCH v2 3/4] arch/x86: Optionally flush L1D on context switch In-Reply-To: <728ba30fdc269d4b24c4fb16832e0151e8270cba.camel@amazon.com> References: <20200406031946.11815-1-sblbir@amazon.com> <20200406031946.11815-4-sblbir@amazon.com> <202004071125.605F665@keescook> <728ba30fdc269d4b24c4fb16832e0151e8270cba.camel@amazon.com> Date: Wed, 08 Apr 2020 01:49:40 +0200 Message-ID: <87y2r6j1pn.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Singh, Balbir" writes: > On Tue, 2020-04-07 at 11:26 -0700, Kees Cook wrote: >> On Mon, Apr 06, 2020 at 01:19:45PM +1000, Balbir Singh wrote: >> > Add arch specific prctl()'s to opt-in to the L1D cache on context switch >> > out, the existing mechanisms of tracking prev_mm via cpu_tlbstate is >> > reused. cond_ibpb() is refactored and renamed into cond_mitigation(). >> >> I still think this should be a generic prctl(). If there is a strong >> reason not to do this, can it be described in the commit log here? > > I can move to prctl() if that is what you prefer, the prctl() can then do arch > specific things. I thought in my question around would other arch's like to do > this, I did not hear anything specific, but I am happy to convert the > interface over. Yes, please. It's just a matter of time that other architectures find this useful. L1D attacks are not restricted to x86 AFAICT. Thanks, tglx